From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011011 BuildID: 2001101113 I am running debian woody packages of gnome 1.4. This happens when, in the gnome preferences theme selector, if I choose "use custom font" and then choose any font. After that, if I boot up any of the recent nightlies, the font size for the menu is literally about 5000 points, and the menu bar takes up the entire screen. This does not happen with my 0.9.4 debian package, but happens in all the recent nightlies. I'm too lazy to trace back as far as it will go right now - 2001101113 is as far as I tried and it happens all the way up through today, both in the trunk and in 0.9.5 branch.

Sorry, messed up the title.

WFM. Can you please check your setting under preferences/fonts/display resolution Does setting it to "System setting" improve things? If not, can you please check that your fontpath setting in XF86COnfig(-4) is correct. See bug 100432 for a misconfiguration that showed a similar erronous fontsize

->jag? punt as needed.

This is system font stuff.

Any font? What type of font? TrueType? (If so, which TrueType font server?) PostScript? Bitmap?

No response? Without a response we can't fix the bug. If it's a truetype font and your font server is XFSTT, then this could be a duplicate of bug 92590.

(Sorry for the delayed response). I'm having trouble figuring out what could be causing this. I have two computers that I've tested it on, both running debian unstable and the exact same packages, except on the one that had this bug, at one point I had tried to install Gnome anti-aliasing support. So it turns out that most likely this is on my end. Sorry :) But still, there is the question of why only mozilla is affected.

It's probably a bug in Mozilla exposed by something rather unusual at your end, and it would be good to fix that. But it would help to know what it is that's unusual. Could you have set up xfstt?

To tell you the truth, I really can't remember what I did. But xfstt rings a bell :). I know that whatever I did, I gave up after it didn't work. So probably the problem is that I have a half-installed xfstt.

please the environment variable NS_FONT_DEBUG=5, do a minimal run (eg: ./mozilla http://some.website.com/some_content.html), capture the output, and attach it to this bug

Peter Davis, is this still a problem?

Um, I guess not -- I never figured out what was wrong and it magically went away. Maybe this bug should be closed and then I'll ask to reopen it if I ever figure this out :)

resolving worksforme, pending problem actually being present. ;)

Sorry for my 2 obsolete screenshot attachments, galeon was uploading it properly but hanging on the next page... I have the same bug happening with mozilla 0.9.9 ... so <a href="http://bugzilla.mozilla.org/showattachment.cgi?attach_id=53234">attachment id 53234</a> applies to me, too. Additionally, i am using galeon and this bug seems to appear only in the rendered html, but not in the gui. I have no xfstt running, no obsolete "truetype" dir in my fontpath. I will try to capture mozilla's output with NS_FONT_DEBUG=5 and attach it.

Using debian woody, mozilla package from unstable.

Reopening.

Some more fiddling... and sorry i forgot to put the exact mozilla version into the previous comment... debian/unstable uses mozilla 0.9.9 at the time i am writing this. Looking at the output of NS_FONT_DEBUG=5 mozilla (http://bugzilla.mozilla.org/attachment.cgi?id=75850&action=view) made me think it might have to do something with locale... Some fiddling shows that the font -urw-nimbus sans l-bold-r-condensed does not exist in encoding iso8859-15. But that is what i was using initially, before installing mozilla. This was the output of the locale command on my system: LANG=de_DE@euro LC_CTYPE="de_DE@euro" LC_NUMERIC="de_DE@euro" LC_TIME="de_DE@euro" LC_COLLATE="de_DE@euro" LC_MONETARY="de_DE@euro" LC_MESSAGES="de_DE@euro" LC_PAPER="de_DE@euro" LC_NAME="de_DE@euro" LC_ADDRESS="de_DE@euro" LC_TELEPHONE="de_DE@euro" LC_MEASUREMENT="de_DE@euro" LC_IDENTIFICATION="de_DE@euro" LC_ALL=de_DE@euro Then i tried setting LC_ALL and LANG to "C" and starting mozilla. Voilà! Menus looked normal. Then i tried to reproduce this bug by setting LC_ALL and LANG to "de_DE@euro" again... mozilla started up *drumroll* The fonts in the menus still look normal. Even doing a mv ~/.mozilla /somewhereelse does not reproduce the bug. I had this problem after a fresh install of galeon 1.0.3 on debian/woody. Setting locale to "C" before starting mozilla made it go away, and i cannot make it come back... Errr... go figure? I can't find out how to reproduce this... but honestly i am happy it did go away... As someone on irc channel #mozillazine said: <basic> TauPan: mozilla bugs have the habit of playing hide and seek

Nothing in the mozilla configuration changed, except the stunt with the locale settings described above.

Hmm, I'm seing this neat bug here now.. Both with a cvs build from the weekend and debian unstable 0.9.9 package. I'm running debian unstable (sid), I have truetype fonts (not any fileserver, just added /usr/X11/blabla/fonts/TrueType in my XF86Config file). I see the same problem in galeon, also latest sid package, except the menus look ok there. (it's not just the menus in moz; it's almost all input fields too (but not the textbox, luckily.) The locale trick didn't work for me; it was C from before. changing it to something else didn't help. changing it back from something else didn't help either. I tried a new profile. I tried renaming /etc/mozilla/prefs.js. Nothing seems to help... hoping this will "magically go away" soon, kind of annoying browsing this way.

oh, I forgot to mention, my "theme selector" component in gnomecc is segfaulting on me, might be related. anyway, I foud a workaround: comment out the FontDir entry in XF86Config. and, got this bug also when using moz remotely from my server (X over ssh). Without changing _any_ config thingies on the server.

Peter: does it still happen on 1.0RC1? If not, set the bug to "worksforme"

Worksforme at the moment. This hasn't happened to me in quite some time, and it also hasn't happened since I switched from Debian Unstable to Gentoo.

Resolving worksforme. If this still occurs in recent builds reopen this bug.

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

Reopening since a new bug that happens on current builds was dupped to this. Let's avoid that in the future, ok?

This is still a problem (Bug 142757), this time on Suse 7.3. Here's some ascii art from the reporter: \ type1 on | off truetype\---------------------------------------- | | on | HUGE fonts in | small fonts in | mozilla, chosen | mozilla & other | fonts in other gtk | gtk apps | apps. | --------------------------------------------- | | off | Chosen fonts in | small fonts in | both mozilla and | both mozilla and | other gtk apps | other gtk apps | | By the way: this is my chosen font in gtk: { font="-ult1mo-arial-medium-r-normal-*-*-180-*-*-p-*-iso8859-2" } Now, this isn't very repoduceable, but it's sure as meep is a bug. IIRC, gecko under galeon also did this when I saw it. Galeon's menus were ok, but the rendered html had huge fonts. Roland: Please use the URL on the top of the mail you get to post more feedback. Also, could you try enabling both truetype and type1 again, see if it repoduces reliably? Thanks for your help so far (:

Is this patch in the nightly builds only, or already in rc2 too?

It isn't checked in yet, anywhere.

setting status to new since people keep seeing this...

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

Is this still a problem in 1.1beta?

haven't seen it since march. I'm currently not running gnome btw - blackbox 0.62 on X 4.2 with type1 and true(free)type support.

Haven't seen it either, since my last report. However, you should remember that this was quite hard to reproduce.

We need a way to reproduce this or at least people currently saying that they are having this problem. Lacking either of these I'd recommend we close this for now.

This is the previous patch, updated to the trunk. I may as well get it in since it's the right way to use the APIs according to the documentation.

Comment on attachment 101478 [details] [diff] [review] above patch, updated to trunk sr=bzbarsky

Comment on attachment 101478 [details] [diff] [review] above patch, updated to trunk r=bryner

does this need to be done in gtk2 and/or xlib as well?

No. xlib doesn't have system fonts and gtk2 forks only the widget code, not the gfx code.

Error handling patch checked in, 2002-11-06 04:53 PDT. Marking worksforme per comments above. If anyone is still seeing this problem please report additional details.