Re: [ft-devel] ttfautohint & x-heights

[Werner LEMBERG]

> At the moment ttfautohint can increase the x-height by using the -x
> argument, but switching this feature off (-x 0) still increases
> x-height compared to the original instructions. Would it be possible
> for ttfautohint to decrease the x-height snapping by 1px at
> particular size range? :)

Right now I'm thinking hard about this issue.  Brad has shown me a
font where ttfautohint's code causes vertical clipping of glyph `g' on
some (older) Windows IE versions since its depth at same ppem sizes
exceeds the usWinDescent value.  This is something I haven't taken
into consideration until now.

Reason of the vertical size increase is some vertical scaling the
autohinter applies to the whole font so that the x height gets
adjusted to the pixel grid.  It's quite an elegant way to improve
rasterization while having almost no glyph distortion.

BTW, if you say `ttfautohint --help', you can see

  -X, --x-height-snapping-exceptions=STRING
                             specify a comma-separated list of
                             x-height snapping exceptions

which is not implemented yet, but you would need exactly this option
to avoid the effect you are observing.

The problem is deep, since the usWin values always get rounded (and
not floored and ceiled) to the pixel grid.  It essentially means that
hints must *always* stay within the area spanned up by the original
outline (in font units) or some glyphs are cropped.[1] In particular,
using a vertical scaling factor >1 inevitably leads to clipping.

I'm not sure how to proceed, and any ideas are highly welcomed.


    Werner


[1] Interestingly, Microsoft itself doesn't always obey that,
    cf. glyph U+01FA (Aringacute) in Arial (according to
    
http://code.google.com/p/googlefontdirectory/wiki/VerticalMetricsRecommendations).