A translated IDML opens with a missing-font warning, even though the file came from InDesign and the source layout looked fine. The warning usually means the receiving workstation can’t access one or more font faces the document references - not that the translated text has vanished.
The fix starts with a useful handoff, not a guess at a replacement. Send the DTP team the translated IDML, an exact font inventory, any font files you’re allowed to share or instructions for getting authorized access, and a visual reference PDF. Then ask the operator to confirm which family and style are missing before approving a substitution.
What a missing font in an IDML actually means¶
An IDML file is an InDesign interchange format that carries document structure and font references, but not the font data itself. The application opening the file checks its own available fonts against those references. The IDML Reference’s description of fonts and faces explains that Resources/Fonts.xml lists fonts used by a document so an opening application can tell which ones are unavailable.
That distinction matters in a translation handoff. Sending the IDML tells the DTP operator which fonts the layout expects; it doesn’t automatically give the operator the font files or access to them. The recipient may have the same family name installed but still lack the exact face the document uses.
As the IDML Reference puts it: “An IDML package contains no font data: Resources/Fonts.xml lists the fonts the document uses, so that the application opening it can tell which are missing.”
In plain terms, the file contains a list of requirements, not the resources themselves. Treat fonts as a separate part of the handoff, just as you would treat a reference PDF or linked assets as separate from the IDML.
An opening application can report a missing face and use a substitute. A substitute may look close at a glance, but that doesn’t make it equivalent. Font metrics and letter shapes can affect line breaks, text fit, spacing, and the page’s overall appearance. The operator therefore needs to know whether a substitution is expected and whether the translated layout has been checked after it happens.
The IDML format also distinguishes a family from a face. AppliedFont names the family; FontStyle names the face within that family, such as Bold or Semibold Italic. The IDML Reference’s font and face documentation describes that two-part naming. If you send only a family name, the DTP operator may still have to guess which style is missing.
A useful handoff answers three separate questions:
- Which font family does the document reference?
- Which specific face or style does the layout use?
- Can the receiving operator access that face, either from a permitted file or through an authorized activation or licensing route?
The answers aren’t interchangeable. “The font is installed” doesn’t settle the issue if the document calls for a face that the installed family doesn’t contain. The reference describes a missing face as a missing font even when the family is present.
How to identify the exact missing family and style¶
A font inventory gives the DTP operator something more useful than a warning dialog or a vague note such as “use the same font as the source.” Start with the IDML’s font resource information, then compare that list with the fonts available to the operator.
The IDML’s Resources/Fonts.xml part lists fonts referenced in the document. The resource-parts guide explains where that file sits within the package structure. Because an IDML is a package, an operator or technically confident coordinator can inspect its parts rather than treating it as a single opaque document. The font list is useful as an inventory, but it doesn’t supply the missing files.
For each entry, capture the family and face separately. Include the PostScript name if it’s available, plus any font type or status information shown in the resource data. Those details help distinguish names that look similar in an informal email but refer to different faces or font records. The IDML Reference describes font entries with information such as PostScript name, style name, font type, and status.
| Inventory field | What to record | Why the DTP operator needs it |
|---|---|---|
| Family | The name recorded for the font family | Identifies the typeface family the document expects |
| Face or style | The exact face, such as Regular, Bold, or Semibold Italic | Helps catch a missing style even when the family is installed |
| PostScript name | The PostScript name, when available | Adds a more precise identifier than a family-only label |
| Recorded status | The status shown in the IDML resource information | Helps explain what the document records, without proving availability on the receiving computer |
| Availability note | Whether the operator can access the face, or needs authorization or a substitute | Makes the next action clear |
The IDML reference describes status values including Installed, Substituted, and NotAvailable. Read those as information recorded for the document, not as a guarantee about the fonts available on the DTP operator’s computer. A font marked as available in one environment may still be unavailable to another operator.
The IDML Reference describes the naming split this way: “A run names its typeface in two parts: AppliedFont is the family and FontStyle is the face within it.”
That split is the key to a reliable inventory. A family-only list can hide the exact problem: the family may be present, while the requested face is absent. Ask the operator to report the full family and face combination, not just “font missing.”
If you can’t inspect the IDML resource data yourself, send the file and ask the DTP operator to return a list of missing family-and-style pairs from the opening application. Ask the operator to distinguish between three cases: the family isn’t available, the family is available but the required face isn’t, or the expected font file wasn’t included in the handoff. Those cases call for different next steps.
The source InDesign file can help if it’s available, but don’t treat it as a substitute for the translated IDML or the inventory. A reference PDF helps the operator compare the page’s appearance, while the IDML provides the editable layout and the font resource list identifies the document’s expectations.
What to send the DTP team¶
A complete font handoff keeps the translated layout, the font requirements, and any permitted font assets together. The operator should be able to identify which file belongs with which font folder and what to do if a face remains unavailable.
Use this checklist when you prepare the delivery:
- Send the translated IDML. Use a clear filename that identifies the language or version. Don’t assume that sending the IDML also sends its fonts.
- Attach a font inventory. List each family and face separately. Add the PostScript name when available, along with any useful status information from the IDML resource data.
- Provide font files only when you’re allowed to share them. If the font can’t be included, provide the authorized activation or licensing instructions available to your team, or ask the recipient to obtain access through the appropriate route.
- Include a reference PDF. Use a visual reference that helps the operator compare pages while resolving font availability. The PDF is a comparison aid; it doesn’t restore editability or supply font data.
- Keep a Document fonts folder beside the matching IDML when one is part of the handoff. Use clearly matching names so the operator can tell which folder belongs to which file.
- Ask for a specific confirmation. Have the DTP operator report the exact missing family and face, whether the issue is access or a missing style, and whether any substitution is planned.
- Request a layout check after fonts are resolved. Compare line breaks, text fit, and page appearance against the reference PDF before treating the file as ready.
InDesign’s Package command places collected fonts in a Document fonts folder beside the .indd or .idml, rather than embedding font files inside the IDML. The IDML Reference’s font documentation describes that relationship. Keep the folder with the corresponding IDML and preserve a clear match between their names.
A folder name is a small detail that can prevent a handoff mix-up. If several translated versions are being sent, use names that make the connection obvious, such as manual-fr.idml with a clearly corresponding font folder. The point is not to enforce a particular naming scheme; it’s to make sure the operator doesn’t mistake an unrelated folder for the assets belonging to the file under review.
The Package command is useful, but a package summary isn’t the same thing as checking the actual contents. In an Adobe Community discussion dated April 4, 2024, a user reported a discrepancy between the font counts shown in Find/Replace Fonts and Package, and the files in the resulting folder. The user said the package was intended for a translator. That report is an individual case, not a general guarantee about package behavior, but it shows why the recipient should inspect the actual folder instead of relying only on a summary.
In the same Adobe Community discussion dated April 4, 2024, the poster wrote: “Means, the package, which is supposed to be sent to a translator, misses files.”
The forum post describes one user’s reported packaging problem, not a rule that every package will be incomplete. The practical lesson is narrower: confirm that the folder you send contains the permitted files you expect, and let the receiving operator confirm what is actually available on their system. The Adobe packaging guidance and Adobe’s InDesign font guidance are useful references when checking packaging and font handling.
Put the handoff details in the message accompanying the files. A short note can state which IDML is translated, where the font inventory is, whether a Document fonts folder is included, and which faces the recipient must check. Include the reference PDF and name it clearly. If the operator needs to obtain a font rather than receive a file, say so directly instead of letting them assume the font was forgotten.
When font files can’t be sent¶
Font availability and permission to share font files are separate questions. A team may know exactly which font the IDML needs but still be unable to send the font file. Don’t solve a licensing problem by copying a font into a delivery folder without checking whether sharing is permitted.
The Adobe Learn guide to sharing InDesign projects can help teams think through sharing a project, but the handoff still needs a decision about the particular font and the recipient’s access. If you can’t provide the font file, send the exact family, face, and PostScript name if available. Then provide the permitted access or activation instructions, or ask the DTP operator to obtain authorized access through the appropriate route.
A substitute is another possible route, but it needs explicit agreement. The opening application may use a substitute when it can’t find a referenced face, as described by the IDML Reference. That behavior keeps the document open, but it doesn’t establish that the replacement will preserve the original layout or appearance.
Ask the operator to identify the proposed substitute and show what changed. At minimum, compare line breaks, text fit, and the overall page appearance against the reference PDF. If the replacement changes the layout materially, decide whether to obtain authorized access to the original face or approve the substitute after reviewing the result. Don’t leave the decision implicit in a status message such as “font issue resolved.”
A reference PDF is helpful when the original InDesign file or font is unavailable, but it has a limited role. A PDF lets the operator compare the appearance of pages; it doesn’t make the translated IDML editable in the same way, provide the original font, or prove that a substitute is equivalent. The IDML font reference explains why the IDML itself can identify a font without carrying its data.
When the operator reports a warning, ask for the exact family and face before sending another package or requesting a substitution. The answer helps determine whether the problem is missing access, a missing face in an otherwise available family, or a folder that wasn’t included. Each diagnosis points to a different action, and a vague “missing font” label doesn’t tell the team which one applies.
Common handoff mistakes and how to avoid them¶
The most common font handoff mistakes happen when teams confuse a reference with a resource, a family with a face, or a package summary with the contents of the package. Each distinction is small, but missing one can leave the DTP operator unable to finish the layout without asking for more information.
Sending only the IDML. The file contains font references, not font data. Send a separate inventory and, when permitted, the corresponding font assets or access instructions. The IDML Reference documents the references-only behavior.
Listing only family names. “Family present” doesn’t prove that the requested face is present. Record the family and style separately, and include the PostScript name when available. The IDML Reference explains why AppliedFont and FontStyle identify different parts of the typeface.
Assuming the Document fonts folder is inside the IDML. The folder sits beside the InDesign document when collected through Package; it’s not embedded in the IDML package. Send it as a separate folder with an unambiguous match to the IDML. The font reference describes this placement.
Relying on a package summary without checking the folder. The Adobe Community example from April 4, 2024 reports a mismatch between counts and files in one user’s package. The example doesn’t prove that every package has a problem, but it gives the team a concrete reason to check the actual output folder.
Approving substitution because the document opens. An application can use a substitute for a missing face. Opening successfully doesn’t mean the substitute matches the original in line breaks, text fit, or appearance. Ask for a visual comparison and make the approval explicit.
Treating the status in Fonts.xml as proof of recipient access. The IDML resource data can show statuses such as Installed, Substituted, or NotAvailable, but the receiving operator’s environment is what determines whether the referenced font can be used there. Ask the operator to confirm availability on the workstation used for the layout.
Sending the font folder without explaining what it belongs to. A folder of fonts sent among several translated versions can be hard to match to the right IDML. Give the folder and file names a clear relationship, and state that relationship in the handoff message.
Leaving the DTP operator to decide silently. A missing face can lead to a substitution or a request for font access. Ask the operator to report the exact family and face and to flag any planned substitution before final layout approval. The request keeps a technical workaround from turning into an unreviewed design decision.
An IDML handoff is ready when the operator can answer three questions without guessing: which family and face the translated layout needs, where the permitted font files or access instructions are, and how to compare the resolved layout with the intended appearance. The translated IDML preflight checklist can help with the wider delivery review, while DTP mistakes in translated documents covers layout issues beyond fonts.
FAQ¶
Does an IDML file include the fonts used in the InDesign document?¶
No. An IDML records font references in Resources/Fonts.xml, but it doesn’t contain the font data. Send font files separately only when you’re allowed to share them, or provide instructions for authorized access.
How can I identify the exact missing font style in an IDML?¶
Check the family and face separately in Resources/Fonts.xml. AppliedFont names the family, while FontStyle names the face, such as Bold or Semibold Italic. Add the PostScript name if it’s available.
Can the DTP team use a Document fonts folder with an IDML file?¶
A Document fonts folder can accompany the IDML as a separate folder. Keep it beside the matching file, use clear names, and confirm that the font files may legally be shared. The folder doesn’t become part of the IDML itself.
What should I send if I can’t provide the font files?¶
Send the translated IDML, the exact family and face names, the PostScript name if available, and any permitted activation or licensing instructions. Include a reference PDF and ask the operator to report which exact face is unavailable and whether a substitution is planned.
What should I do if InDesign can’t package a font?¶
Check the actual output folder instead of relying only on the package summary. If the required font file isn’t there, confirm whether it can be shared; otherwise, arrange authorized access or agree on a substitute and review the translated layout against the reference PDF.