Ulrich Drepper Reporter
	Description • 25 years ago

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.

	verah (gone)
	Comment 1 • 25 years ago

Reassigning as per Don

	don
	Comment 2 • 25 years ago

Move to M21 target milestone.

	robbe
	Comment 3 • 24 years ago

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.

	sairuh (rarely reading bugmail)
	Comment 5 • 24 years ago

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

	Chris McAfee Assignee
	Comment 6 • 24 years ago

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.

	Akkana Peck
	Comment 7 • 24 years ago

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.

	robbe
	Comment 8 • 24 years ago

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.

	Chris McAfee Assignee
	Comment 9 • 23 years ago

I think gerv is working on this for bug 81904, marking dup

*** This bug has been marked as a duplicate of 81904 ***

	sairuh (rarely reading bugmail)
	Comment 10 • 23 years ago

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.