[ft] New FreeType proofing tool: ftdiff

[David Turner]

Hello everyone,

just to publicly announce that I added a new tool named "ftdiff" that allows 
you to
easily compare FreeType's output with various combinations of hinting and 
rendering
modes. Its window contains three columns of text, each one with its own 
settings. Press F1
to get a list of keybinding to use the application.

It's in the CVS right now, under "ft2demos", and will be part of the next 
release, which
should hopefully be imminent.

Playing with the tool, several important things can be noticed:


I. RSB/LSB Deltas rock:
=======================

we have introduced the fields lsb_delta and rsb_delta in FT_GlyphSlotRec several
releases ago in order to allow sophisticated text layout of auto-hinted text. 
The
idea is that these values record the displacement of left and right edge in each
glyph due to auto-hinting, and this can be useful to correct the space between 
two
glyph images to better respect their original spacing.

Thanks to Owen Taylor for the original idea, which he exposed in an online paper
I cannot find anymore. Details at the end of this e-mail

Here are a few screenshots illustrating the difference it makes:

  http://david.freetype.org/freetype/why-deltas-matter-1.png
  http://david.freetype.org/freetype/why-deltas-matter-2.png
  http://david.freetype.org/freetype/why-deltas-matter-3.png

in each screenshot:
  - the left column is unhinted text (with sub-pixel accuracy),
  - the middle column auto-hinted text typeset using the delta adjustments
  - the right column uses auto-hinted text without delta adjustments

I now feel the urge to provide patches to many libraries and programs on top of 
FreeType
so they can exhibit this *huge* improvement. However, this is likely to require 
a *lot*
of work.


II. The Legacy LCD filter is both good and ugly, depending on the font:
=======================================================================

The "legacy" LCD filter corresponds to the current implementation found in
LibXft and Cairo, which exhibits very high contrast for high-quality bytecode
hinted fonts, but some nasty color fringes in all other cases (e.g. low quality
bytecode, auto-hinting, light-hinting, no-hinting)

This is illustrated by the following screenshots:

  http://david.freetype.org/freetype/lcd-filters-with-arial.png
  http://david.freetype.org/freetype/lcd-filters-with-georgia.png
  http://david.freetype.org/freetype/lcd-filters-with-impact.png
  http://david.freetype.org/freetype/lcd-filters-with-impact-unhinted.png
  http://david.freetype.org/freetype/lcd-filters-with-arialbd-autohint.png
  http://david.freetype.org/freetype/lcd-filters-with-trebuchet-autohint.png

Notice that in certain cases, no filter can completely get rid of color fringes,
but that, except for high-quality bytecode hints, the legacy filter creates more
unpleasant artefacts.

On the other hand, the default LCD filter is a lot more consistent and works
pretty well in all situations.

I'm suspecting that we'll want to be able to use the legacy filter only when
we have a bytecoded hinting, and probably only with a selection of well-known
fonts. For all other cases, using the default filter would be preferable.

If this is too complicated to implement, using the default LCD filter beats
any other combination, unless you exclusively use high-quality fonts with the
bytecode interpreter.

I don't see *any* reason to use the legacy filter with the auto-hinter. This 
should
be fixed in libraries like Cairo and LibXft, and I already provided patches for
some versions of these.


III. The auto-hinter is pretty good at respecting original glyph shapes
=======================================================================

the auto-hinter, even in "normal-not-light" mode, is pretty good at producing
glyphs that look like the original font glyphs. There are still a few issues
(e.g. handling of accents and dots) that I'd like to work on in the future, but
My general feeling is that, using the delta adjustments, we have some very
very pleasant rendering, which is much more pleasant than Windows anti-aliasing
or Mac OS X.

  http://david.freetype.org/freetype/hint-modes-with-arial.png
  http://david.freetype.org/freetype/hint-modes-with-comicsans.png
  http://david.freetype.org/freetype/hint-modes-with-georgia.png

The only other case I could think about is ClearType, which uses slightly
different techniques to produce good-looking text. It also seems that ClearType
on Vista can use sub-pixel positioning, unlike on XP. Note that I don't plan
to work on implementing ClearType in FreeType at the moment.


Conclusion:
===========

I previously thought that implementing sub-pixel hinting and positioning would 
be
the next step required to improve text rendering with FreeType, but obviously 
simply
using the LSB/RSB deltas to adjust inter-character space has much more obvious 
benefits.

For the record, this works a bit like kerning, i.e. these values are used to 
adjust
the space between two auto-hinted character pairs. The layout algorithm is 
described
in the FreeType documentation and looks like the following:

  /* <Note>                                                                */
  /*    Here a small pseudo code fragment which shows how to use           */
  /*    `lsb_delta' and `rsb_delta':                                       */
  /*                                                                       */
  /*    {                                                                  */
  /*      FT_Pos  origin_x       = 0;                                      */
  /*      FT_Pos  prev_rsb_delta = 0;                                      */
  /*                                                                       */
  /*                                                                       */
  /*      for all glyphs do                                                */
  /*        <compute kern between current and previous glyph and add it to */
  /*         `origin_x'>                                                   */
  /*                                                                       */
  /*        <load glyph with `FT_Load_Glyph'>                              */
  /*                                                                       */
  /*        if ( prev_rsb_delta - face->glyph->lsb_delta >= 32 )           */
  /*          origin_x -= 64;                                              */
  /*        else if ( prev_rsb_delta - face->glyph->lsb_delta < -32 )      */
  /*          origin_x += 64;                                              */
  /*                                                                       */
  /*        prev_rsb_delta = face->glyph->rsb_delta;                       */
  /*                                                                       */
  /*        <save glyph image, or render glyph, or ...>                    */
  /*                                                                       */
  /*        origin_x += face->glyph->advance.x;                            */
  /*      endfor                                                           */
  /*    }                                                                  */

This certainly isn't computationally complex. Any text layout engine that
already deals with kerning should be able to support it. However, the problem
is that one normally needs to cache the rsb_delta/lsb_delta values with each
glyph bitmap, in order to later re-use them at text-layout time.

This means changing the caching mechanism used by libraries/applications,
which can be more or less complex, depending on their implementation.

I'd like to see this enhancement spreading as widely as possible. I've
already tried to scan the Pango sources to see how to implement these, but
I must say this is not an easy piece of code. Any help would be appreciated,
there are countless other libraries to touch, like libXft, Cairo, FireFox,
ThunderBird, OpenOffice.org, Poppler. This certainly not a small work, but
I think the payoff can be quite big.

Voilà, that's all for the moment. "FTDiff" will acquire new features in the
near future, but it's pretty useful as it is.

Regards,

- David Turner
- The FreeType Project  (www.freetype.org)