TrueType in Windows 95
In Windows 95, enhancements to TrueType 1.0 improve font performance and appearance, and support international typography. The following TrueType enhancements are summarized in this article:
Better font performance
- 32 bit rasterizer: faster and better hinting and rendering.
- Embedded bitmaps: combine contours and bitmaps in one font file.
- TrueType collections: share glyph sets among fonts.
Better font appearance
- Vertical font metrics: layout of vertical text.
- Gray scale font rasterization: render smooth and sharp glyphs.
Better support for international typography
- Windows glyph list 4: new "pan-European" character set.
- Codepages: better codepage classification and design.
- Unicode: 16 bit character code representation.
- TrueType OS/2 table: identify the scripts in a font.
- TrueType Open: support for international typography.
32 bit rasterizer: faster and better hinting and rendering
The new 32 bit TrueType rasterizer performs font hinting and rendering faster at all resolutions with more efficient memory use and better scan conversion. To maximize speed, the rasterizer streamlines the hinting process with improved calling conventions, opcode dispatch, and math processing. To efficiently use memory, the rasterizer caches grid-fitted contours, provides two new modes of scan conversion banding, and reuses rasterizer workspace. The 32 bit rasterizer eliminates numerical overflow problems.
The new rasterizer supports bitmap embedding and gray scale rendering (both are discussed in this article) and corrects problems with composite glyph nesting and scaling. Now, composite glyphs can contain glyph components that are composites themselves.
To improve the appearance of fonts, the TrueType rasterizer provides better curve rendering and pixel drop-out control. The curve rendering algorithm now rasterizes curves directly without first converting them to lines. The drop-out control positions extra pixels precisely where they are needed to fill gaps in rasterized glyph shapes.
Embedded bitmaps: combine contours and bitmaps in one TrueType font file
Embedded bitmaps are bitmaps that can be added to a TrueType font file. A font may contain one or more embedded bitmaps, for one or more pixel-per-em (ppem) sizes. For instance, a TrueType font might include embedded bitmaps of glyphs that are difficult to hint at small sizes, such as complex ideographs. Windows 95 uses TrueType embedded bitmaps to render small glyphs in its Kanji and Lucida Console fonts and for selected glyphs in its core fonts, such as shade characters. Embedded bitmaps also are called "scaler bits" or, more commonly, "sbits".
The behavior of embedded bitmaps within a TrueType font is transparent to the text processing client. Because the TrueType rasterizer includes a font driver for both contours and bitmaps, the client does not need to know whether a bitmap glyph returned by the rasterizer comes from an embedded bitmap or from a scan-converted contour. If an embedded bitmap exists in a font for a requested glyph at a selected size, then the rasterizer returns the embedded bitmap. If the embedded bitmap does not exist in the font, then the rasterizer returns a bitmap that is generated from the contour data. 'Sbit only' fonts, that is fonts with embedded bitmaps but without contour data, are permitted, but such fonts can only return the sbit glyphs and sizes that are defined in the font. The TrueType font format currently does not support gray scale embedded bitmaps.
Revision 1.65 of the TrueType 1.0 Font File Specification includes three new tables for embedded bitmap data. The Embedded Bitmap Location Table (EBLC) identifies the sizes and glyph ranges of the font's embedded bitmaps and contains offsets to the glyph bitmap data. The Embedded Bitmap Data Table (EBDT) stores the glyph bitmap data in a number of different formats. The Embedded Bitmap Scaling Table (EBSC) specifies the bitmap point sizes that can be generated by scaling embedded bitmaps up or down.
TrueType collections: share glyph sets among fonts
A TrueType Collection (.TTC file) is a single file structure that allows multiple TrueType fonts to efficiently share data tables. TrueType Collections can be used when several fonts share many glyphs in common, resulting in a significant reduction in font file space.
For example, a group of Japanese fonts might each have their own designs for the Kana glyphs, but share identical designs for the larger set of Kanji glyphs. With ordinary TrueType font files, the only way to include the common Kanji glyphs is to duplicate the Kanji glyph data in each font. But, with TTCs, several fonts can share a single copy of the Kanji glyphs. Currently, TTCs are supported in GDI for the Far East versions of Windows.
Vertical metrics: layout of vertical text
Two new TrueType tables support vertical text layout. The Vertical Header Table (vhea) provides vertical metric information for the entire font, such as vertical ascent, descent and line gap data. The Vertical Metrics Table (vmtx) supplies two vertical spacing metrics for each glyph, the top sidebearing and the advance height. The formats of these tables are similar to TrueType's hhea and hmtx tables for horizontal metrics.
Gray scale font rasterization: render smooth and sharp glyphs
The TrueType rasterizer now supports gray scale scan conversion, an anti-aliasing technique that uses gradated values of gray to smooth the jagged edges of bitmap shapes. Gray scale is most effective when bitmaps are displayed on screens at small sizes and coarse resolutions.
For added control over glyph rasterizing, a new TrueType table, called 'gasp' (for Grid-fitting and Scan Conversion Procedure), defines the best combinations of hinting and gray scale to apply at different font sizes. Hinting preserves the design characteristics of a typeface and it corrects font scaling defects, such as uneven stroke widths and curve asymmetries, usually by constraining the control point extrema of contour glyph shapes to the pixel grid before scan conversion. When hinting is combined with gray scale rendering, the rasterizer applies gray values only to the contour shape edges that do not align with the pixel grid, such as curved and diagonal edges. Horizontal and vertical edges that do align with the pixel grid remain black to retain image sharpness.
The 'gasp' table specifies up to eight pixel-per-em (ppem) size ranges and the combination of hinting and gray scale operations to apply within each range. Ranges may require different rasterization actions. For example, at very small screen sizes, gray scale scan conversion, without hinting, produces the best appearance. At intermediate screen sizes (10 to 12 points), hinting generates high quality text, without the use of gray scale. And, at large screen sizes, a combination of hinting and gray scale scan conversion is optimal.
Windows 95 uses a scale of five gray values to generate a gray scale glyph: black, white, and three intermediate grays. The gray scale scan converter determines the specific value of gray to apply to a pixel by calculating the extent of the glyph's contour that falls within the pixel's boundaries. If a small percentage of the contour lies within a pixel, then the pixel's color is light gray; conversely, if a large percentage of the contour falls within a pixel, then the pixel's color is dark gray. The rasterizer applies this gray scale blending technique to other foreground and background text colors on some display devices.
Gray scale rasterization is applied only to contour glyph shapes; currently, there is no support for storing an embedded gray scale bitmap or for generating a gray scale bitmap from a monochrome bitmap. If a specific glyph is selected for display at a particular size, and gray scale is requested, then the TrueType rasterizer will generate a gray scale bitmap directly from the glyph contour data, even if an embedded bitmap exists at the requested size.
Windows glyph list 4 (WGL4): new "pan-European" character set standard
Microsoft has defined a new "Pan-European" character set standard, Windows Glyph List 4 (WGL4), that contains 652 characters required in Western, Central, and Eastern European writing systems, and Greek and Turkish. The WGL4 character set covers several major codepages: 1250 for Eastern European languages, 1251 for Cyrillic, 1252 for US English, 1253 for Greek, and 1254 for Turkish. Before WGL4, a user typing characters in English, Cyrillic, and Greek would have to select three different fonts, Times New Roman, Times New Roman Cyrillic, and Times New Roman Greek, in order to access all of the characters. Now, a user can load a single WGL4 font and change codepages as needed. WGL4 fonts are not required under Windows 95, which will continue to support fonts that worked under Windows 3.1.
The WGL4 character set is listed in the TrueType 1.0 Font File Specification where it is compared to the Win 3.1 ANSI, UGL, and Macintosh character sets. WGL4 takes advantage of the ability of Windows 95 to address characters according to their Unicode double-byte character codes using API extensions.
Microsoft is supporting font developers as they create new WGL4 fonts. Font developers also may create fonts for Windows 95 with large character sets other than WGL4, but the characters must exist in the codepages supported by Windows 95 for users to access the glyphs.
WGL4 fonts will be released on the CD ROM version of Windows 95, and released for "Pan-European" countries, but will not be available on floppy disk versions of Windows 95 that are released domestically.
Codepages: better codepage classification and design
Microsoft has improved codepage design for the NT and Windows 95 operating systems. A codepage is a list of selected character codes, arranged in a certain order, that support specific languages or groups of languages that share common scripts. For example, codepage 1253 provides character codes for Greek and codepage 1252 lists character codes for US English and other languages that use the Latin script.
The encoding order of the character codes in a codepage enables the operating system to return the appropriate character code to an application when a user presses a key on the keyboard. When a new codepage is loaded, a new set of character codes is returned to the application.
Using the OS/2 table data in a TrueType font, an application can determine which codepages a specific font supports and can then present script or language system options to the user. In Windows 95, the user can change codepages on-the-fly without changing the default language system in use.
Unicode: 16 bit character code representation
Unicode is a 16 bit character encoding standard that represents most of the characters used in general text interchange throughout the world. Unlike other character encoding standards that assign character codes to both characters and glyphs, Unicode assigns character codes only to characters. In Unicode, each character has a distinct linguistic function or meaning, and its character code is unambiguous. Character codes are not assigned to glyphs or glyph variants because a glyph is simply a graphic depiction that has no meaning apart from the character or characters that it represents. By functionally separating characters and glyphs, Unicode simplifies text processing for software developers and users.
Although Windows 95 does not use Unicode internally for character encoding, it does include a small number of Unicode-enabled APIs for converting character codes and rendering characters, such as MultiByteToWideChar, ExtTextOutW, and GetCharWidthW.
NT uses Unicode internally for character encoding, but applications can still support existing single-byte codepages using the NLS APIs. Mappings between double-byte character sets and Unicode values are handled via the MultiByteToWideChar and WideCharToMultiByte APIs.
TrueType OS/2 table: identify the scripts in a font
The OS/2 table in the TrueType 1.0 font format now identifies the scripts that are supported by the glyphs in a font. Scripts are defined by Unicode script ranges or by codepage numbers. A font manufacturer specifies one or more script or codepage ranges by setting the appropriate bits in the uICodePageRange or uIUnicodeRange fields of the OS/2 table; the script data cannot be changed by the user. The core fonts in Windows 95 use the uICodePageRange field to specify character sets, not the uIUnicodeRange field.
TrueType Open: support for international typography
The TrueType font format now supports international typography with five new tables, collectively known as TrueType Open: GSUB, GPOS, BASE, JSTF, and GDEF. TrueType Open provides typographic and linguistic information for properly positioning and substituting glyphs, operations that are required for accurate typographic composition in many language environments. With TrueType Open, multiple scripts may be supported by a single font. To assist application and OS text processing clients, the TrueType Open data is organized by script, language system, and typographic feature.
The GSUB and GPOS tables define glyph substitution and positioning features. GSUB supplies five types of substitutions to support different kinds of character-to-glyph mappings, such as many-to-one ligature glyph substitution and one-to-many ligature decomposition. GPOS defines seven types of positioning features that provide two-dimensional positioning data for adjusting glyph placement and for glyph attachment.
The BASE table contains baseline and minimum/maximum extent data for each script. Script baselines can be defined in relation to one another to properly align glyphs from different scripts. Min/max extent values can be modified for particular language systems or features. With JSTF, text processing clients can turn glyph substitution and positioning features on and off to adjust line lengths and glyph spacing when justifying text. GDEF contains assorted tables that define useful information for text processing clients, such as ligature caret positions and lists of glyph attachment points.
The architecture of TrueType Open provides backwards font compatibility, client control, ease of use, and portability across machine platforms. Because TrueType Open fonts are simply TrueType 1.0 fonts that contain additional tables, they are compatible with any software that currently supports TrueType 1.0. And TrueType 1.0 fonts that do not contain TrueType Open data are still valid fonts. Font developers can define their own TrueType Open features in a font, and text processing clients can decide which of these features, if any, to apply to the text. TrueType Open data is decodable; an operating system or application can easily parse and understand it. If the same TrueType Open code is used in cross-platform applications, it will function properly.
When Microsoft releases the Arabic and Japanese versions of Windows 95, the core system fonts will be TrueType Open fonts. These fonts demonstrate some of TrueType Open's versatility.
Arabic Windows 95 will ship with several TrueType Open fonts that define many glyph substitution features, namely single substitution (a one-to-one contextual operation), ligature substitution (a many-to-one operation), and mark set substitutions. In Arabic Windows 95, the operating system itself manages glyph substitution, using data in the GSUB table of each font.
Japanese Windows 95 also will ship with several TrueType Open fonts that include vertical glyph substitution features and baseline positioning. Again, the operating system in Japanese Windows 95 manages glyph substitution, using the GSUB table data in each font. The text-processing client manages baseline positioning, using the BASE table data.
Microsoft, TrueType 1.0 Font File Specification version 1.66
See for more information about character sets, WGL4.0 list of characters, Macintosh compatibility, and language encoding within a font. Available on MSDN.
Microsoft, TrueType Open Font Specification
See for more information about the TrueType Open tables.
The Unicode Standard, version 1.0 (Addison-Wesley, 1991)
See for more information about Unicode script ranges and the characters they cover.
this page was last updated 30 June 1997.
Top of page