Re: [ft-devel] Stem darkening toggling API

[Nikolaus Waxweiler]

New revision. Reverts the no_stem_darkening rename, typedefs FT_Byte
lcd_weight[5] and uses memset in a few places to avoid creating an emtpy
LCD filter.

So far, I have not received comments from Behdad or Qt people on the API
as such, however one person on the Qt development list said that he
wouldn't like the automatic toggling of the autohinter for font drivers
that can't darken stems by themselves.

I think that even without the new API, toolkits can already make an
informed decision about whether to enable stem darkening or not: by
querying the no-stem-darkening property of a driver or the autohinter.
If FT_Property_Get returns an error indicating the property doesn't
exist, the driver/autohinter probably doesn't darken stems.

So now I'm also thinking about how to implement stem darkening in the
TrueType driver. The first problem would be to determine the stem
widths, but a first version could use the heuristic Dave Arnold
described a while back: using fixed values according to what weight a
font advertises itself. Problems begin with hinting, as the concept of
stem darkening is somewhat incompatible with the explicit programming of
TrueType hints. On v40 in backwards compatibility mode, where hinting on
the x-axis is ignored, this is less of a problem, because you can just
darken vertical stems only. In v40 native mode, (tricky) fonts can
modify points on the x-axis. Dave Arnold mentioned that Adobe's software
lessens the darkening in that case because many fonts snap vertical
stems to pixel boundaries, thereby darkening them already. Some don't,
however, so you'd have to darken them normally. Ideally, you measure
stems after the hinting process... Not sure if an acceptable solution
can be found here so that stem darkening can just be toggled for the
TrueType driver and then forgotten about.

0001-Implement-FT_Face_Option-1-2.patch
Description: Text Data

0002-Implement-FT_Face_Option-2-2.patch
Description: Text Data