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.
Attached image A screenshot, showing too-small fonts (deleted) —
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.
Attached image mac arial vs. helvetica explanation (deleted) —
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.
Attached patch fix for rounding issue (deleted) — Splinter Review
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: