Unix: default UI font very small



20 years ago
14 years ago


(Reporter: thully, Assigned: alecf)



Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nsbeta3-][RTM NEED INFO])


(9 attachments)



20 years ago
I am running Mozilla M4 on Linux, and the default font is tiny!  I do not have
many fonts installed, but that should not affect anything.  I am running RedHat 5.2 with gtk 1.0.6 and 1.1.2 hanging around (should this work?) and kernel
2.0.36.  On the first loading of Mozilla on this configuration, it gave me an error about gtk.  I think this is related to the default font Mozilla picks.


20 years ago
Assignee: troy → kipp


20 years ago
Assignee: kipp → erik


20 years ago
Target Milestone: M5

Comment 1

20 years ago
What is the error message about GTK that you get on first loading?

Also, we are currently working on the default font size. In the meantime, could
you try the following before starting Mozilla:


You can change the number to 2.5 if you want it even bigger.

Comment 2

20 years ago
I do not know, but I have already un-installed that release of Linux because it
was crashing a lot.  It happened especially if I went to the Mail window or
tried to Add a bookmark.


20 years ago
Target Milestone: M5 → M6

Comment 3

20 years ago
I have checked in a change to make the default DPI on Unix (GTK) be 96 (per
peterl@netscape.com). This may improve your situation. Also, in the future
there will be a UI for changing the pixel density. Marking M6 to get it off the
M5 radar.


20 years ago
Summary: On Linux, default font very small. → Unix: default font very small

Comment 4

20 years ago
Thully, have you tried a more recent build?

Comment 5

20 years ago
No, I have not tried a more recent build.  I cannot download 8MB that often with
my speed of connection.


20 years ago
Summary: Unix: default font very small → [PP]Unix: default font very small


20 years ago
Last Resolved: 20 years ago
Resolution: --- → WORKSFORME

Comment 6

20 years ago
Date: Tue, 27 Apr 1999 21:45:04 -0700
From: Erik van der Poel <erik@netscape.com>
Newsgroups: netscape.public.mozilla.gtk, netscape.public.mozilla.unix

I just checked some code into the GTK version of Mozilla to read the
"browser.screen_resolution" preference. This preference can be set in
your prefs file (~/.mozilla/prefs50.js) as follows:

  user_pref("browser.screen_resolution", 120);

The above will set the dpi to 120. If you set the pref to zero (0),
Mozilla will use the X server's dpi value. Note that "viewer" does not
read the prefs file yet, due to an unrelated bug. Use "apprunner" to try

If the pref is not set, it uses the default value of 96.


20 years ago

Comment 7

20 years ago
In the 5/17 Linux Build, the default font size appears correctly.

Comment 8

19 years ago
Created attachment 3828 [details]
A screenshot, showing too-small fonts


19 years ago

Comment 9

19 years ago
This bug is not fixed, despite the bug report.  See the attached screenshot.
The line of menu items above the URL field is especially tiny; hard to read &
hard to hit.

Comment 10

19 years ago
Ooops!  A few further notes.  I have observed this in M12; it must have
regressed.  My X server uses about 100 dpi and is AFAIK properly configured.
The attached GIF, for the problem to be seen, must be viewed at 100 dpi.


19 years ago
Component: Layout → UE/UI

Comment 11

19 years ago
randolph, the screenshot show no problem about this origional bug. Basicailly,
your comment reflect your psonal opinion about the usage of a small size font
for the toolbar menu. This is by-design instead of a software bug. (Although I
totally w/ you that the size is too small- in particular for CJK text).

I reassign this to our UI person to encourage they use bigger font size for ALL
their UI design. Again, this is not a software implementation bug, but a UI
design problem. The origional problem is fixed by erik.


19 years ago
Assignee: erik → shuang

Comment 12

19 years ago
reassign to shung- Is that possible you can use font size > 9 for all the UI design in the futre.Font size <=9 is unreadable for Chinese/Japanese/Korean. Making is adjustable throuth CSS is not a solution since it dramatically increase L10N and QA work and cost.


19 years ago
Resolution: WORKSFORME → ---
Target Milestone: M6 → M14

Comment 13

19 years ago
Clearing WorksForMe Resolution.  Moving from M6 to M14 for Beta since reopened.
shuang, please reset milestone if this is incorrect.


19 years ago
Assignee: shuang → german

Comment 14

19 years ago
reassign to german. german, please make final decision about default font use
for UI before M14. cc other ui folks for consistence considerations they may

Comment 15

19 years ago
I think we can close this bug now that we have exposed this pref direc tly in the

prefs UI, which should remedy the problems described by the original poster.

We'll probably move this pref to the 'Advanced' section.

Comment 16

19 years ago
Having a pref is a workaround for now, but if the default size is unusable
on some platforms, we should consider increasing the default size, IMHO.


19 years ago
Keywords: pp

Comment 17

19 years ago
moving out to way after beta, because the pref is what we are going to have for 
beta. Awaiting end user feedback after beta has been seeded, and see whether we 
need to correct anything
Target Milestone: M14 → M20


19 years ago
Summary: [PP]Unix: default font very small → Unix: default font very small

Comment 18

19 years ago
Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.
Component: UE/UI → User Interface: Design Feedback


19 years ago
Blocks: 28883

Comment 19

19 years ago
Is this bug related to 18135
The descriptions are very very close.

Comment 20

19 years ago
I've seen a LOT of complaints from PR1 about the small font which is the default 
on Unix.  I also think we should set the default font larger or figure out why 
some users have small fonts and others don't.  Maybe the installer (if/when we 
have one?) could set an appropriate default?  

We should definitely release note this.
Keywords: relnote

Comment 21

19 years ago
*** Bug 30285 has been marked as a duplicate of this bug. ***

Comment 22

19 years ago
I suspect that the problem is that Unix users are accustomed to having a large
font in the UI (e.g. menubar). We currently have a very small font in the UI,
possibly because that is the norm on Windows. Perhaps one possible solution to
this problem is to use CSS "system" fonts in Mozilla's skin(s). On Unix, the
system fonts could be implemented in such a way that they are larger than those
on Windows. There are separate bug reports for the CSS system fonts on the
various platforms.

Comment 23

19 years ago
need fixed in beta2 for localizing Linux
Keywords: nsbeta2

Comment 24

19 years ago
CC:ing akkana at her request.

Comment 25

19 years ago
Joining bug since 30285 was just marked as dup.

There are two issues with fonts on linux:
1. The fonts in the UI are far too small for any normal human to read.  This is
what bug 30285 (fonts in chrome and dialogs) was about.  There is no pref for
this font; the app is just unusable unless the user wants to play a
guessing-game about which button is what or what's in the urlbar.
2. Some Unix users, depending on their installed fonts, resolution, and prefs,
find the default font too small.  The prefs should normally take care of
changing this, though it might be reasonable to worry about whether the default
is right.

If this bug tracks issue 1, then perhaps the summary should be changed to
indicate this.  If it covers issue 2, then bug 30285 isn't really a dup.

Comment 26

19 years ago
It is quite clear that this bug is about the UI font. I'm updating the Summary
Summary: Unix: default font very small → Unix: default UI font very small

Comment 27

19 years ago
I'm not running Linux, but if "the fonts in the UI are far too small for any
normal human to read", then this should not be M20 and should be nominated for

Comment 28

19 years ago
bob, you should take a look at it in Allan's machine. Font is quite ugly and 
text overlaps in chrome.I agree, it is nsbeta2


19 years ago
Target Milestone: M20 → ---

Comment 29

19 years ago
Cleared TM M20 since it conflicts with the "nsbeta2" nomination.

Comment 30

19 years ago
Putting on [nsbeta2+] radar.  
Whiteboard: [nsbeta2+]

Comment 31

19 years ago
*** Bug 39431 has been marked as a duplicate of this bug. ***

Comment 32

19 years ago
Hi German, this bug has been nominated for nsbeta2 and approved by PDT as
[nsbeta2+], but the target milestone still says "---". I'm wondering whether
this is because you are swamped with other work. Do you need help? Or would you
prefer to make the decisions yourself and then do the work?


19 years ago
Severity: normal → major

Comment 33

19 years ago
This has gotten much worse with the recent skin landing.  At 1600x1200 on a
vanilla Redhat 6.2 system, I can't read fonts in dialogs or in the activation
panel at all -- the letters write on top of each other.  I've had to make a
user.css for myself in order to be able to use the app.

Comment 34

19 years ago
Here's what we need to can to fix it for beta2 (I assume this bug is true and 
verified for both the classic and moderfn skins) We need to hardcode the an 
appropriate Linux/Unix font into the window{} style rule (global.css I believe). 
Since I have no clue what fonts are commonly shipped with linux and other Unixes 
(I understand they are not similar to Mac/Win32), I will pass this on to Don to 
assign to the appropriate X-head to make the change. Pick a sans-serif font that 
is legible under the conditions described. 
The tricky part is for the mdoern skin that we have *one* Theme, not three 
variants for the three platforms. The challenge is to pick a set of font-families 
(default, fallback 1, fallback 2) such that they look right on Win32 and Mac and 
use a fallback font that ships with Linux, like:
font-family: Arial, Helvetica, LinuxFontName, sans-serif;
so Windows will trigger on the first, mac on the second and Linux on the third 
font, and all others will fall back to sans-serif. 
cc'd Ben, Hyatt
Assignee: german → don

Comment 35

19 years ago
When I put the following in my user.css, dialogs, the mail thread window, and
mail headers become much more usable and better looking, both in Modern and Classic:

window {
  font-family: helvetica !important;
  font-size: 3.5mm !important;

This is at 1600x1200.

Comment 36

19 years ago

I'm sorry, but my team can't fix this bug at the eleventh hour.  (If you would
have asked for help last week then I might have been able to do something about
it. :-)  As per our conversation on the phone I'm re-assigning this to you.

Neither Ben nor I like the hardcoding idea.  Ben's not even sure how to fix it
the right way.  My advice: ask hyatt and pavlov for help.  Sorry.

BTW, I certainly sympathize with the other X-heads about the problem. :-)
Assignee: don → german

Comment 37

19 years ago
Thanks Akkana!

This will not be a problem I believe in Linux classic, we just need to set the 

font on window to said 3.5mm Helvetica

As for Linux modern it seems to me the safest strategy is right now to set the 

font of Window (which is not currently set at all) to Arial, Helvetica, sans-

serif 3.5mm. This should work, I'll try it out tomorrow. Taking the bug back from 

Don. Setting ETA to 7/21. Akkana can you try this out by editing your global.css 

under /skins/modern/ and adding the following rules under window {}:

font-familiy: Arial, Helvetica, sans-serif;

font-size: 3.5mm;

and let me know whether this does it for you. I will do the same on macOS, win32 

and ask Hyatt whether the style rule would be OK overall.

Whiteboard: [nsbeta2+] → [nsbeta2+] ETA 7/21

Comment 38

19 years ago
The size worked, but the font family list didn't.  Apparently redhat 6.2 has an
Arial installed which is awful, very difficult to read (I can attach a screen
shot on request).  If I reverse the order of the font families, i.e.

      font-family         : Helvetica, Arial, sans-serif;
      font-size           : 3.5mm;

then everything looks beautiful and readable.  I tried this on a Mac, and it
looked nice there, too.  Wouldn't this order work just as well on Windows (and
pick up Arial if Helvetica isn't installed)?

Comment 39

19 years ago
yep this would work for modern windows as well IMO. Hyatt, any objections?
What about 
      font-family         : Geneva, Tahoma, Helvetica, Arial, sans-serif;

Given that Geneva is (I would think) hardly ever found on either Windows or 
Unix systems, and Tahoma hardly ever on Unix, this would make all three 
platforms look better, would it not?

Comment 41

19 years ago
Tahoma does not come with every win32 system, only with the ones with Office 
installed (at least on Win95, but that would be OK as Arial is likel on those 

Comment 42

19 years ago
Matthew's suggestion of "Geneva, Tahoma, Helvetica, Arial, sans-serif;" with
3.5mm font-size looks fine on my RH 6.2 system.

Comment 43

19 years ago
While testing on MacOS and Win32 some more I found that the large font-size 
3.5mm does not work well with certain dialogs, it's simply too large. Certain 
Panels like SmartBrowsing would get cropped if we chose 3.5mm. I will 

Comment 44

19 years ago
Akkana, can you try 3mm on your RH6.2 system?

Comment 45

19 years ago
Taking this ...
Assignee: german → don

Comment 46

19 years ago
Checked in partial fix (reviewed and suggested by akkana and german) which
changes the font-fmaily but not the font-size.  This oughta be something better,
at least, for beta 2.

Removing nsbeta2+, nominating for nsbeta3, and assigning to mcafee so he can
help german do this the right way.
Assignee: don → mcafee
Keywords: nsbeta2 → nsbeta3
Priority: P3 → P2
Whiteboard: [nsbeta2+] ETA 7/21 → (PDT: this WAS nsbeta2+ earlier so don't freak out)
Target Milestone: --- → M20

Comment 47

19 years ago
Additional notes: 3mm is still too small on my 1600x1200 system.  We all agreed
that 3.5mm looked better both on my system and on Don's 1200x1024 (?) system.
Apparently, though, 3.5mm looks too big on Mac and Windows.  It's bothersome
that it would be different for Linux than for Mac and Windows; this may point to
a problem in the Linux font handling (i.e. someone may have re-broken the code
that Erik fixed quite a while ago; alas, Erik is on sabbatical right now, but
maybe we can get together and try to chase this down and get platform parity for


19 years ago
Whiteboard: (PDT: this WAS nsbeta2+ earlier so don't freak out) → (PDT: this WAS nsbeta two plus earlier so don't freak out)

Comment 48

19 years ago
Target Milestone: M20 → M17

Comment 49

19 years ago
I also find the default settings unreadable. I've had to go to 12pt to get
something usable. That's for 1024x768 on a 17" monitor. That comes out to
about 80dpi so I've set Mozilla's screen resolution to 75dpi.

I don't think there's an easy fix because:
1) Mozilla thinks in terms of pixels while X thinks in points. Because of
this there are some round-off errors in the pixel size fields of some of the
standard unscaled (.pcf) fonts. Using pixels to select font sizes is
2) Mozilla tries to use the unscaled fonts to avoid "ugly looking"
rendering. Nice idea but Mozilla seems to round down which isn't good.

Add in some round-off error in Mozilla's calculations plus the usual Unix
goofiness and Mozilla often chooses unwisely. From a bash shell, you can say
  NS_FONT_DEBUG=3 ./mozilla
and you can watch what happens

There are bugs filed on all of this but it's going to take some work.

I also would not assume that an X system is missing a particular font. It
didn't take me long to find the Tahoma truetype fonts. Not surprisingly,
they look worse that the standard Helvetica ones. I'm sure I could find
Geneva if I wanted to but there's no guarantee it would be the Windows one.

Comment 50

19 years ago
I don't understand this bug.  The defaults are fine on my system, and I run at
2000x1500 pixels on a 125 dpi screen.  It seems like the problem is that people
aren't informing their X server of the physical size of their display.  For
example, by launching X with start -- -dpi 130, or setting the parameter in the
XFree config file (assuming XFree).  If your X server can't properly translate
points to pixels, you can't really expect the fonts to look right.

P.S. use xdpyinfo | grep resolution to determine what X thinks your dpi is, and
refer to your owners' manual to determine the actual size of the screen.  If I'm
way off base here, somebody clue me in.  It just seems to me that we might be
screwing up Mozilla's defaults to make them better on poorly configured

Comment 51

19 years ago
Nav triage team: [nsbeta3+]
Whiteboard: (PDT: this WAS nsbeta two plus earlier so don't freak out) → [nsbeta3+]

Comment 52

19 years ago
> I don't understand this bug.  The defaults are fine on my system, and I
> run at 2000x1500 pixels on a 125 dpi screen.  It seems like the problem
> is that people aren't informing their X server of the physical size of
> their display.  For example, by launching X with start -- -dpi 130, or
> setting the parameter in the XFree config file (assuming XFree).

Sure, a misconfiguration can cause all sorts of problems but your 125dpi is
outside the common 75dpi - 100dpi range. You may be using just scalable

> If your X server can't properly translate points to pixels, you can't
> really expect the fonts to look right.

The unscaled (.pcf) fonts hardcode the pixel size and the point size fields
and the X server just accepts them so only the unscaled fonts have a
round-off problem. If you never use them, you never see this.

> P.S. use xdpyinfo | grep resolution to determine what X thinks your dpi
> is, and refer to your owners' manual to determine the actual size of the
> screen.  If I'm way off base here, somebody clue me in.  It just seems
> to me that we might be screwing up Mozilla's defaults to make them
> better on poorly configured machines.

I agree somewhat. I've always thought that Mozilla tries to hard to be
clever and tries to work around too many problems. I think that Mozilla
should just accept the system defaults. If they're wrong, that's the user's
problem, although a some recommendations on how to fix problems would be

However, Mozilla still has troubles on a properly configured system. On my
75 dpi machine with the standard X fonts, 3mm is ~8.8px. There is just no
available font at either 8px or 9px that I can read. Yes, the cause is X's
poor font support, but that's the way it is. If Mozilla wants to support X
server based systems, it has to deal with this.

Now 4.x uses 12pt by default for its chrome so I think Mozilla must do the
same thing. If that means a loss of cross-platform purity, tough.

Comment 53

19 years ago
larger 3.5mm size requires 12 pref panels to be relaid-out/squished:
fonts, Navigator, Smart Browsing, Mail and Newsgroups, Viewing Messages,
Composing Messages, Disk Space, Composer, Cookies/Images, Forms and Passwords,
Desktop Integration, Debug.  Possibly other panels on commercial build.

Comment 54

19 years ago
*** Bug 40888 has been marked as a duplicate of this bug. ***


19 years ago
Depends on: 40888


19 years ago
Keywords: UE2

Comment 55

19 years ago
pref panels have been fixed, 3.5mm font looks Ok on Linux, Win32,
but NOT on Mac (too big?).  Need help on Mac.


19 years ago
Priority: P2 → P1

Comment 56

19 years ago
3.5mm = 9.96pt so why not just use 10pt; it would make more sense.

Comment 57

19 years ago
Sure, that would be okay too.

Comment 58

19 years ago
Bah, nothing is ever easy. If I set browser.display.screen_resolution 75
to match my system, use the standard X fonts, and set the default chrome
to 10pt then Mozilla should look for a 10pt font.

I know Mozilla thinks in pixels but 10pt is 10.4px@75dpi so it should
have rounded to 10 and found something like
-adobe-helvetica-medium-r-normal--10-100-75-75-p-56-iso8859-1 which is a
standard X font. Instead it seems to have settled on 11px and chose
-adobe-helvetica-medium-r-normal--11-80-100-100-p-56-iso8859-1. Too bad
that's 8pt at the wrong resolution. It should be no surprise that the
75dpi and 100dpi bitmap fonts do not have exactly the same metrics so
the result is a rendering that's too small.

I have no idea why it thinks 10 is 11 but that's certainly a problem.
There's also bug 40373 on why Mozilla should use points when talking to
an X server.

Comment 59

19 years ago
Investigating platform-specific style rule for this.
Linux & Win32 look ok, Mac looks huge with this change.

Comment 60

19 years ago
The geneva font _is_ huge. I installed it on my Linux system and it renders
significantly larger that Tahoma or Helvetica.

Comment 61

19 years ago
Aha!  Do we need to use Geneva?  Could we drop that and just use Helvetica,
Arial, Sans Serif, so Unix and Mac would both pick up Helvetica?

Comment 62

19 years ago
We still have a problem with font size, Mac wants to specify
fonts in pixes and Win32/Linux want to use points/mm.
Erm, the idea behind using Geneva on Mac is that using *anything* besides Geneva 
10 (or 9, at a pinch) on Mac, Helvetica included, looks pretty crappy to your 
average Mac user.

But Mac Classic is using Geneva 10 already, and I would guess that the number of 
Mozilla users on Mac who will use the Modern skin will be in the single figures, 
so you may not care about this. :-)

Comment 64

19 years ago
Now now Matt, I sense some negative vibes here :-) you will see lots of people
use modern, as they do today with Netscape 6, yes even on a Mac.
I hate to bring this up but does Arial solve the problem? Arial looks better
on-screen on a Mac and would render similar on Win32.  Only philosphical problem
is that Arial on Mac comes bundled with any newer Mac due to the fact that IE
that comes with MacOS also throws the MS fonts onto the Macs. Helvetica and
sans-serif could then still be the back up fonts in case Arial was not on the

Comment 65

19 years ago
pref layout work is done, we should find a reasonable
fallback font list and hope the larger font works on Mac.

I think my part of this bug is done, I really need help
with the Mac issue, over to german for a look.
Assignee: mcafee → german

Comment 66

19 years ago
There are still some font mysteries. See bug 47582 for an example. It may be
very hard to find a set of font names that will work even halfway well on all
platforms, not to mention the fact that you can do all sorts of tricks with
fonts.* files on an X server

Comment 67

19 years ago
German: using Arial won't solve the problem (at least in XP chrome) because
listing Arial first will bring back the Linux problem with Arial that we just
fixed for M17.

Comment 68

19 years ago
Created attachment 13523 [details]
mac arial vs. helvetica explanation

Comment 69

19 years ago
a mac side note, see attachment above - the standard helvetica bitmap should 
never be an option for a mac display font, it is of very poor quality.  that's 
one vote to place helvetica further towards the end of the list. possibily remove 
it entirely if, there are no other cross platfrom system dependencies.

Comment 70

19 years ago
That's too bad, since on Linux it's the opposite (at least with our app; I think
we may be doing something evil when it looks for arial, though, since it's not
obvious to me that my system actually has arial installed at all).

Will attach a screenshot of arial vs. helvetica on my redhat 6.2 machine.

Comment 71

19 years ago
Created attachment 13526 [details]
Moz/Linux Arial vs. Helvetica screenshot

Comment 72

19 years ago
I talked with hyatt, if we cannot get the fallback hack to work
(and it *is* really a hack), we should go with platform-specific
style sheets and throw the font family and size stuff in there.
Yeah "it sucks" but I can think of lots of other things that "really
suck" so I'll need a better arguement than that.

german, give this back to me if we decide to go with platform-specific
style sheets.

Comment 73

19 years ago
Not that my opinion matters much, but I think a platform.css with the right
precedence would solve the problem with a minimum of effort; there certainly
are more important things to deal with. Place outside of any skin it could help
enforce standards on all skins.

Comment 74

19 years ago
This looks pretty good with the new modern skin.  Not critical to stop ship.  
Low profile polish.  Moving to P3.  Adding [PDTP3]
Priority: P1 → P3
Whiteboard: [nsbeta3+] → [nsbeta3+][PDTP3]

Comment 75

19 years ago
I think it looks good on Mac and Win32 now. Barring any major objections I'd 
like to take the "+" of this bug. Linux? Mac?
(Also I am worried about Theme Designers wanting to create just one theme and 
get that to work across platforms.)

Comment 76

19 years ago
Well, someone just checked in a 9px font in the new modern theme, which of
course is non-device-independent and practically unreadable on a high-resolution
device.  Personally, I would leave the + until it can be shown that theme people
are paying attention to font size issues.

Comment 77

19 years ago
Has anyone looked at directory or ftp listings recently? They are impossibly
small and they don't seem to want to change size. This isn't over, yet.

Comment 78

19 years ago
For me, the worst of it is the personal toolbar, where the glyphs are miniscule,
and actually missing some strokes.  Status bar text is too small to read too.

Comment 79

19 years ago
Tooltips are just as small. It's because the modern skin specifies absolute
sizes more than once. I've filed bug 51515 on this. Should this bug depend on

Comment 80

19 years ago
Actually, for me, the fonts on the Classic skin are much smaller than the fonts
on the Modern skin (though they're both too small).  This isn't a gtk setting;
when I bring up gnome apps (though I use kde on this machine), their menu font
is significantly bigger than the font used by either Classic or Modern.

Comment 81

19 years ago
akkana, trudelle: is Mozilla's dpi set to the right setting in your prefs?  If
your pref dpi is set lower than your actual dpi, the chrome fonts are all too

On all my machines most of the chrome fonts are the right size if and only if my
display, X, and mozilla all agree on the dpi.  This is true on displays of 75,
100, and 125 dpi.

Comment 82

19 years ago
My true dpi is approximately 100.  Mozilla's setting is 96 (and I think it
rounds, so setting it to 100 would probably gain me nothing).  The X server
thinks I'm at 75: it's XFree86, set up via Redhat 6.2's normal setup for this
resolution and this monitor; I know I can change that, but I've avoided doing so
because most users won't and I persist in thinking that we should work with
configurations generated by installation programs, not just expert users who
know how to hand-configure their X servers.

Comment 83

19 years ago
That's fine, but if we break fonts for those of us with properly configured
displays, that will not be very cool.  Since RH 6 is the only Unix that is an
official 1st-tier platform, why don't we evangelize them to fix their XFree
install procedure?

Actually, if Moz thinks you have a 100 dpi display, and you do have a 100 dpi
display, and Moz is requesting fonts based on their pixel size, I can't imagine
why that doesn't work.  Perhaps your 75 dpi fonts are listed before your 10 dpi
fonts?  I have no other good ideas.

Comment 84

19 years ago
Well, I guess I'm not sure what my actual DPI is, how can I tell?  I think it is
around 100 dpi though, and changing it from 96 -> 100 -> 125 doesn't seem to
have any effect on the problem fonts.  Wouldn't changing it to 75 make all fonts
even smaller?  The fonts in the content are okay, I don't want to change them.

Comment 85

19 years ago
For whatever reason, the content area does not respect the prefs dpi setting, so
you are not in danger of messing up the content fonts.

If you want to know your display's resolution, determine the pixel resolution
(e.g. 1024x768), and the physical size (e.g. 15.9" diagonal), and use math.
The dpi is h/(4*sqrt(d^2/25)), where h is the horizontal resolution in pixels
and d is the diagonal size in inches.  For example, a 15.9" diagonal monitor
running at 1600x1200 has a resolution of 125 dpi.

Comment 86

19 years ago
but math is hard! ;-)  Thanks, that puts me at 102, so I guess my setting was

Comment 87

19 years ago
> For whatever reason, the content area does not respect the prefs dpi setting,
> so you are not in danger of messing up the content fonts.

That depends on the content. If the content uses "pt" units, the dpi pref *will*
have an effect. Ditto for in, mm, etc, but not px.


19 years ago
Depends on: 16729

Comment 88

19 years ago
In the 2000-09-07-08 nightly, the personal toolbar font is specified at an
unreadable 11px.  See bug 51748 which I posted on this issue.

Comment 89

19 years ago
So, am I missing something or is this P3 bug -- destined to automatically 
become nsbeta3- tomorrow anyways -- not going to get fixed for beta3, 
especially considering it's not assigned to an engineer?  Removing nsbeta3+ for 
Whiteboard: [nsbeta3+][PDTP3]

Comment 90

19 years ago
I love how bugs get marked + for every beta, then just ignored month after
month.  Oh, well, we obviously don't really care whether Linux users can read
the UI in our app.

Comment 91

19 years ago
you can also blame CSS for this because it assumes that font families and font
lists, should be independent of a particular size.  The spec would be more
typographically sound if each font name parameter had it's size counterpart,
since typefaces have widely varying proportions and characteristics.  Some are
bitmaped well at 12 but not at 11 or 10 for example, so you cant expect a entire
list of fonts, to work well at the same exact screen size.

The only solution I can see is that we use platform specificness in this
situtation.  otherwise we are sacrificing quality for consistency 
Actually, CSS makes allowances for that. We just don't implement the code that
would solve that particular problem. ('font-size-adjust')

Comment 93

19 years ago
Actually, Mozilla will have to implement read-only @font-face support before it
can use font-size-adjust properly. @font-face is a good idea anyway because we
need a way to combine various physical fonts into one family with appropriate

BTW, the CSS docs use the Verdana font to illustrate the use of dont-size-adjust.
Mozilla seems to have fallen into a known trap.

Comment 94

19 years ago
Marking nsbeta3- until this bug can be assigned to an engineer.
Whiteboard: nsbeta3-

Comment 95

19 years ago
If you guys are really serious about pushing a Linux Mozilla out the door, all
you really have to do is:
1) fix bug 51515 so that there is exactly one place where the font size is set.
   The classic skin does this, the modern skin does not.
2) ship a Linux userChrome.css or, at the very least, a userChrome.css.sample.
3) Mention in the release notes how to deal with umreadable fonts.

I don't see what the big problem is.


19 years ago
Assignee: german → don
Whiteboard: nsbeta3-

Comment 96

19 years ago
Handing German's bugs to Don.

Comment 97

19 years ago
Don's looking into this
Whiteboard: [need info]

Comment 98

19 years ago
Changing relnote keyword to relnote3.
Keywords: relnote → relnote3

Comment 99

19 years ago
Taking off the beta 3 radar and nominating for RTM.
Keywords: rtm
Whiteboard: [need info] → [nsbeta3-][need info]

Comment 100

19 years ago
I really need to get to the bottom of this one ...
Priority: P3 → P2
Whiteboard: [nsbeta3-][need info] → [nsbeta3-][RTM NEED INFO]

Comment 101

19 years ago
Adding alecf to "cc" list so he can save my ass.

Comment 102

19 years ago
If we just used the system font in the modern skin, like we do in the classic
skin, it would solve the problem.  That would really be the best solution since
it respects the user's preferences and eyesight.

Comment 103

19 years ago
I don't think the answer is that simple.  New Modern seems to have literally
been drawn in photoshop and then hacked into XUL/CSS pixel-for-pixel.  For
example, the buttons in new modern will not scale vertically.  You can change
your chrome font size if you want, but tall fonts will simply flow out through
the bottom of the fixed-pixel-sized buttons.

It's depressing, yes, but the solution requires a major re-thinking of the New
Modern implementation.  I'm using Classic :)

Comment 104

19 years ago
there's a change going in very soon for RTM which will give us scalable buttons
and widgets.  it's already been plussed, we're just waiting to check them in.

Comment 105

19 years ago
Marlon, to which bug are you referring?

Comment 106

19 years ago
A quick remark:

Lets set up some reasonable criteria by which we call the theme font selection 

successful on Linux (here is an example):

should be large legible enough for the following resolutions on those monitors:

- 800 * 600 on 15"

- 1024 * 768 on 17"

- 1280 * 1024 on 19"


I have seen people use (especially on Linux) 1600 * 1200 on 17" and 19" screens 

and I would not call this a typical or even healthy resolution. lets avoid 

optimizing for fringe cases, at least not at the cost of the 95% user case.

Comment 107

19 years ago
Xwindows is inherently a variable dpi system so Mozilla's inability to
deal with this exposes a fundamental flaw in its design. Obviously, it's
too late right now to address this.

Xwindows also has a relative scarcity of usable fonts and those are
available only in a few sizes. Since it can't anti-alias, it's attempts
at scaling are usually laughable. You might wish it weren't so but it's
a fact of life. To me, this means that you have to simplify the skins
which, in turn, means you can't make fancy font choices which, in turn,
means a skin should use precisely one font size. Yep, it's ugly. Yep, it
an affront to everyone's sensibilities but it *is* necessary.

Finally, note that 800x600/15" and 1024x768/17" are closer to 75dpi than
100dpi and also that XFree86 defaults to 75dpi. A fresh Mozilla will
ignore the OS value and *assume* 96dpi. In theory, this works; in
practice, it often doesn't. Mozilla is in the difficult position of
justifying why it ignores the OS values, particularly when they may well
be correct. This, in turn, makes it difficult for you to justify any errors.

Comment 108

19 years ago
don - bug #54105

Comment 109

19 years ago
If the buttons in New Modern are going to be rescalable, I'll reiterate my plea
for using the CSS system font.

Comment 110

19 years ago
it seems wrong that we default to 96DPI right off the bat.. .it seems like we
need to add this line to unix.js:
user_pref("browser.display.screen_resolution", 0);

this will cause mozilla to take on the OS default screen resolution.
If the user's machine is screwed and has the wrong DPI, then they should
override it the prefs....

Does this sound good enough to take us through Netscape's RTM?

Comment 111

19 years ago
It sounds SO good, that I'm re-assigning this to you. :-)

Hell, go ahead and work up the change!  When you have a reviewed patch, let me
know and I'll mark this "rtm+".
Assignee: don → alecf
1. Note that the DPI stuff only affects font sizes that are given in "real"
units, e.g. pt (points), in (inches), mm (millimeters), etc. So if the font(s)
targetted by this bug report use other units like px, then fixing the DPI stuff
won't affect the UI font sizes.

2. It might be a good idea to clearly define the boundaries of this bug report.
I.e. do we want to fix the font size in all of the themes, or just the default

Comment 113

19 years ago
Created attachment 16054 [details] [diff] [review]
add a default pref so that real screen res. is used
r=erik for the patch attached 10/03/00 13:58

What about the other questions that have been asked? E.g. the default theme, or
all themes? Using CSS "system" fonts in one or more of the themes?

Comment 115

19 years ago
I think this bug just applies to the 'Modern' theme as this is the only one with 
a cross-platform font CSS setting. (like many subsequent themes will have where 
designers will not want to go through the effort of creating 3 platform specific 

Comment 116

19 years ago
ok, adding that pref on my system, which is 1280x1024 on a 21" monitor makes
everything look really bad. 

Then I discovered that I'm running at 75dpi. I actually measured the  screen
with a ruler: it's 12x16", which would make it about 85.3dpi. I entered this as
my screen resolution, and the menus are exactly 8 pixels high, and an "e" is 4
pixels wide.

On windows, the menus are 9 pixels high, and an "e" is 5 pixels wide. This means
that in pixels, the menus are about 13% taller and 25% wider, which would
explain why menus look a bit bigger there.

When I increase my preference to 100dpi, I get 9 pixel high menus, and a 5
pixel-wide "e" Seems to me like we have some kind of rounding or calculation
error such that a correct DPI of 85 does not give us a 9-pixel font. I'm going
to try to see what the threshold is

This is all with the modern skin on both platforms.

So here is what I think we need to do:
- add this pref, which will make things look bad
- in the release notes, explain how to change the DPI on XFree86. The only way I
can find is "startx -- -dpi 100" or edit your Xservers file. We should suggest a
few defaults like 85, 96, and 100. 
- fix this rounding error. Anyone know where we should look?

Comment 117

19 years ago
With XFree86 4, you can specify the physical screen size in millimeters with the
DisplaySize directive in the XF86Config file.  The syntax is:
	DisplaySize width height

	DisplaySize 327 243

The physical screen size is normally found in the display's owner's manual.
The rounding is performed in mozilla/gfx/src/gtk/nsFontMetricsGTK.cpp, in
nsFontMetricsGTK::Init(), where it is setting mPixelSize.

Comment 119

19 years ago
Ok, after a binary search with some font resolutions, I found that on my screen
(1280x1024 on a 21" screen, true resolution of 85dpi) there is a threshhold
between 99 and 100dpi that gets me 9 pixel menus: 
at 99dpi I get 8 pixel menus
at 100dpi I get 9 pixel menus

I don't know if this is signifigant, but what this means is that there is no
difference between entering my real resolution (85dpi) and the suggested DPI in
the prefs (96dpi)

There is a similar threshold between 82dpi and 83dpi, for 7 pixel and 8 pixel

Comment 120

19 years ago
ok, more interesting stuff. it seems that in nsDeviceContextGTK::SetDPI(), we're
hardcoding a variable pt2t, which I think is points-to-twips, to 72. When I
lower this number (it's the numerator in the calculation of mPixelsToTwips, and
the divisor in mTwipsToPixels) I get some decent fonts. 

When I set this number to 60 instead of 72, I get 9 pixel menus at 85dpi! (I
also tried setting it to 50 and I got giant 12 pixel menus, doh!)

This is basically what _I've_ been shooting for. Does anyone object to this as a
goal - 9 pixel menus at the correct resolution for your machine? If so, I'd like
to consider changing pt2t to a reasonable number lower than 72.

Erik: where did the original 72 come from? Is it reasonable to lower this to 60?

Everyone else who wants to help: Can people with other resolutions try this:
- Determine your TRUE dpi: Measure the width of the display area of your
monitor, in inches. Divide your horizontal resolution (i.e. 1280, 1600, etc) by
this number.
- edit gfx/src/gtk/nsDeviceContextGTK.cpp and change line 514 so that pt2t is
- start mozilla. Use XV or a similar tool to zoom in on the menu and count the
height of the capital "F" in the File menu.
- if you have time, experiment with values of pt2t.

Now answer the following questions:
Monitor/pixel dimensions: (i.e. 16"x12" at 1280x1024)
DPI used: (e.g. 85dpi - as set by your X server, or as overridden by mozilla)
Font size with pt2t=60: (e.g. capital letters are 9 pixels high)
Font is too big/too small/perfect for my tastes:

and post results here (make sure someone else has not already entered your
screen resolution)

Comment 121

19 years ago
That isn't the solution at all.  There are 20 twips to a point, regardless of
the output device resolution.

Comment 122

19 years ago
well, pt2t is currently 72, so I guess that means that it's not points-to-twips.
You got me.
Here's the relevant calculation:
  mPixelsToTwips = float(NSToIntRound(float(NSIntPointsToTwips(pt2t)) /
  mTwipsToPixels = 1.0f / mPixelsToTwips;
No, please do not change the 72. I don't know who wrote that code, but "pt2t" is
a terrible name for that variable. 72 is the number of points (pt) per inch, and
it is fixed (not a variable). The calculations in SetDPI() are basically
correct, although it is performing some rounding that may require further

Comment 124

19 years ago
ok, experimenting with the rounding to see what I can find.
>Does anyone object to this as a
>goal - 9 pixel menus at the correct resolution for your machine?

I object rather strongly to this goal. Remember that this DPI code is used for
*all* fonts using physical sizes (pt, in, mm, etc) in Mozilla -- both in the UI
and in the content. I think we should take a closer look at the theme (themes?)
to see exactly what they are requesting, and check whether Mozilla is doing the
right calculations for those requests, including the DPI value.

If the theme is asking for N points, then the number of pixels should *vary*
from resolution to resolution. (It shouldn't be a constant 9px.) If the theme is
asking for 9px, then we should get 9px on every screen, regardless of DPI value.

Comment 126

19 years ago
Yes, it would be a great mistake to redefine the point. What happens is a page
wants 36pt or 0.5 in fonts?

There is an interesting point (yes I meant that) here. I do like letters that
are about 9 or 10 pixels high. To get them on my 75dpi system I have to
force 12pt.

12pt is also "special" since it is, by far, the most common font size specified
int all the XFree86 distribution. Look at the app defaults, or the font aliases,
or the font server config files. I do believe they know something.

Comment 127

19 years ago
Forgot to add that mozilla/xpcom/ds/nsUnitConversion.h has a fairly large set
of conversion functions. Perhaps they weren't available when the code was written.

I also hate to harp on this but talking pixels to the X server is a mistake.

Comment 128

19 years ago
you're right eric, I'm not sure what I was thinking a few hours ago since
pixels-per-inch will vary from machine to machine. I think the true DPI of a
monitor is going to be the only real way to compare & contrast machines.

I guess maybe what we need to do is figure out how the modern theme sets it's
menu font size, and decide on a correct pixel value at 75, 85, and 100DPI?
Ultimately I'd like to express this in pixels so that it can be verified once
and for all. At 85dpi I would personally like to see 9 pixel menus. How about
75DPI? 100DPI? Measure your monitor, play with the resolution preference, and
post here.

Comment 129

19 years ago
ok, more interesting information. With the following patch, the thresholds I
described above move to 80/81dpi and 97/98dpi. The difference between the old
calculation and the new calculation is about 0.34%

RCS file: /cvsroot/mozilla/gfx/src/gtk/nsDeviceContextGTK.cpp,v
retrieving revision 1.67
diff -u -r1.67 nsDeviceContextGTK.cpp
--- nsDeviceContextGTK.cpp  2000/09/14 18:57:05 1.67
+++ nsDeviceContextGTK.cpp  2000/10/04 00:05:41
@@ -514,8 +514,8 @@
   int pt2t = 72;
   // make p2t a nice round number - this prevents rounding problems
-  mPixelsToTwips = float(NSToIntRound(float(NSIntPointsToTwips(pt2t)) /
float(a-  mTwipsToPixels = 1.0f / mPixelsToTwips;
+  mPixelsToTwips = NSFloatPointsToTwips(pt2t) / float(aDpi);
+  mTwipsToPixels = float(aDpi) / NSFloatPointsToTwips(pt2t);
   // XXX need to reflow all documents
   return NS_OK;

Comment 130

19 years ago
I use 1600x1200 on a 21" (which is actually about 15.5" wide, so actual dpi is
just over 100).  The gtk "system" menu font (the font I get by default in gnome
app menus) is 9 pixels high.

If we ended up showing most people 9 pixels, it would probably be okay for most
people, but would leave visually impaired people without anywhere to go (unless
they knew to switch to the Classic skin).

Comment 131

19 years ago
I object to all this guessing.  We should figure out a *real world* size (not
pixels) that is comfortable for normally-sighted people.  I choose 12 points. 
12 points is also a good size because the two most universal X fonts are Adobe
Times and Adobe Courier, both of which look spiffy at 12 points.

On my laptop which is 100 dpi, the font should be rendered 16.67 == 17 pixels
high.  On my desktop, which is 130 dpi, the font should be rendered 21.67 = 2
pixels high.

In any case, the font should be chosen by the following algorithm:

pixles = round(font size in pt / 72 pt per in * resolution in dots per in)

Then Mozilla should request the font in that point size, and my X server will
choose the font which best matches given the font's scalability, etc.

The final question is how do we choose the font point size in this equation? 
Simply, we ought to use the system font size where available.  In no case should
we start out by specifying the pixel size, which is sadly what New Modern does

Comment 132

19 years ago
> Then Mozilla should request the font in that point size, and my X
> server will choose the font which best matches given the font's
> scalability, etc.

Actually, the X server doesn't choose, the app does. Mozilla is
reasonably smart but can be better.

> ok, more interesting information. With the following patch, the
> thresholds I described above move to 80/81dpi and 97/98dpi. The
> difference between the old calculation and the new calculation
> is about 0.34%

0.34% should not make a big difference. The fact that it does
illustrates that there's something smelly in the chrome. I'm going to
attach a zip file with some examples of how fragile Mozilla is.

I must say that there is the implicit assumption going around that the X
code must be broken because Mozilla looks different than on Windows or a
Mac. I see no reason to assume that. The GTK code acts properly as far
as I can see. Instead of hacking the X code at the drop of a hat, it's
time to figure out how to make a cross-platform browser, not a Windows
one with tacked-on X support.

Comment 133

19 years ago
Created attachment 16118 [details]
110K zip file showing current screenshots

Comment 134

19 years ago
Actually Mozilla can only request fonts from the X server, and the X server
really is free to return something other than the requested font.  For example,
if only :unscaled fonts are in my font path, X will return Times 12pt if Times
13pt is requested.

The only way Mozilla could get around that is by including its own font renderer
and screen blitter.

Comment 135

19 years ago
Well, yes if a program is silly enough to do that. Mozilla isn't. A call to
XListFonts reveals what is and isn't available.

Comment 136

19 years ago
I take that back. X will not fake things. Consider this with :unscaled.
--->xlsfonts  -fn '-adobe-helvetica-medium-r-normal--43-*-*-*-p-*-iso8859-1'
xlsfonts: pattern "-adobe-helvetica-medium-r-normal--43-*-*-*-p-*-iso8859-1" \

--->xlsfonts  -fn '-*-helvetica-medium-r-normal--x-*-*-*-p-*-iso8859-1'
xlsfonts: pattern "-*-helvetica-medium-r-normal--x-*-*-*-p-*-iso8859-1" \

It all depends on what question you ask.

Comment 137

19 years ago
0.34% doesn't seem like a big error I realize, but that error can grow depending
on how the numbers are manipulated. I was just saying that THAT particular
calculation was off by 0.34% - the actual calculation of font size could be off
by some multiple of that.

Also, understand that we're not implying that X is broken. It's mozilla's
X-specific code that is slightly busted. gtk must have a dpi-independant way of
choosing fonts. If a gtk-enlightened person wants to chime in and tell us what
they're doing, I'll be very pleased.
> Created an attachment (id=16118)
> 110K zip file showing current screenshots

Thanks for the screenshots. I'm not going to claim that the Unix Mozilla font
code is perfect, but I would also take a good look at the theme(s) to see what
they're requesting (and whether that's correct/appropriate).

Also, I realize that this bug report is out in the open (on bugzilla), but is
Netscape 6's default theme different from Mozilla's? (Silly question, but I have
to ask...)

Comment 139

19 years ago
Re tenthumbs' comment about looking different on Linux than it does on Windows:
the problem is not that they look different, it's that mozilla running on
Windows is readable while it isn't on Linux, using exactly the same resolution
and monitor.  They needn't look the same, but if we don't make an effort to see
that mozilla on linux has the same level of readability it does on windows using
the same hardware, then we're penalizing linux users and encouraging them to
switch to windows or another browser.

Comment 140

19 years ago
Created attachment 16133 [details] [diff] [review]
fix for rounding issue

Comment 141

19 years ago
Created attachment 16134 [details]
sample HTML file to show font and pixel-sized fonts

Comment 142

19 years ago
you know, I don't see ANY place in the modern skin where the "default" font size
is set. Could we be falling back to some horrible system default?

Comment 143

19 years ago
ugh, there are typos with the 14 pixel/point samples in that file.

But with that sample page (typos fixed) on my system at 85dpi,
nsFontMetricsGTK::mPixelSize is getting set to: (with corresponding float that
it got rounded from)
8 point: mPixelSize = 9 (9.44444)
10 point: mPixelSize = 12 (11.805555)
12 point: mPixelSize = 14 (14.166666)
14 point: mPixelSize = 17 (16.527777)

8 pixel: mPixelSize = 8 (8.0277778)
10 pixel: mPixelSize = 10 (9.975694)
12 pixel: mPixelSize = 12 (11.982639)
14 pixel: mPixelSize = 14 (13.989583)

I find it interesting that the pixel-based font sizes don't match exactly, but
it's only off by about 0.07%

If I go back to the old method of calculating the mPixelsToTwips/etc, then the
pixel-based fonts nail the right sizes, no rounding required. I guess this isn't
surprising because we're basically pre-rounding during calculation anyway.

Comment 144

19 years ago
<erik> but is Netscape 6's default theme different from Mozilla's?
Yes. Netscape 6 defaults to modern, Mozilla defaults to classic.

Comment 145

19 years ago
I created a simple test file combo ( a xul file and a css file) that lets you
see the effects of using all 6 available system fonts. I am going to upload
those 2 files to the bug in a moment for external use. Internal users can simply
click on http;//blues/users/german/publish/openLocation2.xul when this is viewn
within NS6 or Mozilla.

Comment 147

19 years ago
Created attachment 16182 [details]
Use this xul file with the next to be uploaded css file to see the effects of using system fonts in controls

Comment 148

19 years ago
Created attachment 16183 [details]
Use this css file along with the previous XUL file (have to be in the same location to work) to see the effects of the use of system fonts

Comment 149

19 years ago
Ok, talked with Erik. Here's what it LOOKS like. The modern skin is not
specifying a default size for fonts, so it seems to be falling back to a
12-point font. 

This is happening here:

However, Erik said he saw it trying to get a 170 twip, aka 8.5 point, which
would certainly explain the tiny fonts. So the 12-point fallback may actually be
a red herring. The next step is to figure out where this 8.5 is coming from. The
quick-hack fix would be to override this 8.5 default on unix to be 12 point or

It seems like the "real" fix is to start using a system font like the "dialog"
font. The problem with this is that the modern skin is not scalable.
Specifically, the status bar and the url bar are not scalable. This means if we
switch to the system font on windows and mac, which currently use a hardcoded
font family and default font size, the skin will look odd. Compounding this is a
bug where images wont scale in certain situations on Linux.

(though the rounding bug should still be fixed)

Because this has gotten so large, I'll be marking this INVALID later today and
dividing it up into a few issues:
- the rounding bug
- using the "system" font in the modern skin
- fixing the modern skin so that the url bar and status bar are scalable
- fixing the linux image scaling issue so that we can scale the status bar.

I'll post bug numbers here when I have them.

Comment 150

19 years ago
I wouldn't get all that excited about round-off errors. There are errors in the
pixel_size field of some of the X bitmap fonts. That's one reason you really want
to talk in points to the X server.

8.5pt = 3mm which is a number that seems to crop up a lot.

And what is a system font in Unix anyway?

Comment 151

19 years ago

Comment 152

19 years ago
ok the bugs are:
bug 55463 - modern skin should use system fonts
bug 55464 - modern skin statusbar and urlbar not scalable

I want to make a reproducable testcase before I file the image scaling bug.
After talking to hangas, it soundsl like the image scaling bug isn't required to
make the statusbar/urlbar scalable.

Comment 153

19 years ago
ok, marking this WONTFIX once and for all - the issues should be covered by the
bugs I just filed.
Last Resolved: 20 years ago19 years ago
Resolution: --- → WONTFIX

Comment 154

19 years ago
Noting the comments about Helvetica on the Mac (and the suggestion to use Geneva 

instead): there is also a problem with Geneva. In both cases, the main difficulty 

is the antialiasing (as previously mentioned) and simply changing to Geneva would 

not fix the problem (at least on my sys9 implementation).

	The only real fix is on the user end: Control Panels -> Appearance and click 

off the antialiasing. At that point, *all* fonts behave better.

	I have particularly noted both Arial and Geneva failures in windows *other 

than* system windows -- in apps, basically. There is no single font I know of 

that's safe, but there is also none that is more drastically ruined than 

Helvetica (that I have seen).

	This is G3-233 beige Sys9.0.

	I use Helvetica as the normal user font on Mac, Linux and Windows. This 

problem is only on the Mac, only system 9, and only with the (default) lousy 

antialiasing (there is no similar problem on windows).

	I have no suggestion for how this could be fixed in Mozilla (wontfix is 

inevitable). Mac is singlehandedly ruining helvetica.

	On the other hand, macusers who turn off the antialiasing will get it back 

(if my system is any indicator).

Comment 155

18 years ago
vrfy wontfix


18 years ago
Keywords: rtm, UE2 → nsrtm


16 years ago
Component: User Interface Design → Browser-General
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.