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

[vern adams]

Erik,

Are you testing the rendering via web browsers only? Or do you get same results 
with e.g. ftview? 

-vern


On 21 Apr 2012, at 16:51, Infinality wrote:

> Hi Vernon / Werner,
> 
> I tried it out with the version of Oxygen you sent me, with similar results.  
> I was also able to view it in Windows XP, and as I thought it renders fine 
> there (although they filter the hell out of it).
> 
> 1. This is the image in my original email.  The settings I'm using here are:  
> Infinality patches, native TT hinting.  (I also have a custom FIR filter 
> value set on the LCD filter for all of these images)
> http://www.infinality.net/files/oxygen-infinality-problems.png
> 
> 2. This is what it renders like with native TT hinting if I disable all 
> Infinality TT instruction tweaks:
> http://www.infinality.net/files/oxygen-freetype-tt-hinting.png
> 
> 3. This is what it renders like with Infinality-patched autohinting (which 
> uses "slight" hinting):
> http://www.infinality.net/files/oxygen-infinality-autohinting.png
> 
> You can see with #2 that it's faithfully rendering the instructions as you'd 
> expect, and it looks much like standard Freetype "slight" hinting, which 
> you'd also expect, since ttfautohint is creating the TT hints from autohint.  
> (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.)
> 
> 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.  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 ).  Is 
> it possible to accomplish the same things that SHPIX is doing in ttfautohint 
> with the more common MIRPs and such?  Not only for my patches, but perhaps 
> for other device compatibility?
> 
> Thanks,
> Erik
> 
> 
> On 04/21/2012 02:07 AM, vern adams wrote:
>> Many thanks for this Erik,
>> 
>> You seem to have recreated the glitchy rendering that earlier versions of 
>> ttfautohint created on iOS and when adobe apps converted ttfautohinted fonts 
>> to outlines. That's very interesting i think, as it probably points to 
>> something important still going on.
>> 
>> First though i think we should check that the issue is not with a particular 
>> buggy build of Oxygen; very occasionally a nightly build of an oxygen font 
>> has been sent to the git repo with weird extra points that could upset ttf 
>> instructions. I'll mail you some Oxygen fonts to test with and confirm that 
>> you get same rendering?
>> 
>> Many thanks
>> 
>> vernon
>> 
>> 
>> 
>> 
>> On 21 Apr 2012, at 03:15, Infinality wrote:
>> 
>>> 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
>>>