Multilingual Font and Encoding Problems in Documents

A Vietnamese name that looks fine on your screen can lose a mark in a PDF viewer, while an Arabic paragraph can show every letter but fail to connect them. Those failures look like “font problems,” but they don’t all have the same cause.

A multilingual document passes text through several layers: character data, font selection, script shaping, and the application or viewer that draws the page. A failure in any one layer can change what people see, copy, search, or print. Treating every problem as an encoding issue sends you to the wrong fix.

What multilingual font and encoding problems actually mean¶

A font and encoding problem is a mismatch between a document’s text data, the font’s available glyphs, and the software’s ability to display the relevant writing system. The word “encoding” often gets used for all of these failures, even when the character data is correct.

Unicode’s display guidance separates three broad kinds of display problems: missing font support, incorrect shaping, and incorrect or garbled characters. The distinction matters because a font change won’t repair corrupted text, and re-saving a file in UTF-8 won’t make a font draw a character it doesn’t contain. Unicode describes these separate problem types.

A character is an abstract item of text, such as a letter or punctuation mark. A glyph is the shape a font draws to represent that character. One character can have different glyph shapes depending on context, and a font may not contain a glyph for every character in a document.

A character encoding maps text characters to bytes so software can store or transmit them. Unicode defines characters and UTF formats for representing them; it doesn’t guarantee that every font includes every glyph or that every application shapes every script correctly.

The practical symptoms fall into three groups:

The table is a starting point, not a verdict. A PDF viewer may render the page differently from a word processor, and a page that looks right can still have a faulty text layer. Check how the content behaves as well as how it looks.

Unicode calls a generic missing-character glyph a “.notdef” glyph. In everyday use, the missing character may appear as a white square, a box with a question mark, a box with a diagonal mark, a hexadecimal code point, or an empty space. Unicode’s display guidance explains these missing-character symptoms.

As Unicode describes the symptom: “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.”

“Tofu” is the informal name for the empty replacement boxes that can appear where characters should be. A box is a clue that a font or fallback path may not have supplied a glyph; it does not by itself prove that the text bytes are damaged.

How text, fonts, and shaping interact¶

Understanding the layers makes diagnosis much faster. The same visible failure can come from different stages, so trace the document from its text data through the font and the application that displays it.

Unicode characters and UTF encodings¶

UTF-8, UTF-16, and UTF-32 can all represent Unicode characters, but they use different byte or code-unit sequences. The Unicode FAQ describes UTF-8 as using one to four 8-bit bytes per character, UTF-16 as using one or two 16-bit code units, and UTF-32 as using one 32-bit code unit. These are fixed format properties, not version-dependent usage figures. Unicode’s FAQ explains the UTF formats.

The software reading a file needs to interpret its bytes using the right encoding. If a program decodes valid bytes using the wrong encoding, the result can be mojibake: readable-looking but incorrect symbols where the intended text should be. Converting the text correctly between UTF formats can preserve its characters; decoding it incorrectly can change what the software sees.

Malformed UTF-8 sequences aren’t valid characters. A conformant process must not treat ill-formed sequences as characters; software may report an error, filter bytes, or insert U+FFFD REPLACEMENT CHARACTER during recovery. Unicode documents the behavior of ill-formed UTF sequences.

That replacement character is a visible clue, but it doesn’t tell you where the damage happened. The text might have been corrupted during export, transfer, or import, or the wrong decoder might be interpreting valid bytes. Keep an unchanged copy of the source before testing conversions.

Font coverage and fallback¶

A font file contains outlines or other drawing data for particular glyphs. Font coverage means the range of characters a font can display. A document can contain correct Unicode characters that the selected font doesn’t cover.

When that happens, an application may choose another font for the unsupported characters. This process is called font fallback. The fallback font may draw the missing glyph, but its letterforms, weight, baseline, or spacing can differ from the surrounding text.

The operating system and application both affect font selection. A recipient may not have the same font installed, and different software can have different fallback behavior. Unicode notes that choosing a font with the required coverage, or selecting it explicitly where the application permits, can resolve some missing-character problems. Unicode’s guidance covers font availability and fallback.

A particularly confusing symptom is a blank space. Blank output can mean the selected font lacks a glyph, but invisible Unicode characters can also be intentionally zero-width. Unicode says unsupported default-ignorable characters, including zero-width joiners and non-joiners, bidirectional controls, variation selectors, and zero-width space, should generally remain invisible and zero-width. Their invisibility alone doesn’t prove corruption. Unicode’s FAQ explains unsupported default-ignorable characters.

Shaping for Arabic and Indic scripts¶

Shaping is the process that selects the correct glyph forms and positions marks according to a script’s rules. Some writing systems can’t be displayed correctly by drawing each character as an isolated, fixed shape.

Arabic letters can change form depending on their position in a word and connect to neighboring letters. Indic writing systems can use conjuncts, where characters combine into forms, and marks that need precise placement. A shaping engine in the application works with the font to produce the text people read.

A shaping failure can leave the expected characters recognizable while making their forms wrong. Arabic letters may not connect; Indic conjuncts or marks may appear incorrectly. Unicode identifies both software shaping support and font limitations or bugs as possible causes. Unicode’s display guidance describes shaping failures.

Character choice matters too. Unicode gives legacy Arabic Presentation Forms as an example of text that may appear correct in a particular application but use non-interoperable characters. Ordinary Arabic text needs the appropriate underlying characters so software can apply contextual forms; using presentation-form characters instead can prevent the normal shaping process. A page that looks right in one place isn’t proof that its text is encoded appropriately for other software.

The PDF page and its text layer¶

A PDF can contain a visible page and a separate representation of text used for selection, copying, searching, and extraction. Those layers can disagree. A viewer may draw the intended shapes while the underlying character mapping is missing or wrong.

A ToUnicode mapping connects a displayed PDF character or glyph with Unicode text. When that mapping is absent or inaccurate, selecting the text can return gibberish even though the page looks correct. Embedding a font and mapping text to Unicode address different parts of the problem: a font helps the viewer draw glyphs, while a text mapping helps software identify characters.

A Mozilla PDF.js issue illustrates why one-viewer tests aren’t enough. A reporter said a Vietnamese PDF worked in Chrome but lost some characters in PDF.js. The discussion found that the affected font had blank glyph slots for two characters, and the behavior varied across software and platform combinations. The PDF.js issue records the report and investigation.

The reporter described the contrast: “I have a PDF document using the font ‘UVN Hong Ha Hep’. My PDF file works well when viewed in Chrome, but some characters are missing when using PDF.js.”

The useful lesson isn’t that one viewer is always right. The same file can behave differently depending on the PDF viewer, browser, operating system, and font. Test the actual file in the software recipients use, then check text extraction separately.

How to diagnose a multilingual document problem¶

A reliable diagnosis compares the same text in more than one way. Use an untouched copy of the file, change one variable at a time, and note whether the problem affects display, editing, search, copying, or printing.

1. Record the symptom. Note the exact characters, script, file type, application, and point where the problem first appears. A missing mark in a PDF after export is a different clue from garbled text that appears as soon as a text file opens.

2. Compare the source application with another viewer. Open the same file on another suitable application or platform. If one viewer draws the text correctly and another doesn’t, the difference may involve font availability, fallback, rendering, or shaping rather than damaged source text.

3. Copy or extract the affected text. Paste it into a plain-text editor or use the PDF viewer’s text selection. Compare the extracted characters with the intended text. Correct extracted text with broken visual display points toward rendering or glyph coverage; incorrect extracted text means the text layer or character data needs attention.

4. Check the encoding where the file format makes it relevant. For a plain-text export or data file, confirm that the writing program and reading program agree on the encoding. Don’t assume that changing an encoding label repairs bytes that were already decoded or saved incorrectly.

5. Check the font and its coverage. Confirm that the font is installed and selected in the application, and that it covers the affected characters. Try a known font that supports the script. If only certain characters change, compare those characters with the font’s available glyphs rather than replacing every font in the document.

6. Test shaping and direction. For Arabic or Indic text, check whether letters connect, marks sit correctly, and the order makes sense. Test in an application with script support and compare the result; replacing the font alone may not fix a shaping-engine problem.

7. Check PDF appearance and text extraction independently. Inspect the page visually, then copy, search, or extract a sample. Correct appearance does not guarantee a correct text mapping, and correct extracted text does not guarantee that every viewer can draw the glyphs.

8. Make one controlled correction and retest. Change the font, encoding, export settings, or application only after the checks point to that layer. Reopen the saved file in the recipient’s likely software and repeat the visual and text checks.

The sequence reflects distinctions in Unicode’s display guidance, Microsoft and LibreOffice font documentation, and the PDF.js report. It avoids a common time sink: repeatedly changing fonts when the actual issue is corrupted character data, or repeatedly converting encodings when the font simply lacks a glyph.

How can I tell font problems from encoding problems?¶

Copy the affected content into a plain-text editor and compare the characters with the original. If the copied text is correct but the document shows boxes or blanks, investigate font coverage, font availability, or rendering. If copied text is garbled too, inspect the underlying characters and, for formats that expose it, the encoding.

The check isn’t absolute. A PDF can have a faulty text mapping even when its page looks right, and an application can render a character correctly while copying the wrong value. For PDFs, compare visible output and extracted text as separate tests.

Why does text look right but copy and paste as gibberish?¶

PDF display and text extraction don’t always use the same information. A PDF may draw a font’s glyphs in the correct positions but lack a reliable mapping from those glyphs to Unicode characters, so copied text becomes incorrect.

Test more than one viewer and compare a short extracted sample with the source. If the visible page looks correct in all tested viewers but the selected text is wrong, focus on the PDF’s text layer and character mapping rather than changing the page’s font.

As Unicode explains: “The content might not be using the appropriate Unicode characters for the text, or it might not be using appropriate character sequences to represent certain text elements.”

The point is broader than an incorrect byte decoder. A document may contain the wrong Unicode characters or the wrong sequence of characters for a text element, even if one application can make the result look plausible.

How to make Word and PDF files more portable¶

Portability means that recipients can read, edit, search, and print a document consistently in their own software. No single setting guarantees that outcome, but good font choices, permitted font embedding, and cross-viewer testing reduce common surprises.

Choose fonts for all scripts in the document¶

A multilingual file may use different fonts for Latin, Asian, and complex scripts. A font that handles the English paragraphs might not cover accented names, Cyrillic text, Arabic, or Indic writing. Check the actual characters in the file, not just the language named in the font menu.

LibreOffice’s font embedding dialog separates Latin, Asian, and Complex font scripts. That separation is a reminder to check the categories relevant to the document rather than assuming one Latin font setting covers every script. LibreOffice describes its font embedding options.

When a recipient’s system lacks a font, a word processor may substitute another one. The text can remain editable, but changes in glyph widths and metrics can shift line breaks, table cells, page breaks, or headings. Inspecting only the first page can miss a layout change lower in the document.

Embed fonts in Office documents when the workflow allows¶

Embedding stores font data in a document so a recipient who lacks the font can still view it with the intended appearance. Microsoft says font embedding can preserve font, layout, and styling and can prevent special characters from turning into rectangles. Embedded fonts increase file size, and font creators can restrict embedding. Microsoft explains the benefits and limits of font embedding.

Office can embed only the characters used in a document or embed all characters. Embedding only used characters reduces file size, but limits a recipient’s ability to edit the file with the same font. Embedding all characters is the more suitable choice when recipients may add or change text, provided the font’s permissions allow it. Microsoft’s guidance describes these options and the relevant restrictions. Check Microsoft’s documentation before choosing an embedding setting.

A font may be marked non-embeddable, preview-and-print only, editable, or installable. Those permissions come from the font creator, so the fact that an application offers an embedding control doesn’t mean every font can be embedded for every use. Check the font’s permissions and the recipient’s editing needs before sharing the file.

Microsoft notes that Office cloud fonts are available to Office subscribers with internet access. Cloud font availability doesn’t guarantee that every recipient has access to a custom font, especially when a recipient works offline or uses a non-standard font. Microsoft’s font embedding guidance discusses cloud fonts and embedding.

Microsoft says: “Some Microsoft 365 apps let you embed fonts in your documents. That way, if you share your document with someone else who doesn’t have the same fonts installed that you do, the fonts, layout, and styling of the document won’t change, and special characters won’t turn into meaningless rectangles.” Read the Microsoft explanation.

Embedding is a useful portability option, not a universal fix. It can preserve a font’s appearance where supported, but won’t correct wrong underlying characters, repair a faulty shaping process, or guarantee that text extraction from a PDF is accurate.

Understand what substitution does¶

Substitution replaces a missing font for display or printing. It can keep text visible, but the replacement font may have different proportions or lack the same glyphs. Substitution isn’t the same as changing the font saved in the original document.

LibreOffice offers a font replacement table that can substitute unavailable fonts on screen, in print, or both; the replacement doesn’t change the font setting saved in the document. That distinction helps explain why a file can look acceptable on one computer and shift on another. LibreOffice documents its font replacement table.

Microsoft’s modern font picker in Word for the web and PowerPoint for the web can flag missing fonts. When an unavailable font is replaced for viewing, Microsoft says the replacement doesn’t change the font applied to the text, though the replacement may alter the design and layout. Microsoft explains missing fonts in the modern font picker.

Treat a substitution warning as a prompt to inspect the document, not as proof that the file is repaired. Check line breaks, tables, page layout, special characters, and any text that must remain editable. If a recipient needs an exact design, agree on an available font or provide a PDF as a visual reference alongside the editable file.

Export and test PDFs for both appearance and text¶

A PDF can preserve the appearance of a page across systems, but that appearance doesn’t prove the text layer is sound. Export from the source application with the intended fonts available, then check the resulting PDF for visible glyphs and usable text selection.

Test the specific scripts and characters that matter: accented names, punctuation, currency symbols, combining marks, or non-Latin passages. Copy a short sample into a plain-text editor, search for a known word, and compare the extracted text with the source. If the visual page is correct but extraction fails, investigate the PDF’s character mapping rather than assuming that font embedding will fix it.

A font embedded in a PDF can help a viewer render its glyphs without relying on the recipient’s installed font. The result still depends on how the PDF was made and how the viewer handles its text. The PDF.js case shows that a particular font and viewer combination can behave differently from another combination, even with the same document.

What commonly goes wrong when sharing multilingual files¶

The costliest mistakes come from treating a visible symptom as a complete diagnosis. Check the layer that failed before making changes that can affect the rest of the document.

• Changing the encoding to fix empty boxes. Empty boxes often point to missing glyph support or font selection. If copying the text gives correct characters, start with font coverage and rendering rather than converting the entire file.

• Changing the font to fix garbled text. A new font can change glyph appearance, but it doesn’t rewrite corrupted character data. If copied text is wrong, investigate the source text, decoder, or conversion path.

• Assuming one viewer proves the PDF is correct. The Vietnamese PDF described in the PDF.js issue appeared correctly in Chrome but lost characters in PDF.js; the investigation also found variation across software and platforms. Test the file in the viewers your audience is likely to use.

• Assuming a visible Arabic form is the right character. Legacy Arabic Presentation Forms can look correct in a particular application while failing to behave like ordinary Arabic text. Check the underlying Unicode characters and let suitable software handle contextual shaping. Unicode explains the issue.

• Embedding a font without checking its permissions. Font creators can restrict embedding, and Office documents can become larger when they include font data. Confirm the font’s permissions and decide whether recipients need to edit the document before choosing an embedding option. Microsoft outlines embedding restrictions and options.

• Embedding only the characters used when recipients need to add text. That setting can reduce file size, but it may limit editing with the embedded font. Microsoft’s guidance distinguishes embedding used characters from embedding all characters for this reason. Review the Office embedding options.

• Confusing invisible control characters with missing glyphs. Zero-width joiners, non-joiners, and bidirectional controls may be invisible by design. Their absence from the page isn’t enough to diagnose corruption; check how they affect the surrounding text and whether the sequence is appropriate. Unicode lists default-ignorable characters.

• Assuming a substituted font changes the document itself. LibreOffice’s replacement table can change what appears on screen or in print without changing the font setting saved in the document. Check the file on the recipient’s system rather than relying on a local substitution. LibreOffice documents that distinction.

A practical handoff checklist helps catch these failures before a file leaves your team:

The checklist is a way to make verification repeatable, not a promise that every application will render every file identically. When accuracy matters, preserve the source, test the recipient-facing file, and state which application or format is the reference for visual layout.

FAQ¶

How can I tell whether missing characters are caused by a font or by character encoding?¶

Copy the affected text into a plain-text editor and compare it with the intended characters. Correct copied text with missing boxes on screen points toward font coverage, font availability, or rendering; garbled copied text points toward the text data, decoding, or a PDF mapping problem.

Why does multilingual text look correct in a PDF but copy and paste as gibberish?¶

The PDF’s visible glyphs and its text mapping are separate. A viewer can draw the intended shapes while copied or extracted text is wrong because the mapping from displayed characters to Unicode is missing or inaccurate.

How do I prevent font substitution when sharing a Word document?¶

Choose fonts that cover every script used in the file, then embed them if the font permissions and recipient’s workflow allow it. Check the document on another system because embedding can increase file size, some fonts restrict embedding, and a recipient may need all characters embedded to edit the text with the same font.

Why do Arabic or Indic characters appear disconnected or in the wrong order?¶

Arabic and Indic text needs shaping: software and fonts work together to choose context-sensitive forms and place marks. A font limitation, unsupported shaping behavior, or unsuitable underlying character sequence can leave letters disconnected or marks misplaced.

Can embedding fonts fix multilingual PDF display and text extraction problems?¶

Embedding can help a viewer draw glyphs when the recipient doesn’t have the font, but it doesn’t automatically repair incorrect character data, script shaping, or a PDF’s text mapping. Test page appearance and copied or extracted text separately.