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
ttfautohint 0.92 has been released.
The source tarball, statically-linked binaries for Win32 (TTY and GUI) and
OS X (TTY only) are available from
http://savannah.nongnu.org/download/freetype/
or
http://sourceforge.net/projects/freetype/files/ttfautohint/0.92
Enjoy!
Werner
PS:
Hello Werner,
FYI: I ran into a discrepancy between how FT (latest) and Acrobat render
some CFF fonts.
It seem that the error is cause due to interpretation of the fill rule (even
odd vs. winding) or something like that.
The font file was generated with Adobe PaperCapture.
IvanN
I reproduced this issue by 2.4.6, 2.3.12, 2.3.0.
Although it would be an issue, I think this is NOT regression.
Regards,
mpsuzuki
Ivan Nincic wrote:
Hello Werner,
FYI: I ran into a discrepancy between how FT (latest) and Acrobat render
some CFF fonts.
It seem that the error is cause due
