Re: [ft-devel] A review of ttfauthint by designer of Siri

[Infinality]

Does TTfautohint allways snap upwards, to the pixel edge above?
rather than snapping to the pixel edge below, even if the pixel edge
below is closest?

It depends.  For x-heights, the current code slightly favors rounding
up (using 0.375 instead of 0.5 as the threshold).  I will soon add an
option so that in the range 5 < ppem < 15 glyph x-heights are strongly
rounded up (using 0.125 as the threshold).  This should avoid filling
holes in bold letters like `e'.

Is it actually possible to specify the x-height threshold independently of the total height threshold?  I never could seem to find that in the code!  David addresses the "e" issue at the bottom of this page:
http://www.freetype.org/autohinting/alignment.html

"Distortion measurement" and "outline optimization" is what's needed.  Not sure if this is easier, but I've thought that the easiest way conceptually would be to force at least 1 pixel between any two horizontal stems when available.  Like, if you have 5px of height to work with, and 3 horizontal stems, you would always hint them to snap pixel 1, 3, and 5.  Then the "e" will always look normal. (i.e.  This won't happen: http://www.freetype.org/autohinting/image/hinted_e.png).   Of course, if you only have 4px of height you have to make a choice. 

The unwanted conversion of `i' to `l' is a bug, I think (at least at
this size).  Alas, I don't know yet how to fix it.

I'm pretty sure that (at least some of) the issues with the main body of i and j touching the dot will go away if the x-height can be made lower, in cases where this happens.


Erik / Infinality