* 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.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91
diff --git a/ChangeLog b/ChangeLog
index c88ec45..d90f504 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,12 @@
2013-08-02 Werner Lemberg <wl@gnu.org>
+ * 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 <wl@gnu.org>
+
[autofit] Move declaration of scripts into separate file.
This has the benefit that we don't need to duplicate the data at
diff --git a/include/freetype/ftcffdrv.h b/include/freetype/ftcffdrv.h
index f2b1016..cd6373c 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.
*/