[LONG] On the 96dpi Fedora/GNOME setting

[Nicolas Mailhot]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060717/7b860e17/attachment.sig>