Closed
Bug 20802
Opened 25 years ago
Closed 13 years ago
Should use logical resolution from OS when higher than 96ppi
Categories
(Core :: Graphics, defect, P3)
Core
Graphics
Tracking
()
RESOLVED
FIXED
People
(Reporter: erik, Unassigned)
Details
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...
Updated•25 years ago
|
Assignee: beard → troy
Comment 1•25 years ago
|
||
The Mac doesn't really have a call for this. Essentially everything is 72ppi.
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 #).
Updated•25 years ago
|
Assignee: kmcclusk → dcone
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → LATER
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.
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...)
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...)
Updated•25 years ago
|
Status: RESOLVED → REOPENED
Comment 7•25 years ago
|
||
I'm going to reopen this in the hopes that my recent comments clarify what this bug is about...
Updated•25 years ago
|
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: LATER → REMIND
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.
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
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>
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
Status: VERIFIED → REOPENED
Resolution: REMIND → ---
Comment 12•24 years ago
|
||
This is not going to happen anytime soon given the other bugs that need fixing.
Status: REOPENED → ASSIGNED
Target Milestone: --- → Future
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.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → REMIND
Comment 14•24 years ago
|
||
Remind is deprecated. Reopening.
Status: RESOLVED → REOPENED
Resolution: REMIND → ---
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?
Comment 16•21 years ago
|
||
->GFX?
Assignee: dcone → general
Status: REOPENED → NEW
Component: Layout → GFX
QA Contact: chrispetersen → ian
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
Assignee | ||
Updated•16 years ago
|
Product: Core → Core Graveyard
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.
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.
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.
Assignee: general → nobody
Component: GFX → Graphics
Product: Core Graveyard → Core
QA Contact: ian → thebes
Hardware: PowerPC → All
Target Milestone: Future → ---
Updated•13 years ago
|
Status: NEW → UNCONFIRMED
Ever confirmed: false
Updated•13 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago → 13 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•