Hi, Recently, while reviewing Fedora testers reports on the DejaVu font, it has come to my attention the user feeling about the way GNOME forces 96dpi in user sessions hasn't changed much over the years, and still hovers between incomprehension and outwards hate (especially among KDE users). Rahul Sundaram has convinced me it might be the time to put the subject on the table again, and that fedora-devel may be the right forum to do so. Since I have little appetite for a new flame war, if tempers haven't cooled down enough since last time I'll forget about it and try again in a few years. So: The contentious issue ===================== Since the beginning of 2003 GNOME font rendering is controled by a "dpi" gconf key initialised by default at 96dpi. Why it is good ============== 1. Bill does it in Windows, and Bill can not be wrong. 2. many screens actually have a dpi close to 96 3. some fonts have hinting optimised for 96dpi, they look better on close-to-96-dpi screens when the font rendering engine is tricked into thinking it's a 96dpi screen 4. fontconfig has a "dpi" tunable 5. In 2002, the dpi setting of X11 (xdpyinfo) could not be trusted : a. many people forced it to 75 or 100 b. computing the correct dpi requires knowledge of the exact screen dimensions, you can get it by parsing screen EDID info, but the Linux DCC implementation of the time lacking c. no X11 configurator of the time knew how to teach X11 the correct screen size (even though the corresponding setting, DisplaySize, has been existing all along) 6. it has a zooming effect 7. anaconda and rhbg were too dumb to get by without forcing the dpi, so we forced it on everyone 8. what the w3c calls pixels is actually angles of view, not hardware pixels, so software should ignore the actual hardware limitations 9. what does dpi mean for a projector? 10. we where in the big leap forward GNOME 2 times, and what users or developers of the rival DE thought weighted little before the consistency of a small team's view Why it is bad ============= I'll start by refuting the previous arguments : 1. Bill may do it now, but won't do it for long with Aero, and won't we look ridiculous holding back on a change till he ok's it? 2. On 2. the GNOME developers hit a streak of luck. The migration to LCDs and flat-panels has seriously retrained the natural tendency for hardware to improve, and LCDs have only recently recovered the dpi levels achieved by CRTs in the past. Also, 1. was a natural deterrent for hardware manufacturers to improve resolutions, as the main consumer OS couldn't take advantage of them. You'll note however 1. won't be true for long, LCDs in laptops already far exceed the 100 mark, and devices like OLPC have wildly changing resolutions depending of the mode their screen use. 96dpi may be right for a 94 or 98 dpi screen, but for a 125dpi one? 3. if font rendering needs resolution rounding, do some rounding but do not force a single value everywhere 4. So what ? we don't expose every low-level setting as is without giving some thought on its use or naming. Also fontconfig can also scale fonts without touching dpi. 5. a. no one does this anymore b. the FLOSS EDID parsing implementations today are way better they were. In fact getting EDID to work is a prerequisite for "just working" screen configuration (hotplug, multihead...) and many core Xorg developers have made it their priority c. the natural solution to the X11 autoconf limits then and now would have been to set screen size system-wide in system-config-display (for non-DCC capable hardware) 6. If you want a zoom, use a zoom factor not a side-effect of something completely orthogonal. You don't change your text print size by switching between 300, 600, 1200 or 2400 dpi printers, right? 7. do we want to propagate the limitations of anaconda and rhbg to the user GUI session? If they need 96dpi forcing, they should do it at their own level. 8. if you want to use w3c virtual pixels, you have to use virtual pixels for image sizes. And we all know developers (even mozilla/firefox developers) use hardware pixels for image sizing. So all the "it's not actual hardware pixels" stance is pure fluff 9. every projector has a recommended throw distance and view zone, as bulb luminosity is not infinite. So it's possible to define a typical DPI even in their case. 10. hopefully making KDE and GNOME work bad together has not the same glamour now as in these heroic times. Additionally, my personal reasons for disagreeing with this setting are the following : A. text size and resolution are different things (cf printer argument). The dpi hack is mixing orthogonal concepts B. you can't ignore the hardware capabilities as ultimately you'll render on actual hardware not some sort of abstraction. And actual hardware is moving away from the 96dpi model (you can only increase screen size so much before you have to compete on resolution) C. hardware resolution is a device-specific system-wide setting. Changing it at the GNOME user session level is plain wrong. i. It forces every single user of a system to set settings for the same devices individually ii. It breaks when the session is reused on hardware with different characteristics (nfs home, OLPC) iii. It breaks with every single non GNOME app (hello KDE users, Fedora loves you) or even with GNOME apps launched when gconfd is not running (hello gconfd crashes and GNOME apps ran from KDE) D. text UI relative size *is* a user-level setting. However it can only be achieved by applying a zoom factor over a stable baseline (hardware DPI) or every device change forces the user to recalibrate it. E. how come KDE managed all these years without forcing DPI to something else than the hardware DPI, if 96dpi everywhere was such a must-have? With the FLOSS desktop moving away from hardcoded settings to dynamic automated HAL-mediated setup I hope we can soon let this ugly wart behind us. Thank you to everyone who read my boring prose till its end. Kind regards, -- Nicolas Mailhot
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
