How People Translate Quickly | Font Glyph Coverage and Fallback QA: Prevent Missing Characters, Tofu Boxes and Mixed-Typeface Breakage Across Scripts

People searching font fallback, missing glyph, tofu boxes font, glyph coverage, international font support, font fallback localization, Unicode font missing characters, or multilingual typography QA are usually dealing with a problem that appears after the translation is already correct: the target contains valid Unicode characters, but the chosen font cannot draw them. The product then shows empty squares, replacement boxes, mismatched fallback typefaces, broken combining marks, clipped diacritics, or a sentence that suddenly switches visual style halfway through.

Modern text systems normally use font fallback or font linking when the preferred typeface lacks a glyph. Current platform documentation describes multilingual font support, composite fonts, Unicode coverage, and fallback chains designed to avoid missing-glyph boxes. But automatic fallback is not the same as typographic quality. A system may successfully render Arabic or Devanagari using a fallback font while breaking brand style, weight, line height, shaping, or visual hierarchy. The current query family therefore points to one reader job: prove that every supported script has a deliberate glyph-and-fallback path, not merely a lucky operating-system substitute.

This article has one dominant job: build a font glyph-coverage and fallback QA workflow that prevents translated text from becoming unreadable or visually inconsistent when the primary font does not support the target script. It does not replace target-script QA, which checks whether the right script is present, and it does not replace pseudolocalization, which can expose some font problems before real translation. This page owns the typography-resource layer: glyph coverage, font fallback chains, combining marks, shaping, weight/style matching, line metrics, downloaded fonts, platform differences, and visual regression.

Quick answer

A reliable multilingual font workflow is:

1. list every script and writing system the product officially supports;
2. test the real production font files for representative glyph coverage;
3. define an explicit fallback stack instead of relying only on whatever font the operating system chooses;
4. verify normal, bold, italic, and UI weight variants;
5. test combining marks, punctuation, digits, symbols, and emoji separately from base letters;
6. test shaping scripts such as Arabic and Indic text in the actual rendering engine;
7. compare line height, baseline, width, and x-height/cap-height relationships between primary and fallback fonts;
8. run real-language screenshots on each supported platform and browser/device family;
9. fail or alert when a released font bundle loses previously supported glyphs;
10. treat typography defects as rendering/internationalization defects, not as reasons for translators to replace correct characters.

The central rule is:

the target language should not have to change because the chosen font cannot display it.

Characters, glyphs, and fonts are different things

Unicode defines characters.

A font provides glyphs—visual shapes—for some of those characters.

The renderer maps text to glyphs using:

• font coverage;
• shaping rules;
• fallback;
• OpenType features.

A character can be perfectly valid Unicode and still have no glyph in the selected font.

That is where the square box appears.

What “tofu” means

The missing-glyph box is often called tofu because it resembles a small square block.

It can appear as:

• empty square;
• square with code point;
• replacement symbol;
• blank space.

To the user, all are failures.

The translation exists.

The typography pipeline cannot render it.

Worked example 1: Latin-only brand font

A product uses a custom Latin brand typeface.

English looks beautiful.

Japanese target arrives.

The font lacks:

• kana;
• kanji.

The browser falls back to a system Japanese font.

The text becomes readable.

But headings now mix:

• branded Latin glyphs;
• system Japanese glyphs.

This may be acceptable if deliberately designed.

It may look inconsistent if not.

Fallback prevented tofu but did not automatically preserve visual identity.

Step 1: inventory supported scripts

Start from product locales.

Map each to scripts.

Example:

• en-US → Latin;
• fr-FR → Latin;
• ru-RU → Cyrillic;
• ar-AE → Arabic;
• hi-IN → Devanagari;
• ja-JP → Han + Hiragana + Katakana + Latin;
• ko-KR → Hangul + Han/Latin as needed.

Do not stop at languages.

Font coverage is a script/glyph problem.

Step 2: define representative test strings

For each script, create a fixture containing:

• common letters;
• diacritics;
• punctuation;
• digits;
• currency;
• symbols;
• combining sequences.

Use real words, not only alphabet charts.

Real shaping reveals more.

Step 3: test font files, not marketing claims

A font website may say:

supports Latin Extended.

Which characters exactly?

Inspect the actual font file shipped in production.

Different weights or subsets can have different coverage.

A webfont subset may omit glyphs that exist in the desktop master font.

Step 4: test every weight

Regular supports: Ł

Bold does not.

The browser falls back only for one character in a bold heading.

Result: visual mismatch.

Test:

• regular;
• medium;
• semibold;
• bold;
• italic.

Whatever the product actually uses.

Step 5: test webfont subsetting

Web performance pipelines often subset fonts.

This is valuable.

It can also remove target-language glyphs accidentally.

Example:

Build pipeline creates Latin subset for all users.

Japanese locale downloads the same file.

Fallback hides the missing coverage in developer testing.

Production brand font never renders Japanese.

Locale-aware font loading can solve this.

Step 6: define a fallback stack

CSS example conceptually:

font-family: BrandLatin, NotoSansCJK, system-ui, sans-serif;

The exact stack depends on product licensing and platforms.

The important part is intention.

Do not leave:

BrandLatin, sans-serif

and hope every OS chooses a visually compatible font.

Fallback order matters

The renderer selects the first font that can supply a glyph.

If a broad symbol font appears too early, it may unexpectedly render:

• punctuation;
• Latin letters;
• emoji

with the wrong appearance.

Build the chain deliberately.

Step 7: use script-appropriate fallback

A single global fallback font can be enormous.

Another strategy:

• Latin stack;
• Arabic stack;
• CJK stack;
• Indic stack.

The locale or script can select the appropriate family.

This reduces download size and improves visual control.

Step 8: test line metrics

Two fonts can share the same CSS size and have different:

• ascender;
• descender;
• line gap;
• visual x-height.

Fallback text can:

• look too small;
• look too large;
• clip vertically;
• increase row height.

Test actual components.

Worked example 2: clipped Vietnamese marks

A custom font nominally supports Vietnamese.

The UI button has fixed line height.

A stacked diacritic reaches above the Latin ascender.

The glyph clips.

The character exists.

The layout still fails.

Glyph coverage and line metrics must be tested together.

Step 9: test combining marks

Some fonts support a base character but poorly position combining marks.

Test:

• decomposed accents;
• multiple combining marks;
• target-language diacritics.

Normalization to NFC may reduce some decomposed sequences, but not every character has a precomposed form.

Good font shaping must handle combining marks.

Step 10: test canonical equivalents

If the product may receive both NFC and NFD text, render both.

They should look equivalent.

A font/rendering bug that handles only precomposed characters can expose normalization assumptions.

Unicode normalization and glyph QA complement each other.

Step 11: test Arabic shaping

Arabic letters change shape depending on context.

A font needs:

• correct glyphs;
• shaping support through the text engine.

A font can contain Arabic code points but render poorly if OpenType shaping data or engine support is broken.

Test full words and sentences.

Do not test isolated letters only.

Step 12: test Arabic marks

Arabic can include:

• vowel marks;
• Quranic/educational marks in specialized content.

If the product supports marked text, test it specifically.

Marks can collide or clip.

Step 13: test Indic shaping

Devanagari and other Indic scripts can form conjuncts and reorder marks visually.

Glyph coverage alone is insufficient.

Use real target-language words that exercise:

• matras;
• conjuncts;
• reph/marks as relevant.

The shaping engine and font must cooperate.

Step 14: test Southeast Asian scripts

Thai, Khmer, Myanmar, Lao, and others can use:

• stacked marks;
• complex positioning;
• script-specific line metrics.

A “Unicode font” label is not a QA result.

Render real content.

Step 15: test CJK

CJK fonts have huge glyph repertoires.

A product can choose different families for:

• Simplified Chinese;
• Traditional Chinese;
• Japanese;
• Korean.

Unified Han code points can have locale-preferred glyph forms.

The font/language context matters.

Do not assume one CJK font is typographically appropriate for every locale.

Step 16: language-aware Han glyph selection

The same Unicode character can have typographic variants preferred in:

• Japanese;
• Simplified Chinese;
• Traditional Chinese;
• Korean.

A locale-specific font stack helps render culturally expected glyph forms.

This is a font selection issue, not a translation-string issue.

Step 17: test punctuation

A fallback font may take over only:

• quotes;
• dashes;
• bullets;
• currency symbols.

The sentence then shows subtle mismatches in stroke weight or baseline.

Include punctuation in visual QA.

Step 18: test currency symbols

Symbols such as:

• ₹;
• ₩;
• ₫;
• ₺;
• ₴

may be missing from a custom brand font.

Fallback can render them with visibly different metrics.

Financial UI should test all supported currencies.

Step 19: test mathematical and technical symbols

Technical translation can include:

• Greek letters;
• arrows;
• degree sign;
• micro sign;
• mathematical operators.

A general UI font may have partial coverage.

Use a compatible symbol/math fallback where needed.

Step 20: emoji are a separate font/color-glyph problem

Emoji often use dedicated color fonts.

Do not expect the text font to contain them.

Test:

• emoji next to target script;
• baseline;
• line height;
• variation selectors.

Emoji fallback is part of modern multilingual typography.

Step 21: test variation selectors

Some Unicode characters can request text or emoji presentation.

A font stack can render them differently.

If product copy depends on a particular presentation, include the correct sequence and test the target platforms.

Step 22: test symbol fallback before text fallback

Some systems choose symbol fonts for characters the primary font lacks.

This can be correct for icons.

It can also cause punctuation or letters to come from a visually incompatible symbol family.

Inspect computed fonts where the browser/devtool supports it.

Step 23: inspect which font actually rendered the glyph

A CSS declaration tells you the requested stack.

The browser may select different fonts per character.

Use developer tools or font-inspection APIs to identify the actual rendered font.

This turns:

“The Arabic looks strange”

into:

“This word is falling back to system font X because BrandArabic-Bold lacks U+XXXX.”

That is actionable.

Step 24: platform differences

The same fallback stack can produce different results on:

• Windows;
• macOS;
• Android;
• iOS;
• Linux.

Why?

Different installed system fonts and rendering engines.

Test production platforms.

Step 25: browser differences

Browsers mostly rely on OS shaping/font systems, but behavior can differ in:

• font loading;
• fallback timing;
• variable fonts;
• color glyphs.

High-traffic web products should include cross-browser samples for target scripts.

Step 26: downloaded font failure

A webfont can fail because of:

• network;
• CORS;
• CSP;
• preload mistake;
• cache.

Fallback should remain readable.

The product should not show invisible text while waiting indefinitely for a font.

Step 27: font-display behavior

Web font loading policies can produce:

• invisible text;
• fallback first;
• late swap.

A late font swap can change:

• line wraps;
• button width;
• layout.

Localization visual QA should test both loaded and fallback states for constrained UI.

Step 28: fallback can change text width dramatically

Source font: compact.

Fallback font: wide.

A translated label that fit during screenshot review can overflow when the brand font fails to load.

Layout should tolerate the fallback stack too.

Step 29: missing glyph inside an otherwise supported script

A font may support 99% of Cyrillic but miss one extended character used by a minority language.

Do not say:

“Cyrillic works.”

Test the actual language repertoire.

Script coverage is not binary.

Step 30: minority-language support needs explicit glyph sets

If the product adds:

• Kazakh;
• Kyrgyz;
• Sami;
• Yoruba;
• Māori;

check the exact diacritics and letters.

A Western European Latin font may not cover them all.

Locale launch checklists should include glyph repertoire.

Step 31: build a per-locale glyph fixture

For each locale, store a small string containing:

• alphabet-specific characters;
• common diacritics;
• digits;
• punctuation;
• currency.

Render every fixture in every product font weight.

Automate screenshots.

This is a simple regression system.

Step 32: font updates can regress coverage

A design team replaces:

Brand Sans v3

with:

Brand Sans v4.

The visual Latin changes look correct.

The new font subset accidentally drops Vietnamese glyphs.

A glyph fixture catches it before release.

Font files are dependencies.

Version them and test them.

Step 33: variable fonts

Variable fonts can provide many weights in one file.

They can also have script/axis behavior that differs across ranges.

Test:

• light;
• regular;
• bold;
• extreme axis values actually used.

Do not assume coverage is identical at every instance.

Step 34: synthetic bold/italic

If a real bold/italic face is missing, the browser/system may synthesize one.

For complex scripts, synthetic styling can look poor or harm legibility.

Provide real style faces or disable synthesis where typographic quality requires it.

Step 35: font fallback and bold consistency

Primary font bold weight: 700.

Fallback font lacks 700 and uses 600 or synthetic bold.

Mixed-script heading looks uneven.

Choose fallback families with compatible weight ranges.

Step 36: baseline consistency

Latin and CJK glyphs can sit at different visual baselines depending on font pairing.

A bilingual brand name can look vertically misaligned.

Test mixed-script strings:

Acme 東京

not only monolingual paragraphs.

Step 37: x-height and apparent size

Two fonts at 16px can look radically different in size.

Fallback choice should consider apparent visual size.

Otherwise embedded Latin names in Arabic or CJK can appear too small/large.

Step 38: line-height consistency

A fallback with large ascenders/descenders can increase line boxes.

This can:

• shift cards;
• clip rows;
• break vertical rhythm.

Use flexible layouts.

Do not force a tight line-height optimized only for English.

Step 39: vertical writing

Some East Asian publishing contexts use vertical text.

Font glyph orientation and vertical metrics matter.

If the product supports vertical layout, test it separately.

Horizontal glyph coverage does not prove vertical quality.

Step 40: print/PDF embedding

A document can look correct on the author’s computer because the fallback font is installed.

The exported PDF can show missing glyphs on another machine if fonts are not embedded correctly.

Test the final PDF on a clean environment.

Typography QA must follow the deliverable.

Worked example 3: PDF missing Chinese glyphs

Designer reviews InDesign on a workstation with a CJK font installed.

PDF export does not embed the fallback subset correctly.

Client opens PDF: boxes appear.

The translation was correct.

The production artifact failed.

Embed and preflight fonts.

Step 41: office documents

DOCX/PPTX can reference fonts not installed on the recipient’s system.

Fallback changes layout.

If the deliverable must travel:

• use widely available fonts;
• embed where supported/licensed;
• convert to PDF for final fixed layout.

Choose based on user needs.

Step 42: font licensing

A technically perfect font may not be licensed for:

• web embedding;
• app bundling;
• PDF embedding;
• server rendering.

Check licensing before choosing multilingual fallback.

Do not discover this after twenty languages depend on it.

Step 43: font file size

Pan-Unicode fonts can be large.

Performance matters.

Strategies:

• locale-specific subsets;
• script-specific downloads;
• unicode-range CSS;
• system fallback.

Balance:

• coverage;
• brand;
• performance.

Step 44: unicode-range

CSS unicode-range can help browsers load font subsets for relevant code points.

This is powerful.

A wrong range can prevent the intended font from loading for target characters.

Test actual resource requests under each locale.

Step 45: don’t subset combining marks away

A naive font subset based only on observed precomposed source can omit combining marks.

User-generated names or decomposed input then render incorrectly.

Include the script’s required combining repertoire according to product input policy.

Failure mode 1: primary font supports English only

Result: tofu or random fallback.

Repair: script-aware stack.

Failure mode 2: fallback readable but visually incompatible

Result: brand inconsistency.

Repair: curated fallback pairing.

Failure mode 3: only regular weight tested

Result: bold headings lose glyphs.

Repair: all production weights.

Failure mode 4: font subset drops diacritics

Result: minority/extended Latin fails.

Repair: coverage fixture.

Failure mode 5: Arabic letters present but shaping poor

Result: unreadable joined forms.

Repair: font + shaping engine test.

Failure mode 6: correct font on designer machine only

Result: recipient sees fallback/tofu.

Repair: embed/bundle/test clean environment.

Failure mode 7: fallback metrics break layout

Result: clipping/wrap.

Repair: flexible layout + compatible metrics.

Failure mode 8: one generic CJK font used everywhere

Result: locale-inappropriate glyph style.

Repair: locale-aware font choice.

Failure mode 9: downloaded font fails and text becomes invisible

Result: content unavailable.

Repair: robust font loading policy.

Failure mode 10: translator replaces unsupported character

Result: language damaged.

Repair: fix font coverage.

A font/glyph QA checklist

Coverage:

• every supported script?
• every locale-specific letter?
• combining marks?
• punctuation?
• currency/symbols?

Styles:

• regular?
• bold?
• italic?
• variable weights?

Rendering:

• shaping?
• baseline?
• line height?
• mixed scripts?
• fallback state?

Platforms:

• Windows?
• macOS?
• Android?
• iOS?
• browsers?

Artifacts:

• PDF embedded?
• app font bundled?
• webfont loads?
• subsets correct?

A glyph fixture screen

Create one internal screen with:

• one row per supported locale;
• locale’s diagnostic string;
• regular/bold/italic samples;
• long paragraph;
• mixed Latin + native script;
• numbers/currency.

Automate screenshots after font updates.

This catches regressions quickly.

A font coverage report

For each font file:

• file/version;
• Unicode ranges/scripts;
• missing required code points;
• weight;
• fallback mapping.

Example:

BrandSans-Regular v4
Required vi-VN: PASS
Required pl-PL: PASS
Required ar-AE: FAIL -> use BrandArabic

Now typography support is explicit.

Search-intent transfer

People searching:

• “font fallback”
• “missing glyph”
• “tofu boxes font”
• “glyph coverage”
• “international font support”

need one operational answer:

verify that every target script has a deliberate font and fallback path, then test real text across production weights, platforms, and final artifacts.

That is the job this URL owns.

Transfer to websites

Web localization needs:

• webfont coverage;
• unicode-range;
• CSP/CORS;
• font-display;
• responsive metrics.

Do not test only the designer’s desktop font installation.

The browser bundle is the product.

Transfer to mobile apps

Mobile apps may bundle:

• one custom font;
• rely on OS fallback.

Test on real OS versions.

System fallback families can change across platform versions.

A screenshot baseline helps.

Transfer to documents

Word and PowerPoint can silently substitute fonts.

The translation may expand because the fallback has different width.

Final PDF/preflight can stabilize the deliverable.

Transfer to educational materials

A worksheet teaching Chinese, Arabic, or phonetics requires fonts that clearly distinguish educational forms.

Generic fallback may be readable but pedagogically wrong.

Font choice is part of teaching quality.

The deeper principle: Unicode support is not the same as font support

A system can store every Unicode character correctly and still display boxes.

A font can contain the character and still shape it badly.

A fallback can render it and still damage visual hierarchy.

Multilingual typography is a chain:

Unicode text → shaping → glyph selection → fallback → layout → final artifact.

QA must follow the chain.

Why this improves speed

A deliberate font stack prevents:

• translators substituting characters;
• repeated screenshot bugs;
• per-locale CSS patches;
• PDF re-export loops;
• emergency font swaps.

One font-coverage fixture can protect every translated string in that script.