$HOME/.mozilla/default/prefs.js user_pref("browser.display.screen_resolution", 400); is ignored by the main browser window. (How about an option to simply force a single font size???)
Do you really have a 400 dpi screen? WOW! BTW, in a debug build, you get a startup message about what mozilla thinks your screen resolution is. Compare with xdpyinfo.
*** Bug 49190 has been marked as a duplicate of this bug. ***
Confirming on Linux 2000-08-16-05. The problem is that the chrome typography is scaling with the screen resolution setting, while the rendered content area is not. To reproduce: 1) Set browser.display.screen_resolution to 1000 dpi 2) Start Mozilla The problem is nicely shown in the attached screen shot, sent to me by the original reporter. Not sure who this belongs to, sending to Style.
Closed as invalid: the content area does take the screen resolution into account. See http://www.w3.org/Style/CSS/Test/current/sec61.htm for instance: all the values specified in absolute units such as inches or centimeters are affected by the screen resolution. You can't see it when browsing common web sites because they use pixels. See bug 17926 for more information about screen resolution within the chrome.
If the content area took screen resolution into account, then its size would change when the resolution is modified. It doesn't. The basic problem is that currently it is impossible to read any page that uses <font size=1> or <font size=2> on a high resolution monitor (reallistically about 96/inch instead of the default 72) Four possible fixes: 1. Support the adustable screen resolution settings. 2. Add option to enforce a minumum font size 3. Support decent antialiased fonts (likely an X11 problem) 4. Fix the stupid HTML feature that allows authors to specify absolute font sizes. Mozilla already has an option to set resolution. It should just use it!
The content takes the screen resolution into account (of course, the sizes have to be specified in inches or points - not in pixels or ems). See the attached testcase. Or is there a problem on unix only? That would be surprising. #1 is invalid - see attached testcase #2 is dup of bug 30910, also related to bug 46286 Closed as invalid again.
Netscape's standard compliance QA team reorganised itself once again, so taking remaining non-tables style bugs. Sorry about the spam. I tried to get this done directly at the database level, but apparently that is "not easy because of the shadow db", "plus it screws up the audit trail", so no can do...
The four possible fixes are currently either done or covered by other bugs.