From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461) BuildID: 20011112009 In Windows you can set the system DPI to things other than the default 96, but Mozilla does not notice what you have set the system DPI to, and you have to input it manually. Reproducible: Always Steps to Reproduce: 1. Change the system DPI. In Display Properties - Settings - Advanced - DPI setting (may be different if you don't have XP, but the feature's been available ever since Windows 3.1). 2. Reboot 3. Start Mozilla. Actual Results: Mozilla still thinks the display is 96 dpi. Expected Results: Mozilla should have read the system DPI via the GetDeviceCaps call and used that value for rendering. The following code can be used to read the system DPI: int intScreenXDPI, intScreenYDPI; HDC hdcDesktop; HWND hwndDesktop; hwndDesktop = GetDesktopWindow(); hdcDesktop = GetDC(hwndDesktop); intScreenXDPI = GetDeviceCaps(hdcDesktop,LOGPIXELSX); intScreenYDPI = GetDeviceCaps(hdcDesktop,LOGPIXELSY);
Are you referring to the DPI dropdown in preferences->fonts? This is not hooked at up at all on Windows.
Well, you set it through that dropdown. Shouldn't its default be the same as the current Windows system DPI?
Reassigning to Don.
*** Bug 161660 has been marked as a duplicate of this bug. ***
This behavior may be intentional -- by default, we shouldn't use a system DPI that's less than 96dpi, but we should use it if larger, although the default might be modifyable.
If Windows doesn't use the DPI stuff in prefs, it shouldn't be there. The issue is that the user has the ability to change DPI in prefs, but it does nothing.
*** Bug 247822 has been marked as a duplicate of this bug. ***
The screenshots in bug 247822 demonstrate that, at 144 DPI for Moz 1.7 at least, Windows' system DPI is not ignored. If rather this bug is about the Moz DPI pref being ignored in Windows, then the summary should be adjusted accordingly. Otherwise, this is WFM.
Created attachment 152392 [details] Test Default 12pt against Explicity 12pt The dpi settings are ignored if the font size is not explicitly set in the HTML. With the attached test case, on a normal (96DPI) system, the font-sizes are the same. But on a non-standard (eg. 120DPI) system, they're different! Tested on firefox 0.9.1
Comment on attachment 152392 [details] Test Default 12pt against Explicity 12pt Our default font size is 16px, not 12pt.
*** Bug 274848 has been marked as a duplicate of this bug. ***
*** Bug 274848 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > If rather this bug is about the Moz DPI pref > being ignored in Windows, then the summary should be adjusted accordingly. ...and marked as a duplicate.
*** Bug 296501 has been marked as a duplicate of this bug. ***
*** Bug 291647 has been marked as a duplicate of this bug. ***
Can I suggest to increase the priority? With the newest laptops with an high resolution display it is normal to set the windows DPI to 120 otherwise all the text will be really difficult to read. The gmail website doesn't specify directly the font size and thus it is really broken in Firefox.
Conforming summary to comment 7. The Windows system DPI setting, 96 by normal default, 120 by default on many high resolution laptops, is not ignored. Either the pref needs to be made to work, or the pref panel needs to exclude display resolution.
Re Windows setting DPI to 120: that's a deficit of Windows. Measure your laptop, say 15" screen @ 1600x1200 -> 133.3 DPI. At 1920x1024, in a 15" frame -> / 145 DPI, 15.1 -> 144 DPI, 16" -> 136 DPI. It's not just text -- it's also widget and picture sizing: things likely beyond the scope of this bug -- but too many webpages are designed for the mono-window, 1024x768 user (ex.: Tom's HW!). One can increase text size, but thanks to some stupidity somewhere, they still specify sizes in pixels. HTML spec should get rid of idea of physical pixels & goto virtual pixels so entire displays in a given window can be resized on the fly. Same problems with enlarging text does happen in FF as in IE though not as often -- I notice it more in IE as it respects the DPI and "Accessibility" restraints more so than FF, but conversely more websites are designed to use fixed pixel objects that get truncated or written over the top of things in IE with larger fonts. Case in point is new CSS code in "/.". Unless I set IE to display all text in "smallest", I have fields overwriting each other in IE. Seems like they recoded to break compatibility with older browsers that default to allowing larger fonts. Don't have micron level eyesite? Too bad. I can see why open source is getting bad reviews on accessibility issues. Yes -- FF's "control-+" works when MSIE's "change font size" doesn't and has some benefits -- but the columns stay the same size -- if you make the text large, you can end up with a few words/line in some badly designed websites, it's also a problem when your "control-+" setting doesn't follow you on other pages on the same website or in the same session. Not sure what would add to least surprise, but it is a pain to open up several tabs from an expanded text webpage (control-+'d) then have to manually blow up text on each of them. Perhaps this should be moved into the area of accessibility bugs?
It's no longer clear what this bug is about. I've adjusted the summary to what I think it was originally about. I'm marking it wontfix since that behavior is intentional. The other issue frequently mentioned here is bug 69205.
Hrm. Actually, Windows is the only platform where we don't ignore the system's idea of DPI when it's less than 96dpi, so I'm really not sure what this bug is about, unless it's purely a duplicate of bug 69205.
Based upon comment 0 alone this looks invalid, since the system DPI is in fact used. But, based upon the original summary and the comment 2 response to comment 1, it's apparently really about a UI pref that can apparently be changed, but without having any effect. Since comment 0 constitutes a dupe of bug 69205, but comments 1/2 constitute a valid separate complaint, we could simply resummarize this bug as a request to remove the UI pref panel item on this platform until and unless such time as bug 69205 gets fixed.
Is there a developers mailing list to discuss these issues? This bug is only a small part of the problem(s): The larger problem(s) are: 1) DPI settings are ignored (they should not be considered a "font-only" property) 2) User-setttings of Font size minimums appear to have no effect for a given language Neither of the above problems should be considered 'minor'. Problem "1" is major and minimally should address placement and size of HTML widgets/structures (unfortunately, exluding graphical items), but ideally (eventually) including dynamic resizing of both static and dynamic graphical items. There are several new bugs that also touch on font issues -- I was going to open another bug (or two) to address these larger issues, but don't really feel like just adding to the exsisting noise -- was hoping for a better venue to discuss these issues?
I wonder how cairoization is going to effect this... Pav?
I've suggested that we remove the UI for setting the "DPI" on various occasions. If we want something similar, it should probably be more of a font scale setting than a DPI one. We want to use the system DPI across the board for DPI-related matters. Currently in cairo-land, we do mostly what we do now.. linux pays attention to that preference and windows completely ignores it. I think we'll soon see a better solution all around, but i'm not sure what that is yet.
(In reply to comment #25) > ... If we want something similar, it should probably be more of a font > scale setting than a DPI one. ... Don't expect font settings in Firefox on Linux to affect every element on a page consistently: On Linux, text font settings do not affect size of form controls (e.g. buttons, input fields, etc.) as their font sizes come from the system's fonts for form controls (-> GTK). In contrast to Windows where font settings do scale form elements. In bug 305109, I suggested that Firefox resolve this cross platform incoherency. Pity, it was rejected. This inconsistency is obviously intentional.
By 'linux does and windows doesn't', do you mean the 'linux' version of Tbird and Firefox _do_, pay attention, to the Display DPI, but the 'Windows' versions of Tbird and Firefox _don't_ pay attention to the Display DPI? Isn't it the case of this feature never being implemented in the mozilla/netscape Windows port? I seem to remember this problem in the earliest Window's ports of the product in the late 90's when run side-by-side on DPI-correct displays with Unix ports of the product. -l
Comment 7 and comment 25 indicate that this bug should be about removing the DPI UI from the subject OS builds, so Linux discussion here is inappropriate.
I was referring to comment 25's suggestion to remove "the UI for setting DPI" in favour of a "font scale setting" and talking about what problems may arise. True, that was not directly belonging to this bug.
Just ran into this one on Windows XP. Got a new 15" widescreen laptop with 1680x1050 resolution. I adjusted the Windows desktop to 106 dpi resolution (Windows allows resolutions other than 96 and 120!). IE picks up this resolution, and displays larger fonts, but FF continues to use 96 dpi (resulting in minuscule fonts). Worse, setting a custom DPI in FF preferences (what a weird GUI in 1.5 - making me measure a line - now where's my ruler?!) didn't help at all. I restarted FF, and apart from now displaying a blank in the resolution dropdown box, it had no effect on the displayed fonts. FF should just pick up the Windows-reported desktop DPI values (doesn't *matter* if that is the "real" DPI - if IE uses it, and Office uses it, heck, FF should use it!) and automatically use that to scale the fonts for display. I would like to bump this bug back to "normal" priority, as super high-resolution laptops and displays are becoming increasingly common, and FF looks really bad on these displays when the desktop is set to a comfortable font display size. And also maybe reset the Target milestone to something closer than "Future"?
After the fixes for bug 233082 and bug 323962, which are in Firefox 2.0 but not 1.5, Firefox will (again!) pick up the Windows preference. This bug is about the user interface not reflecting reality, and/or not being able to change anything, not about the problem you mention (except perhaps for the ruler not doing anything). (I haven't read it carefully enough to be sure which.)
IS ANYONE PLANNING ON FIXING THIS? PROBLEMS: 1) I have Windows DPI set to 125%. Firefox sets my text and image DPI to 150%. === !!!!! 150% !!!!! ==== === !!!!! 150% !!!!! ==== === !!!!! 150% !!!!! ==== 2) <CANVAS>, other elements WON'T GET RESIZED A web-game that relies on <canvas> and other HTML GUI elements (like <img>) will make for a broken presentation, because <img> scales, while the <canvas> area will not. 3) Web developers can't change this, if they are working in PX! (you want images to be specified in ems?) Chrome actually knows that I ONLY WANT MY WINDOWS GUI TO BE RESIZED and keeps everything normal. SOLUTIONS: 1) Make Firefox reflect the ACTUAL Windows DPI. If I set 125%, then 125%. 2) Make a way for a NON-TECHNICAL user to modify the Firefox DPI. Many users don't want to change Firefox settings, but only the WINDOWS GUI settings. 3) Add a Firefox-specific CSS property that specifies to ignore the user's Firefox DPI settings.