glynn at gclements.plus.com
Fri Jun 27 18:15:38 PDT 2008
Sean Estabrooks wrote:
> > I care about AA text. Specifically, it matters quite a lot to me that
> > I never have to look at it. The only time that scalable fonts make
> > sense is if you absolutely have to display some text at an exact size
> > (i.e. desktop publishing). Even in cases where there are *some* layout
> > constraints (e.g. diagrams), choosing the nearest bitmap font size is
> > usually perfectly adequate.
> As soon as you admit that there are cases where scalable fonts are desirable
> you must begrudgingly accept that people will endeavor to support them.
> This thread is not about a return to fixed-sized fonts, rather it is about
> supporting scalable fonts (and other GUI elements) in a more consistent
Sure, there are cases where scalable fonts are desirable. I just wish
that developers would not try to force them onto the other 95% of
cases. The fonts used in a file manager or a text editor don't need to
be some exact physical size on the screen.
And even in the cases where they are desirable (i.e. DTP), the thing
that really matters is relative consistency, not absolute size. And
even DTP packages only scale the document, not the UI.
> Anyway, a system which supports scalable fonts can trivially support
> pixel based fonts,
It could, if the developers weren't so obsessed with physical sizes
that they go out of their way to prevent you from using pixel sizes
> whereas the reverse just isn't true. So far, i haven't
> seen where any of your ideas can be used to improve scalable font
I'm not interested in scalable font rendering. I'm a computer
programmer, not a graphic artist, and my main use for a computer is to
view and edit text.
However, on the "improving" front, I have at least tried to remind
people that "resolution independence" involves more than just fonts.
Possibly the biggest reason for hard-coded DPI assumptions is that
people keep coming up with systems where text is measured in points
and everything else is measured in pixels. At which point, you end up
forcing a fixed "nominal" resolution so that everything works as
expected on a wide range of displays.
The second biggest reason for hard-coded DPI assumptions is that
people keep coming up with systems where physical sizes are the only
things that matter, essentially pretending that you have infinite
resolution. At which point, everything has to be substantially
over-sized, with even the thinnest lines being several pixels thick,
otherwise everything becomes a faint blur.
Right now, a typical monitor still has a low enough resolution that
single-pixel lines are common UI elements. If you try to design a UI
where everything is specified in physical units, but has roughly the
same dimensions on an average monitor as the pixel-based alternative,
you end up with a blurred mess (or, without AA, a jagged mess) of
near-unity-width lines, raster images scaled by near-unity factors,
etc. So you either oversize everything, or you end up having to hack
in a fixed nominal DPI so that the resulting pixel sizes end up as
> > The notion that AA text is a good idea is a classic example of reverse
> > reasoning. Starting with the quasi-religious ...
> More proof that Goodwin's law needs to be updated to include accusations
> of religiosity against anyone with a differing view.
No, I have had plenty of disagreements with people for all kinds of
reasons, and I don't normally imply quasi-religious motivations. I
describe that position as quasi-religious because I think that it's,
well, quasi-religious. And that's the only way that I can see this
obsession with physical sizes.
We managed to survive with a hard-coded 75 dpi for years. Windows was
quite successful with a hard-coded choice of either 96 or 120 dpi (in
spite of a few programs overlooking the 120 dpi possibility).
But now, if the monitor says it's 121x124 dpi, apparently it's my
responsibility to somehow choose a 20.167 x 20.667 point font to avoid
it looking like crap. And it's also my responsibility to re-calculate
those settings if I switch monitors.
Glynn Clements <glynn at gclements.plus.com>
More information about the xorg