Closed Bug 439195 Opened 17 years ago Closed 14 years ago

default chrome fonts too small at 96dpi on OS/2

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Platform:
x86
OS/2
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: stevew, Unassigned)

References

(
URL
)

Details

Attachments

(7 files, 2 obsolete files)

desktop screenshot, 100% 120 DPI
256.90 KB, image/png
Details
desktop screenshot, layout.css.dpi set to 96 in Firefox & Minefield; otherwise all 120 DPI
253.87 KB, image/png
Details
Desktop screenshot, 1600x1200 pixel, 96 dpi
502.93 KB, image/jpeg
Details
screenshot - WarpSans vs. WorkPlace Sans, FF2 vs. FF3 @ 96 DPI
160.32 KB, image/png
Details
screenshot - WarpSans vs. WorkPlace Sans, FF2 vs. FF3 @ 120 DPI
173.24 KB, image/png
Details
WorkPlace Sans 0.6 at various point sizes
67.81 KB, image/png
Details
Peter's patch with the 7 changed to 11
65.71 KB, application/octet-stream
Details
As can be seen in attachment 323657 [details], changing the default 9pt to 10pt makes the chrome look far better; Workplace Sans just looks really bad at the smaller size. In the top portion, note how the 'P' in 'Private' barely has any space inside of the loop. In the middle and bottom, note how much more legible the text is - you can barely read the 9pt version. To my eyes, Workplace Sans 10pt looks much closer to WarpSans 9pt in Seamonkey 1.x. For anyone who wants to try this, it's a single line in userChrome.css: * { font-size: 10pt !important; }
I've been using 10pt for years, probably 4 or more, but I do it on my whole OS/2 desktop. Why should OS/2 Geckos not continue to use system menu (CSS font-family: menu) fonts as they do now on both OS/2 and the 3 main other platforms? If workplace sans is bad at 9pt, why not choose something else system wide, or set 10pt system wide? Have you tried setting Liberation Sans or DejaVu Sans system wide? Fedora, Mandriva, Debian & Ubuntu Linux all default to 10pt DejaVu Sans for system menu fonts. SUSE will also use DejaVu Sans system wide if neither Arial nor Albany AMT nor Verdana are available.
URL: http://fm.no-ip.com/auth/Font/fonts-f...
(In reply to comment #1) > If workplace sans is bad at 9pt, why not choose something else > system wide, or set 10pt system wide? Changing the system-wide settings because one app looks bad doesn't make much sense to me...
I still think this is a specific problem of Steve's setup (the DPI of the display?). On mine I can very well see the hole in the P in the preferences. I could write a small test program to print out the DPI used but there is probably also a way to ask SNAP for it. And I am actually not sure how, where, and what to change to 10pt. Just Workplace Sans 10 if WarpSans 9 would be used otherwise? And hardcode it to 10? I actually tried the hardcode way a while ago, and it still doesn't look right, because with 10px size it is larger than in 1.8 branch builds. At least on my system.
I am running 1400x1050 with SDDFONTDPI=96 and SDDFONTSIZE=small. As I recall, there used to be a DPI setting in Mozilla, but I think that is long gone (?), and I never messed with it before. Is it possible that FreeType and/or FontConfig is not taking DPI into account, and expects 120dpi?
(In reply to comment #4) > I am running 1400x1050 with SDDFONTDPI=96 and SDDFONTSIZE=small. As I recall, > there used to be a DPI setting in Mozilla, but I think that is long gone (?), > and I never messed with it before. Well over a year ago, browser.display.screen_resolution was replaced by layout.css.dpi. Here. screen resolution is 1400x1050, layout.css.dpi is set to 0, and in CONFIG.SYS has: SET SDDFONTSIZE=medium REM SET SDDFONTDPI=120 SET SDDICONS=small All 4 Geckos are set to Arial for proportional sans-serif. The desktop menu font is 10pt.
Here you can see in Firefox & Minefield the impact of layout.css.dpi is the same in both for web page content, but that in Minefield it has no impact on UI. That's the result of a bug fix in Gecko 1.9 intended to keep Gecko using system settings for the UI.
OK, I can reproduce the problem with SDDFONTDPI=96, SDDFONTSIZE doesn't seem to influence the behavior. Upper-case characters are 1px too short while lower case characters have the correct height. This could be fixed by using 10pt instead of 9pt but I still don't see a good reason to do so. I debugged gfx\src\thebes\nsSystemFontsOS2.cpp and gfx\thebes\src\gfxOS2Fonts.cpp a bit and I think that the code there is correct. For 9pt it computes a size of 12px (9pt * 96dpi / 72). If I artificially add 1px to the outgoing number I get the correct height for the upper-case chars, too. If I have "9.WarpSans" set. If I set instead e.g. "14.Helvetica Bold" for menus in the system, the outgoing size is correct without doing any weird code changes like that. I could special-case WarpSans again, but without any good understanding on why it again behaves differently, I don't want to do that.
This shows Firefox 3.0pre and other applications on a system with SDDFONTDPI=96. To get the same size for the menu font as in the other apps, I have to increase the font size for Workplace Sans to 11pt.
Peter, it looks to me from Christian's screenshot that the code to substitute Workplace Sans for font: menu (WarpSans.9) is making the substitution after the system specifies the low resolution version of WarpSans, whereby the conversion code provides bolded 7pt Workplace Sans instead of 9pt, probably due to SDDFONTSIZE=small. I'm using SDDFONTSIZE=medium and freetype supported 10pt font for system menus, so no substitution takes place here, and FF3 UI fonts are the same as all other apps.
Peter knows better than I, but I doubt any variation in WarpSans has anything to do with it - it does a substitution to WorkPlace Sans long before anything else happens.
1-The line (The Quick Brown Fox Jumps Bookmarks Over The Lazy Dog) length of the CSS Menu 9pt line in FF2 is almost exactly the same as the CSS Menu 11pt line in FF3, while much longer than the CSS Menu 9pt & 10pt lines in FF3. 2-The apparent size of CSS Menu 11pt in FF3 is similar in apparent size to CSS Menu 9pt in FF2, while CSS Menu 9pt & 10pt in FF3 are quite smaller. 3-Looking at the CSS Menu px-sized lines it is readily apparent that there are alternating larger and smaller increments between sizes, and the size that would probably look best in the FF3 menus is probably the 14px size that is eschewed in favor of 15px when 11pt is requested.
1-The line length of the CSS Menu 9pt line in FF2 is exactly the same as the CSS Menu 10pt line in FF3, while much longer than the CSS Menu 9pt line in FF3. 2-The apparent size of CSS Menu 10pt in FF3 is much larger than the apparent size of CSS Menu 9pt in FF2, due to the former's taller and fatter letters with less space between letters and lines. 3-Looking at the CSS Menu px-sized lines it is readily apparent that there are alternating larger and smaller increments between sizes, and the size that would look best in the FF3 menus is probably the one that does not exist between 15px and 16px, or the 16px size that is eschewed in favor of 17px when 10pt is requested.
Using my most recent eCS beta installation, I did a bunch of CONFIG.SYS changes to SDDFONTSIZE & SDDFONTDPI, reboots, switches between scalable & WarpSans system menu fonts, and screenshots to try and quantify what we've seen. For the time being, these can be viewed at http://fm.no-ip.com/SS/Fnt/ECS/ In summary: 1-menu font size depends on SDDFONTDPI, if set 2-titlebar height depends on SDDFONTSIZE (probably dialog sizing too), if set 3-Desktop/FF2 UI @ 96 DPI uses 9pt(1px-13px) WarpSans 4-Desktop/FF2 UI @ 120 DPI uses 9pt(14px-infinitypx) WarpSans 5-Whether 10pt WorkPlace Sans or 11pt WorkPlace Sans is closer to FF2's WarpSans menu text size depends on whether the desktop is running 96 or 120 DPI. 6-Calling WorkPlace Sans in FF3 by px size rather than pt size should produce more a more pleasant match to the menus elsewhere. 7-'.menubar-text, .menu-text, menuitem, menu, .menuitem-iconic, .bookmark-item, .popup-internal-box {font-size: 15px}' (or {font-size: 11pt}) seems to go a long way in making FF3 UI text similar in size & appearance to the rest of a 96 DPI desktop. 8-'.menubar-text, .menu-text, menuitem, menu, .menuitem-iconic, .bookmark-item, .popup-internal-box {font-size: 16px}' in userChrome.css seems to go a long way in making FF3 UI text similar in size & appearance to the rest of a 120 DPI desktop.
I actually found an FAQ for FreeType that said that such things can happen with hinting switched on. Please try with gfx.os2.font.hinting set to 0.
Turning off hinting does allow you to see the "hole" in the 'p' character, but the fonts are still too small, and they are too fuzzy and gray, as in the original screen shots in bug 432575.
Summary: change default point size for chrome to 10pt on OS/2 → default chrome fonts too small at 96dpi on OS/2
I just came across this: https://bugzilla.mozilla.org/show_bug.cgi?id=387969#c14 Is that applicable to the OS/2 code (if not, should it be)?
Yes, we react to browser.display.auto_quality_min_font_size by disabling kerning, no matter if it's supported by the font, if the size is too small. We don't do ligatures on OS/2 anyway. But I don't really see the relation to this bug?
Other than being an optimization for small fonts, it's not really related - sorry for cluttering this bug. :-/
(In reply to comment #13) > 6-Calling WorkPlace Sans in FF3 by px size rather than pt size should produce more a more pleasant match to the menus elsewhere. > 7-'.menubar-text, .menu-text, menuitem, menu, .menuitem-iconic, .bookmark-item, .popup-internal-box {font-size: 15px}' (or {font-size: 11pt}) seems to go a long way in making FF3 UI text similar in size & appearance to the rest of a 96 DPI desktop. > 8-'.menubar-text, .menu-text, menuitem, menu, .menuitem-iconic, .bookmark-item, .popup-internal-box {font-size: 16px}' in userChrome.css seems to go a long way in making FF3 UI text similar in size & appearance to the rest of a 120 DPI desktop. Felix, thanks for your nice analysis. Just two things: - Testing your item 8, I found 16px for 120dpi is too large. 15px _looks_ like it was too small, but comparing character boxes it seems to me that it actually is correct. Just that Workplace Sans is not a perfect reproduction of WarpSans. - Workplace Sans is effectively selected in pixel-size, just that for 96dpi that pixel size is not determined if one wants to replicate WarpSans. If Christian and Steve agree (after testing suggestion 7) I could hardcode the 15px for WarpSans with 96dpi.
Specifying all of those items individually, rather than '*', I can see that the text in the status line (i.e. 'Done') and below the icons (i.e. 'Get Msgs') is still too small. To me, 15px looks a little on the large size, but it's better than the current default; 10pt still looks better to me. It would be good to have other opinions - Christian (or ...)?
Any idea how to change the font used for Bugzilla form fields? https://bugzilla.mozilla.org/show_bug.cgi?id=432575#c51 The 'P' characters in the input fields still look like: https://bugzilla.mozilla.org/attachment.cgi?id=323657
(In reply to comment #19) > - Testing your item 8, I found 16px for 120dpi is too large. 15px _looks_ > like it was too small, but comparing character boxes it seems to me > that it actually is correct. My judgements of comparative size were made primarily using a ruler to measure the width of the word "Bookmark". Simply looking without measuring is deceptive. > Just that Workplace Sans is not a perfect reproduction of WarpSans. You got that right. :-)
(In reply to comment #19) > If Christian and Steve agree (after testing suggestion 7) I could hardcode the > 15px for WarpSans with 96dpi. So if an OS/2/Linux multibooter had changed his OS/2 desktop to match typical Linux desktops in using DejaVu Sans 10pt for menu fonts, his OS/2 Geckos would still use WorkPlace Sans 15px?
(In reply to comment #23) > (In reply to comment #19) > > If Christian and Steve agree (after testing suggestion 7) I could hardcode the > > 15px for WarpSans with 96dpi. > > So if an OS/2/Linux multibooter had changed his OS/2 desktop to match typical > Linux desktops in using DejaVu Sans 10pt for menu fonts, his OS/2 Geckos would > still use WorkPlace Sans 15px? No, unless DejaVu Sans reports itself as WarpSans. But before making that change I would really like to make sure that it doesn't hurt on any setup. So, if you are running with 96dpi at whatever real resolution and .menubar-text, .menu-text, menuitem, menu, .menuitem-iconic, .bookmark-item, .popup-internal-box { font-size: 15px } does not do the right thing, please speak up.
Ah, wait. Getting confused in the flurry of bugmail. Steve already said in comment 20 that 10pt would be better. Problem is that I'm not sure if I can easily change the point value. I guess I could make a test DLL...
Depends on: 490561
No longer depends on: 490561
SM11x with WarpSans, then SM2 with WorkPlace Sans 0.6 at default 9pt, 10pt, 10.5pt, and 11pt.
In m.d.p.os2, Alex Taylor wrote: WarpSans comes in 2 sizes: 9pt/120dpi, and 9pt/96dpi. The 9pt/96dpi version is actually available in some contexts as 7pt/120dpi. What Mozilla is rendering in those forms is 7-point Workplace Sans, which suggests that it's trying to work with the same relationship, i.e. if dpi==96 then map the requested 9pt font to the actual 7pt one. IMO it should really not be doing that; requesting the 9pt size at 96dpi should _already_ get the correct size (i.e. something that's roughly equivalent to 9pt WarpSans under 96dpi). Whether it's something in Mozilla itself, or in FreeType, or in FontConfig that's doing it, I couldn't say...
(In reply to comment #27) > In m.d.p.os2, Alex Taylor wrote: > > What Mozilla is rendering in those forms is 7-point Workplace Sans, > which suggests that it's trying to work with the same relationship, > i.e. if dpi==96 then map the requested 9pt font to the actual 7pt one. And then recanted after further discussion: In fact, though, I think it is actually behaving correctly. In retrospect, it makes sense. 120dpi/9pt is the same as 96dpi/11pt. So it's probably correct that 120dpi/7pt is the same as 96dpi/9pt. WarpSans is a bitmap font, which follow different rules than outline fonts.
(In reply to comment #28) > In fact, though, I think it is actually behaving correctly. In > retrospect, it makes sense. 120dpi/9pt is the same as 96dpi/11pt. > So it's probably correct that 120dpi/7pt is the same as 96dpi/9pt. > > WarpSans is a bitmap font, which follow different rules than outline fonts. To clarify: what's working "correctly" (as far as I can see) is the scaling of the font by the font driver. Whether Mozilla (apparently) forcing the chrome font to be always 9pt size, regardless of dpi is "correct" or not is a separate issue, and one that goes back to the original bug report above...
(In reply to comment #29) > Whether Mozilla (apparently) forcing the chrome font to be always 9pt size, > regardless of dpi is "correct" or not is a separate issue, and one that goes > back to the original bug report above... In default themes, Mozillas do not force chrome fonts to a size per se. What they do is query the OS for special fonts, such as menu, caption, message box, etc., which the OS "provides" (other than CSS is used, I don't know the mechanics, just the impact) both as to family and size. This is supposed to populate Mozillas with the same fonts as other applications, giving consistency within any given platform or DTE. http://fm.no-ip.com/Auth/Font/fonts-system.html can show you the various fonts returned by calling those special names.
Mozilla uses whatever point size the system tells it about. Querying the system we get a string like 9.WarpSans where the leading number is then converted to the point size we want, see <http://hg.mozilla.org/mozilla-central/annotate/2f7e4b1a5030/gfx/src/thebes/nsSystemFontsOS2.cpp#l192>. A few lines further down this number is then scaled by the resolution in DPI queried from the system. It's really stupid if OS/2 lies to us about the font size that's really needed for the font string, but a workaround can easily be implemented, like this: /* 9.WarpSans at 96 dpi resolution really means 7pt WarpSans */ if (vertScreenRes == 96 && !strncmp(szFontNameSize, "9.WarpSans", 10) { aFontStyle->size = 7.; } (At line 203.) Somebody else has to make a build with that...
Attached file test gkgfxthb.dll (obsolete) —
This is a test build of gkgfxthb.dll against the SeaMonkey webm build from Jun 13 at netlabs. With Peter's simple fix. Replace the one in components. I haven't actually tested this.
Thanks guys, but the size change is backwards. I don't want it smaller (which did succeed in making things worse!), I want it bigger. ;-) If you change that 7 to 11, it should have the intended result: "120dpi/9pt is the same as 96dpi/11pt"
Attached file test gkfxthb.dll ver2 (obsolete) —
Second try with the 7 replaced by 11 per Steve's request. Once again linked against the webm SeaMonkey from June 13th. Also untested
Attachment #456062 - Attachment is obsolete: true
Dave, thanks again, but did you attach the right file? It is dated 6/18, and doesn't seem to do anything differently from the original 6/13 version.
Sorry Steve, I have too many object directories and it was late. This should be the right one.
Attachment #456143 - Attachment is obsolete: true
That definitely made a difference, although some things still use the smaller size, including the status line (where it shows the URL when you hover one, or "Done"), and the text under the toolbar icons in Mail/News. Interestingly enough, those are the same items I mentioned in comment 20. Of course, now that Alex has bitmap versions, they are actually readable, and I don't mind the smaller size as much as I did before. ;-)
Should we consider getting the patch into the tree?
(In reply to comment #36) > Created an attachment (id=456222) [details] > Peter's patch with the 7 changed to 11 > > Sorry Steve, I have too many object directories and it was late. This should be > the right one. Of course that is gkfxthb.dll with Peter's patch with 7 changed to 11 applied
Yes, the patch certainly helps a lot. It would be nice to know why some of the items are not properly affected, though.
Steve, that probably depends on which INI key is taken for which onscreen element. There are "IconText", "Menus", and "WindowText". My guess is that the last one is taken for the status bar. For menus (which so far was the complaint?) it obviously takes the "Menus" entry which is the one that is most often configured to be 9.WarpSans IIRC.
Statusbar is intended, at least in Modern theme, to be smaller than menu text. In global/skin/global.css line 122, font-size for statusbar is set to 83.3333%. I have to think the base for that to be CSS menu, which is normally 9.WarpSans. With 9.WarpSans as the starting point, the next pt size smaller one would think to be the natural result. With WarpSans, there is no 8, so at 120 DPI at least drops to 7, but with Workplace Sans, 8 should be expected. At 96 DPI there couldn't be a WarpSans drop to less than 9, so 96 DPI users are/were probably used to statusbar text at the same size as menu text. Those who want to be sure which sizes actually get used might want to check against http://fm.no-ip.com/Auth/Font/fonts-comps-os2basic.html To avoid the size limitations of WarpSans, I've been using Trebuchet for my menus for several years, so I can't test this WarpSans/Workplace Sans chrome stuff myself.
After a lot of testing, I'm not convinced that there's more to this than the intersection of a possibly problematic font with one person's system settings and/or perceptions. I run at 1680x1050 with SDDFONTDPI=96 & SDDFONTSIZE=SMALL using Alex's FreeType v1.30. I set PM_SystemFonts->Menus and ->WindowText to many different TrueType fonts, and found in every instance that Mozilla rendered them wider & heavier than PM. I also did a few tests with the SDD settings rem'd-out and the results were the same. I didn't perceive any difference in these fonts' height when comparing PM's rendering to Mozilla's. I also tried Peter's suggestion of setting gfx.os2.font.hinting to 0. WorkPlace Sans looked vastly better but everything else looked worse (e.g. the Courier used by Bugzilla). If there are errors in converting points to pixels or in WorkPlace Sans' hinting, then let's fix them. But if the real problem is that WarpSans/WorkPlace Sans is too small (actually, too condensed) to be usable at 96dpi on a high-res display, then a code fix isn't appropriate. BTW... PM_SystemFonts->Menus only controls menus; everything else is controlled by ->WindowText. Try changing these settings to a less condensed 9pt font, then restart the browser (no reboot needed). I think you'll find menus and window text are far more readable.
(In reply to comment #42) > Statusbar is intended, at least in Modern theme, to be smaller than menu text. > In global/skin/global.css line 122, font-size for statusbar is set to 83.3333%. Thanks, that explanation makes sense. (In reply to comment #43) > After a lot of testing, I'm not convinced that there's more to this than the > intersection of a possibly problematic font with one person's system settings > and/or perceptions. The default font for the PM settings is WarpSans, so it's not just "one person." I concede that most people will not switch to 96dpi. > I set PM_SystemFonts->Menus and ->WindowText to many different TrueType > fonts, and found in every instance that Mozilla rendered This bug isn't about anything other than the "default" font settings. > I also tried Peter's suggestion of setting gfx.os2.font.hinting to 0. > WorkPlace Sans looked vastly better Using the new bitmap version does wonders. > BTW... PM_SystemFonts->Menus only controls menus; everything else is > controlled by ->WindowText. Try changing these settings I addressed this in comment 2.
I run at 120dpi, and I do see the occasional form button or whatnot being rendered much too small. The form at http://www.torrenteditor.com for example... for some reason the "Browse" button is not only rendered in Workplace Sans while all the others use my default browser font (Nu Sans), it is only shown at 7- or 8-pt size. (This is the non-bitmap version so I can't really identify the point size at a glance, but it's definitely not 9pt.)
Forgot to mention, this is SeaMonkey 2.0.5. In actual fact, it seems to be all "Browse" buttons on forms, not just the above site. I assume it uses default chrome setting for this (unlike SeaMonkey 1.1x which used the web page font).
(In reply to comment #46) > In actual fact, it seems to be all "Browse" buttons on forms That's the file-picker, and the website doesn't control that, the browser does. I agree with you that it is too small; without digging too much, I'd guess that comment 42 offers an explanation for these kinds of things.
http://www.torrenteditor.com/style.css specifies 8pt Tahoma for input with fallback to system font family if Tahoma isn't available. Input text there is tiny on Linux too.
It does look as though there's a scaling discrepency between WarpSans and Workplace Sans, but I don't think there's much that can be done about it. According to FontForge (when I tell it to rasterize bitmaps from Workplace Sans), 9pt at 96 dpi should produce a 12-pixel high max baseline extent. However, 9pt WarpSans is implemented as a 14-pixel high max baseline extent. That explains why 9.Workplace Sans shows up smaller than WarpSans at 96 dpi. This may be due, as I mentioned before, to OS/2 bitmap fonts following different rules for calculating point sizes. I'm not quite sure how it works, actually... the GPI documentation is a bit confusing on the subject.
Ping. What needs to happen here? CCing font people.
I'm not sure anything else needs to be done at this point. The scaling of Workplace Sans (the default chrome font under OS/2) is not actually wrong as far as I can see. Also, the font has been updated (several times, in fact) since the ticket was opened, and in a number of ways that should improve the situation. First, the default weight has been changed to have a wider stroke width throughout, which hopefully improves readability at very small sizes when antialiased. Second, it's available now in a build with embedded bitmaps, which makes the letters much clearer; and even the build without bitmaps has had all its (auto-generated) hinting removed, which also improves readability with FreeType 2. Steve should probably have the final say, though.
OK. I'll be very bold and close this bug then, reopen if needed. Not sure about the resolution, picking INCOMPLETE.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INCOMPLETE
I object to INCOMPLETE, changing to WONTFIX. The workaround listed in comment 0, along with the version of the font with embedded bitmaps, do make things work reasonably well. I think the underlying issue here is that IBM did screwy things for the WarpSans font, and replicating that (comments 31, 33) in Mozilla for the font substitution to Workplace Sans appears to be undesirable.
Resolution: INCOMPLETE → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: