PDF TrueType Font
TrueType is a font format developed by Apple and Microsoft that uses quadratic Bézier curves for glyph outlines. TrueType fonts embedded in PDF are stored in /FontFile2 streams. They are the most common font format in PDFs created on Windows and macOS, and are the basis for OpenType fonts with TrueType outlines (OTF/TTF).
TrueType is the most widely used font format in PDF documents today. Originally developed by Apple and Microsoft as a competitor to Adobe's Type 1, TrueType uses quadratic Bézier curves for glyph outlines (rather than the cubic curves used by Type 1 and PostScript). TrueType fonts are embedded in PDFs as /FontFile2 streams and are the default format produced by most modern operating systems, design applications, and word processors.
In PDF, TrueType fonts can be used as simple fonts (single-byte encoding, like Type 1) or as part of Type 0 composite fonts via CIDFont dictionaries — the latter is required for CJK text and broad Unicode coverage.
TrueType font structure in PDF
A TrueType font dictionary in PDF has /Subtype /TrueType (for simple, single-byte use). The embedded font program is stored in a /FontFile2 stream — a copy of the binary TrueType font file (an .ttf file). The key tables inside the TrueType binary:
<strong>glyf</strong> — Glyph outline data. Each glyph is defined as contours made of on-curve and off-curve (quadratic control) points. Unlike Type 1's cubic Bézier curves, TrueType uses quadratic Bézier curves (also called conic curves), which require two control points per curve segment rather than one. This means TrueType curves need slightly more points to approximate the same shape as a cubic curve, but the format is simpler to implement.
<strong>cmap</strong> — Character map table. Maps Unicode codepoints (or platform-specific character codes) to glyph IDs (GIDs). The cmap table is the TrueType equivalent of a CMap — it tells the system which glyph to render for a given character. PDF viewers use the cmap table when building the text rendering pipeline.
<strong>hmtx</strong> — Horizontal metrics. Width and left side bearing for each glyph — used for text layout.
<strong>name</strong> — Font naming table. Contains the font's family name, style name, copyright, and other metadata.
<strong>head, hhea, OS/2</strong> — Font-level metrics: units per em, ascender/descender heights, style flags, weight class. These populate the PDF FontDescriptor dictionary.
<strong>hints tables (cvt, fpgm, prep)</strong> — TrueType hinting instructions. These are optional but important for rendering at small sizes on low-resolution screens. PDF viewers may ignore hinting for high-resolution output.
TrueType CIDFonts for Unicode and CJK
When a PDF needs to represent text beyond the 256-character limit of simple font encoding — especially CJK (Chinese, Japanese, Korean) scripts — TrueType fonts are embedded as CIDFont dictionaries within a Type 0 composite font. In this configuration:
1. The outer font dictionary has /Subtype /Type0 and a /Encoding CMap (typically Identity-H for horizontal CJK text). 2. The /DescendantFonts array contains a CIDFont dictionary with /Subtype /CIDFontType2 (TrueType CIDFont). 3. The CIDFont dictionary's /FontDescriptor contains the /FontFile2 stream with the embedded TrueType font. 4. The CIDFont dictionary's /CIDToGIDMap entry maps CIDs to glyph IDs — either /Identity (for fonts where CID = GID, typical with Identity-H and Unicode TrueType fonts) or a stream of GID mappings for non-identity relationships.
This CIDFontType2 configuration is how virtually all Unicode text is embedded in modern PDFs produced from Word, InDesign, Google Docs, and other mainstream tools. See <a href="/glossary/pdf-cmap" target="_blank" rel="noopener">PDF CMap</a> for how the CMap controls character code to CID mapping in this structure.
<strong>Font subsetting</strong> — Most PDF generators subset embedded TrueType fonts — including only the glyphs actually used in the document. This dramatically reduces file size but means the embedded font program cannot render characters not present in the original document. Subset fonts are identified by a 6-character tag prefix in the BaseFont name (e.g., <code>ABCDEF+Arial</code>). See <a href="/glossary/pdf-font-subsetting" target="_blank" rel="noopener">PDF Font Subsetting</a> for the full subset embedding process.
OpenType as the modern successor
OpenType fonts (.otf) are the modern successor to both TrueType and Type 1. An OpenType font is a wrapper format that can contain either: - A TrueType glyph table (glyf table) — called OpenType with TrueType outlines, or CFF-based, or - A Type 1 / CFF (Compact Font Format) glyph table — called OpenType with CFF outlines.
In PDF, OpenType fonts with TrueType outlines are embedded identically to TrueType (/FontFile2) and treated as /CIDFontType2. OpenType fonts with CFF outlines are embedded as /FontFile3 with /Subtype /OpenType and treated as /CIDFontType0. Most modern system fonts (Windows, macOS) are OpenType with TrueType outlines, so the /FontFile2 + CIDFontType2 path dominates in PDFs from everyday tools.
The /GSUB (Glyph Substitution) and /GPOS (Glyph Positioning) OpenType tables — which enable typographic features like ligatures, kerning, and contextual alternates — are not used during PDF rendering; these features are applied by the layout engine before the text reaches the PDF. The final PDF content stream contains the resulting glyph IDs after layout, not the original characters with typographic features to be applied at render time.
Frequently asked questions
What is the difference between FontFile, FontFile2, and FontFile3 in PDF?
PDF uses three keys in the font descriptor to embed different font formats: /FontFile embeds a Type 1 font program (two segments: ASCII and encrypted binary). /FontFile2 embeds a TrueType font program (a binary .ttf file). /FontFile3 embeds a CFF (Compact Font Format / Type 2) font program, with the /Subtype of the stream set to /Type1C (for CFF Type 1), /CIDFontType0C (for CFF CIDFont), or /OpenType (for an OpenType font). OpenType with TrueType outlines uses /FontFile2; OpenType with CFF outlines uses /FontFile3 /Subtype /OpenType. This distinction matters when processing or re-embedding fonts from PDF.
Why do some PDFs have multiple embedded copies of the same font?
Multiple embedded copies of the same font typically arise from font subsetting: each document section or fragment embedded the font with a different subset of glyphs. Because subset fonts have different glyph sets (and different 6-character tag prefixes like ABCDEF+Arial vs GHIJKL+Arial), PDF merging tools may not recognise them as the same font and keep all copies. This is common in PDFs assembled by merging independently generated fragments (e.g., report pages generated separately and merged). Specialised PDF optimisation tools can de-duplicate font subsets by merging them into a single complete (or merged-subset) font instance. See PDF Optimisation for related file size reduction techniques.
Can TrueType fonts in PDF be extracted and reused?
Technically yes — a /FontFile2 stream contains a standard TrueType font binary that can be extracted with PDF processing tools. However, doing so for copyrighted fonts without permission would violate the font's license. Most commercial fonts have licenses that prohibit extraction from PDFs. Fonts embedded with PDF encryption or with licence flags set in the OS/2 table's fsType field signal their embedding restrictions — though these flags are not enforced by the PDF format itself, only by licensing terms. The PDF format requires that embedded fonts be usable for rendering the document; it does not restrict the technical possibility of extraction.