Closed
Bug 531299
Opened 15 years ago
Closed 13 years ago
Inconsistent Font sizes when windows dpi >96
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: danialhorton, Unassigned)
References
Details
Attachments
(4 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.3a1pre) Gecko/20091125 Minefield/3.7a1pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.3a1pre) Gecko/20091125 Minefield/3.7a1pre At the same level of Zoom, certain text in webpages is larger than it should be when the windows dpi is >96. It appears to be inconsistent usage of DPI scaling, The scaling on the UI is fine however. Reproducible: Always Steps to Reproduce: 1. Set windows DPI to 120 2. Open a forum such as forums.guru3d.com 3. Compare the text for topic names (and topic name links) and quotes between Firefox and IE. (installation of Default FullZoom will help set the proper 125% for comparison) Actual Results: Certain area's of text are different sizes even using the same font size, when the windows dpi is above 96. Expected Results: The font sizes are consistent between Firefox and IE at the same font size / font type and style I believe this issue stems from partial application of the windows dpi setting to the contents of the webpage. For all intents Firefox should just apply a default zoom level equivalent of the Windows DPI Percentage, rather then attempting to do its funky DPI calculation, as at default DPI the zoom settings and text sizes are 1:1 between Firefox and IE.
Reporter | ||
Comment 1•15 years ago
|
||
Reporter | ||
Comment 2•15 years ago
|
||
Reporter | ||
Comment 3•15 years ago
|
||
Reporter | ||
Comment 4•15 years ago
|
||
Comment 5•15 years ago
|
||
Take a look at Bug 433664. This looks to be a duplicate of that bug.
Reporter | ||
Comment 6•15 years ago
|
||
possibly, though mine differs from his in several ways. For starters i realise the difference between IE and Firefox's text size actually lays in the fact that the IE text is not scaled to DPI, rather IE matches the Page zoom to the current DPI % The problem im having is that when both are set to the same Zoom amount, then certain area's of text appear to have the DPI scaling applied as well as the zoom so they appear larger than they should. Such as my screenshots demonstrates.
Comment 7•15 years ago
|
||
I think that duping to 433664 is the right call. Take a look at Bug 433664 comment 18 if you want FF to act more like IE w/ DPI.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 8•15 years ago
|
||
Disagreed, it is not a duplicate, i do not want the dpi to scale the text in the webpage AT ALL. get it through your skull. Text scaling in webpages should not be effected by the dpi at all, only the GUI. Text scaling in IE is done via the zoom function and the same should go for Firefox.
Reporter | ||
Updated•15 years ago
|
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Reporter | ||
Comment 9•15 years ago
|
||
The modification in the comment specified effects the GUI. The GUI is not the problem here. Its certain area's of text in the webpage itself. The screenshots should be more then enough of an example. DPI effects certain area's of text in firefox's page area, Where as it does not effect IE in the same way. Its CLEARLY a different issue. Regardless of the usage of those settings, You just end up making the GUI smaller, and both the correct and incorrect areas of text smaller. Regardless the comparison is still incorrect and the size is not consistent in the same webpage between IE and Firefox.
Reporter | ||
Comment 10•15 years ago
|
||
The Text in the quote area should be the same size as the text outside it, the only time the size should differ is when a size tag is used to increase or decrease it. Granted the size can be made smaller with size tags however this then makes them different in IE, and firefox when at the default DPI. It is entirely an issue in which firefox is applying the system DPI to certain area's of text in a webpage. Let me make this clear. the DPI does not effect the Page Text size in IE directly, it manages the difference by applying a level of zoom equal to the current DPI % to the page viewing area. The DPI DOES effect the page text size in Firefox Directly, but only for certain area's of text. Some area's of text are consistent between IE and Firefox while others have Firefox render them differently. This is the inconsistent behavior. The only thing that effects page text size should be the Font options in Firefox's options (which they do, i can increase the min text size but this breaks other pages), and the Zoom control. DPI should be entirely limited to the scaling of the GUI. it should not effect the webpage outside of default setting the Zoom to match, or near the same zoom % of the system DPI.
Comment 11•15 years ago
|
||
That's because Gecko uses by default the system dpi value for computing the size of elements that are sized using an absolute length unit. That's the case of the quote section on that forum page which uses a font size of 10pt. IIRC, IE and WebKit hardcode 96dpi when computing the size of absolute length units ('pt', 'in', 'cm', etc.) but Gecko and Opera use the system dpi value. If you want to match IE behavior, you could set layout.css.dpi to 96 in about:config.
Component: General → Graphics
Product: Firefox → Core
QA Contact: general → thebes
Reporter | ||
Comment 12•15 years ago
|
||
Ok that makes sense, and that config actually works, so thanks (comment 18 didn't). actually, im surprised that setting actually works, i've read forum posts where it was linux or mac only. That said, wouldn't it be better to expose a drop down DPI menu in the fonts options, with settings such as Use System Default 96 120 etc. To be assured, the first thing a person on a high dpi screen will notice is the differences in fonts, when moving between Firefox and IE, and there is inconsistent information on the internet to explain why. Was this setting changed to apply on windows as only recently? because the page describing the setting was formely indicating it is ignored on windows, however it does not anymore.
Comment 13•15 years ago
|
||
I think this behavior is be the same between all platforms, and I guess it works that way since at least Firefox 3.5, but I didn't check to make sure. Where did you see documentation about this feature? If it's part of the official documentation (i.e. somewhere on the mozilla.org domain) it should probably be fixed. The problem I see with a "select your DPI" UI is that the average user wouldn't understand what this is about and how it would affect web pages. I agree that the current situation with high DPI is less than optimal on Firefox. If you set your system to 120 DPI on Windows for instance, you usually expect everything to be larger in the same proportions but that's not what happens.
Reporter | ||
Comment 14•15 years ago
|
||
Microsoft was actually addressing that issue, Though anyone who has found their way into the DPI screen on windows, would have to have atleast googled what it does. One of the places i found when looking for help on the dpi issue was this thread/discussion http://support.mozilla.com/en-US/forum/1/70669 It seems some people still don't know it now works on windows?
Comment 15•14 years ago
|
||
So the upshot is this is working as designed? (In reply to comment #13) > The problem I see with a "select your DPI" UI is that the average user wouldn't > understand what this is about and how it would affect web pages. perhaps there are other things which might be appropriate on a preferences "accessibility tab"?
Comment 17•13 years ago
|
||
Since bug 537890 landed 16px always equals 12pt, which means desktop DPI no longer impacts the so-called "absolute units" pt, pc, in, mm & cm. The only unit left that is supposed to be affected by DPI is mozmm, which is not supported by other browsers. The guru3d.com forum mixes pt and px text sizing. With the old behavior, differences between IE and Gecko at other than 96 DPI from that poor type of page styling were to be expected. -> INVALID
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago → 13 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•