Why Your Treatment's Fonts Change After Export or Handoff

The complaint arrives as one sentence — the fonts changed — and it is usually two problems wearing the same coat. Start by identifying which object failed. An editable treatment and the PDF exported from it carry type in different ways, and the repair that fixes one does nothing for the other.

Then ask what the handoff has to do. Preserving the words already on the page and supporting words a collaborator will type are different jobs with different requirements. A file that displays perfectly for a reader can still fail the first time someone edits it.

Only after those two answers do you touch the design. Where the intended face cannot travel through a route the application supports and the font's licence permits, agree on a replacement and re-check the layout. Flattening every word into a picture is a last resort, because it trades a font problem for a text problem: no selection, no search, no edits.

Capture the failure before changing the font

Four probes will surface almost everything worth knowing. Put the same content in the source and in the affected output:

• A long headline that wraps at least once, so you can see where the line breaks.
• A word with diacritics or a non-English name.
• A symbol your layout depends on: an arrow, a star, a section mark, a curly quote.
• A passage carrying emphasis, whether italic, bold, small caps or a colour change.

Then record three things about each failure you find. Which object is wrong — the source file or the exported one. When it appeared — on export, on first opening somewhere else, or during later editing. And what kind of failure it is, because the three kinds have different causes:

Keep the failing file and its corrected successor distinguishable. Suffix filenames, never overwrite, and make sure the eventual before-and-after comparison uses one revision against its own fix. A screenshot from the recipient is evidence of how something looked, not of why. Ask for the file, or run the check yourself on a machine that lacks your fonts.

The sample below is invented — project, face names, files and all — so that the checks have something specific to point at. What you take from it is a sequence to run and a record to keep. Whether your own file behaves this way is exactly what the checks are for.

One headline card carries a long line: A surveyor maps a coastline that redraws itself every spring, and the town that refuses to move with it. The deck also includes the director's name, Anaïs Fournier; a flow line built from arrows (the ledger → the lighthouse → the harbor); and one emphasized phrase inside a body paragraph. Headlines are set in a licensed display face, body text and arrows in a text face. Two handoffs get tested: a PDF export opened on the producer's laptop, which has neither face installed, and the editable file sent to the same producer, who opens it there and types one new headline line in the display face.

Inspect the PDF as a PDF

A PDF is not a container for your working file. It carries layout and either a usable copy of the glyphs it needs or a reference to a font name the viewer has to find locally. Adobe's documentation on font handling in PDF creation describes full embedding, subset embedding, vendor embedding restrictions, and substitution when the original font is unavailable (Adobe, Embedding fonts in PDFs overview).

Keep two distinctions separate, because they get mixed up constantly.

Subset is not the same as substituted. A subset contains only the glyphs your document actually uses. If your PDF holds a subset of the display face, every word in it displays exactly as designed. That is not a defect; it is the correct and economical outcome for a file nobody is meant to retype.

Substitution is what you get when the original is not available and no usable copy travelled with the file. The viewer reaches for something else and renders your headline in it, with different letterforms and different metrics.

The sample's PDF handoff is where substitution would show up first. The producer's machine has neither face installed, so if the export did not carry a usable copy of the display face, the viewer renders the headline in whatever it finds instead. The long line reflows, and a card that fit in two lines on your screen may take three on theirs. Record that as a PDF handoff, appearing on first open on a machine without the face, with the changed wrap marked as a consequence of substitution rather than a second fault. Missing-character symptoms belong in their own category: an arrow can come back as a box, a blank, or a glyph borrowed from a system fallback, and which one you see depends on the viewer.

Two checks belong here, and they answer different questions.

Open the PDF's font information — in most readers this lives in document properties — and compare what it lists against the text on the page. The exact wording varies between applications, so read the panel rather than pattern-matching a label someone mentioned online.

Then test the text itself. Drag across a headline, copy it, and paste it into a plain text editor. Search the document for a word you set in the display face. A screenshot that matches your screen proves neither of those things. Text can look right and still be unselectable, unsearchable, or partly replaced by outlines, and if your treatment is meant to be read, quoted, or indexed, that matters as much as the shape of the letters.

One scope note. Adobe's guidance describes PDF and Distiller behaviour. It does not tell you that your source deck will open correctly anywhere else. A PDF that looks right is a statement about that PDF.

Ask what the next editor needs to change

For an editable file, the question is not "did the font travel?" but "did the right amount of it travel for what happens next?" Microsoft's documentation on embedding custom fonts, covering the listed Office versions, distinguishes embedding the characters a file uses from embedding a font's full character set, and notes that font-specific restrictions and offline use both affect the result (Microsoft, Benefits of embedding custom fonts).

That distinction is the whole decision. Used-character embedding keeps the file small. If the recipient only reads, it is often enough. If the recipient will type new words in that face, it is exactly the case the smaller setting does not cover: the characters they add may not exist in the embedded set, and their new line falls back to something else. Establish the intended edits before choosing a setting, not after the file comes back.

Two ways the sample's editable deck breaks. If the display face is absent from the producer's machine and nothing usable was embedded, everything set in that face substitutes the moment the file opens, and the wrap changes on contact. If the face travelled with only the characters the designer used, the existing words display and the producer's new headline line — Add: Act Two flood sequence — São Bento — may fall back for the ã, because that character does not appear anywhere in the original deck and so may not be in the embedded subset. Now the deck has two faces doing the same job across two cards, which is harder to explain to a client than either failure alone.

Two boundaries are easy to cross here.

An embedding setting is not a licence. Microsoft's documentation notes font-specific restrictions on what may be embedded and where. If the licence does not permit the face to travel, do not send the font file as a workaround. A file listing that says "embedded" describes what software did to a document; it says nothing about your right to redistribute the typeface itself.

And a PDF that displayed the words proves nothing about the editable source. It is common to hand over both, see the PDF come back clean, and assume the deck is fine. They are different objects with different requirements, and only one of them was tested.

Repair the relevant route and repeat representative checks

There are two routes, and the choice is made by permissions and support, not by preference.

If embedding is supported and the licence permits it, fix it in the editable source. Choose the setting that matches the intended edits — the fuller one if the recipient will type in that face — and confirm the font's restrictions allow the use you have in mind. Re-send, then open the result on a machine that lacks the face. That last step is not optional; on your own machine the problem is invisible because the font is installed.

If it is not permitted or not supported, agree on a replacement: a face the recipient already has installed, and one the studio may use. Rebuild the type styles rather than selecting all the text and picking a font from the menu, so headings, body, and emphasis all point at the replacement consistently. Then look at the layout again, because a replacement is never metrically identical.

In the sample, the replacement happens to be wider at headline weight, and the long line takes three lines where it took two. Nobody needs to guess whether that matters; the card is now taller than its slot. The options are familiar: drop the headline a size step, widen the measure, shorten the line with the writer's agreement, or let it run to three lines and adjust the card around it. Whichever you choose, re-check the hierarchy afterwards. A headline that still reads as dominant at a smaller size is fine. One that now sits at the same visual weight as the body text is a design change, not a repair.

Then run the four probes again on the corrected file: longest line, accented name, arrows, emphasis. Test the actual route rather than an approximation of it. Send through the same channel to the same recipient setup, and where editing was required, ask for one new phrase to be typed in the face and confirm it reports as that face afterwards. If the PDF is meant to be searchable, have someone select and search a line.

Re-export from the corrected source. Do not patch the text inside the PDF, and do not fix a screenshot. A change made downstream of the source disappears the next time anyone exports.

If complete fidelity turns out to be unavailable — the original face cannot be embedded, and no acceptable replacement exists — say so plainly in the handoff. One line naming what changed and why is worth more than a silent substitution discovered three meetings later.

The habit underneath all of this is the same at every step. Ask which object the reader or editor will actually open, find out what that object carries, and check the result through the route it will really travel. The goal is not a deck that never changes. It is a handoff where you know what travelled, what did not, and what the recipient is looking at when they open it.

Frequently asked questions

How can I tell whether the font problem is in the PDF or the editable file?

Identify which object failed before touching design. A PDF carries layout and either a usable copy of the needed glyphs or a reference to a font name the viewer must find locally, while an editable file has to serve whatever edits come next. A PDF that displays correctly proves nothing about the editable source: they are different objects with different requirements, and checking one does not test the other.

Does subset embedding in a PDF mean my font changed?

No. A subset contains only the glyphs the document actually uses, and if the PDF holds a subset of the display face, every word in it displays exactly as designed. That is not a defect; it is the correct and economical outcome for a file nobody is meant to retype. Substitution is different: it happens when the original font is unavailable and no usable copy travelled with the file, so the viewer reaches for something else and renders the headline with different letterforms and metrics.

Why might a collaborator's new display-face line fall back even though the existing text looks right?

Used-character embedding keeps the file small by carrying only the characters already in the document. If the recipient types new words in that face, the characters they add may not exist in the embedded set. In the invented example, 'Add: Act Two flood sequence — São Bento' may fall back for the ã because that character does not appear in the original deck. Establish the intended edits before choosing an embedding setting, not after the file comes back.

What should I do if embedding is not supported or the licence does not permit it?

Agree on a replacement face the recipient already has installed and the studio may use. Rebuild the type styles rather than selecting all the text and picking a font from the menu, so headings, body, and emphasis point at the replacement consistently. Re-check the layout afterward, because a replacement is never metrically identical; in the invented case the wider headline weight turns a two-line card into three lines. If no acceptable replacement exists, say plainly in the handoff what changed and why. An embedding setting is not a licence, so do not send the font file as a workaround.

How do I verify the corrected handoff?

Run the four probes again on the corrected file: longest line, accented name, arrows, emphasis. Test the actual route rather than an approximation: send through the same channel to the same recipient setup. Where editing was required, ask for one new phrase to be typed in the face and confirm it reports as that face afterward. If the PDF is meant to be searchable, have someone select and search a line. Re-export from the corrected source; do not patch the text inside the PDF or fix a screenshot, because a change made downstream of the source disappears the next time anyone exports.

Further reading

• How to Choose Fonts and Build a Readable Film Pitch Deck — When a font change looks like a design flaw, this separates type-role problems from handoff faults so you do not rebuild a page around a temporary substitution.
• Check the Actual Treatment File You Intend to Send — Before resending, this checks the actual treatment file in the route it will travel, separating material defects from cosmetic ones and fixing the source, not the PDF.
• Why Your Treatment PDF’s Colors Change After Export — When the export damage is color rather than type, this applies the same object-and-stage isolation method to find where the shift entered: source asset, placement, export, or viewing.