Erik van der Poel Reporter
	Description • 25 years ago

From: dbaron@fas.harvard.edu

See http://bugzilla.mozilla.org/show_bug.cgi?id=17861 for the Unix source code
changes. Mac might be similar.

DESCRIPTION:  Currently Mac and Linux, by default (i.e., without the secret
browser.screen_resolution pref), do not use the logical resolution from the
operating system at all.  Instead, they assume 96ppi.  I think this is a bad
idea - they should only assume 96ppi when the operating system claims the
logical resolution is *less* than 96ppi.  If the OS gives a value *more* than
96ppi, then the OS value should be used.  (Users with poor vision, for example,
may have a high logical resolution set.  Or, for that matter, users with
high-res monitors.  The reason for doing this at all is that the Windows default
is 96ppi, and many web designers write pages with physical units that are
illegible with a logical resolution smaller than 96ppi, because the fonts become
too small to read.  Therefore, there's no reason to *lower* the logical
resolution to 96ppi -- it should only be raised to 96ppi.)  The code should also
respect the browser.screen_resolution pref above all.

I'll try to submit a patch that does this on Linux.  Sometime, that is...


QA:  I can verify this bug by looking at the code.  Steps to reproduce are too
hard...

	Patrick C. Beard
	Comment 1 • 25 years ago

The Mac doesn't really have a call for this. Essentially everything is 72ppi.

	David Baron :dbaron:
	Comment 2 • 25 years ago

But the calculations on the mac *are* based on a call (called
GetDeviceResolution() or something), and it could report something other that
72ppi in the future, since that figure is very inaccurate.  (Also for
printing...)

The fix for this bug is a two line change or so... (but there's another bug in
the same code... I forget the #).

	Kevin McCluskey (gone)
	Comment 3 • 25 years ago

Reassigning to dcone.

	dcone (gone)
	Comment 4 • 25 years ago

The Mac assumes a 72 DPI screen, we currently set it to 96 DPI just because that
is what most monitors are.  The GetDeviceResolution() call on the Mac always
returns 72 DPI.  Who knows what it will do in the future.. and we can't count on
that.  Also Mac assumes 72 DPI because Postscript printers are at 72 DPI
resolution.  This gives them there WYSIWYG...
The solution that was agreed on was that the resolution could be set manually in
the UI.. Currently the Mac will not use the GetDeviceResolution() call.. it will
use the static 96 DPI.. at least for the time being...
This was a decision made by Peter L., Kipp and Troy, and Agreed to by Rick
G. some time ago... I was not part of that disscusion.  Basically this is a dead
snake.  I can put code in that looks to see if it is higher than 96 dpi.. thats
ok, but what if we allow a manual setting of DPI, this change would override
that.. that would not be good either.

	David Baron :dbaron:
	Comment 5 • 25 years ago

The "I can put code in to..." is exactly what this bug was asking.  Suppose some
really high res screens come out next year.  The Mac OS, because of them, might
develop a feature to allow reporting of a different resolution.  If that
happens, you really don't want to use 96dpi if the OS is reporting 200dpi.

That's all I'm asking.  It's a few lines of code, and there's a chance (perhaps
small) that not doing it could be *really* embarrasing in the future.

(BTW, postscript printers are not generally 72dpi.  They're usually 600dpi these
days...)

	David Baron :dbaron:
	Comment 6 • 25 years ago

And, BTW, it wouldn't have to override manual setting of the DPI.  That's why
the Unix diffs attached to bug 17861 are more than two lines.  (When I said 2
lines earlier I was thinking this was a different bug (bug 16200) relating to
the same code...)

	David Baron :dbaron:
	Comment 7 • 25 years ago

I'm going to reopen this in the hopes that my recent comments clarify what this
bug is about...

	dcone (gone)
	Comment 8 • 25 years ago

I understand what you are saying.. but there are some issues that need to be
discussed and understood before we can make such decisions and this is not a
high priority.  Maybee in a few months we can revisit this.. or carry on a
disscusion about this in the mean time.
I will put it on remind..

BTW.. Postscript has a default 72 units per inch in the default user space, this
is the DPI returned by the Mac PS dictionaries and the DPI we use for Unix.
Printers that have Postscript interpreters on them are typically 600 DPI, but PS
does not use this resolution as the DPI amount.  This user space it what allows
PS to be used on printers or raster crt devices.  That is why the Mac
GetDeviceResolution() always returns 72 as its DPI.. its not a matter of what
resolution the screen can support.. it a matter of matching all the devices
DPI's to a value they all can handle, so they all will look the same when they
are compared.  The Mac considers DPI a virtual value (as does Postscript) so
devices can match output.

	Chris Petersen
	Comment 9 • 25 years ago

Marking verified remind.

	rbs
	Comment 10 • 25 years ago

http://www.microsoft.com/presspass/press/2000/Jan00/MacWorldIE5.asp

says:

<quote>
  "Tasman" also displays text in Web pages much more clearly,
  thanks to a feature that automatically adjusts the resolution
  to 96 dots per inch (dpi) instead of the Macintosh-standard 72 dpi.
</quote>

	Gervase Markham [:gerv]
	Comment 11 • 24 years ago

Remind is deprecated; and, given bug 88186 and other work in this area, now
might be a good time to revisit this issue. Reopening.

Gerv

	dcone (gone)
	Comment 12 • 24 years ago

This is not going to happen anytime soon given the other bugs that need fixing.

	dcone (gone)
	Comment 13 • 24 years ago

taking off my radar.. this will not be visited for a few months.. at least based 
on my bug list.

	David Baron :dbaron:
	Comment 14 • 24 years ago

Remind is deprecated.  Reopening.

	Greg K.
	Comment 15 • 22 years ago

If all GetDeviceResolution() returns now is 72, then we could accept its' value
if it's anything other than 72, couldn't we?

	Christopher Hoess (gone)
	Comment 16 • 21 years ago

->GFX?

	Steevithak
	Comment 17 • 17 years ago

Is there any current work being done on this bug? It seems to be responsible for rendering problems I'm seeing on Red Hat Fedora with Firefox. On a high resolution display (greater than 96dpi) all my programs look nice and crisp except Firefox, which looks like fuzzy and, worse, the images and links shift around when you mouse over them. The Red Hat guys said this is a known bug in Mozilla/Firefox and said the only work around was to set your desktop resolution to the incorrect value of 96dpi, regardless of its actual resolution. Here's a reference to the related bug in the Red Hat bugzilla:

 https://bugzilla.redhat.com/show_bug.cgi?id=387561

	dan_500
	Comment 18 • 16 years ago

The "Zoom" feature does work very well with chrome. (Try to open chrome://browser/content/browser.xul in firefox and use  Ctrl and ++ or --) I hope the Zoom feature is soon ready to read my dpi settings to use it for the chrome gui and websites.

	dan_500
	Comment 19 • 16 years ago

To use the "Zoom" feature for resolution independence you have to fix absolute lengths like "in", "cm", "mm", "pt" and "pc". (They have to be zoomed for zoom feature, not for resolution independence) Also you need to zoom GTK+.

If I change the dpi using Shiretoko with Gecko 20090122 or Firefox 3.0, icons seem to be pixel hardcoded. Webpages do ignore my dpi setting.

	Zack Weinberg (:zwol)
	Comment 20 • 13 years ago

I *thought* this had been dealt with ca 2010 but I'm not sure.  Maybe someone in the proper component knows.

	Jeff Muizelaar [:jrmuizel]
	Comment 21 • 13 years ago

I'm pretty sure we have a fixed DPI now. If anyone disagrees reopen.