michael@0: /***************************************************************************/ michael@0: /* */ michael@0: /* ftcffdrv.h */ michael@0: /* */ michael@0: /* FreeType API for controlling the CFF driver (specification only). */ michael@0: /* */ michael@0: /* Copyright 2013 by */ michael@0: /* David Turner, Robert Wilhelm, and Werner Lemberg. */ michael@0: /* */ michael@0: /* This file is part of the FreeType project, and may only be used, */ michael@0: /* modified, and distributed under the terms of the FreeType project */ michael@0: /* license, LICENSE.TXT. By continuing to use, modify, or distribute */ michael@0: /* this file you indicate that you have read the license and */ michael@0: /* understand and accept it fully. */ michael@0: /* */ michael@0: /***************************************************************************/ michael@0: michael@0: michael@0: #ifndef __FTCFFDRV_H__ michael@0: #define __FTCFFDRV_H__ michael@0: michael@0: #include michael@0: #include FT_FREETYPE_H michael@0: michael@0: #ifdef FREETYPE_H michael@0: #error "freetype.h of FreeType 1 has been loaded!" michael@0: #error "Please fix the directory search order for header files" michael@0: #error "so that freetype.h of FreeType 2 is found first." michael@0: #endif michael@0: michael@0: michael@0: FT_BEGIN_HEADER michael@0: michael@0: michael@0: /************************************************************************** michael@0: * michael@0: * @section: michael@0: * cff_driver michael@0: * michael@0: * @title: michael@0: * The CFF driver michael@0: * michael@0: * @abstract: michael@0: * Controlling the CFF driver module. michael@0: * michael@0: * @description: michael@0: * While FreeType's CFF driver doesn't expose API functions by itself, michael@0: * it is possible to control its behaviour with @FT_Property_Set and michael@0: * @FT_Property_Get. The list below gives the available properties michael@0: * together with the necessary macros and structures. michael@0: * michael@0: * The CFF driver's module name is `cff'. michael@0: * michael@0: * *Hinting* *and* *antialiasing* *principles* *of* *the* *new* *engine* michael@0: * michael@0: * The rasterizer is positioning horizontal features (e.g., ascender michael@0: * height & x-height, or crossbars) on the pixel grid and minimizing the michael@0: * amount of antialiasing applied to them, while placing vertical michael@0: * features (vertical stems) on the pixel grid without hinting, thus michael@0: * representing the stem position and weight accurately. Sometimes the michael@0: * vertical stems may be only partially black. In this context, michael@0: * `antialiasing' means that stems are not positioned exactly on pixel michael@0: * borders, causing a fuzzy appearance. michael@0: * michael@0: * There are two principles behind this approach. michael@0: * michael@0: * 1) No hinting in the horizontal direction: Unlike `superhinted' michael@0: * TrueType, which changes glyph widths to accommodate regular michael@0: * inter-glyph spacing, Adobe's approach is `faithful to the design' in michael@0: * representing both the glyph width and the inter-glyph spacing michael@0: * designed for the font. This makes the screen display as close as it michael@0: * can be to the result one would get with infinite resolution, while michael@0: * preserving what is considered the key characteristics of each glyph. michael@0: * Note that the distances between unhinted and grid-fitted positions at michael@0: * small sizes are comparable to kerning values and thus would be michael@0: * noticeable (and distracting) while reading if hinting were applied. michael@0: * michael@0: * One of the reasons to not hint horizontally is antialiasing for LCD michael@0: * screens: The pixel geometry of modern displays supplies three michael@0: * vertical sub-pixels as the eye moves horizontally across each visible michael@0: * pixel. On devices where we can be certain this characteristic is michael@0: * present a rasterizer can take advantage of the sub-pixels to add michael@0: * increments of weight. In Western writing systems this turns out to michael@0: * be the more critical direction anyway; the weights and spacing of michael@0: * vertical stems (see above) are central to Armenian, Cyrillic, Greek, michael@0: * and Latin type designs. Even when the rasterizer uses greyscale michael@0: * antialiasing instead of color (a necessary compromise when one michael@0: * doesn't know the screen characteristics), the unhinted vertical michael@0: * features preserve the design's weight and spacing much better than michael@0: * aliased type would. michael@0: * michael@0: * 2) Aligment in the vertical direction: Weights and spacing along the michael@0: * y~axis are less critical; what is much more important is the visual michael@0: * alignment of related features (like cap-height and x-height). The michael@0: * sense of alignment for these is enhanced by the sharpness of grid-fit michael@0: * edges, while the cruder vertical resolution (full pixels instead of michael@0: * 1/3 pixels) is less of a problem. michael@0: * michael@0: * On the technical side, horizontal alignment zones for ascender, michael@0: * x-height, and other important height values (traditionally called michael@0: * `blue zones') as defined in the font are positioned independently, michael@0: * each being rounded to the nearest pixel edge, taking care of michael@0: * overshoot suppression at small sizes, stem darkening, and scaling. michael@0: * michael@0: * Hstems (this is, hint values defined in the font to help align michael@0: * horizontal features) that fall within a blue zone are said to be michael@0: * `captured' and are aligned to that zone. Uncaptured stems are moved michael@0: * in one of four ways, top edge up or down, bottom edge up or down. michael@0: * Unless there are conflicting hstems, the smallest movement is taken michael@0: * to minimize distortion. michael@0: */ michael@0: michael@0: michael@0: /************************************************************************** michael@0: * michael@0: * @property: michael@0: * hinting-engine michael@0: * michael@0: * @description: michael@0: * Thanks to Adobe, which contributed a new hinting (and parsing) michael@0: * engine, an application can select between `freetype' and `adobe' if michael@0: * compiled with CFF_CONFIG_OPTION_OLD_ENGINE. If this configuration michael@0: * macro isn't defined, `hinting-engine' does nothing. michael@0: * michael@0: * The default engine is `freetype' if CFF_CONFIG_OPTION_OLD_ENGINE is michael@0: * defined, and `adobe' otherwise. michael@0: * michael@0: * The following example code demonstrates how to select Adobe's hinting michael@0: * engine (omitting the error handling). michael@0: * michael@0: * { michael@0: * FT_Library library; michael@0: * FT_UInt hinting_engine = FT_CFF_HINTING_ADOBE; michael@0: * michael@0: * michael@0: * FT_Init_FreeType( &library ); michael@0: * michael@0: * FT_Property_Set( library, "cff", michael@0: * "hinting-engine", &hinting_engine ); michael@0: * } michael@0: * michael@0: * @note: michael@0: * This property can be used with @FT_Property_Get also. michael@0: * michael@0: */ michael@0: michael@0: michael@0: /************************************************************************** michael@0: * michael@0: * @enum: michael@0: * FT_CFF_HINTING_XXX michael@0: * michael@0: * @description: michael@0: * A list of constants used for the @hinting-engine property to select michael@0: * the hinting engine for CFF fonts. michael@0: * michael@0: * @values: michael@0: * FT_CFF_HINTING_FREETYPE :: michael@0: * Use the old FreeType hinting engine. michael@0: * michael@0: * FT_CFF_HINTING_ADOBE :: michael@0: * Use the hinting engine contributed by Adobe. michael@0: * michael@0: */ michael@0: #define FT_CFF_HINTING_FREETYPE 0 michael@0: #define FT_CFF_HINTING_ADOBE 1 michael@0: michael@0: michael@0: /************************************************************************** michael@0: * michael@0: * @property: michael@0: * no-stem-darkening michael@0: * michael@0: * @description: michael@0: * By default, the Adobe CFF engine darkens stems at smaller sizes, michael@0: * regardless of hinting, to enhance contrast. This feature requires michael@0: * a rendering system with proper gamma correction. Setting this michael@0: * property, stem darkening gets switched off. michael@0: * michael@0: * Note that stem darkening is never applied if @FT_LOAD_NO_SCALE is set. michael@0: * michael@0: * { michael@0: * FT_Library library; michael@0: * FT_Bool no_stem_darkening = TRUE; michael@0: * michael@0: * michael@0: * FT_Init_FreeType( &library ); michael@0: * michael@0: * FT_Property_Set( library, "cff", michael@0: * "no-stem-darkening", &no_stem_darkening ); michael@0: * } michael@0: * michael@0: * @note: michael@0: * This property can be used with @FT_Property_Get also. michael@0: * michael@0: */ michael@0: michael@0: michael@0: /************************************************************************** michael@0: * michael@0: * @property: michael@0: * darkening-parameters michael@0: * michael@0: * @description: michael@0: * By default, the Adobe CFF engine darkens stems as follows (if the michael@0: * `no-stem-darkening' property isn't set): michael@0: * michael@0: * { michael@0: * stem width <= 0.5px: darkening amount = 0.4px michael@0: * stem width = 1px: darkening amount = 0.275px michael@0: * stem width = 1.667px: darkening amount = 0.275px michael@0: * stem width >= 2.333px: darkening amount = 0px michael@0: * } michael@0: * michael@0: * and piecewise linear in-between. Using the `darkening-parameters' michael@0: * property, these four control points can be changed, as the following michael@0: * example demonstrates. michael@0: * michael@0: * { michael@0: * FT_Library library; michael@0: * FT_Int darken_params[8] = { 500, 300, // x1, y1 michael@0: * 1000, 200, // x2, y2 michael@0: * 1500, 100, // x3, y3 michael@0: * 2000, 0 }; // x4, y4 michael@0: * michael@0: * michael@0: * FT_Init_FreeType( &library ); michael@0: * michael@0: * FT_Property_Set( library, "cff", michael@0: * "darkening-parameters", darken_params ); michael@0: * } michael@0: * michael@0: * The x~values give the stem width, and the y~values the darkening michael@0: * amount. The unit is 1000th of pixels. All coordinate values must be michael@0: * positive; the x~values must be monotonically increasing; the michael@0: * y~values must be monotonically decreasing and smaller than or michael@0: * equal to 500 (corresponding to half a pixel); the slope of each michael@0: * linear piece must be shallower than -1 (e.g., -.4). michael@0: * michael@0: * @note: michael@0: * This property can be used with @FT_Property_Get also. michael@0: * michael@0: */ michael@0: michael@0: michael@0: /* */ michael@0: michael@0: FT_END_HEADER michael@0: michael@0: michael@0: #endif /* __FTCFFDRV_H__ */ michael@0: michael@0: michael@0: /* END */