Table Requirements & Recommendations

Table Alignment and Length

As suggested in the introduction to Chapter 2, all tables should be aligned to begin at offsets which are multiples of four bytes. While this is not required by the TrueType rasterizer, it does prevent ambiguous checksum calculations and greatly speeds table access on some processors.

All tables should be recorded in the table directory with their actual length. To ensure that checksums are calculated correctly, it is suggested that tables begin on LONG word boundries, as mentioned in Chapter 2. Any extra space after a table (and before the next LONG word boundry) should be padded with zeros.

'cmap' Table

When building a Unicode font for Windows, the platform ID should be 3 and the encoding ID should be 1 (this subtable must use cmap format 4). When building a symbol font for Windows, the platform ID should be 3 and the encoding ID should be 0.

Remember that, despite references to "first" and "second" subtables, the subtables must be stored in sorted order by platform and encoding ID.

Macintosh 'cmap' Table

When building a font containing Roman characters that will be used on the Macintosh, an additional subtable is required, specifying platform ID of 1 and encoding ID of 0 (this subtable must use cmap format 0).

The Apple 'cmap' subtable should be constructed according to the guidelines in the "Character Sets" chapter. Note that the "apple logo" and "propeller" (

) should be mapped to the nonexistent glyph.

'cvt' Table

Should be defined only if required by font instructions.

'fpgm' Table

Should be defined only if required by font instructions.

'glyf' Table

Must contain all data required to construct the complete UGL character set as specified by the 'cmap' table.

In order for the Macintosh 'cmap' table to be useful, the glyphs required for the Macintosh must have glyph indices less than 256 (since the 'cmap' subtable format 0 uses BYTE indices and therefore cannot index any glyph above 255). This, of course, means that all the glyphs needed to map to the Macintosh character set (as per Chapter 4) must be placed within the first 256 glyph "slots" in this table.

'hdmx' Table

This table is not necessary at all unless instructions are used to control the "phantom points," and should be omitted if bit 2 of the flags field in the 'head' table is zero. (See the 'head' table documentation in Chapter 2.) Microsoft recommends that this table be included for fonts with one or more non-linearly scaled glyphs (i.e., bit 2 or 4 of the flags field is set).

Device records should be defined for all sizes from 8 through 14 point, and even point sizes from 16 through 24 point. However, the table requires pixel-per-em sizes, which depend on the horizontal resolution of the output device. The records in 'hdmx' should cover both 96 dpi devices (CGA, EGA, VGA) and 300 dpi devices (laser and ink jet printers).

Thus, 'hdmx' should contain entries for the following pixel sizes: 11, 12, 13, 15, 16, 17, 19, 21, 24, 27, 29, 32, 33, 37, 42, 46, 50, 54, 58, 67, 75, 83, 92, 100. These values have been rounded to the nearest pixel. For instance, 12 points at 300 dpi would measure 37.5 pixels, but this is rounded down to 37 for this list.

This will add approximately 9,600 bytes to the font file. However, there will be a significant improvement in speed when a client requests advance widths covered by these device records.

If the font includes an 'LTSH' table, the hdmx values are not needed above the linearity threshold.

'head' Table

All data required.

'hhea' Table

All data required. It is suggested that monospaced fonts set numberLongMetrics to three (see hmtx).

'hmtx' Table

All data required. It is suggested that monospaced fonts have three entries in the nMetric field.

'kern' Table

Should contain a single kerning pair subtable (format 0). Windows and OS/2 will not support format 2 (two-dimensional array of kern values by class). Windows and OS/2 will not support multiple tables; only the first format 0 table found will be used. Also, Windows and OS/2 will not support coverage bits 0 through 4 (i.e. assumes horizontal data, kerning values, no cross stream, and override).

'loca' Table

All data required. In order for the Macintosh 'cmap' table to be useful, the glyphs required for the Macintosh must have glyph indices less than 256 (since the 'cmap' subtable format 0 uses BYTE indices and therefore cannot index any glyph with an index greater than 255). Beyond this requirement, the actual ordering of the glyphs in the font can be optimized based on expected utilization, with the most frequently used glyphs appearing at the beginning of the font file. Additionally, glyphs that are often used together should be grouped together in the file. The will help to minimize the amount of swapping required when the font is loaded into memory.

'LTSH' Table

Should be defined if bit 2 or 4 of flags in 'head' is set.

'maxp' Table

All data required.

'name' Table

When building a Unicode font for Windows, the platform ID should be 3 and the encoding ID should be 1. When building a symbol font for Windows, the platform ID should be 3 and the encoding ID should be 0.

When building a font containing Roman characters that will be used on the Macintosh, an additional name record is required, specifying platform ID of 1 and encoding ID of 0.

Each set of name records should appear for US English (language ID = 0x0409 for Microsoft records, language ID = 0 for Macintosh records); additional language strings for the Microsoft set of records (platform ID 3) may be added at the discretion of the font vendor.

Remember that, despite references to "first" and "second," the name record must be stored in sorted order (by platform ID, encoding ID, language ID, name ID). The 'name' table platform/encoding IDs must match the 'cmap' table platform/encoding IDs, which is how Windows knows which name set to use.

Name strings

The Subfamily string in the 'name' table should be used for variants of weight (ultra light to extra black) and style (oblique/italic or not). So, for example, the full font name of "Helvetica Narrow Italic" should be defined as Family name "Helvetica Narrow" and Subfamily "Italic." This is so that Windows can group the standard four weights of a font in a reasonable fashion for non-typographically aware applications which only support combinations of "bold" and "italic."

'OS/2' Table

All data required.

'post' Table

All information required, although the VM Usage fields may be set to zero. Format 2 is required in order to support the two-byte glyph indices in the UGL character set. Glyph names for the PostScript character set must be defined as per the "PostScript Reference Manual" (Adobe Systems Incorporated, 1988); note that names for all glyphs must be supplied as it cannot be assumed that all Microsoft platforms will support the default names supplied on the Macintosh. Names for the Unicode glyphs outside the PostScript set should be assigned a four character hexidecimal string that corresponds to their Unicode index (e.g. '2302' for the small house glyph). See Chapter 4 for the complete Unicode character set, including PostScript glyph names (where defined).

'prep' Table

Should be defined only if required by the font instructions.

'VDMX' Table

Should be present if hints cause the font to scale non-linearly. If not present, the font is assumed to scale linearly. Clipping may occur if values in this table are absent and font exceeds linear height.