freetype-devel
[Top][All Lists]
Advanced

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

[ft-devel] Autohinter as a front-end for the CFF hinting engine?


From: Nikolaus Waxweiler
Subject: [ft-devel] Autohinter as a front-end for the CFF hinting engine?
Date: Mon, 11 Jan 2016 13:59:11 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0

Hey list,
so I recently tested GNOME's Cantarell with the autohinter and was disappointed that at the default UI size (11pt @ 96 dpi), it snapped the x-height 1 pixel lower than the native hinter. The native hinter does the same thing actually unless you set BlueScale to e.g. 3 / (4 * LargestBlueZoneHeight) as noted in Miguel Sousa's Robothon 2012 presentation on Postscript hinting. I thought about changing around the autohinter code somewhat to emulate this when I had the following idea:

What if the autohinter was reworked to be a front-end for the CFF grid-fitting machinery?

The autohinter already works conceptually similar to Type1/Postscript hinting and can provide BlueValues, OtherBlues (maybe Family*Blues with some extending?), StdH/VW and StemSnapH/V with minor extensions, BlueFuzz and BlueShift can be left at the defaults or something else after analysis, BlueScale can use the above formula. Tadaa, a perfectly usable per-script "PS Private" dictionary. What's left would be inserting H/V/DStems (and Flex-hints?) at FT_Load_Glyph() time, but I have no idea how much work this would be and how much performance it would drain (it would only be done once per glyph I think?)

Adobe's CFF engine brought an advanced piece of grid-fitting code into the code base, I think it would be a shame not to use it. The autohinter could be truer to its' name and focus on script analysis and glyph hinting while the CFF grid-fitter would potentially improve the quality of hinted output. Maybe this can even solve my problem with the autohinter stem-darkening code that has to scale emboldened glyphs down so that they stay inside their blue zone, losing some emboldening. The CFF grid-fitter has to handle this somehow already.

I have not looked closely at the source yet, but what would probably be necessary is first separating the CFF grid-fitter (along with stem darkening?) code into its' own module and rewiring the CFF module (and maybe the Type1 module?). Reworking the autohinter is probably the biggest piece of work depending on how compatible the workflow of the autohinter and CFF engine is and how hard it is to add H/V/DStems at runtime and at what cost.

Is this reasonable?

PS: Would Arabic scripts require diagonal blue zones?



reply via email to

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