The OpenType Font File (OpenType 1.6)

An OpenType font file contains data, in table format, that comprises either a TrueType or a PostScript outline font. Rasterizers use combinations of data from the tables contained in the font to render the TrueType or PostScript glyph outlines. Some of this supporting data is used no matter which outline format is used; some of the supporting data is specific to either TrueType or PostScript.


OpenType fonts may have the extension .OTF or .TTF, depending on the kind of outlines in the font and the creator’s desire for compatibility on systems without native OpenType support.

  • In all cases, fonts with only CFF data (no TrueType outlines) always have an .OTF extension.
  • Fonts containing TrueType outlines may have either .OTF or .TTF, depending on the desire for backward compatibility on older systems or with previous versions of the font. TrueType Collection fonts should have a .TTC extension whether or not the fonts have OpenType layout tables present.

Data Types

The following data types are used in the OpenType font file. All OpenType fonts use Motorola-style byte ordering (Big Endian):

Data Type Description
BYTE 8-bit unsigned integer.
CHAR 8-bit signed integer.
USHORT 16-bit unsigned integer.
SHORT 16-bit signed integer.
UINT24 24-bit unsigned integer.
ULONG 32-bit unsigned integer.
LONG 32-bit signed integer.
Fixed 32-bit signed fixed-point number (16.16)
FUNIT Smallest measurable distance in the em space.
FWORD 16-bit signed integer (SHORT) that describes a quantity in FUnits.
UFWORD 16-bit unsigned integer (USHORT) that describes a quantity in FUnits.
F2DOT14 16-bit signed fixed number with the low 14 bits of fraction (2.14).
LONGDATETIME Date represented in number of seconds since 12:00 midnight, January 1, 1904. The value is represented as a signed 64-bit integer.
Tag Array of four uint8s (length = 32 bits) used to identify a script, language system, feature, or baseline
GlyphID Glyph index number, same as uint16(length = 16 bits)
Offset Offset to a table, same as uint16 (length = 16 bits), NULL offset = 0x0000

The F2DOT14 format consists of a signed, 2’s complement mantissa and an unsigned fraction. To compute the actual value, take the mantissa and add the fraction. Examples of 2.14 values are:

Decimal Value Hex Value Mantissa Fraction
1.999939 0x7fff 1 16383/16384
1.75 0x7000 1 12288/16384
0.000061 0x0001 0 1/16384
0.0 0x0000 0 0/16384
-0.000061 0xffff -1 16383/16384
-2.0 0x8000 -2 0/16384

Version Numbers

Most tables have version numbers, and the version number for the entire font is contained in the Table Directory. Note that there are two different table version number types, each with its own numbering scheme. USHORT version numbers always start at zero (0). Fixed version numbers start at one (1.0 or 0x00010000), except where noted (EBDT, EBLC and EBSC tables).

Implementations reading tables must include code to check version numbers so that if and when the format and therefore the version number changes, older implementations will reject newer versions gracefully, if the changes are incompatible.

When a Fixed number is used as a version, the upper 16 bits comprise a major version number, and the lower 16 bits a minor. Tables with non-zero minor version numbers always specify the literal value of the version number since the normal representation of Fixed numbers is not necessarily followed. For example, the version number of 'maxp' table version 0.5 is 0x00005000, and that of 'vhea' table version 1.1 is 0x00011000. If an implementation understands a major version number, then it can safely proceed reading the table. The minor version number indicates extensions to the format that are undetectable by implementations that do not support them.

The only exception to this is the Offset Table’s sfnt version. This serves solely to identify whether the OpenType font contains TrueType outlines (a value of 1.0) or CFF data (the tag 'OTTO'), as described in the section below, ‘Organization of an OpenType font.’

When a USHORT number is used to indicate version, it should be treated as though it were a minor version number; i.e., all format changes are compatible extensions.

Organization of an OpenType Font

A key characteristic of the OpenType format is the TrueType sfnt “wrapper”, which provides organization for a collection of tables in a general and extensible manner.

The OpenType font with the Offset Table. If the font file contains only one font, the Offset Table will begin at byte 0 of the file. If the font file is a TrueType collection, the beginning point of the Offset Table for each font is indicated in the TTCHeader.

Offset Table
Type Name Description
Fixed sfnt version 0x00010000 for version 1.0.
USHORT numTables Number of tables.
USHORT searchRange (Maximum power of 2 <= numTables) x 16.
USHORT entrySelector Log2(maximum power of 2 <= numTables).
USHORT rangeShift NumTables x 16-searchRange.

OpenType fonts that contain TrueType outlines should use the value of 1.0 for the sfnt version. OpenType fonts containing CFF data should use the tag 'OTTO' as the sfnt version number.

NOTE: The Apple specification for TrueType fonts allows for 'true' and 'typ1' for sfnt version. These version tags should not be used for fonts which contain OpenType tables.

The Offset Table is followed immediately by the Table Record entries. Entries in the Table Record must be sorted in ascending order by tag. Offset values in the Table Record are measured from the start of the font file.

Table Record
Type Name Description
ULONG tag 4 -byte identifier.
ULONG checkSum CheckSum for this table.
ULONG offset Offset from beginning of TrueType font file.
ULONG length Length of this table.

The Table Record makes it possible for a given font to contain only those tables it actually needs. As a result there is no standard value for numTables.

Tags are the names given to tables in the OpenType font file. All tag names consist of four characters. Names with less than four letters are allowed if followed by the necessary trailing spaces. All tag names defined within a font (e.g., table names, feature tags, language tags) must be built from printing characters represented by ASCII values 32-126.

Calculating Checksums

Table checksums are the unsigned sum of the longs of a given table. In C, the following function can be used to determine a checksum:

CalcTableChecksum(ULONG *Table, ULONG Length)
ULONG Sum = 0L;
ULONG *Endptr = Table+((Length+3) & ~3) / sizeof(ULONG);
while (Table < EndPtr)
	Sum += *Table++;
return Sum;

Note: This function implies that the length of a table must be a multiple of four bytes. In fact, a font is not considered structurally proper without the correct padding. All tables must begin on four byte boundries, and any remaining space between tables is padded with zeros. The length of all tables should be recorded in the table record with their actual length (not their padded length).

To calculate the checkSum for the 'head' table which itself includes the checkSumAdjustment entry for the entire font, do the following:

  1. Set the checkSumAdjustment to 0.
  2. Calculate the checksum for all the tables including the 'head' table and enter that value into the table directory.
  3. Calculate the checksum for the entire font.
  4. Subtract that value from the hex value B1B0AFBA.
  5. Store the result in checkSumAdjustment.

The checkSum for the head table which includes the checkSumAdjustment entry for the entire font is now incorrect. That is not a problem. Do not change it. An application attempting to verify that the 'head' table has not changed should calculate the checkSum for that table by not including the checkSumAdjustment value, and compare the result with the entry in the table directory.

TrueType Collections

A TrueType Collection (TTC) is a means of delivering multiple OpenType fonts in a single file structure. TrueType Collections are most useful when the fonts to be delivered together share many glyphs in common. By allowing multiple fonts to share glyph sets, TTCs can result in a significant saving of file space.

For example, a group of Japanese fonts may each have their own designs for the kana glyphs, but share identical designs for the kanji. With ordinary OpenType font files, the only way to include the common kanji glyphs is to copy their glyph data into each font. Since the kanji represent much more data than the kana, this results in a great deal of wasteful duplication of glyph data. TTCs were defined to solve this problem.

The CFF rasterizer does not currently support TTC files.

The TTC File Structure

A TrueType Collection file consists of a single TTC Header table, one or more Offset Tables with Table Directories, and a number of OpenType tables. The TTC Header must be located at the beginning of the TTC file.

The TTC file must contain a complete Offset Table and Table Directory for each font. A TTC file Table Directory has exactly the same format as a TTF file Table Directory. The table offsets in all Table Directories within a TTC file are measured from the beginning of the TTC file.

Each OpenType table in a TTC file is referenced through the Offset Table and Table Directory of each font which uses that table. Some of the OpenType tables must appear multiple times, once for each font included in the TTC; while other tables may be shared by multiple fonts in the TTC.

As an example, consider a TTC file which combines two Japanese fonts (Font1 and Font2). The fonts have different kana designs (Kana1 and Kana2) but use the same design for kanji. The TTC file contains a single 'glyf' table which includes both designs of kana together with the kanji; both fonts’ Table Directories point to this 'glyf' table. But each font’s Table Directory points to a different 'cmap' table, which identifies the glyph set to use. Font1’s 'cmap' table points to the Kana1 region of the 'loca' and 'glyf' tables for kana glyphs, and to the kanji region for the kanji. Font2’s 'cmap' table points to the Kana2 region of the 'loca' and 'glyf' tables for kana glyphs, and to the same kanji region for the kanji.

The tables that should have a unique copy per font are those that are used by the system in identifying the font and its character mapping, including 'cmap', 'name', and 'OS/2'. The tables that should be shared by fonts in the TTC are those that define glyph and instruction data or use glyph indices to access data: 'glyf', 'loca', 'hmtx', 'hdmx', 'LTSH', 'cvt ', 'fpgm', 'prep', 'EBLC', 'EBDT', 'EBSC', 'maxp', and so on. In practice, any tables which have identical data for two or more fonts may be shared.

A tool is available from Microsoft to help build .TTC files. The process involves paying close attention the issue of glyph renumbering in a font and the side effects that can result, in the 'cmap' table and elsewhere. The fonts to be merged must also have compatible TrueType instructions-that is, their preprograms, function definitions, and control values must not conflict.

TrueType Collection files use the filename suffix .TTC.

TTC Header

There are two versions of the TTC Header: Version 1.0 has been used for TTC files without digital signatures. Version 2.0 can be used for TTC files with or without digital signatures -- if there’s no signature, then the last three fields of the version 2.0 header are left null.

If a digital signature is used, the DSIG table for the file must be the last table in the TTC file. Signatures in a TTC file are expected to be Format 1 signatures.

The purpose of the TTC Header table is to locate the different Offset Tables within a TTC file. The TTC Header is located at the beginning of the TTC file (offset = 0). It consists of an identification tag, a version number, a count of the number of OpenType fonts in the file, and an array of offsets to each Offset Table.

TTC Header Version 1.0
Type Name Description
TAG TTCTag TrueType Collection ID string: 'ttcf'
FIXED Version Version of the TTC Header (1.0), 0x00010000
ULONG numFonts Number of fonts in TTC
ULONG OffsetTable[numFonts] Array of offsets to the OffsetTable for each font from the beginning of the file

TTC Header Version 2.0
Type Name Description
TAG TTCTag TrueType Collection ID string: 'ttcf'
FIXED Version Version of the TTC Header (2.0), 0x00020000
ULONG numFonts Number of fonts in TTC
ULONG OffsetTable[numFonts] Array of offsets to the OffsetTable for each font from the beginning of the file
ULONG ulDsigTag Tag indicating that a DSIG table exists, 0x44534947 ('DSIG') (null if no signature)
ULONG ulDsigLength The length (in bytes) of the DSIG table (null if no signature)
ULONG ulDsigOffset The offset (in bytes) of the DSIG table from the beginning of the TTC file (null if no signature)

Font Tables

The rasterizer has a much easier time traversing tables if they are padded so that each table begins on a 4-byte boundary. It is highly recommended that all tables be long-aligned and padded with zeroes.

OpenType Tables

Whether TrueType or PostScript outlines are used in an OpenType font, the following tables are required for the font to function correctly:

Required Tables

Tag Name
cmap Character to glyph mapping
head Font header
hhea Horizontal header
hmtx Horizontal metrics
maxp Maximum profile
name Naming table
OS/2 OS/2 and Windows specific metrics
post PostScript information

For OpenType fonts based on TrueType outlines, the following tables are used:

Tables Related to TrueType Outlines

Tag Name
cvt Control Value Table
fpgm Font program
glyf Glyph data
loca Index to location
prep CVT Program

The PostScript font extensions define a new set of tables containing data specific to PostScript fonts that are used instead of the tables listed above.

Tables Related to PostScript Outlines

Tag Name
CFF PostScript font program (compact font format)
VORG Vertical Origin

It is strongly recommended that CFF OpenType fonts that are used for vertical writing include a Vertical Origin ('VORG') table. Multiple Master support in OpenType, has been discontinued as of version 1.3 of the specification. The 'fvar', 'MMSD', 'MMFX' tables have hence been removed.

Tables Related to Bitmap Glyphs

Tag Name
EBDT Embedded bitmap data
EBLC Embedded bitmap location data
EBSC Embedded bitmap scaling data

OpenType fonts may also contain bitmaps of glyphs, in addition to outlines. Hand-tuned bitmaps are especially useful in OpenType fonts for representing complex glyphs at very small sizes. If a bitmap for a particular size is provided in a font, it will be used by the system instead of the outline when rendering the glyph. (Note: ATM does not currently support hinted bitmaps in OpenType fonts.)

There are also several optional tables that support vertical layout as well as other advanced typographic functions:

Advanced Typographic Tables

Tag Name
BASE Baseline data
GDEF Glyph definition data
GPOS Glyph positioning data
GSUB Glyph substitution data
JSTF Justification data

For information on common table formats, please see OpenType Layout Common Table Formats.

Other OpenType Tables

Tag Name
DSIG Digital signature
gasp Grid-fitting/Scan-conversion
hdmx Horizontal device metrics
kern Kerning
LTSH Linear threshold data
PCLT PCL 5 data
VDMX Vertical device metrics
vhea Vertical Metrics header
vmtx Vertical Metrics