[Openfontlibrary] david berlow on screen type

Raph Levien raph.levien at gmail.com
Wed Mar 7 15:02:16 PST 2007


On 3/1/07, Alexandre Prokoudine <alexandre.prokoudine at gmail.com> wrote:
> On 2/6/07, Raph Levien wrote:
>
> > I've been playing with this kind of thing too, in different ways. See,
> > for example, my FontFocus prototype:
> >
> > http://www.artifex.com/FontFocus.pdf
>
> <snip>
>
> > Bottom line: it would definitely be possible for Linux to improve its
> > screen font display, but it requires a sense of will from the
> > community, which I think is basically lacking. Much more likely to see
> > incremental improvements, and chasing what the proprietary systems do
> > for their screen fonts.
>
> Will itbe legally possible to use FontFocus technology in, say,
> FreeType? If yes, did you contact David or anyone else from their
> team?

Short answers: yes, and yes, but not recently.

Let me expand a bit, as I think these questions get to significantly
deeper issues.

First off, the patent application for FontFocus was allowed to lapse.
Consequently, the ideas are now in the public domain and everybody is
free to implement them. That said, it's not obvious that's the best
direction to go.

The design space of font rendering technologies is large, and there is
no single optimum. FF is optimized for two goals: no special
dependencies on the display technology, and matching the metrics of
the existing text layout, i.e. for displaying PDF files. To achieve
these goals, several other aspects suffer. For one, glyphs don't have
entirely consistent appearance. For two, it's computationally fairly
complex and, probably more importantly, that complexity needs to be
propagated upwards to the layer that lays out strings into sequences
of glyphs. Unlike other technologies such as ClearType, it cannot
simply be applied on a glyph-by-glyph basis. And, of course, when you
know for a fact what your display technology looks like (LCD RGB
sub-pixelling, for example), it's usually going to be possible to do
even better by breaking out of pure grayscale.

Many, many text rendering applications do not require the matching of
existing layout metrics. Among these are UI strings, web browsing, and
document display in which reflowing the text is feasible. For these
applications, the best grayscale solution is to make glyphs
integer-width, as David Berlow recommends. You lose a little bit of
refinement in terms of spacing (including kerning), but if you're
designing the font specifically for the application, as Berlow has
done, then you can work around that.

The second generation (Vista) ClearType provides another avenue to
making nice spacing: move the glyphs by sub-pixel offsets. In a
grayscale world, this would lead to serious blurring, but LCD's there
is no serious compromise.

Again, the evolution of display technology makes it very, very
difficult to converge on a single best rendering technology. Five
years ago, CRT's were the most popular display technology (sales of
LCD's passed CRT's in late 2003: http://www.gizmag.com/go/2427/). Five
years from now, it's entirely possible that the biggest FLOSS
deployment in numbers will be OLPC devices, which has a display with
entirely different requirements for optimizing text qualty. Two sets,
actually: one each for the color (transmissive) and grayscale
(reflective) modes of the display.

In addition, I've been advocating high-resolution (200+ dpi) LCD's for
many years, and it's inevitable that they will become mainstream
eventually. They're already popular in handhelds such as the Nokia
N800. With this display technology, plain ol' grayscale (with subpixel
positioning) offers excellent contrast and superb outline and
positioning fidelity. Fancy techniques such as CT can improve contrast
by a tiny increment, but the compromises are likely not worth it.

Thus, investing heavily in a solution today makes about as much sense
as figuring out the best approach to 8 bit color palettes ten years
ago. People did care about that a lot (remember the display flickering
when you moused over your Netscape window?), but no longer.

That said, there is a case to be made for optimizing display quality
today. The richest unexplored avenue, I think, is grayscale bitmaps.
These are not protected by either patents or (in the US) copyrights,
which makes them unpalatable in the proprietary world. Yet, in the
free world, that bug is a feature.

Hrant Papazian has done a few grayscale bitmap fonts (see
http://www.daidala.com/mana-13.html). There's also Berlow's work, and
a few others that used to be sold at ultrafonts.com. I think these are
enough to whet people's appetites.

We have something of a Catch-22. Support for grayscale bitmaps is
poor, and there are no free fonts available. People don't want to
develop fonts unless they know applications can use them, and people
don't want to build the infrastructure unless they know there will be
fonts.

There's also the question of creation tools. Drawing grayscales
directly is very painful (I speak from experience). Berlow's approach
of drawing outlines that have been fitted by eye to a grid is more
likely to be practical, but results in images that are not as crisp
and contrasty as, say Hrant's Mana and Coda. The outline approach is
also likely to produce better results on diagonals in combination with
an LCD sub-pixelling technique.

I sense one opportunity for which grayscale bitmap fonts may be
viable: to display text within the WHATWG canvas. That spec currently
has no text drawing API, so people tend to do fairly bletcherous
things with CSS layers. Eventually, a text drawing API will no doubt
emerge, but in the meantime, there may well be an opportunity. And if
the grayscale bitmap fonts are more visually appealing than whatever
technology is standardized upon, then they may have staying power.

In sum, I'm not sure what to recommend. If the free software community
follows its traditional patterns, it will never quite get its butt in
gear. But that's not necessarily a serious problem, because high-res
displays will come along and make the point moot.

Raph


More information about the Openfontlibrary mailing list