User Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111217 Firefox/9.0 SeaMonkey/2.6 Build ID: 20111217095157 Steps to reproduce: to make fonts larger in the whole system I set screen resolution to 200 DPI root@htpc:/temp# xdpyinfo | grep resolution resolution: 200x200 dots per inch it worked for all system and application components including seamonkey 1.x but 2.x versions are ignoring system-wide dpi settings when rendering html. Skins are almost ok although in url autocomplete picklist line spacing is too small and lines merge and cover one another. Setting layout.css.dpi to 200 is not helping Expected results: seamonkey should respect system-wide DPI setting when rendering HTML and zoom fonts and images accordingly

Can you reproduce with Firefox? (which version(s)?)

This appears to be a support question. Please in future use our support forum for issues such as this. Are you using Ubuntu? If so please try the solution described in: <http://forums.mozillazine.org/viewtopic.php?p=9176615#p9176615> "The problem is that (non-repository) Firefox builds in Ubuntu or any Linux distro, by default, uses it's own Cairo rather than system Cairo for rendering UI fonts. I forgot which bug report (Bugzilla, Launchpad) I found this in since it was some time ago but the fix is fairly easy. Note: The reference for the following about:config setting is here: http://kb.mozillazine.org/Layout.css.dpi In about.config set layout.css.dpi to 0. Then restart Firefox and the Firefox UI fonts should now follow system font settings and should look a lot better. This assumes a few things though. 1. You have an LCD display and... 2. You've already set sub-pixel rendering to your liking (slight, medium or full) so the rest of the system fonts look best to you. Since you're using Ubuntu that should be it. If you were using Kubuntu you'd have to take it a step further and head into System Settings (KDE Control Center?) and under "Fonts" set "Force fonts DPI:" to "Disabled". In Gnome it's not required to change the system default DPI setting (default=96)"

wontfix on the seamonkey side as well, this would be a core bug. But you can surely try SeaMonkey Specific support venues.

Gentlemen, you are not reading carefully: this issue has nothing to do with fonts or UI. It concerns html rendering as a whole - fonts AND images, both should be scaled as specified in the X screeen resolution settings. I am afraid I've been a bit imprecise when I mentioned 1.x, I did a bit of regression testing and found out that this bug has been introduced in 2.1 - 2.0.14 is the last version that works correctly. And yes, I was able to reproduce this bug with firefox 8.0 from the distro repository (and by the way it is kubuntu 11.10).

(In reply to lvm from comment #4) > Gentlemen, you are not reading carefully: this issue has nothing to do with > fonts or UI. It concerns html rendering as a whole - fonts AND images, both > should be scaled as specified in the X screeen resolution settings. No, they shouldn't. In the past people filed bugs when screen DPI changes alone resulted in automatic rescaling of content. We fixed those bugs by decoupling these things. We *should* be automatically making fonts and form elements match those used by your desktop. If those automatically change size when you change screen resolution, we should follow suit. But I'm not sure how that works in GTK currently.

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #5) > (In reply to lvm from comment #4) > > Gentlemen, you are not reading carefully: this issue has nothing to do with > > fonts or UI. It concerns html rendering as a whole - fonts AND images, both > > should be scaled as specified in the X screeen resolution settings. > > No, they shouldn't. In the past people filed bugs when screen DPI changes > alone resulted in automatic rescaling of content. We fixed those bugs by > decoupling these things. I am sorry but I cannot agree with this at all. DPI is a grapical device parameter with one specific purpose: match pixel and physical resolution of the deivce so that *all* output may be scaled to make it readable regardless of physical pixel density. Given that pixel density of the modern displays tends to increase the approach you suggesting is a dead end, all output must be scaled, there may be no pixel-sizing at all - it is as grave a mistake as a hardcoding. If someone has been sufficiently unwise to consider these complaints as bugs and 'fix' them, it should be undone with utmost expedience. Incidentally when you say 'decoupled' do you mean that you introduced a configuration option to apply a global non-1 zoom factor to all HTML documents? Can't find it (please, no nosquint) > We *should* be automatically making fonts and form elements match those used > by your desktop. If those automatically change size when you change screen > resolution, we should follow suit. But I'm not sure how that works in GTK > currently. As I said before , it is exactly what happens: all system interface elements, application programs I use – e.g. LibreOffce and even Seamonkey's UI are automaticlly scaled to match screen DPI, only HTML document itself is not. Same bug in windows (XP SP3).

LibreOffice is not really a native application so can't be relied on for things like this. What matters here is the default device pixel size of text and controls rendered by system UI, such as a plain GNOME app or KDE app. If setting the X screen DPI changes those default automatically, we need to figure out by how much, and automatically do the same thing by implementing nsWindow::GetDefaultScale for GTK. Please let us know if you're using GNOME or KDE.

I'll let Karl figure out what, if anything, we should do here :-).

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #7) > What matters here is the default device pixel size of text and controls > rendered by system UI, such as a plain GNOME app or KDE app. If setting the > X screen DPI changes those default automatically Yes, it does. BTW as I said before it is not X-specific, Seamonkey for windows behaves the same way - not the way almost all other windows programs do, so I removed the linux bit from the title. > Please let us know if you're using GNOME or KDE. on linux I am using KDE

The code in question is platform-specific, so we need platform-specific bugs. We already have a different bug about this on Windows.

Comparing with a reference situation with the xrandr dpi set to 96 and Xft.dpi set to 192.0, these are my observations: With xrandr dpi 96, Xft.dpi: 192.0: Enlarges fonts in Qt Designer and Kuickshow but not icons, sliders, radio buttons or checkboxes. Similarly for GNOME Character Map, Evince, gtk-lsw. LibreOffice is similar, and also changes the document zoom at 100% zoom factor. Firefox UI and html text inputs seem to mimic the same behavior. With xrandr dpi 192, Xft.dpi: 96.0 Same as reference 96/96.0. With xrandr dpi 192, Xft.dpi not set same as 96/192.0 As far as I can see, everything seems to be scaling based on Xft.dpi if set, and if not falling back to xrandr / Screen dimensions. LibreOffice is the only application here to scale anything but fonts, that being only the document zoom at 100% zoom factor. Have I missed anything? Most of this looks ugly to me, but Firefox UI seems consistent with desktop apps. There isn't much guide here for how to treat web content that specifies font sizes. There might be a good case for scaling default font sizes for html.

Setting layout.css.devPixelsPerPx to 2.0 scales HTML (without double-scaling text inputs and UI fonts), and scales icons, but not radio buttons and checkboxes. The icons are now in proportion to double sized fonts but blurry and inconsistent with other apps.

If other apps aren't scaling their icons or images, neither should we. Automatically scaling content font sizes to match the rest of the system sounds good though.

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #10) > The code in question is platform-specific, so we need platform-specific > bugs. We already have a different bug about this on Windows. For html it can be done via the global zoom function (as in view-zoom) - is it platform-specific too? I cannot confirm that system icons do not resize - see the attaches screenshots, one at 96 DPI running seamonkey 2.6, the other at 200 DPI running seamonkey 2.0.14 - this is how it should look, note icons on the system task panel (KDE 4.7.3). I myself have no strong opinion about the interface icons - trying to avoid them as much as possible, but they look ok to me zoomed. Resizing text but not images is not a good idea, I remember earlier versions did exactly that and it looked ugly - page formatting was frequently disrupted to say nothing about image readability. Actually 2.6 has an option to zoom just text or both text and images in preferences-appearance-content, perhaps DPI-initiated scaling should use the zoom method set by this option.

different computer, same system version and screen metrics except for DPI

(In reply to lvm from comment #14) > I cannot confirm that system icons do not resize - see the attaches > screenshots, one at 96 DPI running seamonkey 2.6, the other at 200 DPI > running seamonkey 2.0.14 - this is how it should look, note icons on the > system task panel (KDE 4.7.3). Yes, in those screenshots dock icons have changed size. In comment #11 Karl reported that Qt app icons did not change size. We need to investigate further to understand when system icons change size and when they don't. Can you repeat Karl's experiment on a single system? Maybe the setups on your two computers had other differences than just the dpi setting.

KDE Task Manager and Panel icons scale when the size of the Panel changes. System Tray icons remain the same size (even in the screenshots). I haven't tested, by restarting the session, what effect dpi has on these. The scaled icons in Seamonkey 2.0.14 look like they use nearest neighbour interpolation. -moz-crisp-edges might be worth considering to get the same effect, if we were to scale icons.

I've just run into this issue with Firefox, content does not change with my system's DPI setting. What was the upshot of this bug report?

Perhaps what we could aim for here is scaling web content (html) and UI fonts iff Xft.dpi is set to a value other than 96 dpi. You can try out setting the Gecko pref "layout.css.devPixelsPerPx" to the value of the xrdb property Xft.dpi / 96.0. The two obvious issues that I see with that are: 1) UI icons are scaled, but other apps do not scale icons. I expect users who select a different Xft.dpi may pick a theme with larger icons, and we don't want to scale those twice. I suspect there are some icons that Gecko apps use but don't come from the icon theme. Scaling these with bi-linear filter looks bad. We need a better solution. 2) Menus for a window on a monitor below another monitor open on the topmost (wrong) monitor.

I have played around with "layout.css.devPixelsPerPx" but it's not suitable for my needs for two reasons: 1) I want to be able to dynamically change the DPI depending on what monitor I have plugged in. 2) I worry that Firefox sync will set my DPI to the same value across all my devices. Is the setting "layout.css.dpi" depreciated? It doesn't seem to do anything. Ideally I think that setting would work the way that is described.

(In reply to Karl Tomlinson (:karlt) from comment #20) > 1) UI icons are scaled, but other apps do not scale icons. > > I expect users who select a different Xft.dpi may pick a theme with larger > icons, and we don't want to scale those twice. > > I suspect there are some icons that Gecko apps use but don't come from the > icon theme. Scaling these with bi-linear filter looks bad. > We need a better solution. I think the answer here is that we should reverse any scaling that happens for icons, system metrics, and native theme drawing so that they're drawn the same size no matter what the devPixelsPerPx is. (And also things like the front end having a minimum height for menu bars in CSS pixels, if my memory serves.) (In reply to Jamie Kitson from comment #21) > Is the setting "layout.css.dpi" depreciated? It doesn't seem to do anything. > Ideally I think that setting would work the way that is described. Given that relatively few sites specified sizes in pt, in, pc, cm, or mm, it never did much, and since the recent unit changes all it now does is trigger thresholds for the default calculation of device pixels per CSS pixel. The basic problem, I think, is that what you think you want to do actually isn't compatible with a lot of Web content, so it will break a lot of Web sites. The closest thing to it that doesn't break Web sites is pixel-scaling everything (including images, though not necessarily including system icons or controls).

So changing DPI doesn't scale images? Is it possible to set a global zoom level on the command line?

(In reply to Jamie Kitson from comment #21) > 1) I want to be able to dynamically change the DPI depending on what monitor > I have plugged in. That setting should be dynamic, but it is not (yet) automatic. The idea is that we'd have "-1" mean use the system logical dpi. I don't know of a way to receive notifications for xrdb resource changes. Maybe there is, but GTK introduced http://standards.freedesktop.org/xsettings-spec/xsettings-spec-0.5.html to mirror these resources and changes there do cause notifications. GNOME added a settings daemon, as did some other desktops. KDE3 didn't; haven't checked KDE4. http://standards.freedesktop.org/xsettings-spec/xsettings-latest.html That would address 2, but I suspect desktop xsettings daemons don't yet auto change logical dpi when switching monitors. I don't know of a system that allows concurrent different logical DPIs on different monitors. Xrandr might (not sure) give us physical DPI, but we'd have to be clever using that so as not to scale down on projectors, or scale up on handheld displays.

When I say "dynamic" I personally would be happy to restart Firefox. > I don't know of a system that allows concurrent > different logical DPIs on different monitors. No, I don't think that's possible either. > Xrandr might (not sure) give us physical DPI, It does: [jamie@jamie-laptop ~]$ xrandr Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192 eDP1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 282mm x 165mm Obviously you'd have to decide which to use if there were two monitors. I would think that using the system's DPI would be better.

I can confirm this bug. It is already fixed for both Mac OS X and Windows: Mac OS X: bug 674373 Windows: bug 603880 Considering that Mozilla's goal is to make the web accessible, it is really sad that this has not been fixed for a long time.

Any update on this? It is really frustrating to see that this is still not fixed for Linux, while all other platforms behave the right way. This bug makes Firefox unusable for some people on GTK based devices.

(In reply to David Baron [:dbaron] (don't cc:, use needinfo? instead) from comment #22) > I think the answer here is that we should reverse any scaling that happens > for icons, system metrics, and native theme drawing so that they're drawn > the same size no matter what the devPixelsPerPx is. (And also things like > the front end having a minimum height for menu bars in CSS pixels, if my > memory serves.) System metrics and native theme drawing are always in device pixels. Gecko UI icons will scale with the system default scale, but I think that's actually what we want. We have high-DPI icon art available now. (In reply to Martin Jürgens from comment #27) > Any update on this? It is really frustrating to see that this is still not > fixed for Linux, while all other platforms behave the right way. We should fix it, but it's trickier on Linux because Linux doesn't have an obvious API to use to determine the correct scale factor.

ft.dpi is unset. Desktop DPI is matched to screen density via DisplaySize configfile entry. Shown here are Firefox 21 and Konqueror 3.5.10, both with default font size set to 12pt. Firefox UI text nicely matches other apps. Main FF UI shortcomings are tiny icons and scrollbar targets. The only significant rendering difference between the two browsers is due to the old Konq's lack of web font support.

ft.dpi is unset. Desktop DPI is matched to screen density via DisplaySize configfile entry. Shown here are Firefox 21, SeaMonkey rv20, and Konqueror 4.10.2 using the KHTML engine, all with default font size set to 12pt. Both UI text and web page rendering match up well.

ft.dpi is unset. Desktop DPI is matched to screen density via DisplaySize configfile entry. Shown here are Firefox 2.0.0.20, 3.6.28 & 21, SeaMonkey rv19, Konqueror 3, and Chromium 27, all with default font size set to 12pt. UI text in the Geckos again match up well with Konq and other apps. The oldest Gecko, like Konq, lacks web font support. Chromium's icons and UI text are all smaller than elsewhere, and like all WebKit browsers, forces 96 DPI, resulting in smaller text in both UI, and in web pages text sizing in physical units, such as pt.

ft.dpi is unset. Desktop DPI is matched to screen density via DisplaySize configfile entry. Shown here are Firefox 21, SeaMonkey rv20, Konqueror 4.10.4, and Chromium 27, all except Chromium with default font size set to 12pt. User victimization via forced 96 DPI is even worse in Chromium here, where the the adjustment range for default text size has been exceeded, UI text is further shrunken compared to everything else, and web page text sized in pt is even yet smaller. It's clear that the Gecko's, unlike Chromium, are appropriately using DE-specifed fonts for UI, while their icons and scrollbars do lack adequacy. I've been using and testing Mozilla Suite, Firefox & SeaMonkey on KDE Linux desktop systems for over a decade. My recommendation for single display users is to unforce system DPI wherever it can be found. The place to start is to unset Xft.dpi (commonly set to 96 in one, or more, Xresources files). Different distros have various locations and amount of locations where 96 is forced, so it can take some effort to find them all. See e.g. https://qa.mandriva.com/show_bug.cgi?id=57239 & https://bugs.mageia.org/show_bug.cgi?id=10457 What I find easier than finding those other than the non-mandatory Xft.dpi option is to force DPI via a configfile "DisplaySize" option in /etc/X11, either xorg.conf, or the combination of xorg.conf/50-device.conf, xorg.conf/50-monitor.conf & xorg.conf/50-screen.conf. For any interested, the text in the screenshot Konsoles is a result of running this aid to working through DPI issues and collecting bug report data points, in the form of a shell script: #!/bin/sh # xfetch.sh # # run this in X terminal echo $ grep PRETTY /etc/os-release grep PRETTY /etc/os-release echo $ head -n7 /var/log/Xorg.0.log head -n7 /var/log/Xorg.0.log echo "$ grep Output /var/log/Xorg.0.log | egrep -v 'disconnected|no monitor'" grep Output /var/log/Xorg.0.log | egrep -v 'disconnected|no monitor' echo $ 'grep -v ^\# /etc/X11/xorg.conf.d/50-monitor.conf | grep DisplaySize' grep -v ^\# /etc/X11/xorg.conf.d/50-monitor.conf | grep DisplaySize echo $ 'grep -v ^\# /etc/X11/xorg.conf | grep DisplaySize' grep -v ^\# /etc/X11/xorg.conf | grep DisplaySize echo "$ xrdb -query | grep dpi" xrdb -query | grep dpi echo "$ xdpyinfo | egrep 'dime|ution'" xdpyinfo | egrep 'dime|ution' echo "$ xrandr | head -n4" xrandr | head -n4

What is the current preffered way to set firefox's default DPI in linux?

Probably layout.css.devPixelsPerPx Although that page seems to have been deleted from the knowledge base... http://kb.mozillazine.org/Layout.css.dpi

Karl, what about to use the xsettings here, to get the DPI? It's not perfect but it will work somehow.

(In reply to Martin Stránský from comment #36) > Karl, what about to use the xsettings here, to get the DPI? It's not perfect > but it will work somehow. Yes, we can get the DPI, and there is already a function available to do it. Please see Bug 1081142 comment 11. Bug 975919 is also related.

I'll mark this fixed by changes in https://hg.mozilla.org/mozilla-central/rev/bcc6332c88bc even thought that uses GTK's concept of DPI which is not necessarily that described in comment 0. Using GTK's DPI is the right thing to do in a GTK port, and I think the logical DPI should be used when available, as in GTK, in preference to the physical DPI.