FreeType » Docs » Controlling FreeType Modules » The TrueType driver
The TrueType driver¶
Synopsis¶
While FreeType's TrueType driver doesn't expose API functions by itself, it is possible to control its behaviour with FT_Property_Set and FT_Property_Get. The following lists the available properties together with the necessary macros and structures.
The TrueType driver's module name is ‘truetype’.
A single property interpreter-version is available, as documented in the ‘Driver properties’ section.
We start with a list of definitions, kindly provided by Greg Hitchcock.
Bi-Level Rendering
Monochromatic rendering, exclusively used in the early days of TrueType by both Apple and Microsoft. Microsoft's GDI interface supported hinting of the right-side bearing point, such that the advance width could be non-linear. Most often this was done to achieve some level of glyph symmetry. To enable reasonable performance (e.g., not having to run hinting on all glyphs just to get the widths) there was a bit in the head table indicating if the side bearing was hinted, and additional tables, ‘hdmx’ and ‘LTSH’, to cache hinting widths across multiple sizes and device aspect ratios.
Font Smoothing
Microsoft's GDI implementation of anti-aliasing. Not traditional anti-aliasing as the outlines were hinted before the sampling. The widths matched the bi-level rendering.
ClearType Rendering
Technique that uses physical subpixels to improve rendering on LCD (and other) displays. Because of the higher resolution, many methods of improving symmetry in glyphs through hinting the right-side bearing were no longer necessary. This lead to what GDI calls ‘natural widths’ ClearType, see http://www.beatstamm.com/typography/RTRCh4.htm#Sec21. Since hinting has extra resolution, most non-linearity went away, but it is still possible for hints to change the advance widths in this mode.
ClearType Compatible Widths
One of the earliest challenges with ClearType was allowing the implementation in GDI to be selected without requiring all UI and documents to reflow. To address this, a compatible method of rendering ClearType was added where the font hints are executed once to determine the width in bi-level rendering, and then re-run in ClearType, with the difference in widths being absorbed in the font hints for ClearType (mostly in the white space of hints); see http://www.beatstamm.com/typography/RTRCh4.htm#Sec20. Somewhat by definition, compatible width ClearType allows for non-linear widths, but only when the bi-level version has non-linear widths.
ClearType Subpixel Positioning
One of the nice benefits of ClearType is the ability to more crisply display fractional widths; unfortunately, the GDI model of integer bitmaps did not support this. However, the WPF and Direct Write frameworks do support fractional widths. DWrite calls this ‘natural mode’, not to be confused with GDI's ‘natural widths’. Subpixel positioning, in the current implementation of Direct Write, unfortunately does not support hinted advance widths, see http://www.beatstamm.com/typography/RTRCh4.htm#Sec22. Note that the TrueType interpreter fully allows the advance width to be adjusted in this mode, just the DWrite client will ignore those changes.
ClearType Backward Compatibility
This is a set of exceptions made in the TrueType interpreter to minimize hinting techniques that were problematic with the extra resolution of ClearType; see http://www.beatstamm.com/typography/RTRCh4.htm#Sec1 and https://www.microsoft.com/typography/cleartype/truetypecleartype.aspx. This technique is not to be confused with ClearType compatible widths. ClearType backward compatibility has no direct impact on changing advance widths, but there might be an indirect impact on disabling some deltas. This could be worked around in backward compatibility mode.
Native ClearType Mode
(Not to be confused with ‘natural widths’.) This mode removes all the exceptions in the TrueType interpreter when running with ClearType. Any issues on widths would still apply, though.