PDF Fonts: Embedding, Subsetting, and Substitution

A PDF created on your computer might display completely differently on someone else's system. Text shifts position. Characters become unreadable. Carefully chosen typography degrades to generic substitutes. The culprit is almost always font handling—how the document specifies fonts, whether it includes the necessary font data, and what happens when expected fonts aren't available.

Font handling is the most common source of PDF display problems. Understanding how PDF fonts work helps you create documents that display correctly everywhere and diagnose problems when documents from others don't render as expected.

How PDF Represents Text

PDF doesn't store text as a simple sequence of characters. Instead, it stores glyph descriptions—references to specific shapes in font programs—along with precise positioning information. The distinction matters: regular text files contain character codes that renderers convert to visual forms using available fonts. PDFs contain specific visual form references that require the exact font to render correctly.

A content stream might specify: use font /F1 at 12 points, position at coordinates (72, 720), show glyphs with indices 43, 65, 72, 72, 79. The renderer must have access to /F1's glyph definitions to know what shapes indices 43, 65, 72, 72, 79 represent. Without those definitions, the renderer can only guess.

This glyph-based approach enables PDF's precise appearance control. Unlike word processors that flow text dynamically, PDF specifies exact glyph positions. Line breaks, letter spacing, word spacing—all are explicitly encoded. The font provides shapes; the content stream provides positions.

The Three Font Handling Strategies

PDF documents handle fonts in three fundamentally different ways, each with distinct tradeoffs.

Referenced fonts assume the reader has access to specific fonts by name. The document says "use Helvetica" without including Helvetica's glyph definitions. If the reader has Helvetica, rendering succeeds. If not, the reader must substitute something else. This approach produces small files but unreliable display.

Embedded fonts include complete font programs within the document. Everything needed to render the font travels with the PDF. File sizes increase, but display is consistent regardless of what fonts the reader has installed. This is the recommended approach for reliable documents.

Subsetted fonts embed only the glyphs actually used in the document. If your document uses only uppercase letters and numbers from a font, the subset includes only those characters, not the thousands of unused glyphs in the complete font. This balances file size against rendering reliability.

Font Embedding: The Details

Embedding a font means including its glyph outlines (or equivalent rendering instructions) within the PDF. Different font technologies embed differently.

Type 1 fonts, Adobe's original outline format, embed as PostScript programs describing glyph shapes. Each glyph is a series of drawing commands—move to, line to, curve to—that produce the character shape. Type 1 embedding is well-understood and reliable but limited to 256 glyphs per font, requiring multiple font subsets for large character sets.

TrueType fonts embed as TrueType programs with quadratic Bézier curves describing glyphs. The embedded font is essentially a complete TrueType file within the PDF. TrueType supports large character sets and includes hinting instructions for screen rendering optimization.

OpenType fonts can use either PostScript (CFF) or TrueType outlines. OpenType embedding in PDF typically extracts the outline data while discarding OpenType-specific layout features. The embedded font renders glyphs correctly but may not preserve advanced typographic features like contextual alternates or stylistic sets unless the creating application explicitly encoded their effects.

CID-keyed fonts handle large character sets like Chinese, Japanese, and Korean. Rather than 256-glyph limits, CID fonts can contain tens of thousands of glyphs accessed by character ID numbers. Embedding these fonts can substantially increase file sizes.

Subsetting: Balancing Size and Completeness

Font subsetting reduces embedded font size by including only glyphs the document actually uses. A document using only the characters "Hello World" from a font might embed just those 8 unique glyph shapes rather than an entire font's worth.

Subsetting dramatically reduces file sizes for documents using few characters from large fonts. A decorative headline font used for a single word might contribute 50KB subsetted versus 2MB complete. For documents distributed widely, this difference matters.

However, subsetting has limitations. A subsetted font can't be used to add text not in the original document—the glyphs don't exist. If someone tries to add comments using the document's fonts, the characters they type may not render. For documents intended for further editing, complete embedding may be preferable.

Subsetting also affects font identification. Subsetted fonts typically receive modified names (like "ABCDEF+Helvetica") to distinguish them from complete fonts and prevent improper reuse. These modified names can complicate font management and identification.

The Fourteen Standard Fonts

PDF defines fourteen standard fonts that readers should have available: four variants each of Times, Helvetica, and Courier (regular, bold, italic, bold-italic), plus Symbol and Zapf Dingbats. Documents using only these fonts can reference them without embedding, assuming all readers have compatible versions.

In practice, "compatible" is problematic. Different implementations of standard fonts have different metrics—character widths, spacing, and positioning vary. A document formatted with one Helvetica implementation may wrap lines differently with another. The visual appearance may be similar, but precise layouts can shift.

For critical documents, even standard fonts should be embedded. The file size cost is modest, and the guarantee of exact reproduction is valuable. Our tools embed fonts when converting or processing documents to ensure reliable rendering.

Font Substitution: When Things Go Wrong

When a document references fonts that aren't embedded and the reader doesn't have them, font substitution occurs. The reader selects substitute fonts based on various strategies, all of which compromise appearance.

Name-based substitution looks for fonts with similar names. "Helvetica" might substitute with "Arial" or "Liberation Sans." The substitutes have different metrics, causing text to shift, overflow, or underlap its intended boundaries.

Classification-based substitution considers font characteristics: serif versus sans-serif, proportional versus monospaced, weight and style. A missing serif font substitutes with an available serif font. The result may be readable but differs visibly from the intended appearance.

Generic fallback substitution uses a default font when nothing better matches. Some systems use a single fallback for all missing fonts, producing dramatically wrong results when decorative or specialized fonts are replaced with generic alternatives.

Missing glyph handling varies when specific characters aren't available in substitute fonts. Some renderers show blank spaces. Others show placeholder boxes or question marks. Documents using extended character sets—mathematical symbols, emoji, non-Latin scripts—are particularly vulnerable to glyph availability issues.

Font-Related Problems and Solutions

Missing text usually indicates font problems. If text exists in the document structure but doesn't display, the font may be missing, corrupted, or incompatible with the renderer. Embedding fonts when creating documents prevents this issue.

Wrong characters appear when font encoding doesn't match assumptions. A document might specify character code 65 expecting glyph "A", but an incompatibly encoded font might render something else at position 65. Encoding issues are particularly common with older documents and symbolic fonts.

Shifted layouts result from metric mismatches between intended and substitute fonts. Text that should fit on one line wraps to two. Columns don't align. Tables overflow cells. Even when text is readable, the document's careful formatting is destroyed.

Poor print quality sometimes stems from font issues. Fonts optimized for screen display may print poorly. Fonts without hinting render roughly at low resolutions. Our optimize for print tool addresses font-related print quality issues.

Creating Font-Safe Documents

Embed fonts consistently. Most PDF creation tools offer embedding options—enable them. The file size increase is worthwhile for reliable rendering.

Use standard fonts sparingly and consciously. They're appropriate when exact appearance doesn't matter and file size is critical. For anything else, embed.

Consider subsetting for distributed documents. When documents go to unknown recipients who won't edit them, subsetting provides compact files with complete rendering capability.

Test on systems other than where you created documents. A document that looks perfect on your system may fail on others if fonts aren't properly embedded. Testing reveals problems while they're correctable.

Our flatten PDF tool converts text to outlines when font portability is absolutely critical. Flattened text no longer depends on fonts at all—it's just shapes. This eliminates font problems entirely but sacrifices searchability and editability.

Checking Font Embedding Status

Document properties typically show which fonts a PDF uses and whether they're embedded, subsetted, or referenced. Check this information when troubleshooting display problems.

Fully embedded fonts show complete embedding status. These fonts will render correctly regardless of the reader's installed fonts.

Subset fonts show subset status with modified names. They'll render correctly for the document's existing content but can't support additional text using characters not in the subset.

Referenced fonts show no embedding status. These fonts depend on the reader having compatible fonts installed. Documents with referenced fonts should be tested on systems without those fonts to verify acceptable substitution behavior.

Unicode and Modern Font Handling

Modern PDF font handling increasingly relies on Unicode mappings—connections between font glyphs and standard Unicode character codes. These mappings enable text extraction, search, and accessibility features.

A properly constructed PDF includes ToUnicode maps that specify what Unicode characters each glyph represents. Without these maps, glyph index 65 might render correctly but copy-paste as the wrong character, or search might fail to find text that's visibly present.

Our OCR tool adds text layers with proper Unicode mappings to scanned documents, making them searchable while preserving visual appearance.

PDF/A archival standards require specific font embedding and Unicode mapping. Documents without proper font handling fail PDF/A validation. Our PDF/A converter ensures fonts meet archival requirements.

Font Licensing Considerations

Font embedding raises licensing questions. Some font licenses prohibit or restrict embedding. Others require specific embedding modes—allowing embedded fonts for viewing but not editing.

PDF supports embedding restrictions through flags that conforming readers should respect. A font marked as "no embedding" shouldn't be embedded at all. A font marked as "preview and print" should embed in ways that prevent extraction for other uses.

In practice, enforcement is imperfect, and embedding restrictions create practical problems for document exchange. When choosing fonts for documents you'll distribute, consider embedding permissions alongside aesthetic preferences. Fonts explicitly licensed for embedding avoid legal ambiguity.

Many high-quality open-source fonts have permissive licenses allowing unrestricted embedding. Using these fonts simplifies document distribution while providing typographic quality comparable to commercial alternatives.

Understanding PDF font handling transforms mysterious rendering failures into diagnosable, fixable problems. More importantly, it enables you to create documents that work reliably across the diverse systems that will ultimately render them. Embed your fonts, test on multiple systems, and your carefully designed documents will appear as intended wherever they go.