Re: [Devel] FT_Set_Hint_Flags() , etc.

[David Turner]

Hello David,

David Chester wrote:
> Is the implementation of adding configurable options to the hinters still
> a work in progress?  It looks like its 99% done, but the hinters aren't
> reading the information from face->internal->hint_flags.
Nope, FT_Set_Hint_Flags is now completely ignored by the hinters in the
CVS repository. There is a new scheme that, while still a bit experimental
allows applications using FreeType to obtain similar results without
knowing precisely what "stem snapping" and other typographic-specific
things are.

IMPORTANT: The new scheme is not publicly documented, consider that as
its first specification :o)


The idea is to use new constants in the "load_flags" parameter of
FT_Load_Glyph and FT_Load_Char. These new values combine a hinting
and rendering mode, not specific operations to perform on the outline.
Here's their current list (still subject to change though):

  FT_LOAD_TARGET_NORMAL ::
    to specify "default" hinting and rendering, which currently
    means hinting for 8-bit anti-aliased displays. For now, this
    prevents in all hinters the process of integer stem snapping
    in both horizontal and vertical directions (however stems are
    still slightly quantized and aligned to the pixel grid)

  FT_LOAD_TARGET_MONO ::
    to specify "monochrome" hinting and rendering. This forces
    integer stem snapping and alignements in both hinters (automatic
    and Postscript) to produce "better" monochrome glyph images.
    The hinting should be similar to what 2.0.9 produces by the
    way (well, probably a bit better), even if you render the
    glyph outline into an anti-aliased bitmap.

  FT_LOAD_TARGET_LCD ::
    to specify hinting and rendering that is specific to horizontal
    sub-pixel displays (like most LCD screens). This forces integer
    stem snapping along the X axis only, since this is crucial to
    reduce unpleasant color fringes. On the other hand, vertical
    hinting is similar to FT_LOAD_TARGET_NORMAL

  FT_LOAD_TARGET_LCD_V ::
    a variant of the previous render mode for vertical sub-pixel
    displays (like rotated LCD screens, like the ones found on most
    PDAs, or when the XFree86 RandR extension will be finished to
    support pivoting desktop LCD screens). As you probably guessed
    this forces integer stem snapping along the Y axis only :-)

There are two important things about this new scheme:

  - applications don't need to bother about hinting algorithms and
    their arcane parameters, they simply specify what kind of surface
    they want the outlines optimized for. This let us improve the
    hinters in subsequent releases of the library without changing
    application sources or binaries.

  - it's relatively simple to produce a new "target mode" if a new
    incredibly smart new hinting technique comes in, or when we'd like
    to support optimisations specific to other kinds of displays (TVs for
    example, can benefit from a hinting scheme where you _avoid_ aligning
    stems to the pixel grid, in order to reduce flickering effects).

    Besides, updating applications to use the new mode is trivial
    compared to bit-fiddling.

Of course, while this makes the API much more user-friendly, it means
that the arcane hinting parameters are no longer available to application
developers. In other words, if you want to play with this, you'll need
to hack the hinters directly :-)

Finally, note that the current default target mode produces anti-aliased
glyphs that are, in my opinion, a good compromise between correct pixel
grid alignement and (blurry) shape correctness (of course, there are still
a few bugs to fix). I have converted all my Linux desktops to it and I'm
extremely happy with it, since:

  - text is relatively clear and its "color" is much, much more consistent.
    Nothing makes me madder than seeing weird diagonals that seem to
    "stand out" in the flow of text.

  - there is a little fuzziness, but I got used to it extremely quickly,
    and after several comparisons, I find it a lot less "gray" and more
    pleasant than something like MacOS X output (warning: personal taste
    involved here ;-)

  - I can have a professionally-looking desktop displaying text with only
    the free fonts that come with my dsitribution. "Luxi Sans" is great by
    the way, though I wished it had a few more hints for "g", "d" and "e"
    ;-)

  - And all of this without infringing a single patent from Apple,
    ALLELUIA, we're going to be able to forget about this real crap !! :-)

Ahh, I should really post some screenshots, but I rather invite you to
build and install the current CVS code on your system, maybe change the
fonts you're using, and start using this for a few days...

Note however that there are two disadvantages to the new default hinting mode:

- it produces monochrome glyphs that are of slightly lower quality than
  with FT_LOAD_TARGET_MONO. This is not dramatic and can be "solved" by
  performing a very simple to libXft and/or the XFree86 FreeType font backend
  (which know precisely when to render monochrome bitmaps).

  I don't use FT_LOAD_MONOCHROME to automatically switch to FT_LOAD_TARGET_MONO
  for several reasons, one of them is that a different hinting mode might create
  different metrics for the same glyph, and this might break certain assumptions
  made by programs..


- it doesn't work very well with sub-pixel rendering activated within XFree86
  (because the "gray" parts create visible color fringes). There are two
  solutions to this problem however:

    * simply disable it ! that's what I've done on my two home LCD desktops,
      and frankly don't miss it much anyway.

    * another option is to wait for another simple change in libXft to
      either use FT_LOAD_TARGET_MONO or FT_LOAD_TARGET_LCD/LCD_V to load
      glyph outlines before rendering/filtering them..

My initial plan was to have FT_LOAD_TARGET_NORMAL perform like
FT_LOAD_TARGET_MONO by default (to get results similar to previous
releases of the library) and introduce a new FT_LOAD_TARGET_SMOOTH
mode.

However, this would have meant the following things:

  - I'd need to hack libXft to be able to use the new render mode on
    my desktops (I consider that eating your own dog food is important
    in the case of hinting research :o) And no, thank you, I don't want
    to do that right now...

  - The "smooth" hinting would remain an option, instead of the default,
    and you'd need a cooresponding new option in the libXft configuration
    file, and consequently in the KDE / Gnome control panels to activate it.

You know, being FreeType's dictator life file wouldn't be funny if this
didn't give me any power on *you* mere mortals !! Ah Ah Ah !! I've thus
unilaterally decided to make the new "smooth" hinting the new library
default !! Fear me :-)

More seriously, the "old" hinting behaviour (that people like Vadim seem
to value) is still available by using the FT_LOAD_TARGET_MONO mode. If
you want to activate it, you'll simply need to hack libXft et al.. to
add the relevant option to your favorite desktop's control panel. However
I'll let you these joys... I clearly don't have the time to play with
this right now... (another solution is to provide patches against the
official release, of course)

It's also a very good incentive to force many people to test the new
hinting mode :-)

> Here's an example which shows Times New Roman very slightly hinted,
> similar to how I've just described, but with a few shortcomings.  
>
> http://www.cs.mcgill.ca/~dchest/salon1.png
>
> The implementation in the example is lacking in that the e's and s's,
> etc. reach a tiny bit into the pixel row below, and the f's and p's and
> q's are left alone, unstretched, so their stems are fuzzy.  But, it's
> sort of close.  There's also some gamma correction on the TNR.  In case
> anyone's wondering, the Verdana is hinted with the new options: vstem
> alignment and vstem snapping are turned off.  Also, with both fonts, I've
> altered FT_Set_Char_Size() so that it doesn't round my supplied
> char_width and char_height, and I can choose more strategic values. 
If you want to hack the hinting process, I advise you to define a new
target mode, and modify the hinters to recognize it and take appropriate
action. This shouldn't be too difficult (but please wait that 2.1.3
be released before submitting patches :-)

Not rounding the character width and height might be a good idea, I'll
try to check this in the near future..

Any comments welcomed (but please test the new hinting mode before
commenting on its quality !!)


Best Regards,

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