FreeType » Docs » Controlling FreeType Modules » Driver properties
Driver properties¶
Synopsis¶
Driver modules can be controlled by setting and unsetting properties, using the functions FT_Property_Set and FT_Property_Get. This section documents the available properties, together with auxiliary macros and structures.
FT_HINTING_XXX¶
Defined in FT_DRIVER_H (freetype/ftdriver.h).
#define FT_HINTING_FREETYPE 0
#define FT_HINTING_ADOBE 1
/* these constants (introduced in 2.4.12) are deprecated */
#define FT_CFF_HINTING_FREETYPE FT_HINTING_FREETYPE
#define FT_CFF_HINTING_ADOBE FT_HINTING_ADOBE
A list of constants used for the hinting-engine property to select the hinting engine for CFF, Type 1, and CID fonts.
values
| FT_HINTING_FREETYPE |
Use the old FreeType hinting engine. |
| FT_HINTING_ADOBE |
Use the hinting engine contributed by Adobe. |
since
2.9
hinting-engine¶
Thanks to Adobe, which contributed a new hinting (and parsing) engine, an application can select between ‘freetype’ and ‘adobe’ if compiled with CFF_CONFIG_OPTION_OLD_ENGINE. If this configuration macro isn't defined, ‘hinting-engine’ does nothing.
The same holds for the Type 1 and CID modules if compiled with T1_CONFIG_OPTION_OLD_ENGINE.
For the ‘cff’ module, the default engine is ‘adobe’. For both the ‘type1’ and ‘t1cid’ modules, the default engine is ‘adobe’, too.
note
This property can be used with FT_Property_Get also.
This property can be set via the FREETYPE_PROPERTIES environment variable (using values ‘adobe’ or ‘freetype’).
example
The following example code demonstrates how to select Adobe's hinting engine for the ‘cff’ module (omitting the error handling).
FT_Library library;
FT_UInt hinting_engine = FT_HINTING_ADOBE;
FT_Init_FreeType( &library );
FT_Property_Set( library, "cff",
"hinting-engine", &hinting_engine );
since
2.4.12 (for ‘cff’ module)
2.9 (for ‘type1’ and ‘t1cid’ modules)
no-stem-darkening¶
All glyphs that pass through the auto-hinter will be emboldened unless this property is set to TRUE. The same is true for the CFF, Type 1, and CID font modules if the ‘Adobe’ engine is selected (which is the default).
Stem darkening emboldens glyphs at smaller sizes to make them more readable on common low-DPI screens when using linear alpha blending and gamma correction, see FT_Render_Glyph. When not using linear alpha blending and gamma correction, glyphs will appear heavy and fuzzy!
Gamma correction essentially lightens fonts since shades of grey are shifted to higher pixel values (= higher brightness) to match the original intention to the reality of our screens. The side-effect is that glyphs ‘thin out’. Mac OS X and Adobe's proprietary font rendering library implement a counter-measure: stem darkening at smaller sizes where shades of gray dominate. By emboldening a glyph slightly in relation to its pixel size, individual pixels get higher coverage of filled-in outlines and are therefore ‘blacker’. This counteracts the ‘thinning out’ of glyphs, making text remain readable at smaller sizes.
For the auto-hinter, stem-darkening is experimental currently and thus switched off by default (that is, no-stem-darkening is set to TRUE by default). Total consistency with the CFF driver is not achieved right now because the emboldening method differs and glyphs must be scaled down on the Y-axis to keep outline points inside their precomputed blue zones. The smaller the size (especially 9ppem and down), the higher the loss of emboldening versus the CFF driver.
Note that stem darkening is never applied if FT_LOAD_NO_SCALE is set.
note
This property can be used with FT_Property_Get also.
This property can be set via the FREETYPE_PROPERTIES environment variable (using values 1 and 0 for ‘on’ and ‘off’, respectively). It can also be set per face using FT_Face_Properties with FT_PARAM_TAG_STEM_DARKENING.
example
FT_Library library;
FT_Bool no_stem_darkening = TRUE;
FT_Init_FreeType( &library );
FT_Property_Set( library, "cff",
"no-stem-darkening", &no_stem_darkening );
since
2.4.12 (for ‘cff’ module)
2.6.2 (for ‘autofitter’ module)
2.9 (for ‘type1’ and ‘t1cid’ modules)
darkening-parameters¶
By default, the Adobe hinting engine, as used by the CFF, Type 1, and CID font drivers, darkens stems as follows (if the no-stem-darkening property isn't set):
stem width <= 0.5px: darkening amount = 0.4px
stem width = 1px: darkening amount = 0.275px
stem width = 1.667px: darkening amount = 0.275px
stem width >= 2.333px: darkening amount = 0px
and piecewise linear in-between. At configuration time, these four control points can be set with the macro CFF_CONFIG_OPTION_DARKENING_PARAMETERS; the CFF, Type 1, and CID drivers share these values. At runtime, the control points can be changed using the darkening-parameters property (see the example below that demonstrates this for the Type 1 driver).
The x values give the stem width, and the y values the darkening amount. The unit is 1000th of pixels. All coordinate values must be positive; the x values must be monotonically increasing; the y values must be monotonically decreasing and smaller than or equal to 500 (corresponding to half a pixel); the slope of each linear piece must be shallower than -1 (e.g., -.4).
The auto-hinter provides this property, too, as an experimental feature. See no-stem-darkening for more.
note
This property can be used with FT_Property_Get also.
This property can be set via the FREETYPE_PROPERTIES environment variable, using eight comma-separated integers without spaces. Here the above example, using \ to break the line for readability.
FREETYPE_PROPERTIES=\
type1:darkening-parameters=500,300,1000,200,1500,100,2000,0
example
FT_Library library;
FT_Int darken_params[8] = { 500, 300, // x1, y1
1000, 200, // x2, y2
1500, 100, // x3, y3
2000, 0 }; // x4, y4
FT_Init_FreeType( &library );
FT_Property_Set( library, "type1",
"darkening-parameters", darken_params );
since
2.5.1 (for ‘cff’ module)
2.6.2 (for ‘autofitter’ module)
2.9 (for ‘type1’ and ‘t1cid’ modules)
random-seed¶
By default, the seed value for the CFF ‘random’ operator and the similar ‘0 28 callothersubr pop’ command for the Type 1 and CID drivers is set to a random value. However, mainly for debugging purposes, it is often necessary to use a known value as a seed so that the pseudo-random number sequences generated by ‘random’ are repeatable.
The random-seed property does that. Its argument is a signed 32bit integer; if the value is zero or negative, the seed given by the intitialRandomSeed private DICT operator in a CFF file gets used (or a default value if there is no such operator). If the value is positive, use it instead of initialRandomSeed, which is consequently ignored.
note
This property can be set via the FREETYPE_PROPERTIES environment variable. It can also be set per face using FT_Face_Properties with FT_PARAM_TAG_RANDOM_SEED.
since
2.8 (for ‘cff’ module)
2.9 (for ‘type1’ and ‘t1cid’ modules)
no-long-family-names¶
If PCF_CONFIG_OPTION_LONG_FAMILY_NAMES is active while compiling FreeType, the PCF driver constructs long family names.
There are many PCF fonts just called ‘Fixed’ which look completely different, and which have nothing to do with each other. When selecting ‘Fixed’ in KDE or Gnome one gets results that appear rather random, the style changes often if one changes the size and one cannot select some fonts at all. The improve this situation, the PCF module prepends the foundry name (plus a space) to the family name. It also checks whether there are ‘wide’ characters; all put together, family names like ‘Sony Fixed’ or ‘Misc Fixed Wide’ are constructed.
If no-long-family-names is set, this feature gets switched off.
note
This property can be used with FT_Property_Get also.
This property can be set via the FREETYPE_PROPERTIES environment variable (using values 1 and 0 for ‘on’ and ‘off’, respectively).
example
FT_Library library;
FT_Bool no_long_family_names = TRUE;
FT_Init_FreeType( &library );
FT_Property_Set( library, "pcf",
"no-long-family-names",
&no_long_family_names );
since
2.8
TT_INTERPRETER_VERSION_XXX¶
Defined in FT_DRIVER_H (freetype/ftdriver.h).
#define TT_INTERPRETER_VERSION_35 35
#define TT_INTERPRETER_VERSION_38 38
#define TT_INTERPRETER_VERSION_40 40
A list of constants used for the interpreter-version property to select the hinting engine for Truetype fonts.
The numeric value in the constant names represents the version number as returned by the ‘GETINFO’ bytecode instruction.
values
| TT_INTERPRETER_VERSION_35 |
Version 35 corresponds to MS rasterizer v.1.7 as used e.g. in Windows 98; only grayscale and B/W rasterizing is supported. |
| TT_INTERPRETER_VERSION_38 |
Version 38 is the same Version 40. The original ‘Infinality’ code is no longer available. |
| TT_INTERPRETER_VERSION_40 |
Version 40 corresponds to MS rasterizer v.2.1; it is roughly equivalent to the hinting provided by DirectWrite ClearType (as can be found, for example, in Microsoft's Edge Browser on Windows 10). It is used in FreeType to select the ‘minimal’ subpixel hinting code, a stripped-down and higher performance version of the ‘Infinality’ code. |
note
This property controls the behaviour of the bytecode interpreter and thus how outlines get hinted. It does not control how glyph get rasterized! In particular, it does not control subpixel color filtering.
If FreeType has not been compiled with the configuration option TT_CONFIG_OPTION_SUBPIXEL_HINTING, selecting version 38 or 40 causes an FT_Err_Unimplemented_Feature error.
Depending on the graphics framework, Microsoft uses different bytecode and rendering engines. As a consequence, the version numbers returned by a call to the ‘GETINFO’ bytecode instruction are more convoluted than desired.
Here are two tables that try to shed some light on the possible values for the MS rasterizer engine, together with the additional features introduced by it.
GETINFO framework version feature
-------------------------------------------------------------------
3 GDI (Win 3.1), v1.0 16-bit, first version
TrueImage
33 GDI (Win NT 3.1), v1.5 32-bit
HP Laserjet
34 GDI (Win 95) v1.6 font smoothing,
new SCANTYPE opcode
35 GDI (Win 98/2000) v1.7 (UN)SCALED_COMPONENT_OFFSET
bits in composite glyphs
36 MGDI (Win CE 2) v1.6+ classic ClearType
37 GDI (XP and later), v1.8 ClearType
GDI+ old (before Vista)
38 GDI+ old (Vista, Win 7), v1.9 subpixel ClearType,
WPF Y-direction ClearType,
additional error checking
39 DWrite (before Win 8) v2.0 subpixel ClearType flags
in GETINFO opcode,
bug fixes
40 GDI+ (after Win 7), v2.1 Y-direction ClearType flag
DWrite (Win 8) in GETINFO opcode,
Gray ClearType
The ‘version’ field gives a rough orientation only, since some applications provided certain features much earlier (as an example, Microsoft Reader used subpixel and Y-direction ClearType already in Windows 2000). Similarly, updates to a given framework might include improved hinting support.
version sampling rendering comment
x y x y
--------------------------------------------------------------
v1.0 normal normal B/W B/W bi-level
v1.6 high high gray gray grayscale
v1.8 high normal color-filter B/W (GDI) ClearType
v1.9 high high color-filter gray Color ClearType
v2.1 high normal gray B/W Gray ClearType
v2.1 high high gray gray Gray ClearType
Color and Gray ClearType are the two available variants of ‘Y-direction ClearType’, meaning grayscale rasterization along the Y-direction; the name used in the TrueType specification for this feature is ‘symmetric smoothing’. ‘Classic ClearType’ is the original algorithm used before introducing a modified version in Win XP. Another name for v1.6's grayscale rendering is ‘font smoothing’, and ‘Color ClearType’ is sometimes also called ‘DWrite ClearType’. To differentiate between today's Color ClearType and the earlier ClearType variant with B/W rendering along the vertical axis, the latter is sometimes called ‘GDI ClearType’.
‘Normal’ and ‘high’ sampling describe the (virtual) resolution to access the rasterized outline after the hinting process. ‘Normal’ means 1 sample per grid line (i.e., B/W). In the current Microsoft implementation, ‘high’ means an extra virtual resolution of 16x16 (or 16x1) grid lines per pixel for bytecode instructions like ‘MIRP’. After hinting, these 16 grid lines are mapped to 6x5 (or 6x1) grid lines for color filtering if Color ClearType is activated.
Note that ‘Gray ClearType’ is essentially the same as v1.6's grayscale rendering. However, the GETINFO instruction handles it differently: v1.6 returns bit 12 (hinting for grayscale), while v2.1 returns bits 13 (hinting for ClearType), 18 (symmetrical smoothing), and 19 (Gray ClearType). Also, this mode respects bits 2 and 3 for the version 1 gasp table exclusively (like Color ClearType), while v1.6 only respects the values of version 0 (bits 0 and 1).
Keep in mind that the features of the above interpreter versions might not map exactly to FreeType features or behavior because it is a fundamentally different library with different internals.
interpreter-version¶
Currently, three versions are available, two representing the bytecode interpreter with subpixel hinting support (old ‘Infinality’ code and new stripped-down and higher performance ‘minimal’ code) and one without, respectively. The default is subpixel support if TT_CONFIG_OPTION_SUBPIXEL_HINTING is defined, and no subpixel support otherwise (since it isn't available then).
If subpixel hinting is on, many TrueType bytecode instructions behave differently compared to B/W or grayscale rendering (except if ‘native ClearType’ is selected by the font). Microsoft's main idea is to render at a much increased horizontal resolution, then sampling down the created output to subpixel precision. However, many older fonts are not suited to this and must be specially taken care of by applying (hardcoded) tweaks in Microsoft's interpreter.
Details on subpixel hinting and some of the necessary tweaks can be found in Greg Hitchcock's whitepaper at ‘https://www.microsoft.com/typography/cleartype/truetypecleartype.aspx’. Note that FreeType currently doesn't really ‘subpixel hint’ (6x1, 6x2, or 6x5 supersampling) like discussed in the paper. Depending on the chosen interpreter, it simply ignores instructions on vertical stems to arrive at very similar results.
note
This property can be used with FT_Property_Get also.
This property can be set via the FREETYPE_PROPERTIES environment variable (using values ‘35’, ‘38’, or ‘40’).
example
The following example code demonstrates how to deactivate subpixel hinting (omitting the error handling).
FT_Library library;
FT_Face face;
FT_UInt interpreter_version = TT_INTERPRETER_VERSION_35;
FT_Init_FreeType( &library );
FT_Property_Set( library, "truetype",
"interpreter-version",
&interpreter_version );
since
2.5
spread¶
This property of the ‘sdf’ and ‘bsdf’ renderers defines how the signed distance field (SDF) is represented in the output bitmap. The output values are calculated as follows, ‘128 * ( SDF / spread + 1 )’, with the result clamped to the 8-bit range [0..255]. Therefore, ‘spread’ is also the maximum euclidean distance from the edge after which the values are clamped. The spread is specified in pixels with the default value of 8. For accurate SDF texture mapping (interpolation), the spread should be large enough to accommodate the target grid unit.
example
The following example code demonstrates how to set the SDF spread (omitting the error handling).
FT_Library library;
FT_Int spread = 2;
FT_Init_FreeType( &library );
FT_Property_Set( library, "sdf", "spread", &spread );
note
FreeType has two rasterizers for generating SDF, namely:
-
sdffor generating SDF directly from glyph's outline, and -
bsdffor generating SDF from rasterized bitmaps.
Depending on the glyph type (i.e., outline or bitmap), one of the two rasterizers is chosen at runtime and used for generating SDFs. To force the use of bsdf you should render the glyph with any of the FreeType's other rendering modes (e.g., FT_RENDER_MODE_NORMAL) and then re-render with FT_RENDER_MODE_SDF.
There are some issues with stability and possible failures of the SDF renderers (specifically sdf).
-
The
sdfrasterizer is sensitive to really small features (e.g., sharp turns that are less than 1 pixel) and imperfections in the glyph's outline, causing artifacts in the final output. -
The
sdfrasterizer has limited support for handling intersecting contours and cannot handle self-intersecting contours whatsoever. Self-intersection happens when a single connected contour intersects itself at some point; having these in your font definitely poses a problem to the rasterizer and cause artifacts, too. -
Generating SDF for really small glyphs may result in undesirable output; the pixel grid (which stores distance information) becomes too coarse.
-
Since the output buffer is normalized, precision at smaller spreads is greater than precision at larger spread values because the output range of [0..255] gets mapped to a smaller SDF range. A spread of 2 should be sufficient in most cases.
Points (1) and (2) can be avoided by using the bsdf rasterizer, which is more stable than the sdf rasterizer in general.
since
2.11
svg-hooks¶
Set up the interface between FreeType and an extern SVG rendering library like ‘librsvg’. All details on the function hooks can be found in section ‘OpenType SVG Fonts’.
example
The following example code expects that the four hook functions svg_* are defined elsewhere. Error handling is omitted, too.
FT_Library library;
SVG_RendererHooks hooks = {
(SVG_Lib_Init_Func)svg_init,
(SVG_Lib_Free_Func)svg_free,
(SVG_Lib_Render_Func)svg_render,
(SVG_Lib_Preset_Slot_Func)svg_preset_slot };
FT_Init_FreeType( &library );
FT_Property_Set( library, "ot-svg",
"svg-hooks", &hooks );
since
2.12
glyph-to-script-map¶
Experimental only
The auto-hinter provides various script modules to hint glyphs. Examples of supported scripts are Latin or CJK. Before a glyph is auto-hinted, the Unicode character map of the font gets examined, and the script is then determined based on Unicode character ranges, see below.
OpenType fonts, however, often provide much more glyphs than character codes (small caps, superscripts, ligatures, swashes, etc.), to be controlled by so-called ‘features’. Handling OpenType features can be quite complicated and thus needs a separate library on top of FreeType.
The mapping between glyph indices and scripts (in the auto-hinter sense, see the FT_AUTOHINTER_SCRIPT_XXX values) is stored as an array with num_glyphs elements, as found in the font's FT_Face structure. The glyph-to-script-map property returns a pointer to this array, which can be modified as needed. Note that the modification should happen before the first glyph gets processed by the auto-hinter so that the global analysis of the font shapes actually uses the modified mapping.
example
The following example code demonstrates how to access it (omitting the error handling).
FT_Library library;
FT_Face face;
FT_Prop_GlyphToScriptMap prop;
FT_Init_FreeType( &library );
FT_New_Face( library, "foo.ttf", 0, &face );
prop.face = face;
FT_Property_Get( library, "autofitter",
"glyph-to-script-map", &prop );
// adjust `prop.map' as needed right here
FT_Load_Glyph( face, ..., FT_LOAD_FORCE_AUTOHINT );
since
2.4.11
FT_AUTOHINTER_SCRIPT_XXX¶
Defined in FT_DRIVER_H (freetype/ftdriver.h).
#define FT_AUTOHINTER_SCRIPT_NONE 0
#define FT_AUTOHINTER_SCRIPT_LATIN 1
#define FT_AUTOHINTER_SCRIPT_CJK 2
#define FT_AUTOHINTER_SCRIPT_INDIC 3
Experimental only
A list of constants used for the glyph-to-script-map property to specify the script submodule the auto-hinter should use for hinting a particular glyph.
values
| FT_AUTOHINTER_SCRIPT_NONE |
Don't auto-hint this glyph. |
| FT_AUTOHINTER_SCRIPT_LATIN |
Apply the latin auto-hinter. For the auto-hinter, ‘latin’ is a very broad term, including Cyrillic and Greek also since characters from those scripts share the same design constraints. By default, characters from the following Unicode ranges are assigned to this submodule. |
| FT_AUTOHINTER_SCRIPT_CJK |
Apply the CJK auto-hinter, covering Chinese, Japanese, Korean, old Vietnamese, and some other scripts. By default, characters from the following Unicode ranges are assigned to this submodule. |
| FT_AUTOHINTER_SCRIPT_INDIC |
Apply the indic auto-hinter, covering all major scripts from the Indian sub-continent and some other related scripts like Thai, Lao, or Tibetan. By default, characters from the following Unicode ranges are assigned to this submodule. Note that currently Indic support is rudimentary only, missing blue zone support. |
since
2.4.11
FT_Prop_GlyphToScriptMap¶
Defined in FT_DRIVER_H (freetype/ftdriver.h).
typedef struct FT_Prop_GlyphToScriptMap_
{
FT_Face face;
FT_UShort* map;
} FT_Prop_GlyphToScriptMap;
Experimental only
The data exchange structure for the glyph-to-script-map property.
since
2.4.11
fallback-script¶
Experimental only
If no auto-hinter script module can be assigned to a glyph, a fallback script gets assigned to it (see also the glyph-to-script-map property). By default, this is FT_AUTOHINTER_SCRIPT_CJK. Using the fallback-script property, this fallback value can be changed.
note
This property can be used with FT_Property_Get also.
It's important to use the right timing for changing this value: The creation of the glyph-to-script map that eventually uses the fallback script value gets triggered either by setting or reading a face-specific property like glyph-to-script-map, or by auto-hinting any glyph from that face. In particular, if you have already created an FT_Face structure but not loaded any glyph (using the auto-hinter), a change of the fallback script will affect this face.
example
FT_Library library;
FT_UInt fallback_script = FT_AUTOHINTER_SCRIPT_NONE;
FT_Init_FreeType( &library );
FT_Property_Set( library, "autofitter",
"fallback-script", &fallback_script );
since
2.4.11
default-script¶
Experimental only
If FreeType gets compiled with FT_CONFIG_OPTION_USE_HARFBUZZ to make the HarfBuzz library access OpenType features for getting better glyph coverages, this property sets the (auto-fitter) script to be used for the default (OpenType) script data of a font's GSUB table. Features for the default script are intended for all scripts not explicitly handled in GSUB; an example is a ‘dlig’ feature, containing the combination of the characters ‘T’, ‘E’, and ‘L’ to form a ‘TEL’ ligature.
By default, this is FT_AUTOHINTER_SCRIPT_LATIN. Using the default-script property, this default value can be changed.
note
This property can be used with FT_Property_Get also.
It's important to use the right timing for changing this value: The creation of the glyph-to-script map that eventually uses the default script value gets triggered either by setting or reading a face-specific property like glyph-to-script-map, or by auto-hinting any glyph from that face. In particular, if you have already created an FT_Face structure but not loaded any glyph (using the auto-hinter), a change of the default script will affect this face.
example
FT_Library library;
FT_UInt default_script = FT_AUTOHINTER_SCRIPT_NONE;
FT_Init_FreeType( &library );
FT_Property_Set( library, "autofitter",
"default-script", &default_script );
since
2.5.3
increase-x-height¶
For ppem values in the range 6 <= ppem <= increase-x-height, round up the font's x height much more often than normally. If the value is set to 0, which is the default, this feature is switched off. Use this property to improve the legibility of small font sizes if necessary.
note
This property can be used with FT_Property_Get also.
Set this value right after calling FT_Set_Char_Size, but before loading any glyph (using the auto-hinter).
example
FT_Library library;
FT_Face face;
FT_Prop_IncreaseXHeight prop;
FT_Init_FreeType( &library );
FT_New_Face( library, "foo.ttf", 0, &face );
FT_Set_Char_Size( face, 10 * 64, 0, 72, 0 );
prop.face = face;
prop.limit = 14;
FT_Property_Set( library, "autofitter",
"increase-x-height", &prop );
since
2.4.11
FT_Prop_IncreaseXHeight¶
Defined in FT_DRIVER_H (freetype/ftdriver.h).
The data exchange structure for the increase-x-height property.
warping¶
Obsolete
This property was always experimental and probably never worked correctly. It was entirely removed from the FreeType 2 sources. This entry is only here for historical reference.
Warping only worked in ‘normal’ auto-hinting mode replacing it. The idea of the code was to slightly scale and shift a glyph along the non-hinted dimension (which is usually the horizontal axis) so that as much of its segments were aligned (more or less) to the grid. To find out a glyph's optimal scaling and shifting value, various parameter combinations were tried and scored.
since
2.6