63316 - Modern theme now has huge font

Status: RESOLVED WORKSFORME

(Core :: XUL, defect, P3)

Description

[Travis Ogdon]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.18 i686; en-US; m18) Gecko/20001219
BuildID:    2000121908

The modern theme now has these gigantic,screen filling, fonts. At 1280x1024
Mozilla is maximized, but I still can't read all of the bookmarks in my personal
toolbar. In both Netscape 4.76 and yesterday's build of Mozilla I could read
everything in the personal toolbar folder with the window sized at around
800x600. I see in Bonsai that there were font fixes for bug 16729 with respect
to system fonts, so this is the likely culprit. Is this the way that Mozilla is
intended to look under Linux? If so, is there a way to get it to look like it
used to, or some sort of setting that I'm missing.

I've tried specifying the font from the command line to no avail, reading
through the bug report to 16729 hasn't helped me either...



Reproducible: Always
Steps to Reproduce:
Launch browser

Comment 1

[Håkan Waara]

Reporter, would you please attach a screenshot to this bug? Also, what's your
Mozilla DPI setting?

Comment 2

[Boris Zbarsky [:bzbarsky]]

To add to the previous comment, what's your _actual_ dpi setting (as reported by
xdpyinfo, for example)?

Comment 3

[Travis Ogdon]

Attachment: Screenshot of today's build

Comment 4

[Travis Ogdon]

Attachment: screenshot of yesterday's build

Comment 5

[Travis Ogdon]

Alright, those are too ugly to read... I'll take new ones.

Comment 6

[Travis Ogdon]

Attachment: Better shot of today's build

Comment 7

[Travis Ogdon]

Attachment: Better shot of yesterday's build

Comment 8

[Travis Ogdon]

Mozilla's DPI settings are at 96 dpi (Edit > Prefs > Fonts).

xdpyinfo reports:
resolution:    87x96 dots per inch

Comment 9

[Doron Rosenberg (IBM)]

cc hewitt, who checked in the new modern fonts css 

Comment 10

[Joe Hewitt (gone)]

The problem here is in the Linux implementation of css2 system font fetching.  
Alec Flett has informed me that there are some quirks in the way GTK returns 
system fonts, and currently it is returning the same font setting all the time 
(something like Helvetica 12pt).  

Now that Modern uses system fonts, we should do a better job of getting fonts 
from Linux.  That should probably be a separate bug. CC'ing Alec for more 
comment.

Comment 11

[Alec Flett]

yep, that's the problem. gtk is likely returning helvetica 12pt no matter what
font you ask for.

the problem is that gtk has it's own notion of cascading styles, and what you
basically need to do is create a widget that corresponds to the object that you
need the font for... i.e. if we're asking for the CSS2 "caption" font, then we
need to go create a gtk button, and ask the button what font it is using.

I think it was bryner that told me we're already doing this to get CSS2 system
colors.. Adding Pav and bryner to get their input (maybe there's already a bug)

Comment 12

[R.K.Aa.]

Attachment: 96 dpi different here. Only slightly larger than before

Comment 13

[Keyser Sose]

Marking NEW. This problem is well known and is being worked on. 

Comment 14

[Boris Zbarsky [:bzbarsky]]

*** Bug 63517 has been marked as a duplicate of this bug. ***

Comment 15

[Doron Rosenberg (IBM)]

taking the liberty to nominate for 0.9, and nsbeta1 as well, as they come
together.  This would annoy users a lot if it gets into RTM

Comment 16

[Nicolás Lichtmaier]

Wouldn't it be posible to have the code return a more decent hardcoded value in
Linux? These huge fonts make Mozilla very bad at low resolutions, previously, it
was working very fine.

Comment 17

[Alec Flett]

the hardcoding is being done in gtk+, out side of mozilla's control. It would do
us no good to hardcode a font into mozilla, we're better off just fixing the
problem.
I'm going to reassign to bryner for now, I don't know how this got assigned to
hangas... if anyone else here wants to take this, feel free :)

Comment 18

[Alec Flett]

oops, actually assign to bryner

Comment 19

[Brian Ryner (not reading)]

Sorry for the spam

Comment 20

[Moses Lei]

Note that this only happens if you're using X 100dpi fonts. If you're using
75dpi fonts, Helvetica 12pt is an acceptable size. That's the difference between
attachment 21000 [details] and 21027.

Comment 21

[Brian Ryner (not reading)]

sigh, dpi issues biting us again on unix...

Comment 22

[Moses Lei]

Hm, six votes for a trivial bug? suggest up severity to normal.

So, if I understood correctly, what we need to get the right system font is to:

1. Create a gtk button
2. Ask it what font it's using, and store that value
3. Destroy the button
And repeat for menu, caption and whatever else. Correct?

Comment 23

[Brian Ryner (not reading)]

cc dbaron, he was doing some similar stuff for system colors.

Comment 24

[Peter Trudelle]

->moz0.9.3, but is anyone even seeing this anymore?

Comment 25

[Travis Ogdon]

> moz0.9.3, but is anyone even seeing this anymore?

Yes, I see it every day (stopped using Netscape a couple of weeks ago). Yes, it
annoys me every day.

Comment 26

[Håkan Waara]

Travis, I noticed that you said "Netscape". Do you mean that it's happening in
Netscape 6?

Please try with a nightly build of Mozilla, which you can download by clicking a
link on http://www.mozilla.org . Thanks.

Comment 27

[Travis Ogdon]

Sorry for the confusion I thought I had said I stopped using Netscape, as in I
no longer use Netscape 4.x.

I'm using the nightly build from this morning. I always use the nightly build
(unless it's horribly broken). This has been happening with every nightly build
since I reported the problem. I've used probably just about every nightly build
since reporting it. Nothing has changed, the problem is still there.

I'll create another attachment of the problem as seen in today's build with the
new Modern 3 theme...

Comment 28

[Travis Ogdon]

Attachment: Screenshot of the 2001020108 build

Comment 29

[Joe Hewitt (gone)]

This is definitely still a problem - if I were an everyday Linux user, this
would be enough to drive me away from using Mozilla. Fonts are just too big.

Comment 30

[Brian Ryner (not reading)]

Attachment: this might fix the problem

Comment 31

[Brian Ryner (not reading)]

I have no idea if this patch will actually fix things, since I'm not seeing the
problem myself, but it seems like a reasonable start.  Can someone test it who
is seeing this bug?

Comment 32

[Brian Ryner (not reading)]

One other key piece of information -- for the people are seeing too-large fonts,
are these fonts noticeable larger than the menu font in your other GTK apps?

Comment 33

[Brian Ryner (not reading)]

Attachment: this one doesn't break with non-US locales

Comment 34

[Brian Ryner (not reading)]

My first patch caused hangs/crashes when used with non-US locales.  This fixes
that.  However, it seems that many of the non-US gtkrc files specify fairly
large fonts.

CC'ing erik to see if he has any ideas here.  Should we go ahead and use the
large fonts the gtkrc files specify?

Comment 35

[Travis Ogdon]

I'd love to test this, but I have absolutely no idea how. Do I just download the
source as a tarball, and then do a patch -p0 with this file as the patch source?

Do I need to grab the CVS version, and then???

I'm fine with compiling mozilla (I think), but I have no idea where to begin
with patching the tree. If there's a FAQ on this somewhere, please just point me
there.

For the person who asked the question about other GTK apps... This is only
happening in Mozilla. It didn't used to happen, and I see it in no other GTK apps.

Comment 36

[Brian Ryner (not reading)]

A nightly source tarball will be fine.  Just do:

cd mozilla/gfx/src/gtk
patch -p0 < patchfile       (where patchfile is the path to the patch file)

Then rebuild in gfx/src.

Comment 37

[Erik van der Poel]

bryner: Yes, I think we should just use whatever fonts GTK returns when you call
the APIs properly (as I think you are). If the user doesn't like GTK's defaults,
they can set up their own defaults and/or complain to the GTK developers. That
problem is not in our hands.

Regarding the patch itself, I thought we used the prefix 'g' for global
variables (including "static"), instead of the 's' that you're using.

Comment 38

[pocemit]

bryner: with the second set of patch (fixed for non-us locale as you say), I get
seriously huge fonts (like even bigger than the original). I dont think taht was
intended.  Yes, my ja_JP.eucJP locale gtkrc is set to use fairly small fonts
(8pt or so), and they appear correctly in all other GTK apps.

Comment 39

[Travis Ogdon]

The fonts in the second patch are the correct size for me (ie. nice and small).
I've compared them to other gtk app windows and the fonts match up. I'll attach
a screenshot to show the difference...

Comment 40

[Travis Ogdon]

Attachment: Mozilla window after patch 2 is applied

Comment 41

[Brian Ryner (not reading)]

erik-

One thing I am noticing is that if I write a simple GTK program that creates a
label and gets its style, the font returned (ascent and descent) matches up
exactly with what I get in Mozilla. However, when I actually run my test program
and mozilla side by side, the fonts are visibly larger in Mozilla (with the
locale set to ja_JP.eucjp).  Is there any reason we would be scaling the fonts
in Mozilla after getting the font from gtk, before it's drawn?

Comment 42

[Brian Ryner (not reading)]

Ok, I believe there might be a problem going on here where the native font that
we get from the GTK widget's style is not the same font that gets used to draw
with.  What we're basically doing here is converting our perfectly good X font
into an nsFont (losing all information except font name and pixel size in the
process), then when we need to draw the string, we go back to gfx and ask it to
draw with this font, and it tries to find a "best match" X font.  Not only does
this not give us back the font we want (the one from the GTK widget), it seems
to be a huge waste of work.  I think what we might want to consider here is a
native font "hint" that an nsFont can have.

Comment 43

[Erik van der Poel]

I guess there are several different solutions to this problem. One would be to
add a special native font hint to nsFont, as you say. Another might be to
return the native font (as a void*) in the API that asks for the system font
(instead of returning an nsFont). Yet another solution might be to try to
convert the native font to an nsFont more faithfully so that it can then be
faithfully converted back to a native font again.

Note that there is an additional hitch here. We never got around to solving
bug 20394 in a satisfactory manner (it's pretty hard). Instead, we put in a
kind of workaround where East Asian fonts end up having a minimum size,
currently set to 16 pixels. When Mozilla is running in an East Asian locale
(e.g. Japanese), XUL's UTF-8 documents pick up the locale's language group (ja)
and then ja's min font size rule is applied. This min font size applies to any
font loaded for that document, even a Western font. Anyway, this is the real
reason why you see such large fonts in the Japanese locale.

Korean users have already complained about the min font size of 16px for Korean.
Apparently, Korean users have smaller fonts available, so they would like to
use them. The 16px default is based on the fonts that come with the X Window
System, usually minimally 16px for East Asian. However, if Japanese users now
also have fonts smaller than 16px available to them, they may also want to use
them. (There is at least one 14px ja font; others may be available too.) This
would argue for smaller defaults for the min font sizes in the default prefs
under mozilla/modules/libpref.

Of course, the ideal solution would be to fix bug 20394, but...

Comment 44

[pocemit]

Attachment: screenshot of before, and after the most recent patch in both locales

Comment 45

[Brian Ryner (not reading)]

I think it's probably a safe assumption that if a user has some font set as
their GTK font, they are ok with us using it, regardless of the size.

I'm not sure there is any way to have the conversion to and from nsFont happen
more faithfully if a minimum font size is just going to be applied later on.  I
imagine that this issue brought up in bug 20394 might well be the reason that
larger fonts are the default (even for Western fonts) in East Asian locale gtkrc
files.

Do you think the large amount of work required to fix bug 20394 is something
worth doing at this point, or should we opt for a quicker fix?

Comment 46

[Brian Ryner (not reading)]

erik, it sounds like maybe we really want to fix 20394.  It looks like there was
a plan for doing so, but it just got caught up in the logistics of who is
#including what and the time constraints of NS6 beta.  I don't see any real
reason that bug was marked WONTFIX other than that no one wanted to fix it
before NS6.  So, I'm going to reopen 20394.

Comment 47

[Erik van der Poel]

bryner: It would be great for Unix Mozilla if we could fix bug 20394 in a
satisfactory manner. I'm not sure, but performance of the other platforms (e.g.
Windows and Mac) might be impacted by such a change. We would be getting not
only the width of a string, but also the height of the largest font used by
that string. So there would be some additional computation, and I don't know
how much that would affect performance. One way around that might be to stub
out the height calculation on Windows and Mac, since those platforms aren't
affected as much by this English/Japanese font size disparity.

A very quick and dirty solution would be to just decrease the minimum font size
settings in the default pref file (modules/libpref/src/unix/unix.js).

A slightly less quick and dirty solution would be to dynamically find out what
the minimum size of the default Japanese font is, and use that for ja. This way,
you would end up with e.g. 16px for Korean on a stock X Windows release, but a
smaller size on a real Korean user's machine, since they have downloaded the
more popular, small fonts.

Comment 48

[Nicolás Lichtmaier]

I suffered with this bug for a long time. One day, with a new version of mozilla
everything was huge. Until now, I've fixed it for me! I've just removed the 100
dpi fonts from X fontpath with "xset -fp" and voila!

Comment 49

[kill this account]

Nicolás, what is your display resolution set to?

Comment 50

[Nicolás Lichtmaier]

Initially 100dpi (as the Debian X package comes now), in order to try to make
this work I changed it to 75 dpi (as I have it now), and I also tried the
mozilla dpi pref. No results.
Removing the 100dpi fonts from the X fontpath was the only change I did to fix
this (same system, same dpi, same mozilla binary).

Comment 51

[Travis Ogdon]

Changing the font dpi is not an acceptable "resolution" to the problem as it
breaks the fonts in everything else. All of my GTK apps look fine except for
Mozilla. The patch above is a real start in fixing the problem.

As I understand it, 20394 must be fixed in order for the above patch to not make
things worse for users with non-western locales.

It's really frustrating to me that such a large visual defect has existed for 5+
months. I suppose this would have been marked a blocker, or at least been given
a higher priority if it had been on the windows build... 

Comment 52

[Nicolás Lichtmaier]

This is not a resolution, it's a workaround that doesn't affect the rest of my
system (gnome desktop). And I did not change the font's dpi, I just removed the
100 dpi fonts. I've just thought it could be somebody a hint about what's going
on, as you say, it's amazing how low priority this bug is, and that it could
help all those people who are tracking this bug giving them a workaround.

Comment 53

[kill this account]

Nicolás: would try running with the 100 dpi fonts and NS_FONT_DEBUG=5 

Comment 54

[Mikael Nilsson]

This bug makes Mozilla 100% unusable for me on my 800x600 laptop.
Popup windows are extremely large, most of them covering 150% of
the width or height of my screen, with Ok/Cancel button far below
lower limit of my screen.

This is now the _only_ thing stopping me from using Mozilla all the time.
I think the severity of this bug needs to be raised.

I am using 0.9.1 on a debian unstable system.

removing the 100dpi fonts from font path fixes the problem.

I'm attaching a screenshot of the preferences dialog (this is my whole screen!)
together with a GTK application to show the difference.

/Mikael

Comment 55

[Mikael Nilsson]

Attachment: My whole desktop and the prefs dialog, together with gedit.

Comment 56

[kill this account]

Nicolás: would you kindly try running with the 100 dpi fonts and NS_FONT_DEBUG=9
and attach moz's output to this bug report.

I'd like to know what the font system is being told to do and what it is 
actually doing.

Comment 57

[Nicolás Lichtmaier]

I've run Mozilla with and without the xfonts-100dpi Debian package installed
(restarting the X server in between). Here is the diff of both log files (ie:
from good looking to bad looking):

--- without-100dpi-fonts        Wed Jul  4 11:58:38 2001
+++ with-100dpi-fonts   Wed Jul  4 11:56:22 2001
@@ -21,17 +21,19 @@
 scaled font:_______ monotype-times new roman-iso8859-1
                     desired=16, scaled=16, bitmap=0, nsFontMetricsGTK.cpp 2415
 loaded -monotype-times new roman-medium-r-normal--16-*-0-0-p-*-iso8859-1
-bitmap font:_______ adobe-helvetica-iso8859-1
-                    desired=10, scaled=10, bitmap=10, nsFontMetricsGTK.cpp 2409
-loaded -adobe-helvetica-medium-r-normal--10-100-75-75-p-56-iso8859-1
+outline font:______ -adobe-helvetica-medium-r-normal--%d-*-0-0-p-*-iso8859-1
+                    desired=13, scaled=13, bitmap=0, nsFontMetricsGTK.cpp 2384
+scaled font:_______ adobe-helvetica-iso8859-1
+                    desired=13, scaled=13, bitmap=0, nsFontMetricsGTK.cpp 2415
+loaded -adobe-helvetica-medium-r-normal--13-*-0-0-p-*-iso8859-1
 outline font:______ -monotype-times new
roman-medium-r-normal--%d-*-0-0-p-*-iso8859-1
                     desired=16, scaled=16, bitmap=0, nsFontMetricsGTK.cpp 2384
 scaled font:_______ monotype-times new roman-iso8859-1
                     desired=16, scaled=16, bitmap=0, nsFontMetricsGTK.cpp 2415
 bitmap font:_______ adobe-helvetica-iso8859-1
-                    desired=12, scaled=12, bitmap=12, nsFontMetricsGTK.cpp 2409
-loaded -adobe-helvetica-medium-r-normal--12-120-75-75-p-67-iso8859-1
+                    desired=17, scaled=17, bitmap=17, nsFontMetricsGTK.cpp 2409
+loaded -adobe-helvetica-medium-r-normal--17-120-100-100-p-88-iso8859-1
 bitmap font:_______ adobe-helvetica-iso8859-1
-                    desired=12, scaled=12, bitmap=12, nsFontMetricsGTK.cpp 2409
-loaded -adobe-helvetica-bold-r-normal--12-120-75-75-p-70-iso8859-1
+                    desired=17, scaled=17, bitmap=17, nsFontMetricsGTK.cpp 2409
+loaded -adobe-helvetica-bold-r-normal--17-120-100-100-p-92-iso8859-1

Comment 58

[kill this account]

This is very odd. 
In the 'good' case it asks for 12 and gets 12.
In the 'bad'  case it asks for 17 and gets 17.

 bitmap font:_______ adobe-helvetica-iso8859-1
-                    desired=12, scaled=12, bitmap=12, nsFontMetricsGTK.cpp 2409
-loaded -adobe-helvetica-bold-r-normal--12-120-75-75-p-70-iso8859-1
+                    desired=17, scaled=17, bitmap=17, nsFontMetricsGTK.cpp 2409
+loaded -adobe-helvetica-bold-r-normal--17-120-100-100-p-92-iso8859-1

I'm assuming that the only difference is:
> I've run Mozilla with and without the xfonts-100dpi Debian package installed

I'm presently stumped on the connection between installing a font package and
the *desired* font size changing.

Comment 59

[Travis Ogdon]

I switched to using the _ugly_ 75dpi fonts about a month ago. I despise them,
but they look good in Mozilla, which is really all that matters. 

What ever happened with the patch? Or more importantly, since the fonts are
already broken for everyone unless they're using 75dpi fonts, why hasn't the
patch been applied to the trunk (and yes, when they're that big I consider the
fonts broken)? Does the patch actually make the fonts that much bigger in non-us
locales? 

The test shots in http://bugzilla.mozilla.org/showattachment.cgi?attach_id=33015
look like they were taken on a system with 75 dpi fonts installed, since the
original looks about like what I see now with the 75 dpi fonts in use. I may be
wrong though.

I see that 20394 is marked for 0.9.3. Is it safe to assume that once that's
fixed the above patch can be applied right away? I realize that this is marked
minor, but it's definitely annoying...

Comment 60

[Brian Ryner (not reading)]

The patch does cause some assertions/warnings from GTK that I haven't had time
to track down...

Comment 61

[Brian Ryner (not reading)]

bstell, should you own this bug?

Comment 62

[kill this account]

I'll take this bug. If it is not a Linux font issue I will reassign as
appropiate.

Comment 63

[Travis Ogdon]

FWIW - This is definitely still a problem, and has only gotten worse (bigger
fonts) with the release of XFree86 4.1.0. I'm hoping that some of the work on
bug 99010 will help bug 20394, which will in turn allow work to proceed on this bug.

Comment 64

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

If the problem has to do with the way we've been getting system fonts, the fix
to bug 33313 might help this.

Comment 65

[kill this account]

> The test shots in 
> http://bugzilla.mozilla.org/showattachment.cgi?attach_id=33015
> look like they were taken on a system with 75 dpi fonts installed,

Travis: are you running a Japanese locale?

Comment 66

[Travis Ogdon]

> Travis: are you running a Japanese locale?

Nope, that's why the above patch worked for me so very long ago. I believe that
patch doubled the size of everyone who was in Non-US locales, but it would have
fixed it for everyone else, that's why 20394 was a blocker.


To quote Joe Hewitt:

> This is definitely still a problem - if I were an everyday Linux user, this
> would be enough to drive me away from using Mozilla. Fonts are just too big.

I know at least a dozen people who have switched to 75 dpi fonts to get around
this bug. If you like I can prod all of them to create bugzilla accounts solely
for the purpose of voting for this bug...

Comment 67

[Travis Ogdon]

I didn't check out yesterday's build (after the fix for bug 20394 had landed),
and I just got around to checking out todays. Happily something (I'm assuming
the stuff from the fix for bug 20934) has fixed this bug as well the fonts all
look great at 100 dpi.

Thank you! Thank you! Thank you!

(I'll let someone else confirm that it's working for them and mark this
resolved, perferably someone not using a recently apt-get updated Debian
woody/sid, since there have been a boatload of font changes as of late).

Comment 68

[Alec Flett]

coincidentally, the fix to support CSS system fonts on GTK landed yesterday.

Comment 69

[Frank Tang]

bstell-if you agree to work on this, please mark it ASSIGNED. thanks

Comment 70

[kill this account]

--> ftang

Comment 71

[Frank Tang]

give to shanjian

Comment 72

[Nicolás Lichtmaier]

Comment #67 says that this miught be fixed. It is not. I'm seeing it under Linux.

Comment 73

[Shanjian Li]

accepting

Comment 74

[Travis Ogdon]

Nicolás... I was doing some pre-spring HD cleaning today and thought I'd ditch
my 75dpi fonts since I didn't think that I had them configured as in xfs anymore. 

I removed them, restarted xfs, and relaunched my apps. 

The huge fonts returned, so: 

1. You're right this is still a problem. 
2. Using 75 dpi fonts seems to "fix" it, and recent versions of X (4.1+) seem to
make 75 dpi fonts less ugly.
3. I need to pay better attention to what Debian is doing to my xfs config file
when I hit enter a bunch during apt-get updates...

Comment 75

[kill this account]

Shanjian: this is the "Redhat 7.2 and Xfs and Mozilla" problem and I believe
it needs attention.

Comment 76

[Travis Ogdon]

I wouldn't categorize this as a strictly Redhat or strictly xfs problem. I see
it on Debian and FreeBSD. With or without xfs.

Comment 77

[Shanjian Li]

I have been investigating this problem for 2 days. In my understanding, the size
of the font is derived from GTK widget. That is GTK's setting for japanese
locale. In this specific situation, the UI is in fact in English. Since XUL does
not contains language hint yet, it will be really hard to find a good solution.
Bug 115121 was filed asking for xml:lang support. After that, all XUL (or its
associated DTD or property files) should identify themselves what charset they
are. Then we can display XUL independent of user locale. 

Comment 78

[scottputterman]

Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+,
topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword.  Please send any
questions or feedback about this to [e-mail].  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.

Comment 79

[Shanjian Li]

On en-US locale, this seems work fine now. On japanese locale, the font is a
little bit large, but that is understandable. We need large size to handle
japanese characters. So close this bug for now. 

Comment 80

[Nicolás Lichtmaier]

Having seen that this bug has been closed I reinstalled the 100 dpi version of
the X fonts (see comment 48). Huge fonts still there.

Comment 81

[Nicolás Lichtmaier]

Attachment: Screenshot of build 2002081508

Comment 82

[Nicolás Lichtmaier]

I think this should be closed, after so many years... I haven't had similar problems with Firefox...

Comment 83

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

... and many of the problems described here have actually been fixed, since we now have a reasonably solid GTK system fonts implementation.

Comment 84

[Travis Ogdon]

Yes, all of this got better years ago with the switch to gtk2.