Skip to content

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).

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


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).

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.

  U+0020 - U+007F  // Basic Latin (no control characters)
  U+00A0 - U+00FF  // Latin-1 Supplement (no control characters)
  U+0100 - U+017F  // Latin Extended-A
  U+0180 - U+024F  // Latin Extended-B
  U+0250 - U+02AF  // IPA Extensions
  U+02B0 - U+02FF  // Spacing Modifier Letters
  U+0300 - U+036F  // Combining Diacritical Marks
  U+0370 - U+03FF  // Greek and Coptic
  U+0400 - U+04FF  // Cyrillic
  U+0500 - U+052F  // Cyrillic Supplement
  U+1D00 - U+1D7F  // Phonetic Extensions
  U+1D80 - U+1DBF  // Phonetic Extensions Supplement
  U+1DC0 - U+1DFF  // Combining Diacritical Marks Supplement
  U+1E00 - U+1EFF  // Latin Extended Additional
  U+1F00 - U+1FFF  // Greek Extended
  U+2000 - U+206F  // General Punctuation
  U+2070 - U+209F  // Superscripts and Subscripts
  U+20A0 - U+20CF  // Currency Symbols
  U+2150 - U+218F  // Number Forms
  U+2460 - U+24FF  // Enclosed Alphanumerics
  U+2C60 - U+2C7F  // Latin Extended-C
  U+2DE0 - U+2DFF  // Cyrillic Extended-A
  U+2E00 - U+2E7F  // Supplemental Punctuation
  U+A640 - U+A69F  // Cyrillic Extended-B
  U+A720 - U+A7FF  // Latin Extended-D
  U+FB00 - U+FB06  // Alphab. Present. Forms (Latin Ligatures)
 U+1D400 - U+1D7FF // Mathematical Alphanumeric Symbols
 U+1F100 - U+1F1FF // Enclosed Alphanumeric Supplement
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.

  U+1100 - U+11FF  // Hangul Jamo
  U+2E80 - U+2EFF  // CJK Radicals Supplement
  U+2F00 - U+2FDF  // Kangxi Radicals
  U+2FF0 - U+2FFF  // Ideographic Description Characters
  U+3000 - U+303F  // CJK Symbols and Punctuation
  U+3040 - U+309F  // Hiragana
  U+30A0 - U+30FF  // Katakana
  U+3100 - U+312F  // Bopomofo
  U+3130 - U+318F  // Hangul Compatibility Jamo
  U+3190 - U+319F  // Kanbun
  U+31A0 - U+31BF  // Bopomofo Extended
  U+31C0 - U+31EF  // CJK Strokes
  U+31F0 - U+31FF  // Katakana Phonetic Extensions
  U+3200 - U+32FF  // Enclosed CJK Letters and Months
  U+3300 - U+33FF  // CJK Compatibility
  U+3400 - U+4DBF  // CJK Unified Ideographs Extension A
  U+4DC0 - U+4DFF  // Yijing Hexagram Symbols
  U+4E00 - U+9FFF  // CJK Unified Ideographs
  U+A960 - U+A97F  // Hangul Jamo Extended-A
  U+AC00 - U+D7AF  // Hangul Syllables
  U+D7B0 - U+D7FF  // Hangul Jamo Extended-B
  U+F900 - U+FAFF  // CJK Compatibility Ideographs
  U+FE10 - U+FE1F  // Vertical forms
  U+FE30 - U+FE4F  // CJK Compatibility Forms
  U+FF00 - U+FFEF  // Halfwidth and Fullwidth Forms
 U+1B000 - U+1B0FF // Kana Supplement
 U+1D300 - U+1D35F // Tai Xuan Hing Symbols
 U+1F200 - U+1F2FF // Enclosed Ideographic Supplement
 U+20000 - U+2A6DF // CJK Unified Ideographs Extension B
 U+2A700 - U+2B73F // CJK Unified Ideographs Extension C
 U+2B740 - U+2B81F // CJK Unified Ideographs Extension D
 U+2F800 - U+2FA1F // CJK Compatibility Ideographs Supplement
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.

  U+0900 - U+0DFF  // Indic Range
  U+0F00 - U+0FFF  // Tibetan
  U+1900 - U+194F  // Limbu
  U+1B80 - U+1BBF  // Sundanese
  U+A800 - U+A82F  // Syloti Nagri
  U+ABC0 - U+ABFF  // Meetei Mayek
 U+11800 - U+118DF // Sharada

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).

  typedef struct  FT_Prop_IncreaseXHeight_
  {
    FT_Face  face;
    FT_UInt  limit;

  } FT_Prop_IncreaseXHeight;

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