Over the last week, several chrome font specifications have been changed from points or other useful metrics to pixels. Mozilla must not specify font sizes in pixels. For example, the personal toolbar font is now 11px high. This is completely unreadable on my high resolution display. This is a regression because these fonts were formerly specified in sizes such as points and mm, hwich scale properly with display resolution. The change to pixel sizes is a serious problem that needs to stop ASAP. Here is a list of all pixel font sizes in skins: modern/communicator/skin/button.css:12: font : 11px arial; modern/communicator/skin/button.css:233: font-size : 10px; modern/global/skin/menu.css:204: font-size : 9px; modern/navigator/skin/navigator.css:379: font-size : 9px; classic/global/skin/console.css:25: font-size: 12px;

Nominating for beta3 consideration. This is an easy, low-risk fix. We don't want to ship a beta that looks like a bad winamp skin.

I agree, this makes those areas of the product useless, even at 100 dpi. rewriting summary, cc german for UE input, ben to get Classic skin fixed.

Please, please, don't go back to mm or pt which cause problems with low logical resolutions. What really is needed here is inheritance of the system-level UI font prefs or a Mozilla-level UI font pref.

Bug 16729 (use CSS system fonts for skins we ship) would fix this (assuming that bug 33313, get CSS system fonts working on gtk, also got fixed).

I usually use a low-res 75dpi setting but I agree that pixels are the wrong unit. I can switch between a low-res and a high-res setting and Mozilla should remain readable. It doesn't. This is yet another loser.

This is only getting more ridiculous. In Linux build 2000-09-13-12, fonts are specified in pixel units in five places in the modern skin: skins/modern/communicator/skin/button.css skins/modern/global/skin/button.css skins/modern/global/skin/global.css skins/modern/global/skin/menu.css skins/modern/global/skin/menulist.css Now tooltips, the personal toolbar, the status bar, and buttons have fonts pointlessly specified in pixel units. CC hewitt due to bogus review on this bad code.

The default system font sizes needs to be used. I use a 74 dpi resolution, and font sizes specified in physical units (e.g. points) are unreadable.

marking nsbeta3- and marking future. We would like very much to make Modern support system fonts and allow for changing the font from a Pref inside the app; sadly there is no time to do either of these.

You don't need to implement system fonts or prefs. You need only go through the CSS files substituting point sizes for pixel sizes. This solves 99% of the problems, and is a 1-second job for a competent editor.

As stated above, using points (or in, mm, pc or cm) is the *Wrong Way* and causes other issues (bug 17926 to be precise).

Changing the css is not possible. If the fonts can change size then this will break the current implementation of the Modern skin. We do not have time to make every area that has a font scale to the font size. We do plan to do this after N6 is released.

I'm getting rather bored of that argument. Physical units are absolutely THE ONE TRUE correct way to specify type sizes everywhere. The only places that physical units are inappropriate are on broken systems, such as the MacOS which always ass-u-me-s 72 dpi. The correct solution here is to specify the chrome fonts in points. The user should set Mozilla's resolution preference to the right value. On broken systems, Mozilla can translate the specified font size to pixels, and request the font from the system. Permute this for varous platforms. Good Example: MacOS user has a 100 dpi screen, MacOS assumes 72 dpi, and the chrome type is 9 points, or 1/8th inch. The type size should be 12.5 pixels high on that user's display. Mozilla, knowing the deficiencies of the OS, rounds to 12 pixels and requests *either* a 12-pixel or 12-point font from the OS. The resulting type on the screen is in fact 8.640 points, which is reasonably close to the desired size. Bad Example: MacOS user has 100 dpi screen, Unix user has 150 dpi screen, chrome author specifies type at 11 pixels. On the MacOS screen, the type is close to 8 points, but on the Unix screen the type is only 5 points, which is of course completely unreadable. If the chrome author had instead specified 8 points, the type would be 11 pixels high on the Mac, and 17 pixels high on the Unix box, and still readable in both places. Pixels units are WRONG WRONG WRONG.

I have a ~15" monitor set to a resolution of 800x600. In Windows, the default DPI is 96. My monitor has a 74 DPI resolution (I've measured!). *If* the font size is specified in points, it will either look to small for people have set their logical resolution correctly, or too large for all the other (which haven't bothered to change it).

Your argument still sounds bogus to me. If the resolution is set correctly the font will not look "too large", it will be exactly the intended size! Also you fail to quantify "too large" and "too small". If the fonts are in pixel units, they will certainly be rendered at some random, unpredictable size. Finally, if someone has their resolution set incorrectly, there's hardly anything we can do to kludge around that. We aren't trying to hack around people whose proxies and DNS are incorrectly setup, why should we cripple the product for people whose screen resolution is misconfigured?

>I'm getting rather bored of that argument. You still haven't proved it wrong. Argument in the context of theory and the real world: * Two users with identical screens may want to use differently sized fonts. Neither a particular fixed physical length nor a a particular fixed pixel length is good for both of them. Arguments in the context of real world: * Mozilla has no way of querying the hardware for the physical resolution. The correctness of the logical resolution depends on a guess or user input. The concept of "logical resolution" is more difficult to grasp than the concept of setting a font size pref. In reality, Mozilla will run in numerous environments with broken logical resolution values. * Toolbar font sizes are generally at the lower end of the at all readable sizes. Supposing that Mozilla's font sizes are specified in points to be while Mozilla's default guess for logical resolution remains at 96 ppi, the font sizes that will become unreadable with reasonable ppi values (as Karl Ove descrived above and as described in bug 17926). * If the point sizes are chosen to be readable at (eg.) 70 ppi and up, people who have set their logical resolution to 96 ppi will complain about the fonts being too large. Making the UI font sizes user-settable and independent of the logical resolution and the Web content font size pref (either Mozilla-wide or using the system-wide settings) is the right way. Physical units are WRONG, WRONG, WRONG Fixed pixel sizes are wrong Using user-settable sizes is RIGHT, RIGHT, RIGHT

> Physical units are WRONG, WRONG, WRONG > Fixed pixel sizes are wrong > Using user-settable sizes is RIGHT, RIGHT, RIGHT And using system fonts (this includes system font sizes) is right, right, right ...

Adding myself and Paul Hangas to cc

Just an update - we're actually down to bug 55464 (a dependancy of bug 16729) which is the only thing that is preventing modern from being "scalable" - right now we have to use pixels because of the way a few of the wigets work. After that we can switch to the system font, so we won't be specifying the font size in pixels or points, we'll just fall back to the system font.

Is this problem now fixed in the trunk builds, where both Modern and Classic now adopt system fonts?

> Is this problem now fixed in the trunk builds, > where both Modern and Classic now > adopt system fonts? Does Modern also use system fonts? Great! But the answer would still be no, since bug #51346 isn't fixed yet.

Adding dependancy.

Sending to Hewitt.

dup *** This bug has been marked as a duplicate of 51346 ***

Verified dup