A translated file can look finished in one app and arrive as a page of empty squares in another. The text may still be there; the receiving program might simply lack a way to draw it.
That distinction matters. Replacing a font can fix a display problem, but it won’t restore characters that were lost when someone saved the file with the wrong encoding. And a font change won’t repair broken Arabic joining if the application can’t shape the script correctly.
The fastest first check is simple: copy the affected passage and paste it into a plain-text editor. Correct characters point toward a font or rendering problem. Garbled characters point toward an encoding or data problem. The sections below explain how to read the clues and what to try next.
What missing glyphs are, and why translation can expose them¶
A character is an abstract text element; a glyph is the visual shape used to display it. Unicode makes that distinction explicit in its Unicode 17.0.0 core specification. A file can therefore contain a valid character even when a particular font can’t draw its shape.
Think of the character as an entry in the text and the glyph as its printed form. The application, operating system, and font work together to turn one into the other. If the font has no matching shape, the application may show a placeholder instead. That placeholder is often called a missing glyph or .notdef.
The Unicode Consortium describes tofu-like squares, boxes with question marks or diagonals, code-point indicators, and blank spaces as possible signs that a font doesn’t support a character. A blank space is less obvious than a box, but it can be just as disruptive: a name or word may appear to have vanished even though the character remains in the file.
Translation can expose a gap in font coverage because the translated text may use letters or marks that weren’t present in the source. A document set in a font that covers its original script might not have the glyphs needed for the target script. A font substitution can also happen when the file opens on a different computer or in a different app.
A common example: an English document uses a font that contains Latin letters, then receives a translation with Cyrillic text. If the selected font doesn’t include the Cyrillic glyphs, the translated characters may appear as squares. The text’s presence and its appearance are separate questions.
As the Unicode Consortium explains:
“When Unicode text is displayed but there is a lack of font support for some characters in the text, the typical symptom is appearance of special character-not-supported or ‘tofu’ glyphs.”
The practical point is that a box doesn’t automatically mean the translator typed the wrong character. First check what the file contains; then decide whether the problem sits in the font, encoding, or rendering software.
Diagnose the problem before changing the file¶
Start by checking whether the affected text is correct in the file’s underlying text data. Changing fonts before making that check can hide the symptom without addressing its cause, or send you down the wrong troubleshooting path.
Copy a small affected passage¶
Select a word or sentence with missing glyphs and copy it into a plain-text editor. Avoid starting with the entire document: a short sample is easier to inspect, and it reduces the risk of accidentally changing the source.
If the pasted text shows the intended letters, the file probably retains the characters. A font or rendering issue becomes the stronger lead. If the pasted text shows different letters, question marks, or the replacement character U+FFFD, investigate encoding or data loss instead.
The test isn’t perfect for every file. Some PDFs don’t offer usable text selection, and some applications copy text differently from what they display. If selection isn’t available, try another viewer or compare the document’s text in its source application.
Compare a second application or device¶
Open the same file in another application, or on another device, and look at the same passage. If the glyphs appear in one place but not another, the text itself is less likely to be missing. The difference points toward application-specific font fallback, installed fonts, or rendering support.
Unicode notes that display failures can result from a missing glyph in the selected font, outdated application-specific font fallback, or an application that doesn’t support recently added characters. Selecting or installing a supporting font can help when the application allows it.
A PDF may also look different from its Word source. A document author may have used a font that isn’t available on the receiving system, or the PDF may not carry the font information the viewer needs. Check whether the source document displays correctly before editing the translated text.
Look at the shape of the failure¶
The appearance of the problem gives you useful clues, but no single clue proves the cause.
| What you see | What it may indicate | First check |
|---|---|---|
| Uniform squares, boxes, or dots | The font may lack glyphs for the script | Copy the text and test a font with script coverage |
| Garbled letters that look like another alphabet | The file may have been interpreted with the wrong encoding | Reopen the source text with an encoding preview |
| U+FFFD in copied or extracted text | A replacement character may have taken the place of unavailable or damaged text | Check an earlier copy or the original source |
| Correct letters with strange joins or misplaced marks | Shaping or font behavior may be faulty | Compare fonts and applications |
| A blank where a mark or control should be | The character may be invisible by design, or the font may not support it | Check the text data before treating the blank as an error |
U+FFFD is the Unicode replacement character. Its presence can signal that a conversion or decoding step couldn’t preserve the intended character, but the display alone isn’t enough to identify when the loss happened. Compare the current file with an earlier version, if one exists.
Invisible controls need special care. The Unicode Consortium notes that characters such as the zero-width joiner, zero-width non-joiner, variation selectors, and zero-width space shouldn’t ordinarily appear as visible missing-glyph boxes. A blank at one of those positions may be expected rather than evidence that a letter disappeared.
The Unicode Consortium’s display guidance lists disconnected cursive letters, incorrect text direction, reordered syllable clusters, and marks attached to the wrong base as possible shaping symptoms.
Those patterns differ from a plain missing-glyph box. A connected script that breaks in the wrong places can have all its characters present while still appearing incorrect.
Keep a clean copy before testing¶
Save a working copy before changing the font, encoding, or normalization of a file. A font change is usually reversible; saving text in a narrower encoding can permanently replace or omit characters.
Record the application and viewer where the issue appears, whether copying the text returns the right characters, and which font you tested. That short note makes it easier to tell a software-specific display problem from a damaged file when someone else opens the document.
Fix font coverage and font fallback¶
When copied text is correct but the screen shows squares, start with the font. The selected typeface may not contain glyphs for every character in the translated text, or the app may not be choosing a suitable fallback.
Select a font that covers the script¶
Select the affected text and choose a font that supports the script and marks it uses. Check the whole passage, not just one letter: a font may cover basic letters but lack a combining mark or a less common character used in a name.
If the document uses several scripts, a single font may not cover all of them. The application might use a fallback font for characters that the main font can’t draw. That substitution can vary by app and operating system, which is why a file may look right on one computer and wrong on another.
Unicode’s general display guidance says that installing or selecting a font with the required support may solve a missing-glyph problem when the application permits it. If the application doesn’t offer a useful font choice, test the file in another app before altering its text.
Check whether the font is embedded¶
A font embedded in a document or PDF can help preserve its intended appearance on systems that don’t have the same font installed. Embedding isn’t a cure for every display problem, and the available options depend on the application and file format. Check the app’s export or save settings rather than assuming every file carries its fonts.
If the receiving system substitutes a font, the substitute may not contain the needed characters. A PDF that uses an unembedded font can therefore look different from the source document. Compare the file in its original application and in a second PDF viewer before deciding that the translation itself is wrong.
Don’t confuse font fallback with missing text¶
Font fallback replaces one font’s drawing role with another font that might contain the needed glyph. It doesn’t recreate characters that have already been lost from the text data.
A useful diagnostic sequence is:
- Copy the affected characters into a plain-text editor.
- Compare the copied characters with the intended text.
- If the copied characters are right, change the font or application and compare again.
- If the copied characters are wrong, keep the original file unchanged and investigate encoding or data loss.
Unicode distinguishes a font-support problem from incorrect encoding, while Microsoft’s guidance explains how an encoding mismatch can produce garbled text. A successful font change after correct copying supports a display diagnosis. A font change that leaves copied text wrong doesn’t repair the underlying data.
Microsoft Support warns that a file may show boxes or dots when the needed font isn’t installed. In its guidance on opening and saving text files, the support page says:
“If almost all the text looks the same (for example, all boxes or all dots), the font required for displaying the characters may not be installed.”
That clue is especially useful when an entire passage or script turns into the same placeholder. Still, check copied text before treating every box as a font issue.
Repair encoding and protect the text data¶
Encoding determines how stored numeric values map to characters. If an application reads those values using the wrong encoding, the result can be garbled even though the original file once contained the right text.
Microsoft gives an example in its Word encoding guidance: interpreting a file under a different encoding can turn Cyrillic Й into Western-European É. A result like that isn’t a missing glyph. The application has mapped the stored values to the wrong characters.
Reopen text files with an encoding preview¶
For a text file opened in Word, Microsoft advises reopening it through the Encoded Text option and testing another encoding with the preview. Use the preview to find a setting that displays the text correctly before opening or saving the file.
Don’t pick an encoding just because its name mentions the language. A file can contain several scripts, and a narrow encoding may not support all of them. Microsoft explains that Word saves files as Unicode by default when no other encoding is chosen, and Unicode text can be opened on an English-language system while containing Greek, Cyrillic, Arabic, or Japanese text.
Save a Unicode copy when the file needs multiple scripts¶
Unicode is useful when a file contains different writing systems. Microsoft advises saving text with Unicode encoding to avoid encoding and decoding problems. A narrower encoding may not preserve every character: Microsoft notes that a Cyrillic encoding can’t preserve Hebrew characters in the same file, and vice versa.
Before saving as encoded text, inspect the preview. Microsoft says Word marks characters in red if the selected encoding can’t save them. Red characters are a warning to stop and choose a format that preserves the text, rather than saving and hoping the display problem will disappear.
Saving can also remove text for reasons unrelated to the visible font. Microsoft notes that text formatted in the Symbol font or stored in field codes is removed when a file is saved as encoded text. That loss is different from a display-only font problem, so keep a source copy and check the saved file after conversion.
Treat normalization as a targeted repair, not a universal fix¶
Unicode text can represent canonically equivalent forms in different ways. A character might appear as one precomposed character or as a sequence that combines a base character with a mark. Unicode’s normalization FAQ explains that normalization gives equivalent representations a consistent form.
Unicode recommends NFC for general text. The same FAQ warns that NFKC and NFKD remove compatibility distinctions and can lose information, so those forms are better suited to restricted domains such as identifiers. Don’t apply compatibility normalization blindly to a translated document: a transformation that changes distinctions may alter the text rather than fix its appearance.
Normalization is worth investigating when equivalent text behaves inconsistently across a system that handles Unicode differently. It won’t add missing glyphs to a font, correct the wrong encoding, or restore text that a previous save already discarded.
Repair Arabic, Indic, and other shaped text¶
Some scripts need more than a font that contains individual character shapes. A shaping engine works out how characters combine, connect, change form, or position marks when text is rendered. If that process fails, every character can exist in the file while the word still looks broken.
Arabic text can appear disconnected when joining behavior isn’t handled correctly. Direction can also be wrong. Indic text may show reordered syllable clusters, or marks may attach to the wrong base character. Unicode lists these kinds of failures as signs that shaping support may be inadequate.
Change fonts, then test the application¶
Try a different font first, because a font limitation or bug can cause script-formation problems. Keep the same text and compare the result in the same application so that only the font changes.
If a different font doesn’t help, open the text in another application or on another system. If the same shaping issue persists with different fonts from different vendors, Unicode says a software problem becomes a stronger possibility than a fault in one individual font.
That comparison gives you a practical way to separate causes:
| Test result | More likely explanation | Next move |
|---|---|---|
| One font breaks the text, another displays it correctly | A font limitation or bug | Use the working font and check the output after saving |
| Several fonts break it in one app, but another app displays it correctly | An application-specific rendering or shaping problem | Use the working app or check for a supported update |
| Several fonts and apps show the same broken characters, and copied text is garbled | Encoding or data damage | Compare with the original and repair the text data |
| Several fonts and apps show the same shaping fault, but copied text is correct | A broader shaping-support issue | Test another operating system or a tool with suitable script support |
The table points to troubleshooting paths, not a guarantee. A document may have more than one issue, such as a font that lacks a mark and an application that handles direction poorly.
Don’t make invisible controls visible¶
Zero-width joiners and non-joiners can affect how text is shaped without appearing as visible characters. A variation selector can influence how a preceding character is displayed. The Unicode Consortium says such default-ignorable characters shouldn’t ordinarily be shown as visible missing-glyph boxes.
Removing invisible characters to make a string look tidier can change its behavior. Before deleting anything, compare copied text, test a different rendering environment, and check whether the control character belongs in that script or sequence. A visible box for a normally invisible character may itself indicate a rendering problem.
Check web pages separately¶
A web page can rely on fonts installed on the reader’s device, and a browser might not have a suitable font available. For web content with missing glyphs, Unicode advises authors to control display with CSS web fonts rather than assume that each reader’s browser or operating system has the necessary font.
For a reader, compare the page in another browser or device and check whether the same text appears correctly elsewhere. For a site owner, test the font’s script coverage and provide appropriate web-font support. A web page and a translated Word file may show similar boxes, but their font delivery paths differ.
Common mistakes and a practical check before delivery¶
The most expensive troubleshooting mistake is changing several things at once. If the font, encoding, application, and source text all change together, a successful result won’t tell you what fixed the issue. Work from a copy and change one variable at a time.
Replacing the font before checking the copied text¶
A font change can fix correct characters that lack glyph support, but it can’t reliably repair garbled text. Copy the passage first. If the copied characters are wrong, preserve the original and investigate encoding before changing the layout.
A second common mistake is assuming that every blank means a character vanished. A blank can represent an unsupported glyph, but whitespace and default-ignorable characters are exceptions. Check the text data and the role of the character before inserting a visible symbol.
Saving in a narrower encoding to make the preview look right¶
A preview that looks acceptable for one script may hide characters that the chosen encoding can’t preserve elsewhere in the document. Microsoft warns that Cyrillic and Hebrew text can’t both be preserved by the corresponding narrow encodings. Inspect the full preview and use Unicode when the text needs multiple scripts.
Saving as encoded text also carries a separate risk for Symbol-font text and field codes, which Microsoft says can be removed. Keep a source copy, confirm the encoding, and inspect the saved result before sending it on.
Applying NFKC or NFKD to every translated file¶
Compatibility normalization can collapse distinctions. Unicode recommends NFC for general text and says NFKC and NFKD may lose information. A normalization pass isn’t a safe substitute for finding out whether the actual problem is a missing font, incorrect encoding, or weak shaping support.
Sending a PDF without checking another viewer¶
A PDF can look correct on the creator’s computer and different on the recipient’s. Test the final file in a second viewer and compare it with the Word source, if one exists. If text selection works, copy the affected passage and inspect the result before recreating the translation.
The Unicode Consortium’s normalization FAQ says:
“NFC is the best form for general text, since it is more compatible with strings converted from legacy encodings.”
That recommendation gives you a sensible default for general text, not permission to normalize blindly. Preserve a copy of the source and use a targeted change when the evidence points to a normalization issue.
Use a delivery checklist¶
Before handing over a translated file, run through this short check:
- Inspect the target script. Look at letters, combining marks, punctuation, and names, not just the first line.
- Copy a suspect passage. Confirm that pasted text contains the intended characters.
- Compare fonts or viewers. Check whether a different font or application changes the display.
- Check encoding before saving text files. Use the application’s preview and avoid a narrow encoding for mixed scripts.
- Review shaped text. Check Arabic joining, text direction, Indic syllable order, and mark placement.
- Inspect the delivered file. Reopen the saved or exported version in a separate viewer and compare it with the source.
A real-world-style example helps make the sequence concrete without guessing at the cause. Suppose a translated name appears as squares in a Word file. Copy the name into a plain-text editor. Correct letters point to font coverage; garbled letters point to encoding or data damage. If the letters are correct but Arabic joining is broken, test another font and application. Each result narrows the next step without altering the text prematurely.
The same method applies to a PDF with missing characters. Try selecting and copying a short passage, open the PDF in another viewer, and compare it with the source document. If the extracted characters are correct but the page shows boxes, investigate font support. If the extracted characters are wrong, go back to the source text or an earlier saved copy.
FAQ¶
Why do translated documents show squares instead of letters?¶
A translated document can contain valid characters that the selected font can’t draw. The Unicode Consortium calls the resulting placeholders tofu-like glyphs and lists boxes, question marks, code-point indicators, and blank spaces among possible signs of missing font support. Copy the text to check whether the characters themselves are intact.
How do I fix missing glyphs in a translated Word document?¶
Copy a short affected passage into a plain-text editor. Correct copied characters suggest a font or rendering issue, so test a font with coverage for the target script; garbled copied characters suggest an encoding or data problem. Save a copy before making changes.
Why are characters missing from a translated PDF?¶
A PDF can show missing glyphs when the viewer can’t access a suitable font, or when the text data is damaged. Compare the PDF in another viewer, check the Word source if available, and copy a short passage to see whether the extracted characters are correct. A blank may also be an invisible control rather than a lost letter.
How can I tell whether missing text is caused by encoding or a font?¶
Copy the affected text. Correct characters paired with boxes or faulty shapes point toward font support or rendering; garbled letters or U+FFFD point toward encoding or data loss. Microsoft documents how a wrong encoding can map stored values to unintended characters.
Why does Arabic or Indic text look disconnected after translation?¶
Arabic and Indic scripts need shaping behavior that controls connections, character forms, direction, syllable order, and mark placement. Test another font first; if the same issue persists across fonts from different vendors, compare applications because the problem may sit in the software’s shaping support rather than in one font.