Re: [ft-devel] ttfautohint x-heights
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. Uh, oh. This was caused by a very embarassing bug: one of the central bytecode routines to round to integers was buggy. Since the fix (already in the git repository) considerably improves the appearance of a lot of fonts, I'll soon do a new release of ttfautohint. Anyway, the central question remains: What to do if hinting might exceed the usWin values (e.g. by using ttfautohint's -x option). Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint x-heights
Werner, I still think the issue here is the way the Freetype auto hinter snaps to pixel edges. It tends to snap 'upwards' compared to the bytecode interpreter, which when following manually hinted TT instructions may be instructed to snap 'downwards' with certain stems at certain pt sizes. But i may be misunderstanding the way the Freetype autohinter works compared to Freetype's bytecode interpreter? Please see page 3 of http://goo.gl/hOa1A where i haveposted screenshots to show what i think is happening. 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. Uh, oh. This was caused by a very embarassing bug: one of the central bytecode routines to round to integers was buggy. Since the fix (already in the git repository) considerably improves the appearance of a lot of fonts, I'll soon do a new release of ttfautohint. Great. bugs are good :) Anyway, the central question remains: What to do if hinting might exceed the usWin values (e.g. by using ttfautohint's -x option). Would using the -x option ever cause a font's rendered outlines to exceed the usWin values? Isn't it only usWinAscent that is relevant here? Does the -x option increase overall height of glyphs or *just* the x-height? If -x only increases x-height then i can't imagine it would increase it enough to get clipped by usWinAscent. -v ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint x-heights
I still think the issue here is the way the Freetype auto hinter snaps to pixel edges. This is *another* issue. It tends to snap 'upwards' compared to the bytecode interpreter, which when following manually hinted TT instructions may be instructed to snap 'downwards' with certain stems at certain pt sizes. This is correct, and intentional. In general, the autohinter is increasing the glyph size much more often than decreasing. Remember that the original code in FreeType tries to hint the glyphs without any manual intervention at run-time. Compressing a font vertically might lead to very ugly results, while the opposite can only improve the appearance. However, ttfautohint doesn't hint at run-time, so I can try to make it better, and the forthcoming option -X (or a variant of it) is the right means for that. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint x-heights
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
