> 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). _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel