On systems using X programs can get the screen resolution from the X server. The xdpyinfo program can serve as an example how this can be done. Nevertheless, Mozilla sets the initial font scaling to, in my case, 96dpi. The xdpyinfo program reports screen #0: dimensions: 1600x1200 pixels (542x406 millimeters) resolution: 75x75 dots per inch and after setting the font scaling in the preferences appropriately the pages look much closer to what one gets with other browsers.

Reassigning as per Don

Move to M21 target milestone.

somewhat-WFM in M18 and trunk build 2001010223 (both Linux): Starting with a fresh profile, mozilla will pick up the dpi setting from the X server. Menu font sizes and CSS lengths like "1cm" all vary according to the server's idea of the screen resolution. The real problem is, that the default behaviour (signaled by a dpi override value of 0) is overwritten at the first visit to the "Fonts" panel - after that, 96 dpi is hardcoded into the users preferences unless you set it back to 0. Please stop the preferences dialog from overwriting the value. The X server's dpi value may be wrong, but certainly 96 is wrong in even more cases! The fix seems very low-risk to me.

chris, what d'you think of the proposed patch?

Mac needs this to be fixed at 96, I think. Maybe we could try a unix-only version of this patch? E.g. stuff this into locale/en-US/unix/platformPrefOverlay.dtd.

The deal here is that most Unix systems (including most Linux distributions) set the dpi wrong (they get the monitor and resolution, then proceed to set the dpi wrong anyway) so the only systems that have it right (except by accident) are systems with expert users. We had to make a decision: set the defaults for people who just know how to follow installer instructions, or set the defaults for people who know how to edit their X server's config file? Most people thought that people who knew how to configure their X server could also figure out how to configure mozilla, whereas people who don't know how to configure mozilla are probably running the incorrect default dpi setting in their X server (usually 75). Cc'ing people who are more up on the current state of dpi/font issues.

I agree that the 75 dpi fonts look quite broken on a 100 dpi display. (OTOH, they don't look pretty in 75 dpi neither, so maybe *that* should be fixed.) But 96 is only a guess as well ... and right now we're punishing exactly those vendors/admins getting there act together while the others get off the hook. This probably has to be relnoted anyway, as the 96 will be wrong in many cases. I think it's more up front to leave the override disabled per default, and state something like this in the relnotes: Many X servers are not setup to report the display resolution (dpi) correctly. If Mozilla starts up with a very small/large menu font, the cause is probably a wrong dpi value. [maybe point to docs that explain how to do this for XFree] If you are unable to change your X server's settings, Mozilla can be told to use another dpi value: open the "Fonts" tab in the preferences dialog, ... In any case, it should be documented that 0 dpi means to take hint from the X server. Better yet, the UI could contain a radio switch between "use X server's setting (currently nn dpi)" and the override. I'll hang that to bug 5599.

I think gerv is working on this for bug 81904, marking dup *** This bug has been marked as a duplicate of 81904 ***

mass verification of duplicate bugs: to find all bugspam pertaining to this, set your search string to "DuplicateBugsBelongInZahadum". if you think this particular bug is *not* a duplicate, please provide a compelling reason, as well as check a recent *trunk* build (on the appropriate platform[s]), before reopening.