Closed
Bug 197037
Opened 22 years ago
Closed 21 years ago
[Xft] Fonts get smaller when preferences dpi value is increased
Categories
(Core Graveyard :: GFX: Gtk, defect, P1)
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:
Comment 1•22 years ago
|
||
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.
Reporter | ||
Comment 2•22 years ago
|
||
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 → ---
Comment 3•22 years ago
|
||
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•22 years ago
|
||
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.
Reporter | ||
Comment 5•22 years ago
|
||
> 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•22 years ago
|
||
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".
Reporter | ||
Comment 7•22 years ago
|
||
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•22 years ago
|
||
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.
Reporter | ||
Comment 9•22 years ago
|
||
> ... give me the spectacular IBM one of 22" I'd be very happy to test ...
Me too, I was just illustrating.
Comment 10•22 years ago
|
||
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
Comment 11•22 years ago
|
||
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•22 years ago
|
||
Comment 13•22 years ago
|
||
Comment 14•22 years ago
|
||
Comment 15•22 years ago
|
||
Comment 16•22 years ago
|
||
Comment 17•22 years ago
|
||
Comment 18•22 years ago
|
||
Comment 19•22 years ago
|
||
Comment 20•22 years ago
|
||
Comment 21•22 years ago
|
||
Comment 22•22 years ago
|
||
Reporter | ||
Comment 23•22 years ago
|
||
> 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: 22 years ago → 22 years ago
Resolution: --- → FIXED
Comment 24•22 years ago
|
||
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 → ---
Comment 26•22 years ago
|
||
See also Fedora bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107803
Comment 27•22 years ago
|
||
Is bug 224729 a dupe of this?
Comment 28•22 years ago
|
||
*** Bug 225961 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 29•21 years ago
|
||
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.
Assignee | ||
Comment 30•21 years ago
|
||
*** Bug 224729 has been marked as a duplicate of this bug. ***
Comment 31•21 years ago
|
||
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•21 years ago
|
||
"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.
Assignee | ||
Comment 33•21 years ago
|
||
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•21 years ago
|
||
*** Bug 188995 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 35•21 years ago
|
||
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 | ||
Updated•21 years ago
|
Assignee: blizzard → dbaron
Priority: -- → P1
Whiteboard: [patch]
Target Milestone: --- → mozilla1.7alpha
Assignee | ||
Updated•21 years ago
|
Attachment #140527 -
Attachment is obsolete: true
Assignee | ||
Comment 36•21 years ago
|
||
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.
Assignee | ||
Comment 37•21 years ago
|
||
Attachment #140530 -
Attachment is obsolete: true
Assignee | ||
Updated•21 years ago
|
Attachment #140542 -
Flags: superreview?(blizzard)
Attachment #140542 -
Flags: review?(bryner)
Assignee | ||
Comment 38•21 years ago
|
||
Change the error handling if GetXftDPI fails.
Attachment #140542 -
Attachment is obsolete: true
Assignee | ||
Updated•21 years ago
|
Attachment #140583 -
Flags: superreview?(blizzard)
Attachment #140583 -
Flags: review?(bryner)
Assignee | ||
Updated•21 years ago
|
Attachment #140542 -
Flags: superreview?(blizzard)
Attachment #140542 -
Flags: review?(bryner)
Assignee | ||
Comment 39•21 years ago
|
||
Same as previous, but merged to trunk (bryner's nsIDeviceContext
deCOMtamination).
Attachment #140583 -
Attachment is obsolete: true
Updated•21 years ago
|
Attachment #140583 -
Flags: superreview?(blizzard)
Attachment #140583 -
Flags: review?(bryner)
Comment 40•21 years ago
|
||
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+
Updated•21 years ago
|
Attachment #140816 -
Flags: superreview?(blizzard) → superreview+
Assignee | ||
Comment 41•21 years ago
|
||
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: 22 years ago → 21 years ago
Resolution: --- → FIXED
Comment 42•21 years ago
|
||
How long will it take for builds with this patch to appear? I need to do some
testing...
Assignee | ||
Comment 43•21 years ago
|
||
Try tomorrow's nightly build (in about 21 hours).
Comment 44•21 years ago
|
||
Those screenshots predate your first comment or patch by about 3 months though.
Assignee | ||
Comment 45•21 years ago
|
||
*** Bug 201020 has been marked as a duplicate of this bug. ***
Updated•16 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•