Erik,
thanks for your analysis. > (The main difference between #2 and #3 is that #3 snaps horizontal > stems to pixel boundaries, which normal Freetype slight hinting does > not do. I personally prefer the stems to be snapped to integer > pixels like this. It looks less dirty to me, however there are some > issues with diagonal stem weights, which is a known issue since > autohint doesn't do diagonal hinting at all.) I'm probably adding horizontal hints also to ttfautohint; however, this is something I still have to investigate, and which doesn't have priority right now. > After experimenting around with the TT tweaks in the infinality > subpixel hinting patches, I am able to get rid of most of the > artifacts by turning *on* SHPIX instructions. OK. Yes, SHPIX is used intensively to move points. > By default they are off in my patches because (my understanding is) > this instruction was used historically as a "hack" to make outlines > fit around pixels, and not much else. (See: > http://www.microsoft.com/typography/cleartype/truetypecleartype.aspx > ). I'll ask Greg *why* fonts hinted by ttfautohint aren't affected, this is, why they render fine with ClearType. Apparently, the bytecode hasn't been recognized as stuff which must be handled in backwards compatibility mode. > Is it possible to accomplish the same things that SHPIX is doing in > ttfautohint with the more common MIRPs and such? It seems that MSIRP will do. Werner _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
