modules/freetype2/include/ftcffdrv.h@b8a032363ba2
modules/freetype2/include/ftcffdrv.h
Thu, 22 Jan 2015 13:21:57 +0100
- author
- Michael Schloh von Bennewitz <michael@schloh.com>
- date
- Thu, 22 Jan 2015 13:21:57 +0100
- branch
- TOR_BUG_9701
- changeset 15
- b8a032363ba2
- permissions
- -rw-r--r--
Incorporate requested changes from Mozilla in review:
https://bugzilla.mozilla.org/show_bug.cgi?id=1123480#c6
1 /***************************************************************************/
2 /* */
3 /* ftcffdrv.h */
4 /* */
5 /* FreeType API for controlling the CFF driver (specification only). */
6 /* */
7 /* Copyright 2013 by */
8 /* David Turner, Robert Wilhelm, and Werner Lemberg. */
9 /* */
10 /* This file is part of the FreeType project, and may only be used, */
11 /* modified, and distributed under the terms of the FreeType project */
12 /* license, LICENSE.TXT. By continuing to use, modify, or distribute */
13 /* this file you indicate that you have read the license and */
14 /* understand and accept it fully. */
15 /* */
16 /***************************************************************************/
19 #ifndef __FTCFFDRV_H__
20 #define __FTCFFDRV_H__
22 #include <ft2build.h>
23 #include FT_FREETYPE_H
25 #ifdef FREETYPE_H
26 #error "freetype.h of FreeType 1 has been loaded!"
27 #error "Please fix the directory search order for header files"
28 #error "so that freetype.h of FreeType 2 is found first."
29 #endif
32 FT_BEGIN_HEADER
35 /**************************************************************************
36 *
37 * @section:
38 * cff_driver
39 *
40 * @title:
41 * The CFF driver
42 *
43 * @abstract:
44 * Controlling the CFF driver module.
45 *
46 * @description:
47 * While FreeType's CFF driver doesn't expose API functions by itself,
48 * it is possible to control its behaviour with @FT_Property_Set and
49 * @FT_Property_Get. The list below gives the available properties
50 * together with the necessary macros and structures.
51 *
52 * The CFF driver's module name is `cff'.
53 *
54 * *Hinting* *and* *antialiasing* *principles* *of* *the* *new* *engine*
55 *
56 * The rasterizer is positioning horizontal features (e.g., ascender
57 * height & x-height, or crossbars) on the pixel grid and minimizing the
58 * amount of antialiasing applied to them, while placing vertical
59 * features (vertical stems) on the pixel grid without hinting, thus
60 * representing the stem position and weight accurately. Sometimes the
61 * vertical stems may be only partially black. In this context,
62 * `antialiasing' means that stems are not positioned exactly on pixel
63 * borders, causing a fuzzy appearance.
64 *
65 * There are two principles behind this approach.
66 *
67 * 1) No hinting in the horizontal direction: Unlike `superhinted'
68 * TrueType, which changes glyph widths to accommodate regular
69 * inter-glyph spacing, Adobe's approach is `faithful to the design' in
70 * representing both the glyph width and the inter-glyph spacing
71 * designed for the font. This makes the screen display as close as it
72 * can be to the result one would get with infinite resolution, while
73 * preserving what is considered the key characteristics of each glyph.
74 * Note that the distances between unhinted and grid-fitted positions at
75 * small sizes are comparable to kerning values and thus would be
76 * noticeable (and distracting) while reading if hinting were applied.
77 *
78 * One of the reasons to not hint horizontally is antialiasing for LCD
79 * screens: The pixel geometry of modern displays supplies three
80 * vertical sub-pixels as the eye moves horizontally across each visible
81 * pixel. On devices where we can be certain this characteristic is
82 * present a rasterizer can take advantage of the sub-pixels to add
83 * increments of weight. In Western writing systems this turns out to
84 * be the more critical direction anyway; the weights and spacing of
85 * vertical stems (see above) are central to Armenian, Cyrillic, Greek,
86 * and Latin type designs. Even when the rasterizer uses greyscale
87 * antialiasing instead of color (a necessary compromise when one
88 * doesn't know the screen characteristics), the unhinted vertical
89 * features preserve the design's weight and spacing much better than
90 * aliased type would.
91 *
92 * 2) Aligment in the vertical direction: Weights and spacing along the
93 * y~axis are less critical; what is much more important is the visual
94 * alignment of related features (like cap-height and x-height). The
95 * sense of alignment for these is enhanced by the sharpness of grid-fit
96 * edges, while the cruder vertical resolution (full pixels instead of
97 * 1/3 pixels) is less of a problem.
98 *
99 * On the technical side, horizontal alignment zones for ascender,
100 * x-height, and other important height values (traditionally called
101 * `blue zones') as defined in the font are positioned independently,
102 * each being rounded to the nearest pixel edge, taking care of
103 * overshoot suppression at small sizes, stem darkening, and scaling.
104 *
105 * Hstems (this is, hint values defined in the font to help align
106 * horizontal features) that fall within a blue zone are said to be
107 * `captured' and are aligned to that zone. Uncaptured stems are moved
108 * in one of four ways, top edge up or down, bottom edge up or down.
109 * Unless there are conflicting hstems, the smallest movement is taken
110 * to minimize distortion.
111 */
114 /**************************************************************************
115 *
116 * @property:
117 * hinting-engine
118 *
119 * @description:
120 * Thanks to Adobe, which contributed a new hinting (and parsing)
121 * engine, an application can select between `freetype' and `adobe' if
122 * compiled with CFF_CONFIG_OPTION_OLD_ENGINE. If this configuration
123 * macro isn't defined, `hinting-engine' does nothing.
124 *
125 * The default engine is `freetype' if CFF_CONFIG_OPTION_OLD_ENGINE is
126 * defined, and `adobe' otherwise.
127 *
128 * The following example code demonstrates how to select Adobe's hinting
129 * engine (omitting the error handling).
130 *
131 * {
132 * FT_Library library;
133 * FT_UInt hinting_engine = FT_CFF_HINTING_ADOBE;
134 *
135 *
136 * FT_Init_FreeType( &library );
137 *
138 * FT_Property_Set( library, "cff",
139 * "hinting-engine", &hinting_engine );
140 * }
141 *
142 * @note:
143 * This property can be used with @FT_Property_Get also.
144 *
145 */
148 /**************************************************************************
149 *
150 * @enum:
151 * FT_CFF_HINTING_XXX
152 *
153 * @description:
154 * A list of constants used for the @hinting-engine property to select
155 * the hinting engine for CFF fonts.
156 *
157 * @values:
158 * FT_CFF_HINTING_FREETYPE ::
159 * Use the old FreeType hinting engine.
160 *
161 * FT_CFF_HINTING_ADOBE ::
162 * Use the hinting engine contributed by Adobe.
163 *
164 */
165 #define FT_CFF_HINTING_FREETYPE 0
166 #define FT_CFF_HINTING_ADOBE 1
169 /**************************************************************************
170 *
171 * @property:
172 * no-stem-darkening
173 *
174 * @description:
175 * By default, the Adobe CFF engine darkens stems at smaller sizes,
176 * regardless of hinting, to enhance contrast. This feature requires
177 * a rendering system with proper gamma correction. Setting this
178 * property, stem darkening gets switched off.
179 *
180 * Note that stem darkening is never applied if @FT_LOAD_NO_SCALE is set.
181 *
182 * {
183 * FT_Library library;
184 * FT_Bool no_stem_darkening = TRUE;
185 *
186 *
187 * FT_Init_FreeType( &library );
188 *
189 * FT_Property_Set( library, "cff",
190 * "no-stem-darkening", &no_stem_darkening );
191 * }
192 *
193 * @note:
194 * This property can be used with @FT_Property_Get also.
195 *
196 */
199 /**************************************************************************
200 *
201 * @property:
202 * darkening-parameters
203 *
204 * @description:
205 * By default, the Adobe CFF engine darkens stems as follows (if the
206 * `no-stem-darkening' property isn't set):
207 *
208 * {
209 * stem width <= 0.5px: darkening amount = 0.4px
210 * stem width = 1px: darkening amount = 0.275px
211 * stem width = 1.667px: darkening amount = 0.275px
212 * stem width >= 2.333px: darkening amount = 0px
213 * }
214 *
215 * and piecewise linear in-between. Using the `darkening-parameters'
216 * property, these four control points can be changed, as the following
217 * example demonstrates.
218 *
219 * {
220 * FT_Library library;
221 * FT_Int darken_params[8] = { 500, 300, // x1, y1
222 * 1000, 200, // x2, y2
223 * 1500, 100, // x3, y3
224 * 2000, 0 }; // x4, y4
225 *
226 *
227 * FT_Init_FreeType( &library );
228 *
229 * FT_Property_Set( library, "cff",
230 * "darkening-parameters", darken_params );
231 * }
232 *
233 * The x~values give the stem width, and the y~values the darkening
234 * amount. The unit is 1000th of pixels. All coordinate values must be
235 * positive; the x~values must be monotonically increasing; the
236 * y~values must be monotonically decreasing and smaller than or
237 * equal to 500 (corresponding to half a pixel); the slope of each
238 * linear piece must be shallower than -1 (e.g., -.4).
239 *
240 * @note:
241 * This property can be used with @FT_Property_Get also.
242 *
243 */
246 /* */
248 FT_END_HEADER
251 #endif /* __FTCFFDRV_H__ */
254 /* END */
