92590 - Problem with XFSTT Font Server and fonts sized in pt

Status: RESOLVED INACTIVE

(Core :: Graphics: Text, defect)

Description

[Rick Branson]

From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.7 i686)
BuildID:    2001072616

Whenever I go to a page that uses CSS, the TrueType fonts served up by XFSTT
scale to massive proportions. That's pretty much it. I don't have this problem
with Netscape 4.76.

Reproducible: Always
Steps to Reproduce:
1. start xfstt, add xfstt's server to the fontpath
2. Start mozilla, go to any site that uses CSS

Actual Results:  The fonts scaled up far too much.

Expected Results:  Produced fonts with a normal size, like Netscape 4.7

Comment 1

[Boris Zbarsky [:bzbarsky]]

A few questions:

1)  What's your DPI setting in NS 4.76?
2)  What's your DPI setting in Mozilla?
3)  What's your actual DPI setting (ie, what resolution are you running and how
    big is your screen?
4)  What happens if you have X itself scale the fonts (if you're using XFree
    4.x) instead of using xfstt?

Comment 2

[Rick Branson]

I can't seem to control the DPI setting in Netscape, but in Mozilla I'm using
72DPI. Even if I try to change this, it stays the same. I'm running 1152x864x24.
The DPI setting that my X server gives me: (--) RADEON(0): DPI set to (292, 68).
If X scales them, they look god awful, they seem to be strangly contorted and
pixelated, CSS or not. XFSTT renders them beautifully.

Comment 3

[Rick Branson]

If you need an example of what they look like when I use CSS, take a look at
http://www.phatlewt.net/screens/mozilla-ttf.png

Comment 4

[Boris Zbarsky [:bzbarsky]]

Rick, note that I did not ask you what DPI setting your X server thinks it's
running at.  Your X server is obviously confused -- unless you have a really
weird display you don't have 292 dpi horizontally and 68 vertically.  What
actual resolution are you using and what monitor size do you have?

Do you see the problem with all CSS-styled fonts?  Or only with the ones for
which a size is set in pt, not px?

Finally, does setting Mozilla's dpi to 96 instead of 72 make the sizes more
correct?

Comment 5

[Rick Branson]

That's what I thought. I'm running 1152x864 with 24-bit color depth on a 19" CRT
(Princeton Graphics AGX 900) Monitor. 

It's just the ones using pt (I did a little test).

No, that doesn't help :/.

Comment 6

[Boris Zbarsky [:bzbarsky]]

OK.  Definitely sounds like the pt -> px conversion is wrong in your case...

Your actual DPI is something like 76 dpi.

Over to layout and setting status to NEW, since we should certainly be creating
about the right font size if Moz is using 72 dpi and the real dpi is 76.

One other thing to try... if you use a 36pt font in CSS, how high are the
letters on your screen when measured with a ruler?  They should be about half an
inch tall...

Comment 7

[Rick Branson]

A 36pt @ in Verdana font is almost exactly an inch and a half.

Thanks for your help, I'm excited that this bug is going to get fixed. I'll
definately report more of the bugs I find like this.

Comment 8

[karnaze (gone)]

Reassigning to ftang.

Comment 9

[Rick Branson]

Some extra information: This problem doesn't exist in the 0.9.1 Release.

Comment 10

[Frank Tang]

bstell- can you quickly look at what happen here?

Comment 11

[kill this account]

Rick,

Can you set the environment variable NS_FONT_DEBUG to 9, do a minimal run
(eg: ./mozilla http://www.cheatingplanet.com), capture moz'z output and
attach it to this bug report.

(dbaron: a fresh example of why I put in (and want to leave in) the debug 
statements)

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

bstell:  The point I made was that NS_FONT_DEBUG is a commons problem, and if we 
had everybody's debug code (NS_HTTP_DEBUG, etc.) then we would have a bloated 
executable.  Maybe the solution is for you to use PR_LOG for this stuff and 
somebody could occasionally provide binaries with NSPR logging turned on?

Comment 13

[Frank Tang]

move to m96

Comment 14

[Frank Tang]

move to m0.9.7 shanjian

Comment 15

[Shanjian Li]

accepting. 

Comment 16

[Shanjian Li]

push to 099

Comment 17

[Shanjian Li]

I could not see any problem on Redhat 7.2. xfs was able to handle ttf.
Is this issue still valid?

Comment 18

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

RH 7.2 uses xfsft, not xfstt.

Comment 19

[Shanjian Li]

reset tm. 

Comment 20

[Frank Tang]

shanjian is no longer working on mozilla for 2 years and these bugs are still
here. Mark them won't fix. If you want to reopen it, find a good owner first. 

Comment 21

[Travis Chase]

Mass Reassign Please excuse the spam

Comment 22

[Travis Chase]

Mass Re-opening Bugs Frank Tang Closed on Wensday March 02 for no reason, all
the spam is his fault feel free to tar and feather him

Comment 23

[Travis Chase]

Reassigning Franks old bugs to Jungshik Shin for triage - Sorry for spam

Comment 24

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:dholbert, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 25

[Daniel Holbert [:dholbert]]

I'm not familiar with XFSTT and don't know whether we'd even have any interaction with it at this point.

But given this bug has been silent for 20 years, I'm assuming it's been fixed or is a non-issue for other reasons. If that's not right, please reopen with more info (or start a fresh bug).