5236 - Unix: default UI font very small

Status: VERIFIED WONTFIX

(SeaMonkey :: General, defect, P2)

Description

[thully]

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.

Comment 1

[Erik van der Poel]

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:

setenv GECKO_FONT_SIZE_FACTOR 1.75

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

Comment 2

[thully]

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.

Comment 3

[Erik van der Poel]

I have checked in a change to make the default DPI on Unix (GTK) be 96 (per
[e-mail]). 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.

Comment 4

[Erik van der Poel]

Thully, have you tried a more recent build?

Comment 5

[thully]

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

Comment 6

[Erik van der Poel]

Date: Tue, 27 Apr 1999 21:45:04 -0700
From: Erik van der Poel <[e-mail]>
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
this.

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

Comment 7

[Chris Petersen]

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

Comment 8

[Randolph Fritz]

Attachment: A screenshot, showing too-small fonts

Comment 9

[Randolph Fritz]

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

[Randolph Fritz]

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.

Comment 11

[Frank Tang]

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.

Comment 12

[Frank Tang]

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.

Comment 13

[leger]

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

Comment 14

[shuang (gone)]

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

Comment 15

[german]

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

[bobj]

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.

Comment 17

[german]

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

Comment 18

[leger]

Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.

Comment 19

[Alan S. Jones]

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

Comment 20

[Kathleen :Brade]

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.

Comment 21

[Kathleen :Brade]

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

Comment 22

[Erik van der Poel]

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

[msanz]

need fixed in beta2 for localizing Linux

Comment 24

[Eli Goldberg]

CC:ing akkana at her request.

Comment 25

[Akkana Peck]

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

[Erik van der Poel]

It is quite clear that this bug is about the UI font. I'm updating the Summary
accordingly.

Comment 27

[bobj]

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

Comment 28

[msanz]

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

Comment 29

[bobj]

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

Comment 30

[leger]

Putting on [nsbeta2+] radar.  

Comment 31

[Brendan Donohoe]

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

Comment 32

[Erik van der Poel]

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?

Comment 33

[Akkana Peck]

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

[german]

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

Comment 35

[Akkana Peck]

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

[don]

German,

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

Comment 37

[german]

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.

Comment 38

[Akkana Peck]

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

[german]

yep this would work for modern windows as well IMO. Hyatt, any objections?

Comment 40

[Matthew T (active 1999-2002)]

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

[german]

BTW:
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 
machines.

Comment 42

[Akkana Peck]

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

[german]

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

Comment 44

[german]

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

Comment 45

[don]

Taking this ...

Comment 46

[don]

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.

Comment 47

[Akkana Peck]

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

Comment 48

[Chris McAfee]

m17

Comment 49

[tenthumbs]

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

[Jeffrey Baker]

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

Comment 51

[verah (gone)]

Nav triage team: [nsbeta3+]

Comment 52

[tenthumbs]

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

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

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

[Chris McAfee]

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

[Chris McAfee]

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

Comment 55

[Chris McAfee]

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

Comment 56

[tenthumbs]

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

Comment 57

[Akkana Peck]

Sure, that would be okay too.

Comment 58

[tenthumbs]

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

[Chris McAfee]

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

Comment 60

[tenthumbs]

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

Comment 61

[Akkana Peck]

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

[Chris McAfee]

We still have a problem with font size, Mac wants to specify
fonts in pixes and Win32/Linux want to use points/mm.

Comment 63

[Matthew T (active 1999-2002)]

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

[german]

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

Comment 65

[Chris McAfee]

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.

Comment 66

[tenthumbs]

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

[Akkana Peck]

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

[marlon bishop]

Attachment: mac arial vs. helvetica explanation

Comment 69

[marlon bishop]

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

[Akkana Peck]

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

[Akkana Peck]

Attachment: Moz/Linux Arial vs. Helvetica screenshot

Comment 72

[Chris McAfee]

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

[tenthumbs]

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

[leger]

This looks pretty good with the new modern skin.  Not critical to stop ship.  
Low profile polish.  Moving to P3.  Adding [PDTP3]

Comment 75

[german]

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

[Jeffrey Baker]

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

[tenthumbs]

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

[Peter Trudelle]

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

[tenthumbs]

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

Comment 80

[Akkana Peck]

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

[Jeffrey Baker]

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

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

[Akkana Peck]

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

[Jeffrey Baker]

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

[Peter Trudelle]

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

[Jeffrey Baker]

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

[Peter Trudelle]

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

Comment 87

[Erik van der Poel]

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

Comment 88

[Jeffrey Baker]

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

[Blake Ross]

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

Comment 90

[Akkana Peck]

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

[marlon bishop]

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 

Comment 92

[Hixie (not reading bugmail)]

Actually, CSS makes allowances for that. We just don't implement the code that
would solve that particular problem. ('font-size-adjust')

Comment 93

[tenthumbs]

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

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

[hangas]

Marking nsbeta3- until this bug can be assigned to an engineer.

Comment 95

[tenthumbs]

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.

Comment 96

[Akkana Peck]

Handing German's bugs to Don.

Comment 97

[Phil Peterson]

Don's looking into this

Comment 98

[verah (gone)]

Changing relnote keyword to relnote3.

Comment 99

[don]

Taking off the beta 3 radar and nominating for RTM.

Comment 100

[don]

I really need to get to the bottom of this one ...

Comment 101

[don]

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

Comment 102

[Akkana Peck]

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

[Jeffrey Baker]

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

[marlon bishop]

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

[don]

Marlon, to which bug are you referring?

Comment 106

[german]

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"

etc.

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

[tenthumbs]

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

[marlon bishop]

don - bug #54105

Comment 109

[Akkana Peck]

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

Comment 110

[Alec Flett]

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

[don]

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

Comment 112

[Erik van der Poel]

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

Comment 113

[Alec Flett]

Attachment: add a default pref so that real screen res. is used

Comment 114

[Erik van der Poel]

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

[german]

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

Comment 116

[Alec Flett]

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

[Jeffrey Baker]

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

Example:
	
	DisplaySize 327 243

The physical screen size is normally found in the display's owner's manual.

Comment 118

[Erik van der Poel]

The rounding is performed in mozilla/gfx/src/gtk/nsFontMetricsGTK.cpp, in
nsFontMetricsGTK::Init(), where it is setting mPixelSize.

Comment 119

[Alec Flett]

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

Comment 120

[Alec Flett]

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

[Jeffrey Baker]

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

Comment 122

[Alec Flett]

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)) /
float(aDpi)));
  mTwipsToPixels = 1.0f / mPixelsToTwips;

Comment 123

[Erik van der Poel]

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

Comment 124

[Alec Flett]

ok, experimenting with the rounding to see what I can find.

Comment 125

[Erik van der Poel]

>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

[tenthumbs]

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

[tenthumbs]

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

[Alec Flett]

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

[Alec Flett]

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

[Akkana Peck]

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

[Jeffrey Baker]

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

Comment 132

[tenthumbs]

> 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

[tenthumbs]

Attachment: 110K zip file showing current screenshots

Comment 134

[Jeffrey Baker]

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

[tenthumbs]

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

[tenthumbs]

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" \
unmatched

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

It all depends on what question you ask.

Comment 137

[Alec Flett]

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.

Comment 138

[Erik van der Poel]

> 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

[Akkana Peck]

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

[Alec Flett]

Attachment: fix for rounding issue

Comment 141

[Alec Flett]

Attachment: sample HTML file to show font and pixel-sized fonts

Comment 142

[Alec Flett]

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

[Alec Flett]

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

[timeless]

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

Comment 145

[german]

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 146

[german]

Sorry I meant http://blues/users/german/publish/openLocation2.xul

Comment 147

[german]

Attachment: Use this xul file with the next to be uploaded css file to see the effects of using system fonts in controls

Comment 148

[german]

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

[Alec Flett]

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:
http://lxr.mozilla.org/seamonkey/source/layout/base/src/nsPresContext.cpp#82

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

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

[tenthumbs]

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

[Alec Flett]

Whatever.

Comment 152

[Alec Flett]

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

[Alec Flett]

ok, marking this WONTFIX once and for all - the issues should be covered by the
bugs I just filed.

Comment 154

[Dave North]

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

[Blake Ross]

vrfy wontfix