Hi guys,
Today I tested out the TT-instructed Oxygen font from the KDE repo with
my TT subpixel hinting patches. This is the result:
http://www.infinality.net/files/oxygen-infinality-problems.png
Yikes!!! After examining the TT instructions in the instructed version
of the Oxygen fonts, it looks like the way that ttfautohint is
generating instructions is substantially different than typical
TT-instructed fonts. Since my patches are attempting to do what the MS
rasterizer does (at least with legacy fonts), I'm curious how these
render on Windows. Unfortunately I don't have a Windows system
available to test that on at the moment, however my guess is that it
renders just fine on Windows.
I have a way to exclude certain fonts or individual glyphs within a font
from using the tweaks that my patches employ (i.e. render it the way
Freetype TT hinter does by default), but I'd rather not build up a giant
hard-coded exclusion list of fonts generated by ttfautohint if at all
possible. And, given that the TT subpixel hinting patches may soon land
into Freetype, I'd like make them work nicely with other
Freetype-related software. :D So, I'd like to adapt my TT hinting
patches to gracefully handle fonts that have been hinted with ttfautohint.
My question is this: Is there something unique about ttfautohint-ed
fonts that indicates they are already taking into account
subpixel-hinting? I know there is the "ready for Cleartype" flag, but
it never seems to be set in any fonts I've seen (including Oxygen), even
the MS ones. Also, the Microsoft Cleartype fonts seem to behave well
with my patches just as they are. They are designed for
Cleartype/subpixel just as the ttfautohint fonts are. I guess I'm
trying to reconcile what exactly ttfautohint is doing differently that
causes these issues. Can any of you provide any insight?
Thanks,
Erik / Infinality
_______________________________________________
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
