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
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.
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
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? :)
The launch of Adobe's 'Source Sans' type family has allowed me to run some
'like for like' tests of ttfautohint instructions against proffesional-level
manual instructions. Source Sans seems very well instructed, so it's a great
tool for testing ttfautohint.
One difference i notice (again) is
