From: email@example.com 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...
The Mac doesn't really have a call for this. Essentially everything is 72ppi.
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 #).
Reassigning to dcone.
Status: NEW → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → LATER
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.
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...)
20 years ago
Status: RESOLVED → REOPENED
I'm going to reopen this in the hopes that my recent comments clarify what this bug is about...
Status: REOPENED → RESOLVED
Last Resolved: 20 years ago → 20 years ago
Resolution: LATER → REMIND
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.
Marking verified remind.
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>
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
Status: VERIFIED → REOPENED
Resolution: REMIND → ---
This is not going to happen anytime soon given the other bugs that need fixing.
Status: REOPENED → ASSIGNED
Target Milestone: --- → Future
taking off my radar.. this will not be visited for a few months.. at least based on my bug list.
Status: ASSIGNED → RESOLVED
Last Resolved: 20 years ago → 18 years ago
Resolution: --- → REMIND
Remind is deprecated. Reopening.
Status: RESOLVED → REOPENED
Resolution: REMIND → ---
If all GetDeviceResolution() returns now is 72, then we could accept its' value if it's anything other than 72, couldn't we?
Assignee: dcone → general
Status: REOPENED → NEW
Component: Layout → GFX
QA Contact: chrispetersen → ian
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
Product: Core → Core Graveyard
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.
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.
I *thought* this had been dealt with ca 2010 but I'm not sure. Maybe someone in the proper component knows.
Assignee: general → nobody
Component: GFX → Graphics
Product: Core Graveyard → Core
QA Contact: ian → thebes
Hardware: PowerPC → All
Target Milestone: Future → ---
I'm pretty sure we have a fixed DPI now. If anyone disagrees reopen.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 18 years ago → 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.