[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: vern adams
Subject: Re: [ft-devel] ttfautohint & x-heights
Date: Tue, 7 Aug 2012 08:45:53 +0100


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 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]