From 0d28a7d6a638fb37f24022f7d0e5a20b5a3cc63f Mon Sep 17 00:00:00 2001 From: Werner Lemberg Date: Fri, 2 Aug 2013 22:59:43 +0200 Subject: [PATCH] * include/freetype/ftcffdrv.h: Improve documentation. This is based on blog entries from David Lemon and Dave Arnold (both from Adobe) with kind permission. Dave also helped in proof-reading. --- ChangeLog | 7 +++++ include/freetype/ftcffdrv.h | 59 ++++++++++++++++++++++++++++++++++++- 2 files changed, 65 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index c88ec457d..d90f504d9 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2013-08-02 Werner Lemberg + + * include/freetype/ftcffdrv.h: Improve documentation. + This is based on blog entries from David Lemon and Dave Arnold (both + from Adobe) with kind permission. Dave also helped in + proof-reading. + 2013-08-02 Werner Lemberg [autofit] Move declaration of scripts into separate file. diff --git a/include/freetype/ftcffdrv.h b/include/freetype/ftcffdrv.h index f2b1016f4..cd6373ce2 100644 --- a/include/freetype/ftcffdrv.h +++ b/include/freetype/ftcffdrv.h @@ -46,11 +46,68 @@ FT_BEGIN_HEADER * @description: * While FreeType's CFF driver doesn't expose API functions by itself, * it is possible to control its behaviour with @FT_Property_Set and - * @FT_Property_Get. The following lists the available properties + * @FT_Property_Get. The list below gives the available properties * together with the necessary macros and structures. * * The CFF driver's module name is `cff'. * + * *Hinting* *and* *antialiasing* *principles* *of* *the* *new* *engine* + * + * The rasterizer is positioning horizontal features (e.g., ascender + * height & x-height, or crossbars) on the pixel grid and minimizing the + * amount of antialiasing applied to them, while placing vertical + * features (vertical stems) on the pixel grid without hinting, thus + * representing the stem position and weight accurately. Sometimes the + * vertical stems may be only partially black. In this context, + * `antialiasing' means that stems are not positioned exactly on pixel + * borders, causing a fuzzy appearance. + * + * There are two principles behind this approach. + * + * 1) No hinting in the horizontal direction: Unlike `superhinted' + * TrueType which changes glyph widths to accommodate regular + * inter-glyph spacing, Adobe's approach is `faithful to the design' in + * representing both the glyph width and the inter-glyph spacing + * designed for the font. This makes the screen display as close as it + * can be to the result one would get with infinite resolution, while + * preserving what is considered the key characteristics of each glyph. + * Note that the distances between unhinted and grid-fitted positions at + * small sizes are comparable to kerning values and thus would be + * noticeable (and distracting) while reading if hinting were applied. + * + * One of the reasons to not hint horizontally is antialiasing for LCD + * screens: The pixel geometry of modern displays supplies three + * vertical sub-pixels as the eye moves horizontally across each visible + * pixel. On devices where we can be certain this characteristic is + * present a rasterizer can take advantage of the sub-pixels to add + * increments of weight. In Western writing systems this turns out to + * be the more critical direction anyway; the weights and spacing of + * vertical stems (see above) are central to Armenian, Cyrillic, Greek, + * and Latin type designs. Even when the rasterizer uses greyscale + * antialiasing instead of color (a necessary compromise when one + * doesn't know the screen characteristics), the unhinted vertical + * features preserve the design's weight and spacing much better than + * aliased type would. + * + * 2) Aligment in the vertical direction: Weights and spacing along the + * y~axis are less critical; what is much more important is the visual + * alignment of related features (like cap-height and x-height). The + * sense of alignment for these is enhanced by the sharpness of grid-fit + * edges, while the cruder vertical resolution (full pixels instead of + * 1/3 pixels) is less of a problem. + * + * On the technical side, horizontal alignment zones for ascender, + * x-height, and other important height values (traditionally called + * `blue zones') as defined in the font are positioned independently, + * each being rounded to the nearest pixel edge, taking care of + * overshoot suppression at small sizes, stem darkening, and scaling. + * + * Hstems (this is, hint values defined in the font to help align + * horizontal features) that fall within a blue zone are said to be + * `captured' and are aligned to that zone. Uncaptured stems are moved + * in one of four ways, top edge up or down, bottom edge up or down. + * Unless there are conflicting hstems, the smallest movement is taken + * to minimize distortion. */