Re: [ft-devel] ttfautohint / Oxygen / infinality

[Werner LEMBERG]

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