Closed Bug 197037 Opened 21 years ago Closed 21 years ago

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

Categories

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

x86
Linux

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.7alpha

People

(Reporter: michael.lampe, Assigned: dbaron)

References

Details

(Whiteboard: [patch])

Attachments

(13 files, 5 obsolete files)

288.89 KB, application/octet-stream
Details
284.40 KB, application/octet-stream
Details
279.99 KB, application/octet-stream
Details
272.77 KB, application/octet-stream
Details
271.65 KB, application/octet-stream
Details
271.88 KB, application/octet-stream
Details
267.21 KB, application/octet-stream
Details
259.65 KB, application/octet-stream
Details
286.79 KB, application/octet-stream
Details
271.09 KB, application/octet-stream
Details
273.29 KB, application/octet-stream
Details
157.25 KB, application/octet-stream
Details
8.74 KB, patch
bryner
: review+
blizzard
: superreview+
Details | Diff | Splinter Review
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:
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.
Blocks: xft_tracking
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → WONTFIX
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 ...
 
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
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.
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.
> 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.
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".
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.
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.
> ... give me the spectacular IBM one of 22" I'd be very happy to test ...

Me too, I was just illustrating.

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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: [Xft] Fonts get smaller when dpi value is increased → [Xft] Fonts get smaller when preferences dpi value is increased
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
> 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 ;-)
Status: NEW → RESOLVED
Closed: 21 years ago21 years ago
Resolution: --- → FIXED
Reporter, this bug is not "fixed" just because you have a workaround. "Fixed" is
for bugs eliminated via a code patch.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
status should still be NEW
Status: REOPENED → NEW
Is bug 224729 a dupe of this?
Blocks: 224729
*** Bug 225961 has been marked as a duplicate of this bug. ***
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.
*** Bug 224729 has been marked as a duplicate of this bug. ***
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)
"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.
Attached patch patch that didn't work (obsolete) — Splinter Review
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.
*** Bug 188995 has been marked as a duplicate of this bug. ***
Attached patch patch (obsolete) — Splinter Review
This does work, although it also seems to change noticeably the fonts that are
chosen, which seems odd.
Attachment #140349 - Attachment is obsolete: true
Assignee: blizzard → dbaron
Priority: -- → P1
Whiteboard: [patch]
Target Milestone: --- → mozilla1.7alpha
Attached patch patch (obsolete) — Splinter Review
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.
Attached patch patch (obsolete) — Splinter Review
Attachment #140530 - Attachment is obsolete: true
Attachment #140542 - Flags: superreview?(blizzard)
Attachment #140542 - Flags: review?(bryner)
Attached patch patch (obsolete) — Splinter Review
Change the error handling if GetXftDPI fails.
Attachment #140542 - Attachment is obsolete: true
Attachment #140583 - Flags: superreview?(blizzard)
Attachment #140583 - Flags: review?(bryner)
Attachment #140542 - Flags: superreview?(blizzard)
Attachment #140542 - Flags: review?(bryner)
Attached patch patchSplinter Review
Same as previous, but merged to trunk (bryner's nsIDeviceContext
deCOMtamination).
Attachment #140583 - Attachment is obsolete: true
Attachment #140583 - Flags: superreview?(blizzard)
Attachment #140583 - Flags: review?(bryner)
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.
Attachment #140816 - Flags: superreview?(blizzard)
Attachment #140816 - Flags: review+
Attachment #140816 - Flags: superreview?(blizzard) → superreview+
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.)
Status: NEW → RESOLVED
Closed: 21 years ago21 years ago
Resolution: --- → FIXED
How long will it take for builds with this patch to appear?  I need to do some
testing...
Try tomorrow's nightly build (in about 21 hours).
Those screenshots predate your first comment or patch by about 3 months though.
*** Bug 201020 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: