[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] [ttfautohint] stem width handling is now selectable

From: vern adams
Subject: Re: [ft-devel] [ttfautohint] stem width handling is now selectable
Date: Tue, 3 Jul 2012 12:03:34 +0100

>> In git, I've now fixed the situation displayed in your
>> `Capture-G-win7GDI.png' image (showing Open Sans at 21px, please look
>> at the ugly rendering of digit 3, for example): It was a buglet in
>> FreeType's autofit module which didn't show up because of its smooth
>> rendering algorithm.
>> The old code contained both a (scaled) stem width of 95 and 97 units;
>> for the strong stem width algorithm, the former was rounded to 1px but
>> the latter to 2px.  The new code avoids this by unifying such almost
>> identical stem widths, taking the mean value, 96.  As a threshold,
>> widths which are different less than or equal to 1% of the em size are
>> unified; this is certainly not noticeable visually.
> Wow, that is a really substantial improvement :-) Well done Werner, bravo!

Update from Test Ville - that was a significant  tweak/buglet fix.
see below; test on Dalton Maag's 'Ubuntu Font'. top shot is original extensive 
manual hinting. Bottom is ttfautohint -x 0 -w 'gGD'. WinXP, GDI Cleartype, 
I'd say that's a pretty close contest. TTfauto looses kudos on the lowercase 
's', and tail of uppercase 'Q',  but gains on the lowercase 'y', 'k', 'c'
These are pretty typical results too. I bet "if" one tested some Windows system 
TTF's against latest ttfautohinted versions, i'm pretty sure that you would see 
similar results as below ;)

PNG image

PNG image

reply via email to

[Prev in Thread] Current Thread [Next in Thread]