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

[vern adams]

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