Open a PDF's font list and you will often see names like ABCDEE+Calibri — a six-letter prefix, a plus sign, then the font name. That prefix marks a subset: the document does not contain Calibri, it contains the specific glyphs from Calibri that this document uses. Subsetting is why a two-page letter in a font with 3,000 glyphs adds 20 KB rather than 400 KB, and it is also behind several problems that appear much later in a document's life.
What subsetting does
A modern OpenType font is a large file. A typical text font covers Latin, Greek and Cyrillic, plus punctuation, symbols, currency, small caps, oldstyle figures, ligatures and alternates — several thousand glyphs, often 200–800 KB per weight. A document using four weights would embed 2 MB of font data before a single word of content.
Subsetting includes only the glyphs actually used. A one-page letter might use 70 distinct characters, so the subset is a few kilobytes. The saving is dramatic and the visual result is identical, which is why nearly every PDF producer subsets by default.
The six-letter prefix exists to prevent a specific bug. If two documents both embed a subset of Calibri containing different glyphs and are then merged, a viewer must not treat them as the same font — one subset lacks glyphs the other has. A random unique prefix makes them distinct fonts as far as the file is concerned, so both are retained. ABCDEE+Calibri and XYZWVU+Calibri coexist harmlessly.
Why it matters that fonts are embedded at all
Subsetting is a refinement of embedding, and embedding is the thing that actually matters. A PDF that references a font without embedding it depends on the reader's machine having that font. When it does not, the viewer substitutes — and substitution changes glyph widths, which reflows lines, shifts tables, and breaks layouts. The document no longer looks like the document.
This is why "all fonts embedded" is a hard requirement for print and a strong recommendation for everything else. See embedded fonts in PDF explained and troubleshooting PDF fonts not displaying.
Standard 14 fonts — Helvetica, Times, Courier, Symbol, ZapfDingbats and their variants — are the historical exception, assumed present in every viewer and so not embedded. In practice viewers substitute metric-compatible clones, and the results are close but not identical. For anything where appearance matters, embed even these.
Checking what a file contains
pdffonts document.pdf
gives a table: font name, type, whether it is embedded, whether it is subset, and the encoding. Read it as follows:
emb= yes,sub= yes — embedded subset. The normal, healthy state.emb= yes,sub= no — fully embedded. Larger file, more flexible for editing.emb= no — not embedded. The font will be substituted on any machine lacking it. This is the row to worry about.- Type 3 — glyphs defined as small PDF programs rather than outlines. Usually from older TeX pipelines or some OCR layers; renders poorly at small sizes and extracts badly.
In Acrobat the same information is under File → Properties → Fonts, where the "Actual Font" line tells you what is being substituted when the embedded font is missing.
The problems subsetting causes
You cannot edit freely. This is the big one. Open a subset-embedded PDF in an editor and type a character the subset does not contain — an em dash, an accented letter, a currency symbol — and the editor cannot render it from the embedded data. Depending on the tool you get a blank, a substituted glyph in a visibly different font, or a refusal to edit.
Editors handle this in one of three ways: substitute the full font if it is installed locally (fine, if you have it), fall back to a similar available font (visibly wrong), or subset-extend by adding the needed glyph (correct, and only some tools do it). This is a large part of why editing text in a PDF is so much less pleasant than editing a word processor document — see how to edit PDF text without Acrobat and beginner's guide to editing PDFs.
Merging can bloat. Twenty documents each carrying a different subset of the same font produce twenty embedded fonts in the merged file, because the prefixes make them distinct. Some tools deduplicate identical subsets; none can merge differing ones automatically. A merged pack can therefore be surprisingly large — one contributor to the puzzle in why is my PDF so large.
Text extraction can break. A subset font may use a custom encoding where glyph codes do not correspond to Unicode. If the producer did not include a /ToUnicode mapping, extracted text comes out as gibberish — the characters display correctly and copy incorrectly. This is a genuinely common failure in files from certain LaTeX and design pipelines, and it is behind many "I can see the text but cannot copy it" reports. Related: how to fix PDF text not selectable.
Accessibility depends on the same mapping. A screen reader reads extracted text, so a broken /ToUnicode map means an inaccessible document regardless of how well it is tagged.
Search fails silently. Same root cause. The document is full of text that cannot be found because the search index received nonsense.
Controlling subsetting when producing PDFs
Most producers expose a threshold: subset when the used glyphs are below some percentage of the font.
Adobe applications: "Subset fonts when percent of characters used is less than: 100%" — the default in most presets. Setting it to 100% means always subset; setting it to 0% means never subset (embed in full).
Word: Options → Save → Embed fonts in the file, with Embed only the characters used in the document controlling subsetting. Word's PDF export subsets by default.
LaTeX/pdfTeX: subsets by default; \pdfinclusioncopyfonts and map-file settings control the details.
Ghostscript: -dSubsetFonts=true (default) or false.
When to embed fully rather than subset:
- The document is a template others will edit and extend.
- It is going into an editing workflow where text will change.
- You are producing an archival master and want maximum future flexibility — though PDF/A requires embedding and permits subsetting, so this is a preference rather than a requirement.
Otherwise subset. The size saving is real and the downsides only bite in editing workflows.
Licensing
Font licences vary in what they permit, and PDF embedding is usually addressed specifically. Most commercial licences permit embedding for document distribution; some restrict it to "preview and print" rather than editable embedding; a few prohibit it outright, and some fonts carry the fsType flag set to no-embedding, which compliant producers will honour by refusing to embed.
Two practical consequences: an export that mysteriously fails to embed one font is often a licence flag rather than a bug, and a document you distribute widely with fully embedded commercial fonts is, in a meaningful sense, distributing the font. Subsetting weakens that argument considerably, which is one reason foundries are generally comfortable with it.
Fixing a file with unembedded fonts
If pdffonts shows emb = no and you need it fixed:
- Re-export from the source with embedding enabled. Always the best answer.
- Ghostscript can embed fonts present on your system during a reprocess:
This works only if the font is installed on the machine doing the conversion; otherwise Ghostscript substitutes, which fixes the file's structure while changing its appearance.gs -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -dEmbedAllFonts=true \ -sOutputFile=out.pdf in.pdf - Acrobat's preflight has an "embed missing fonts" fixup with the same caveat.
There is no way to recover a font that is not embedded and not installed anywhere. The glyphs are simply not present.
Summary
Subsetting embeds only the glyphs a document uses, marked by the six-letter prefix on the font name, and it is why PDFs are as small as they are. It costs you editing flexibility — an editor cannot type a character the subset lacks — and it makes merged documents accumulate near-duplicate fonts. Check any file that matters with pdffonts: every row should read emb = yes, and if text copies as gibberish, the culprit is a missing /ToUnicode map rather than the subsetting itself.
