Peterl wrote: All right, the decision has been handed down on us from up on high... We're going forward with switching the default pixel scaling on the Mac to 96 dpi. Mac heads, please make the appropriate changes (setting the twips to pixels ratio in the device contexts) (that also includes removing the 9 pixel minimum font size hack). Also, someone needs to start working on the prefs UI for this option.

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

Same goes for Unix. cc'ing Erik. Pierre, please reassign to appropriate Unix person to follow up there...

Assign the Unix part to me if you like. I wrote the most recent version of that.

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

We will experiment with the new CSS2 system font styles after M5 or as soon as the functionality is implemented on all platforms, this should resolve this problem.

I don't understand how the system font style stuff solves this scaling problem. Before I reopen this bug, could someone explain?

It doesn't. The system font issue is similar only that it may correct some font sizing issues. This bug is a general point/pixel scaling issue.

This bug shouldn't have been closed. Changing the status to Assigned. The target milestone is still M5.

Per discussion with <german>, it was a simple mistake: he meant to close #4951 which is assigned to him.

OK, I checked in the fix to make it assume 96dpi on X (GTK). It now ignores the X server.

If I change the dpi to 96, everything is way too small. In addition, if I remove the test that forces the fonts smaller than 9pt to be rendered as 9pt, many pages are totally illegible. Same problem as last month (see #2411): I have the changes in my tree but I think that we shouldn't check that in. In fact, I did check in most of it... I just did not turn it on. If you want to do it: - In gfx/src/mac/nsDeviceContextMac.cpp, line 32, change kPixelsPerInch to 96. - In gfx/src/mac/nsFontMetricsMac.cpp, line 31, change DONT_USE_FONTS_SMALLER_THAN_9 to 0 Reassigning to <rickg> to take a decision.

No. Your math is wrong. The lines in nsDeviceContextMac should be: mTwipsToPixels = kPixelsPerInch/(float)NSIntPointsToTwips(72); not: mTwipsToPixels = pix_inch/(float)NSIntPointsToTwips(kPixelsPerInch); ie: mTwipsToPixels == the number of pixels in an inch / the number of twips in an inch (20 * 72) You are scaling the wrong way. (Actually, instead of "kPixelsPerInch" it should be the prefs value for dpi, defaulting to 96.0)

Shame on me! I stupidly changed all the "72"s I found... Of course, it works with the right formula.

I verified with the page mentioned in #2411 that it works: http://style.verso.com/junk/fontsize.html

Um, so now all pages render with really big fonts (on Mac sites, anyway). There are also problems with form elements wrapping on www.netscape.com, and gaps betweeen images on www.apple.com where there should be none. Could someone please post the Mac newsgroup describing these changes, and how to set our prefs to go back to the old scaling?

The screen resolution is now a preference ("browser.screen_resolution" = 96 by default). The "really big fonts" are a feature, I guess. They are required if we want to strictly follow the CSS rules. I don't quite understand the logic: I just implemented it and I continue to think that a standard is worth nothing compared to user experience. Now the problem is that if you set the preference back to 72, the toolbar buttons are displayed so small that you can't read them. That's because I also had to remove the test where on the Mac, fonts smaller than 9pt where displayed as 9pt. We need more explanations from <peterl>, if not a fix for that one. Reopening.

I forgot to mention that I'm even more confused because the only problem we had on the Mac (see #2411) was that we were displaying in a readable way some characters that were supposed to be too small to be read on a test case designed to evaluate the strict compatibility of a browser with the CSS standard. Now, we did that at the expense of either displaying the "really big fonts" everywhere, or (if the user sets the resolution back to 72 dpi) displaying unreadable small characters on sites as well-known as CNN. I propose the following solution: - leave the screen resolution as a preference, with 72 dpi as default. - add a preference "dont_use_fonts_smaller_than_9pt", with true as default. This way the folks who want to run the CSS test cases can adjust the prefs to their liking while the rest of us continue to surf the net at large.

Another way to solve this problem is to implement the CSS font-size-adjust property. See http://style.verso.com/cssui/

When I said "this problem", I meant the "don't use fonts smaller than 9pt" problem. This is somewhat separate from the 96dpi default issue, although related.

This has already been discussed to death on the mac newsgroup (under "Mac point to pixel scaling"). This isn't a "let's make the Mac more readable" issue. This is a platform and vendor interoperability issue. And no, the font's aren't "really big" now. They are the size that the page author has intended from day one. The size that 90% of the browsers out there (read: windows boxes) have always been displaying these fonts. The size that Macs have always been too broken to display correctly. Now it's fixed, rejoice. (In other words, for the rest of the world a "point" is 1/72 of an INCH, not 1 pixel like macs have been wrongly assuming for years.) The whole point of Gecko is to fix what's broken on the web, not blindly repeat yesterday's mistakes. (FYI: there were font sizing bugs on windows versions of Nav pre 5.0 also, those are fixed now too.) If the you want the toolbars to not be effected by the user's pixel scaling, you have two options (as I told you about before). You can either: 1) set the point/pixel ratio differently in the chrome's presentation (it is a seperate presentation context/device context from the viewed document), or 2) use pixel values in the CSS for the chrome. Leave the 9 point min font size hack OFF. Leave the default pixel scale at 96dpi. And no, this has nothing to do with font-size-adjust.

> And no, the font's aren't "really big" now. They are the size that the page > author has intended from day one. That's not entirely true; authors of web pages directed at Mac users have been creating pages which assume the old Mac scaling value, and this changes is going to make all such pages look like crap.

Nowhere in the discussion on the mac newsgroup did we approve to garble the display on the Mac. I checked in 2 things: - the default resolution is back to 72 - a preference has been added ("browser.display_very_small_fonts") to allow the display of font sizes smaller than 9pt. I did so because obviously the debate is not over yet and there is no reason to break what's working until a final decision is taken. Please respond on the Mac newsgroup under "Screen resolution: 72 or 96?".

Fixed in the April 28th Mac Build. This version supports 96 dpi.