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

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

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

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

Mozilla's DPI settings are at 96 dpi (Edit > Prefs > Fonts). xdpyinfo reports: resolution: 87x96 dots per inch

cc hewitt, who checked in the new modern fonts css

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.

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)

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

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

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

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.

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 :)

oops, actually assign to bryner

Sorry for the spam

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.

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

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?

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

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

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

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.

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

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

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?

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?

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.

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.

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.

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.

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

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?

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.

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

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?

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.

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.

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!

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

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

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

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.

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

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

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.

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

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.

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

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

bstell, should you own this bug?

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

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.

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

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

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

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

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

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

--> ftang

give to shanjian

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

accepting

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

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

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

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.

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 adt@netscape.com. You can search for "Moving bugs not scheduled for a project" to quickly delete this bugmail.

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.

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.

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

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

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