.TTC File Format – Collection header

Header

The header is at byte 0. Version 1.0 was used for collections without a digital signature; version 2.0 adds three fields after the offsets, and can be used with or without a signature. Without one, the three fields are zero.

So a version 1.0 header is 12 + 4 × numFonts bytes, and a version 2.0 header 24 + 4 × numFonts. The specification defines no other versions or minor versions.

Table directories

• Each font in the collection has a complete table directory of its own, in exactly the same format as at the start of a single font: sfntVersion (0x00010000 for TrueType outlines, OTTO for CFF or CFF2), numTables, the three search fields and the sorted table records.
• Every table offset in every directory counts from the start of the collection file, not from the start of that font’s directory.
• A font is chosen by its index in tableDirectoryOffsets, starting at 0. Software that opens a collection usually shows each font separately, by the names in its own name table.
• Fonts in one collection may have different kinds of outlines, layout tables or not, and may include one or more variable fonts.

Sharing tables

Two fonts share a table simply by having table records with the same offset and length. Any table whose data is identical in two or more fonts may be shared. The specification’s guidance:

The specification’s example is two Japanese fonts with different kana but the same kanji. The collection holds one glyf table with both sets of kana and one set of kanji, and both fonts’ directories point to it. Each font has its own cmap, which maps the kana characters to that font’s kana glyphs and the kanji characters to the shared kanji glyphs.

Fonts that share glyph tables share glyph numbering, so building a collection from separate fonts means renumbering glyphs and fixing every table that uses glyph numbers. Fonts sharing TrueType hinting must also have compatible instructions: their prep and fpgm programs and control values cannot conflict.

Checksums and signatures

• Table checksums in each directory must match the tables as they are in the collection file. They are worked out as for a single font; see checksums.
• The checksumAdjustment field in each head table is not used in a collection and may be 0.
• A signed collection needs a version 2.0 header. The DSIG table must be the last thing in the file, after every other table, and is found through the header’s dsigOffset, not through any font’s table directory. Signatures in a collection are expected to be format 1 (PKCS#7).

Example

The start of ArialHB.ttc, the Arial Hebrew collection that comes with macOS (188,236 bytes):

00000000  74 74 63 66 00 02 00 00  00 00 00 09 00 00 00 3C   ttcf...........<
00000010  00 00 01 88 00 00 02 D4  00 00 04 20 00 00 05 6C   ........... ...l
00000020  00 00 06 B8 00 00 08 04  00 00 09 50 00 00 0A 9C   ...........P....
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 01 00 00   ................

The header is 24 + 4 × 9 = 60 bytes, so the first directory starts at 60. Each directory has 20 tables (00 14), so it is 12 + 20 × 16 = 332 bytes, and the directories follow one another 332 bytes apart. Comparing the first two fonts’ records shows what they share:

Here the two fonts have different outlines, so glyf is not shared, but the character map, the substitution rules and Apple’s morx table are stored once.