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

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?

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.

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

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?

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 :/.

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...

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.

Reassigning to ftang.

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

bstell- can you quickly look at what happen here?

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)

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?

move to m96

move to m0.9.7 shanjian

accepting.

push to 099

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

RH 7.2 uses xfsft, not xfstt.

reset tm.

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.

Mass Reassign Please excuse the spam

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

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