Re: [ft-devel] Start with integration of the Infinality patches

[Werner LEMBERG]

> Please have a look at the `autohinter-properties' branch in the
> FreeType repository.  It contains a first draft how a simple API
> might look like to control the autohinter.  Note, however, that Eric
> and I would like to have something more generic, making it possible
> to (a) fine-tune any FreeType module, using the same API, and (b) to
> allow a finer granularity (for example, to specify PPEM sizes and
> ranges for a certain feature).  In other words, the code will
> certainly change.

In an FT_Library object we have a list of all registered modules, a
set of renderers (which are a subset of the registered modules), a
current renderer, and a (current) auto-hinter; the latter two are
registered modules also.

In an FT_Face object we have an FT_Driver structure only (which gives
extended access to a font driver module).

It's rather obvious that global module properties can be accessed and
set via FT_Library; a natural place to store this information is the
internal FT_ModuleRec structure (in ftobjs.h).

The main question is what exactly should be local to FT_Face.  I think
that renderer properties should *not* be made local, so we should
provide local properties for the current font driver and the
auto-hinter only.

The interface could be like this:

  FT_Library_SetModuleProperties
  FT_Library_GetModuleProperties

  FT_Face_SetAutohinterProperties
  FT_Face_GetAutohinterProperties
  FT_Face_SetDriverProperties
  FT_Face_GetDriverProperties

The argument would be an FT_Int32 used as a bit field to switch on or
off properties.  Later on, a suite of *{Set,Get}*Property functions
could be added to fine-tune a given property.

I'm not really happy about having two sets of functions, but I don't
have a better idea.

Suggestions welcomed!


    Werner