Re: [ft-devel] Stem darkening toggling API

[Werner LEMBERG]

>> Here you can see a small weakness in the idea of shifting the
>> property control from FT_Library to FT_Face: FreeType modules are
>> not the same as FreeType font drivers; the latter is just a subset.
> 
> What do you mean?

`gxvalid' and `psaux' are also FreeType modules, and controlling them
via FT_Face looks strange — fortunately, there aren't properties to
control :-)

>> Get the font format with `FT_Get_Font_Format'; the returned string
>> can then be mapped to the corresponding module name.
>> 
>>   CFF      -> cff
>>   TrueType -> truetype
>> 
>> For the auto-hinter this doesn't work, of course, since it is
>> completely agnostic of the font format.
> 
> Hm. This also means that client libraries have to keep track of the
> names of modules should they change in any way.

Well, after loading a font, the modules don't change...

> Something else became appararent while I looked at a WIP for Qt: If
> a library wants to decided on a face-by-face basis if stem darkening
> can be enabled, it needs to know if the autohinter or the font
> driver will do the hinting *before* calling FT_Load_Glyph so the
> appropriate module can be queried for stem darkening capabilities.
> The trouble is that the final decision is made by FT_Load_Glyph, so
> you'd have to embed assumptions about the decision process into a
> client library.  Suboptimal.

I don't think this is a problem. You know in advance whether you want
to use the auto-hinter, don't you?

> Also, the code currently just uses the autohinter if a font driver
> can't darken stems.  Should it not do that?

I don't know.  What do others think?  Ideally, this can be configured.


    Werner