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