433664 - font size does not increase with DPI setting

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Csimbi]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14

I became a happy owner of a 24" display recently.
I had to change the DPI setting because in 1920*1600 everything became nearly unreadable (I don't have so good eyes anymore). The new DPI setting is 144 (150%).
My homepage is set to Google - however it seems that it does not matter which page I am looking at.
Anyway, after I changed the DPI and restarted my PC, I checked IE6 first. IE6 scales up the fonts properly without any additional messing around, so I expected Firefox to do the same thing, however Firefox does not do anything: same tiny fonts (manual adjustment on every page does not count). I was able to find extensions that imitate the IE-like behavior - to scale all pages automatically, however I was not satisfied with the results. It would be nice if there was an internal scaler that could be replaced by extensions if needed.
Thanks.

Reproducible: Always

Steps to Reproduce:
1. Start Firefox and take a look at a web page; take mental note (screenshot) how it looks.
2. Buy and add large flat panel (24" or bigger)
3. Change DPI to 144.
4. Start Firefox and take a look at the same web page and compare with its earlier look.
5. Realize that Firefox did not do anything, and the font size is tiny (nigh unreadable).
Actual Results:  
Font size remains the same in 96 and 144 DPI.

Expected Results:  
Font size to be scaled up according to the DPI setting on every page.

There are some extensions that do this on a per page basis (or, for all pages), however they are not good enough. Besides, I think that this should be a base functionality in Firefox, so one should not hunt for and experiment with a bunch of useless extensions.

I marked it as a major problem for now for these reasons:
 - there is no good workaround (the again, the available extensions less than satisfactory)
 - the small font tire my eyes very quickly (not ergonomic)
 - IE6 provides this already and Firefox is still lacking this? Come on!

Comment 1

[Nochum Sossonko [:Natch]]

In firefox 2 you can easily scale fonts by going to View-->Text Size-->Increase, or better yet you can change the default font size in Tools-->Options-->Content.

Firefox 3 (coming out soon) has a feature to scale full web pages at a shot!!

(alternatively you can just press ctrl-shift-+ key combination and not have to go through the menus)!

I hope this helps you, although I still think the DPI setting should have an effect on Firefox.

Comment 2

[Csimbi]

Hi Natch,
thanks for the reply.
Yes, I am aware of these workarounds, the shortcuts, etc.
The view->text thing does not stick (setting is dropped), and does not scale the text properly, neither (there are some portions of text that remain unscaled).
The tools->options variant does not work as expected: some fonts are changed (the font, not the size) while some are left the same font and size.
So, I would like to leave it open for now and hope it will be backported from FF3. But, I am a little sceptic about FF3 scaling, let's see when it's out.

Comment 3

[Nochum Sossonko [:Natch]]

If this changed since the new firefox 3 (i.e. firefox 2 handled it fine) AND this problem is still there on the latest nightly http://www.mozilla.org/developer/#builds, then I'd suggest you set this bug as blocking bug #378927.

Please try it though on the latest nightly first to see if the latest code still has the problem.

Comment 4

[Philipp Wolfer]

I've got this problem with the 3.0.3 release in Ubuntu Hardy. The default font size is ridiculous small if a page uses relative font sizes, often nearly unreadable.

I tried to increase layout.css.dpi which shows no effect up to 191 DPI. At 192 DPI the font sizes suddenly change to be really large, in addition the toolbar icons also increase in size. Increasing the DPI setting even more seems to have no effect again.

My current workaround is to set the minimum font size to 12pt, but this breaks many layouts. Zooming the page is not an option since it will zoom everything on a web page, including the graphics (nice feature, but not the correct solution for this issue).

Comment 5

[Michal 'hramrach' Suchanek]

It looks like Firefox does not recognize the DPI unless set in about:config

(look for the dpi setting there)

Also firefox seems to set default font size in pixels because the font size does not change even if the DPI is changed, it has to be set manually to a dpi based size in a css.

Firefox 2.0.14 on NetBSD (linux emulation)

Comment 7

[Jo Hermans]

will probably be solved in bug 426788

Comment 8

[Felix Miata]

This should be a core bug duplicate of bug 186718 but 186718 is marked SeaMonkey rather than core.

Comment 9

[Nochum Sossonko [:Natch]]

Confirming. If bug 186718 is indeed a Core bug, please mark it as such and dupe.

Comment 10

[Felix Miata]

If this is a core bug, then bug 186718 is no less a core bug, which would make this the dupe of a core bug reported over 6 years ago.

Comment 11

[Nochum Sossonko [:Natch]]

The truth be said, this really belongs in Firefox, if I read bug 186718 correctly. This is because of certain settings (using px instead of pt) which I imagine are specific to each app. Then again, like I said, feel free to dupe if I'm wrong.

Comment 12

[Felix Miata]

I don't think this reporter's complaint has anything to do with specific sizes for the selected fonts for either app, but rather the fact that the sizes are listed in px rather than pt. Most apps size text in pt. If Gecko sizes were set in pt, then the selected sizes would grow or shrink as DPI varies (away from 96), as this bug's summary indicates, whether in Firefox or SeaMonkey. As long as they remain indicated in px, raising DPI will not increase the sizes, which makes Firefox defaults smaller than IE defaults as long as the user does not make a manual adjustment to compensate for a DPI increase.

A switch to pt however would increase the granularity of selections available. At 144 DPI for instance, the pt to px ratio is 1:2, which would cut the selections in about half from the 75 DPI of many older and Linux displays, and by about 1/3 from the 96 DPI usually assumed by Windows, OS X, and many recent Linux distros.

Note too the other bug is marked cross-platform, which this should be, as it affects Linux too.

Comment 13

[Ria Klaassen (not reading all bugmail)]

I have a similar problem with a WUXGA laptop and the extension Glazoom ( https://addons.mozilla.org/en-US/firefox/search?q=glazoom&status=4 ) helps a bit by setting one fixed size for all pages (I'm using 133% currently). Plus you find (just like IE8) a little expandable menu on the statusbar. 133% is still a bit too small and 150% is way too big, there is nothing in between, that's why it will never be a comfortable computer (but great for photographs).

Comment 14

[WulfTheSaxon [:Wulf]]

I've filed bug 477213 for supporting the layout.css.dpi pref on Windows. I'm guessing it should either block or depend on this bug.

For the folks who are saying that the fix is to stop specifying the font size in px: The definition of a the "px" unit in CSS 2.1 is not the same as a physical pixel. It is to be scaled according the the user's DPI. See http://www.w3.org/TR/CSS21/syndata.html#length-units

Comment 15

[Felix Miata]

Same with SeaMonkey

Comment 16

[Gili Tzabari]

FireFox is at least somewhat usable under high DPI under Windows. Thunderbird is not. HTML messages are rendered using 4-pt font (?!?). It's completely unreadable at 1280x1024 monitors.

Comment 17

[costinel]

this is still an issue on windows xp with 144 dpi. firefox 3.5 worked just
great. i upgraded to 3.6.b3 and suddenly the gui collapsed. screenshots with
3.5 and 3.6b3:

http://clip2net.com/page/m0/2714596 (3.6b3) TOO SMALL
http://clip2net.com/page/m0/2714709 (3.5) SLIGHTLY TOO LARGE, BUT IT'S MUCH
MORE CONFORTABLE TO THE EYE, working 8 hours a day at 37' from 2 meters
distance

if i managed to workaround websites with defaultzoom level extensio, the gui is a terrible mess in 3.6.b3!

Comment 18

[Sylvain Pasche]

The behavior changed intentionally, see bug 426788.

If you want the same behavior as Firefox 3.5 when using 144 dpi, go to about:config and set layout.css.devPixelsPerPx to "2".

If you want a behavior that kind of matches other Windows applications (and IE) when using 144 dpi, set layout.css.devPixelsPerPx to "1.5" (1.5 = 144 / 96).

Comment 19

[costinel]

oh, thank you Sylvain, your hint saved my day (actually, evening!).
I played a little with ranges from 1,4 to 2 and found that 1,7 is the perfect value for my eyes. Also had to figure that I must enter comma and not dot, since my locale has comma for decimal separator.

THANK YOU !!!

Comment 21

[Marcus Groeber]

(In reply to comment #18)

> If you want a behavior that kind of matches other Windows applications (and IE)
> when using 144 dpi, set layout.css.devPixelsPerPx to "1.5" (1.5 = 144 / 96).

Thanks - I was affected by this issue after upgrading from FF 3.5 to 3.6 as well, and I guess many other users of 1920x1080 displays as well. My personal preference would be for the behaviour in 3.5 (which indeed stretched the UI a bit much, but at least produced web sites scaled in line with the DPI setting by default, and with the expectation set by other Windows apps).

A small note on this workaround: depending on the decimal separator in your locale, this value has to be typed as "1,5" rather than "1.5" (e.g. German), or it will be ignored.

Comment 22

[Martin Jürgens]

this is a bad default behavior, as most people probably want firefox to also display text bigger than before with a lower dpi setting

Comment 23

[Felix Miata]

Maybe Gecko should watch for DPI changes and when one occurs pop up a dialog asking the user to choose among:

1-have Gecko inherit its font defaults from the DTE rather than using its own
2-have scaling the way IE does turned on (by adjusting layout.css.devPixelsPerpx), allowing fine tuning via the prefs panel
3-open the font prefs panel along with a help window or pane suggesting what the individual prefs be changed to based upon the amount of DPI change
4-doing nothing

For Vista & W7, maybe it's time to incorporate suggestions from http://msdn.microsoft.com/en-us/library/dd464660(VS.85).aspx

Comment 24

[Danial Horton]

isn't it layout.css? that seems to work just fine.

Comment 25

[Danial Horton]

err layout.css.dpi infact.

Comment 26

[Felix Miata]

Attachment: 144 DPI WinXP screenshot

(In reply to comment #24)
> isn't it layout.css.dpi? that seems to work just fine.

It doesn't seem so fine here on a 144 DPI WinXP desktop. All 3 browsers are set to layout.css.dpi @ 0 and layout.css.devPixelsPerPx left alone in the 2 supporting it @ 1.0 default . Booted @120 DPI, all 3 do match.

Comment 27

[Danial Horton]

thats because you set 0, if you set it to 96 it uses the same method as IE which is basically a default 125% zoom matching the dpi %

Comment 28

[Danial Horton]

IE matches the 150% zoom to 150% dpi as well.

i prefer setting 96 and zooming since some VB forums have weird font sizing otherwise.

Comment 29

[Danial Horton]

https://bugzilla.mozilla.org/show_bug.cgi?id=531299

it seems this just got marked invalid, both have the same cause iirc.

Comment 30

[Felix Miata]

Attachment: 144 DPI Linux screenshot

Identical to attachment 530543 [details] except for taken on Linux instead of WinXP. This is the expected behavior, which is unavailable on WinXP.

Comment 31

[Ahmad Syukri]

Attachment: UA vs Physical: 96dpi Debian

Screenshots of 3 different test cases of UA dimension vs physical dimension on Debian/Linux. First one is 96 dpi. Second is 168 dpi, which is my native resolution. While the last one is 168 dpi with layout.css.devPixelsPerPx = 1.75 (168/96).

All I can opine is that the root of all evil is the CSS 2.1 recommendation on length. Reference pixel is always from 96 dpi resolution. Therefore a 12pt text on a (Gecko) webpage will not be the same as 12pt text on other GUI widgets unless the resolution was 96 dpi.

Really, what is up with that spec? Display device is getting more modern, we will have very high density display (like iPhone 4's display) coming along. 96 dpi isn't going to make sense on those. It is time we treat 1mm or 1in as what they are. Maybe Gecko developers ought to propose to W3C for review on this particular section.

layout.css.devPixelsPerPx is not the solution because you'll lose pixel precision. Images get scaled up instead of being representated in the original resolution.

Comment 32

[Ahmad Syukri]

Attachment: UA vs Physical: 168dpi Debian

Comment 33

[Ahmad Syukri]

Attachment: UA vs Physical: 168dpi Debian with 1.75 devPixelsPerPx

Comment 34

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)

Comment 35

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 36

[Daniel Holbert [:dholbert]]

I believe this has been fixed (or at least the behavior has changed quite a bit) during the 12 years since the last meaningful comment here. We handle HiDPI / system-level pixel-scaling just fine now, with retina displays on macOS, 125% system scale factors as the default on some Windows systems, etc.

(Side note, the screenshots here seem to be of http://fm.no-ip.com/Auth/dpi-screen-window.html which doesn't load anymore.)

--> Closing as WORKSFORME. If any issues here happen to remain, those should be spun off as new bugs at this point. (As one example, there's a bit of known weirdness on Wayland, which is sort-of a Wayland bug -- see bug 1818837.)