> Since this is an .otf and you can't force the autohinter in light
> rendering mode (bug).
Care to provide a fix? It was you who made the auto-hinter use the
new CFF engine in light hinting mode :-)
> The dot on the i and j are snapped to different heights
Alas, this is such a common problem that I don't have to apply your
patch to answer it. It is a deficiency in the `STEM' action of the
auto-hinter, see lines 2849ff in file `aflatin.c'. Run e.g.
FT2_DEBUG=any:7 ftview ... &> ftview.log
to get all debug data in a large log file.
The dot position is based on both the original and already hinted
coordinates, using an `anchor' position for measurements, which
normally is a blue zone. For the `i', it's the baseline, for the `j',
it's the descender blue zone. The idea is to avoid distortions due to
double rounding and the like, making glyphs too large or small
vertically.
This combination of original and hinted coordinates, however, can
badly interact, causing such `dancing' dots.
> and the ascender of 'd' doesn't seem to be snapped.
A similar issue, this time in the `SERIF_LINK2' action; the
combination of original and hinted coordinates is comparable to
`STEM'. For both glyphs, the auto-hinter sees the lowermost, leftmost
horizontal `edge' first. For glyph `b', this is the small horizontal
line at the lower left; for glyph `d', it is the center of the bottom
of the bowl. Due to overshoot, the original (unhinted) positions are
slightly different, making the SERIF_LINK2 action emit two different
vertical positions.
Currently, I don't have an idea how to fix it in a generic way.
Suggestions are highly welcomed!
Werner
_______________________________________________
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
