Modern theme now has huge font

RESOLVED WORKSFORME

Status

()

Core
XUL
P3
minor
RESOLVED WORKSFORME
17 years ago
9 years ago

People

(Reporter: Travis Ogdon, Assigned: Shanjian Li)

Tracking

Trunk
mozilla1.2alpha
x86
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(12 attachments)

(Reporter)

Description

17 years ago
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

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

Comment 3

17 years ago
Created attachment 20998 [details]
Screenshot of today's build
(Reporter)

Comment 4

17 years ago
Created attachment 20999 [details]
screenshot of yesterday's build
(Reporter)

Comment 5

17 years ago
Alright, those are too ugly to read... I'll take new ones.
(Reporter)

Comment 6

17 years ago
Created attachment 21000 [details]
Better shot of today's build
(Reporter)

Comment 7

17 years ago
Created attachment 21001 [details]
Better shot of yesterday's build
(Reporter)

Comment 8

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

xdpyinfo reports:
resolution:    87x96 dots per inch

Comment 9

17 years ago
cc hewitt, who checked in the new modern fonts css 

Comment 10

17 years ago
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

17 years ago
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

17 years ago
Created attachment 21027 [details]
96 dpi different here. Only slightly larger than before

Comment 13

17 years ago
Marking NEW. This problem is well known and is being worked on. 
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** 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
Keywords: mozilla0.9, nsbeta1

Comment 16

17 years ago
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

17 years ago
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

17 years ago
oops, actually assign to bryner
Assignee: hangas → bryner
Sorry for the spam
Assignee: bryner → bryner
Status: NEW → ASSIGNED
Component: Themes → XP Toolkit/Widgets
Priority: -- → P3
Target Milestone: --- → mozilla0.9

Comment 20

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

Comment 22

17 years ago
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?
Severity: trivial → minor
cc dbaron, he was doing some similar stuff for system colors.
Target Milestone: mozilla0.9 → mozilla0.9.1

Comment 24

17 years ago
->moz0.9.3, but is anyone even seeing this anymore?
Target Milestone: mozilla0.9.1 → mozilla0.9.3
(Reporter)

Comment 25

17 years ago
> 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

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

Comment 27

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

Comment 28

17 years ago
Created attachment 32820 [details]
Screenshot of the 2001020108 build

Comment 29

17 years ago
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.
Created attachment 32847 [details] [diff] [review]
this might fix the problem
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?
Created attachment 32863 [details] [diff] [review]
this one doesn't break with non-US locales
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?
(Reporter)

Comment 35

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

Keywords: nsCatFood
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

17 years ago
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

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

Comment 39

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

Comment 40

17 years ago
Created attachment 32964 [details]
Mozilla window after patch 2 is applied
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.

Comment 43

17 years ago
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

17 years ago
Created attachment 33015 [details]
screenshot of before, and after the most recent patch in both locales
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.
Depends on: 20394

Comment 47

17 years ago
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

17 years ago
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

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

Comment 50

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

Comment 51

17 years ago
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

17 years ago
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

17 years ago
Nicolás: would try running with the 100 dpi fonts and NS_FONT_DEBUG=5 
Target Milestone: mozilla0.9.3 → mozilla1.0

Comment 54

17 years ago
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

17 years ago
Created attachment 40835 [details]
My whole desktop and the prefs dialog, together with gedit.

Comment 56

17 years ago
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

17 years ago
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

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

Comment 59

17 years ago
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?

Comment 62

16 years ago
I'll take this bug. If it is not a Linux font issue I will reassign as
appropiate.
Assignee: bryner → bstell
Status: ASSIGNED → NEW
(Reporter)

Comment 63

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

Comment 65

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

Comment 66

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

Comment 67

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

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

Comment 69

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

Updated

16 years ago
Blocks: 104166

Comment 70

16 years ago
--> ftang
Assignee: bstell → ftang

Comment 71

16 years ago
give to shanjian
Assignee: ftang → shanjian
(Assignee)

Updated

16 years ago
Keywords: mozilla1.0

Comment 72

16 years ago
Comment #67 says that this miught be fixed. It is not. I'm seeing it under Linux.
(Assignee)

Comment 73

16 years ago
accepting
Status: NEW → ASSIGNED
(Reporter)

Comment 74

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

16 years ago
Shanjian: this is the "Redhat 7.2 and Xfs and Mozilla" problem and I believe
it needs attention.
(Reporter)

Comment 76

16 years ago
I wouldn't categorize this as a strictly Redhat or strictly xfs problem. I see
it on Debian and FreeBSD. With or without xfs.
(Assignee)

Comment 77

16 years ago
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. 
Depends on: 115121

Comment 78

16 years ago
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.
Target Milestone: mozilla1.0 → mozilla1.2
(Assignee)

Comment 79

16 years ago
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. 
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME

Updated

15 years ago
URL: Any
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

Comment 80

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

15 years ago
Created attachment 95422 [details]
Screenshot of build 2002081508

Comment 82

9 years ago
I think this should be closed, after so many years... I haven't had similar problems with Firefox...
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago9 years ago
Resolution: --- → WORKSFORME
... and many of the problems described here have actually been fixed, since we now have a reasonably solid GTK system fonts implementation.
(Reporter)

Comment 84

9 years ago
Yes, all of this got better years ago with the switch to gtk2.
You need to log in before you can comment on or make changes to this bug.