* 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.
This commit is contained in:
parent
6d3c10e055
commit
0d28a7d6a6
|
@ -1,3 +1,10 @@
|
||||||
|
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>
|
2013-08-02 Werner Lemberg <wl@gnu.org>
|
||||||
|
|
||||||
[autofit] Move declaration of scripts into separate file.
|
[autofit] Move declaration of scripts into separate file.
|
||||||
|
|
|
@ -46,11 +46,68 @@ FT_BEGIN_HEADER
|
||||||
* @description:
|
* @description:
|
||||||
* While FreeType's CFF driver doesn't expose API functions by itself,
|
* While FreeType's CFF driver doesn't expose API functions by itself,
|
||||||
* it is possible to control its behaviour with @FT_Property_Set and
|
* 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.
|
* together with the necessary macros and structures.
|
||||||
*
|
*
|
||||||
* The CFF driver's module name is `cff'.
|
* 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.
|
||||||
*/
|
*/
|
||||||
|
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue