[GTK system fonts]Menu has *huge* font when running gnome 1.4 with custom font

VERIFIED WORKSFORME

Status

SeaMonkey
UI Design
--
major
VERIFIED WORKSFORME
16 years ago
11 years ago

People

(Reporter: Peter Davis, Assigned: dbaron)

Tracking

({qawanted})

Trunk
x86
Linux
qawanted

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [patch])

Attachments

(7 attachments, 1 obsolete attachment)

(Reporter)

Description

16 years ago
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.
(Reporter)

Comment 1

16 years ago
Sorry, messed up the title.
Summary: Menu has *huge* font when running gnome 1.4 with custom fixed-size font → Menu has *huge* font when running gnome 1.4 with custom font
(Reporter)

Comment 2

16 years ago
Created attachment 53234 [details]
A screenshot of this happening - it's kind of funny, really :)

Comment 3

16 years ago
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.
Assignee: pchen → jaggernaut
This is system font stuff.
Assignee: jaggernaut → dbaron
(Assignee)

Comment 6

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

Updated

16 years ago
Summary: Menu has *huge* font when running gnome 1.4 with custom font → [GTK system fonts]Menu has *huge* font when running gnome 1.4 with custom font
(Assignee)

Comment 7

16 years ago
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.
(Reporter)

Comment 8

16 years ago
(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.
(Assignee)

Comment 9

16 years ago
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?
(Reporter)

Comment 10

16 years ago
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.

Comment 11

16 years ago
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
Keywords: qawanted
QA Contact: sairuh → nobody
Peter Davis, is this still a problem?
(Reporter)

Comment 13

16 years ago
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.  ;)
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
Created attachment 75846 [details]
This is the bug happening with galeon. Text entry field.
Created attachment 75847 [details]
This is the bug happening with galeon. Text entry field.
Created attachment 75849 [details]
This is the bug happening with galeon. Text entry field.
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.

Created attachment 75850 [details]
output of NS_FONT_DEBUG=5 mozilla

Using debian woody, mozilla package from unstable.
(Assignee)

Comment 20

16 years ago
Reopening.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
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
Created attachment 75889 [details]
Here's the output of mozilla without the bug.

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

Comment 23

16 years ago
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.

Comment 24

16 years ago
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"
(Reporter)

Comment 26

16 years ago
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.  

Comment 27

16 years ago
Resolving worksforme. If this still occurs in recent builds reopen this bug.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → WORKSFORME

Comment 28

16 years ago
*** 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?
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---

Comment 30

16 years ago
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 (:
(Assignee)

Comment 31

16 years ago
Created attachment 83081 [details] [diff] [review]
who knows, this might fix it...

Comment 32

16 years ago
Is this patch in the nightly builds only, or already in rc2 too?
(Assignee)

Comment 33

16 years ago
It isn't checked in yet, anywhere.
setting status to new since people keep seeing this...
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 35

16 years ago
*** Bug 148630 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 36

15 years ago
Is this still a problem in 1.1beta?

Comment 37

15 years ago
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.

Comment 39

15 years ago
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.
(Assignee)

Comment 40

15 years ago
Created attachment 101478 [details] [diff] [review]
above patch, updated to trunk

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.
Attachment #83081 - Attachment is obsolete: true
(Assignee)

Updated

15 years ago
Whiteboard: [patch]
Comment on attachment 101478 [details] [diff] [review]
above patch, updated to trunk

sr=bzbarsky
Attachment #101478 - Flags: superreview+
Comment on attachment 101478 [details] [diff] [review]
above patch, updated to trunk

r=bryner
Attachment #101478 - Flags: review+
does this need to be done in gtk2 and/or xlib as well?
(Assignee)

Comment 44

15 years ago
No.  xlib doesn't have system fonts and gtk2 forks only the widget code, not the
gfx code.
(Assignee)

Comment 45

15 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 16 years ago15 years ago
Resolution: --- → WORKSFORME
Product: Core → Mozilla Application Suite
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.