197037 - [Xft] Fonts get smaller when preferences dpi value is increased

Status: RESOLVED FIXED

(Core Graveyard :: GFX: Gtk, defect, P1)

Description

[Michael Lampe]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020903
Build Identifier: Mozilla 1.2.1 and up

If one increases the dpi value in Preferences/Appearance/Fonts while keeping the
actual monitor resolution constant, Mozilla makes GUI fonts smaller and smaller.
Obviously, it should be the other way round.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Christopher Blizzard (:blizzard)]

Actually, no, this isn't a bug.  The DPI is used for all font resolution.  This
is the same as changing the dpi used in the system fonts dialog.

Comment 2

[Michael Lampe]

If I'm not completley wrong (and I think I'm not) then what you select in
Preferences/Appearance/Fonts is the (pretended) resolution of your _monitor_. If
you increase this value without changing the actual (monitor) resolution, fonts
normally get bigger not smaller. At least all other programs I've seen behave
this way. (KDE for example.)

If you think the current behaviour is correct than you should give mozilla a try
on a 15" notebook LCD display with 1600x1200 pixels (about 125 dpi). I hope you
can read the fonts used for the menu bar, etc ...
 

Comment 3

[Felix Miata]

At this testcase for viewport font display
http://members.ij.net/mrmazda/auth/font-default-short16px.html
I went and took screenshots at 96DPI, 120DPI and 144DPI using 2003031208 Linux
trunk in Mandrake 9.0 KDE and 2003031208 W32 in W98. I can't see any distinction
in Mozilla controls among them. The only apparent difference is in the size of
point values in the web page. Relatively among them, each point size is larger
at 96DPI (16px=12pt), medium at 120DPI (16px=10pt), and smaller at 144DPI
(16px=8pt). This seems to confirm at least part of comment 1.

In contrast to the Linux behavior, the behavior in W98 is that changing the
Mozilla DPI setting has no impact at all. But, changing the OS DPI does have an
impact on both Mozilla controls and point sizes in tandem, just like the point
sizes alone in Linux. If anyone wants, I can attach any or all the six
screenshots to this bug, all taken at 1024x768.

I made the changes to Mozilla in Linux via user.js, but I don't know which of
the following actually is responsible for the change (I think the first), and
why the other exists:
user_pref("browser.display.screen_resolution", 144);
user_pref("browser.screen_resolution", 144);
Setting the DPI via the prefs' line measuring tool is a royal PITA. Whoever
designed that needs to go back to usability school.

Comment 4

[Felix Miata]

Forgot to respond to last paragraph of comment 2.

When I use 1600x1200 on W98 and 19", 120DPI makes the system controls too small,
144DPI leaves them a little small, and 192DPI makes them just right, like 120DPI
at 1024x768. I can't picture how a 15" notebook user could use 1600x1200 at 120DPI.

Comment 5

[Michael Lampe]

> When I use 1600x1200 on W98 and 19", 120DPI makes the system controls
> too small, 144DPI leaves them a little small, and 192DPI makes them
> just right, like 120DPI at 1024x768.

You are confirming expected behaviour: increasing dpi at constant monitor
resolution makes fonts bigger. The bug with Xft-enabled mozilla is that it does
it the other way round: increasing dpi makes fonts smaller.

Comment 6

[Giuseppe Ghibò]

IMHO having the font getting smaller as DPI increases is the right behavior.
Currently there are two units: pixels (px) and (big) points (pt) [or
twips which is 1/20 pt]. Points (i.e. 1/72 of inches) are physical
units, so resolution independent, but Mozilla uses for text font the
"pixel units" (as you can see in Preferencs/Appearence/Fonts), so if
DPI density increases, the fonts appears smaller, because the pixel
size will be smaller. Of course if you fake (or override) your real
screen DPI passing from DPI "X" to DPI "2X" you "see" fonts whose size
is specified in "pt" getting bigger, and fonts whose size is specified
in "px" remaining unchanged, because they will have always the same
height in pixels; you can try for instance to get a screen snapshot of
mozilla with some HTML code containing:

<font style="font-size: 16px; font-family: Arial, sans-serif">ABCDEF
abcdef 16px</font><br>
<font style="font-size: 16pt; font-family: Arial, sans-serif">ABCDEF
abcdef 16pt</font><br>

(of course at 72dpi 1pt = 1px). By opposite if you don't fake
your DPI, you'll see fonts in "pt" unchanged in size, and font
in "px" (i.e. defaults) getting smaller.

Menu (UI) fonts instead seems using phisical units for font size, so 
they are scaled with DPI (in other words the phisical size remains more or 
less constant).

IMHO if mozilla needs to be WYSIWYG from point of view of DPI, like
Konqueror, it needs to add something (e.g. in Appearence/Font menu) to
consider the units of fonts not having a specified size as "pt"
instead of "px".

Comment 7

[Michael Lampe]

You seem to suggest to use the real dpi value. Right?

* A 15" notebook LCD at 1600x1200 has 133 dpi
* IBM's T221 (22,2") at 3840x2400 has 204 dpi

Just try to use xft-enabled mozilla on one of these and tell me if it looks right.

Comment 8

[Giuseppe Ghibò]

Yes, I'm suggesting that if we want to have mozilla fonts
with the same dimensions on all the displays it's needed
to add an option to use defaults "pt" instead of "px".

Honestly the best I tried is 16" at 1600x1200 but if you give
me the spectacular IBM one of 22" I'd be very happy to test
(if I remember right it costs around 7-8000 E/$). On the 1600x1200 at
real 124dpi mozilla menus looks pretty fine (because of the increased
density) and have more or less the same dimensions in millimetres
or inches I get on a 1280x1024 or 1024x768 monitor. For sites
using physical units furtermore I get almost the same layout either
in mozilla or konqueror. 
Of course for text where the fonts don't have a specific size,
I see the characters are too tiny and not much readable (because in 
that case it's used the default "pixel" size). Ditto for 
page where style sheets forces usage of "px" units instead of "pt"
(but in that case you have to use the magnification in Text/Zoom
anyway). The problem because they are appearing too tiny is not related
to Xft or to a mozilla bug with Xft, but to units choosen, 
either by mozilla or by who produces the HTML pages (pixels are not a
physical unit, points are). Since the common resolution of displays 
in the last 10 years was more or less from 800x600 to 1280x1024,
HTML writers have produced pages not taking much care of real resolution,
and have used "pixels" like they were physical units, and not taking much
care about page layout. As now (or in some year) screens are
going to reach "printer" resolutions, is IMHO a nonsense to continue
to use "pixels" as defaults units for HTML pages or UI.

Comment 9

[Michael Lampe]

> ... give me the spectacular IBM one of 22" I'd be very happy to test ...

Me too, I was just illustrating.

Comment 10

[Felix Miata]

Setting the Mozilla DPI pref to something other than the system default (0)
conflicts with the xft system setting, typically producing results opposite
those expected, as in oversize or undersize chrome text, and/or oversize or
undersize page text.

Image suite following if it doesn't get rejected for its 3M size.

Comment 11

[Felix Miata]

Attachment: Impact of XFT.dpi & user_pref("browser.display.screen_resolution", value); in Fedora Mozilla 1/12

Since pictures can often show much better than can words, I'm limiting my words
and submitting the visual evidence. This collection of ZIP files includes 81
png images and one HTML file to load them (nearly) all at once and explain. 

    Summary of what the images show:
1a (Fedora)-With xft, & with system DPI held constant, the size of
   a viewport px shrinks as Mozilla DPI is increased. (columns)
1b (Fedora)-With xft, & Mozilla DPI held non-zero constant, the
   size of a viewport px grows as System DPI is increased. (rows)
1c (Win, other)-Without xft, the size of a viewport px is constant
   as Mozilla DPI is increased. (Same as IE6)
2a (Fedora)-With xft, & with system DPI held constant, the size of
   a viewport pt is constant as Mozilla DPI is increased. (columns)
2b (Fedora)-With xft, & Mozilla DPI held non-zero constant, the
   size of a viewport pt grows as System DPI is increased. (rows)
2c (Win, other)-Without xft, the size of a viewport pt is
   increased as System or Mozilla DPI is increased. (Same as IE6)

    Method of setting DPI:
1. Set Fedora system DPI via /etc/X11/Xresources value "Xft.dpi:".
2. To change Mozilla DPI, put in user.js 
      e.g.'user_pref("browser.display.screen_resolution", 90);'.
3. Set DPI in Win via -> Display Properties -> Advanced -> Font Size.

    URLs used in screenshots:
1. file:///usr/share/doc/HTML/index.html (only matches in Fedora)
2. http://members.ij.net/mrmazda/auth/PointsDemo.html
3. http://members.ij.net/mrmazda/auth/fonts-face-samples-s.html

All images were shot at 1024x768 with font prefs set to 16px/16px. Best viewed
at the highest possible resolution and monitor size in order to see the big
picture with the least amount of scrolling.

    Fedora 0.95 Mozilla Build Info:
mozilla-1.4.1-7 - Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.4.1)
Gecko/20031009
about: buildconfig portions: --enable-default-toolkit=gtk2 --disable-freetype2
--enable-xft

Comment 12

[Felix Miata]

Attachment: Impact of XFT.dpi & user_pref("browser.display.screen_resolution", value); in Fedora Mozilla 2/12

Comment 13

[Felix Miata]

Attachment: Impact of XFT.dpi & user_pref("browser.display.screen_resolution", value); in Fedora Mozilla 3/12

Comment 14

[Felix Miata]

Attachment: Impact of XFT.dpi & user_pref("browser.display.screen_resolution", value); in Fedora Mozilla 4/12

Comment 15

[Felix Miata]

Attachment: Impact of XFT.dpi & user_pref("browser.display.screen_resolution", value); in Fedora Mozilla 5/12

Comment 16

[Felix Miata]

Attachment: Impact of XFT.dpi & user_pref("browser.display.screen_resolution", value); in Fedora Mozilla 6/12

Comment 17

[Felix Miata]

Attachment: Impact of XFT.dpi & user_pref("browser.display.screen_resolution", value); in Fedora Mozilla 7/12

Comment 18

[Felix Miata]

Attachment: Impact of XFT.dpi & user_pref("browser.display.screen_resolution", value); in Fedora Mozilla 8/12

Comment 19

[Felix Miata]

Attachment: Impact of XFT.dpi & user_pref("browser.display.screen_resolution", value); in Fedora Mozilla 9/12

Comment 20

[Felix Miata]

Attachment: Impact of XFT.dpi & user_pref("browser.display.screen_resolution", value); in Fedora Mozilla 10/12

Comment 21

[Felix Miata]

Attachment: Impact of XFT.dpi & user_pref("browser.display.screen_resolution", value); in Fedora Mozilla 11/12

Comment 22

[Felix Miata]

Attachment: Impact of XFT.dpi & user_pref("browser.display.screen_resolution", value); in Fedora Mozilla 12/12

Comment 23

[Michael Lampe]

> Setting the Mozilla DPI pref to something other than the system
> default (0) conflicts with the xft system setting, typically
> producing results opposite those expected, as in oversize or
> undersize chrome text, and/or oversize or undersize page text.

Bingo! That was indeed the problem. Thank you for mentioning that!

BTW: Your statement is obviouslay worth a bugzilla entry of its own.

Anyway, I now have finally upgraded to an xft-enabled mozilla-1.5.
Everything is fine so far ;-)

Comment 24

[Felix Miata]

Reporter, this bug is not "fixed" just because you have a workaround. "Fixed" is
for bugs eliminated via a code patch.

Comment 25

[Felix Miata]

status should still be NEW

Comment 26

[Felix Miata]

See also Fedora bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107803

Comment 27

[Robert Mohr]

Is bug 224729 a dupe of this?

Comment 28

[Felix Miata]

*** Bug 225961 has been marked as a duplicate of this bug. ***

Comment 29

[David Baron :dbaron:]

The problem is that we're giving font sizes to Xft in points.  We should
probably use FC_PIXEL_SIZE instead of FC_POINT_SIZE, and perhaps also get rid of
the hack in GetOSDpi in nsDeviceContextGTK.cpp.

Comment 30

[David Baron :dbaron:]

*** Bug 224729 has been marked as a duplicate of this bug. ***

Comment 31

[Bob McElrath]

Perhaps a worse consequence: font sizes specified in px are not constant as DPI
is changed.  Go here:

  http://mcelrath.org/Notes/Fonts

and change mozilla's DPI.  (you must quit and restart mozilla to see the effect)
 If mozilla was doing it correctly, the png letters would always line up with
the broser font letters.

(I know font sizes in px is bad web design -- but I'm trying to line up browser
fonts with png's generated by latex for equations -- so I have to specify an
absolute font size in px)

Comment 32

[Felix Miata]

"Perhaps a worse consequence: font sizes specified in px are not constant as DPI
is changed."

Bob, if you read summary item 1a in comment 11 you'll see that is already
documented in the test suite. I've since found the Fedora behavior also applies
in Mandrake 9.2 w/ Mozilla 1.4. It probably applies to all distros using xft
with an Xft.dpi: setting in /etc/X11/Xresources.

Comment 33

[David Baron :dbaron:]

Attachment: patch that didn't work

I tried this, but it messed up system fonts, and fontconfig seems to pick
different fonts when pixel sizes are used than when point sizes are used.

Comment 34

[Felix Miata]

*** Bug 188995 has been marked as a duplicate of this bug. ***

Comment 35

[David Baron :dbaron:]

Attachment: patch

This does work, although it also seems to change noticeably the fonts that are
chosen, which seems odd.

Comment 36

[David Baron :dbaron:]

Attachment: patch

This adds fixup of system fonts in the GTK2 case.

The fonts differ on my system because I customized my Xft DPI to 116dpi
(correct), which we round to 120dpi for internal use.  So I think the new
result is correct and the old result was incorrect.

Comment 37

[David Baron :dbaron:]

Attachment: patch

Comment 38

[David Baron :dbaron:]

Attachment: patch

Change the error handling if GetXftDPI fails.

Comment 39

[David Baron :dbaron:]

Attachment: patch

Same as previous, but merged to trunk (bryner's nsIDeviceContext
deCOMtamination).

Comment 40

[Brian Ryner (not reading)]

Comment on attachment 140816 [details] [diff] [review]
patch

I'm not entirely comfortable with the + 0.000001, but the result is better than
what we have currently... so r=me.

Comment 41

[David Baron :dbaron:]

Fix checked into trunk, 2004-02-23 13:38 -0800.

(And just FWIW, the screenshots really weren't necessary.  The source of the
problem was clear to me from comment 0.)

Comment 42

[Bob McElrath]

How long will it take for builds with this patch to appear?  I need to do some
testing...

Comment 43

[David Baron :dbaron:]

Try tomorrow's nightly build (in about 21 hours).

Comment 44

[Felix Miata]

Those screenshots predate your first comment or patch by about 3 months though.

Comment 45

[David Baron :dbaron:]

*** Bug 201020 has been marked as a duplicate of this bug. ***