20483 - Huge fonts resulting from nsFontMetricsGTK.cpp change {ll}

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect, P3)

Description

[tor]

Your change v1.63 to nsFontMetricsGTK.cpp makes the fonts in the
content area about twice as large as they should be.  Backing that
file out to v1.62 makes things appear normal again.

Tested on a 12/1 morning cvs pull on solaris/native.

Possibly useful information:

GFX: dpi=96 t2p=0.0666667 p2t=15 depth=24
nsCollationUnix::Initialize mLocale = C

Comment 1

[Erik van der Poel]

Which Solaris are you using? Are you displaying the app on the same machine?
I.e. you aren't using the $DISPLAY envariable, right? Are you using the
GECKO_FONT_SIZE_FACTOR envariable? How about the browser.screen_resolution pref?

Comment 2

[tor]

Solaris 2.7, local display (:0.0), no GECKO_FONT_SIZE_FACTOR, no
browser.screen_resolution pref.

Comment 3

[Erik van der Poel]

OK, I tested it on Solaris 2.6, and the fonts in the content area did indeed
get larger, but it is now more consistent with the Windows version of Mozilla,
as it should be.

Comment 4

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

If your prefs say ``10 point'', shouldn't we be rendering in 10 point fonts?
(On Windows too?)  I think I'm missing something here.

Comment 5

[Pat Gunn]

The right way to achieve size parity is to change defaults, not to change
the meaning of settings.

Comment 6

[Chris McAfee]

Adding akkana.

Comment 7

[Akkana Peck]

Oh, is this the bug that's causing everything in the editor test page to be
large and boldface on Linux as of this morning?  Good, I was wondering whether
anyone had already filed a bug on that.  So it's Linux as well as Solaris.

Comment 8

[Erik van der Poel]

Shaver, are you actually using the prefs file to set your defaults? If so, what
does it say exactly?

Yes, when the prefs get hooked up properly (they aren't currently), if they say
10pt, this means 10 point, which is not the same as 10 pixels, depending on your
resolution.

One of the inconsistencies between the Windows and Unix versions was that the
Windows version was using the em square to request the font, while the Unix
version was using the bounding box, which is often larger than the em square.

Have any of you actually compared the Windows and Unix versions of Mozilla?

Comment 9

[Erik van der Poel]

OK, I had a look at Akkana's machine, and the font was indeed not only larger
(as intended) but also bolder (unintentional). A quick change in her tree
brought the fonts back to "normal" (non-bold). I will revert that part of the
change until I figure out the boldness (and size) issue.

Comment 10

[Erik van der Poel]

OK, checked in a fix to revert that part of the change.

Comment 11

[tor]

Attachment: Comparison of layout after v1.62 of nsFontMetricsGTK.cpp

Comment 12

[tor]

The change leaves mozilla with a fairly large interline spacing.  Attached
is a comparison image.  On the left is mozilla with v1.62 of
nsFontMetricsGTK.cpp, on the right is the tip (v1.64) version.  The large
interline spacing gives an unprofessional look (my opinion) and uses a fair
bit more screen space.

Comment 13

[Erik van der Poel]

Moving all of my M15s to M16. Please add comments if you disagree.

Comment 14

[Erik van der Poel]

This was fixed a while ago as part of fixing bug 13072. Marking this bug FIXED.