Closed Bug 5236 Opened 25 years ago Closed 24 years ago

Unix: default UI font very small

Categories

(SeaMonkey :: General, defect, P2)

x86
Linux

Tracking

(Not tracked)

VERIFIED WONTFIX

People

(Reporter: thully, Assigned: alecf)

References

Details

(Keywords: platform-parity, Whiteboard: [nsbeta3-][RTM NEED INFO])

Attachments

(9 files)

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.
Assignee: troy → kipp
Assignee: kipp → erik
Status: NEW → ASSIGNED
Target Milestone: M5
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.
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.
Target Milestone: M5 → M6
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.
Summary: On Linux, default font very small. → Unix: default font very small
Thully, have you tried a more recent build?
No, I have not tried a more recent build.  I cannot download 8MB that often with
my speed of connection.
Summary: Unix: default font very small → [PP]Unix: default font very small
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
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
this.

If the pref is not set, it uses the default value of 96.
Status: RESOLVED → VERIFIED
In the 5/17 Linux Build, the default font size appears correctly.
Status: VERIFIED → REOPENED
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.
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.
Component: Layout → UE/UI
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.
Assignee: erik → shuang
Status: REOPENED → NEW
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.
Resolution: WORKSFORME → ---
Target Milestone: M6 → M14
Clearing WorksForMe Resolution.  Moving from M6 to M14 for Beta since reopened.
shuang, please reset milestone if this is incorrect.
Assignee: shuang → german
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.
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.
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.
Keywords: pp
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
Status: NEW → ASSIGNED
Target Milestone: M14 → M20
Summary: [PP]Unix: default font very small → Unix: default font very small
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
Blocks: 28883
Is this bug related to 18135
The descriptions are very very close.

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
*** Bug 30285 has been marked as a duplicate of this bug. ***
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.
need fixed in beta2 for localizing Linux
Keywords: nsbeta2
CC:ing akkana at her request.
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.
It is quite clear that this bug is about the UI font. I'm updating the Summary
accordingly.
Summary: Unix: default font very small → Unix: default UI font very small
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.
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
Target Milestone: M20 → ---
Cleared TM M20 since it conflicts with the "nsbeta2" nomination.
Putting on [nsbeta2+] radar.  
Whiteboard: [nsbeta2+]
*** Bug 39431 has been marked as a duplicate of this bug. ***
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?
Severity: normal → major
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.
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
Status: ASSIGNED → NEW
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.
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. :-)
Assignee: don → 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.

Status: NEW → ASSIGNED
Whiteboard: [nsbeta2+] → [nsbeta2+] ETA 7/21
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)?
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?
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.
Matthew's suggestion of "Geneva, Tahoma, Helvetica, Arial, sans-serif;" with
3.5mm font-size looks fine on my RH 6.2 system.
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.
Akkana, can you try 3mm on your RH6.2 system?
Taking this ...
Assignee: german → don
Status: ASSIGNED → NEW
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: nsbeta2nsbeta3
Priority: P3 → P2
Whiteboard: [nsbeta2+] ETA 7/21 → (PDT: this WAS nsbeta2+ earlier so don't freak out)
Target Milestone: --- → M20
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).
Whiteboard: (PDT: this WAS nsbeta2+ earlier so don't freak out) → (PDT: this WAS nsbeta two plus earlier so don't freak out)
m17
Target Milestone: M20 → M17
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.
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.
Nav triage team: [nsbeta3+]
Whiteboard: (PDT: this WAS nsbeta two plus earlier so don't freak out) → [nsbeta3+]
> 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.
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.
*** Bug 40888 has been marked as a duplicate of this bug. ***
Depends on: 40888
Keywords: UE2
pref panels have been fixed, 3.5mm font looks Ok on Linux, Win32,
but NOT on Mac (too big?).  Need help on Mac.
Priority: P2 → P1
3.5mm = 9.96pt so why not just use 10pt; it would make more sense.
Sure, that would be okay too.
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.
Investigating platform-specific style rule for this.
Linux & Win32 look ok, Mac looks huge with this change.
The geneva font _is_ huge. I installed it on my Linux system and it renders
significantly larger that Tahoma or Helvetica.
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?
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. :-)
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. 
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
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
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.
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.
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.
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.
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.
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]
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.)
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
but math is hard! ;-)  Thanks, that puts me at 102, so I guess my setting was
correct.
> 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.
Depends on: 16729
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.
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.
Whiteboard: [nsbeta3+][PDTP3]
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.
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')
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.
Marking nsbeta3- until this bug can be assigned to an engineer.
Whiteboard: nsbeta3-
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.
Assignee: german → don
Whiteboard: nsbeta3-
Handing German's bugs to Don.
Don's looking into this
Whiteboard: [need info]
Changing relnote keyword to relnote3.
Keywords: relnoterelnote3
Taking off the beta 3 radar and nominating for RTM.
Keywords: rtm
Whiteboard: [need info] → [nsbeta3-][need info]
I really need to get to the bottom of this one ...
Priority: P3 → P2
Whiteboard: [nsbeta3-][need info] → [nsbeta3-][RTM NEED INFO]
Adding alecf to "cc" list so he can save my ass.
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.
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 :)
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.
Marlon, to which bug are you referring?
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.

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.
don - bug #54105
If the buttons in New Modern are going to be rescalable, I'll reiterate my plea
for using the CSS system font.
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?
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
theme?
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?
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).
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?
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.
The rounding is performed in mozilla/gfx/src/gtk/nsFontMetricsGTK.cpp, in
nsFontMetricsGTK::Init(), where it is setting mPixelSize.
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.
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)
That isn't the solution at all.  There are 20 twips to a point, regardless of
the output device resolution.
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;
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.
ok, experimenting with the rounding to see what I can find.
Status: NEW → ASSIGNED
>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.
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.
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.
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.
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;

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).
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.
> 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.
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.
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.
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.
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...)
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.
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?
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.
<erik> but is Netscape 6's default theme different from Mozilla's?
Yes. Netscape 6 defaults to modern, Mozilla defaults to classic.
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.
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.
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?
Whatever.
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.
ok, marking this WONTFIX once and for all - the issues should be covered by the
bugs I just filed.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago24 years ago
Resolution: --- → WONTFIX
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).

vrfy wontfix
Status: RESOLVED → VERIFIED
Keywords: rtm, UE2nsrtm
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.

Attachment

General

Creator:
Created:
Updated:
Size: