Browser Font Substitution Experiment — Why Line Breaks Shift After DOCX Import
A reproducible look at EditDocx’s “exact font metrics = partial” lab row: font names survive, glyphs may substitute, and how to test line-break drift before you send a file.
The Compatibility Lab marks exact font metrics as partial: font names are retained, but browser font availability can substitute glyphs and change line breaks. That single sentence explains a surprising number of “the layout broke” reports.
This experiment shows how to see the effect yourself, using the public baseline and a couple of controlled checks.
Lab context: baseline results · ritual: reproduce the round-trip.
Hypothesis
If a DOCX names a font that is not installed (or not licensed to the browser), the editor will still store the font name in the model, but the canvas and sometimes the downloaded rendering environment will substitute. Substitution changes glyph widths → line breaks → pagination.
Materials
- Baseline fixture (verify SHA-256
26bdee56fbbd33eeaf44f73e90502eb2626414a80a9d33eeab9e87225dc3e5d9) - EditDocx editor
- Optional: a second machine without your corporate fonts
- Optional: desktop Word with the corporate font installed
Procedure A — Baseline on your everyday machine
- Import the baseline in EditDocx.
- Note which body font the UI reports for a paragraph.
- Download DOCX; reopen in Word on the same machine.
- Compare line breaks on page 1.
Expected: Often close when both environments share common fonts (Calibri/Arial/Times-like stacks).
Procedure B — Force a missing-font scenario
- In desktop Word, create a one-page
.docxthat uses a font you know is rare on the web (example: a niche corporate display face). Keep text to 3–4 short paragraphs so pagination is obvious. - Open that file in EditDocx on a machine without the font installed.
- Observe canvas substitution (browsers pick a fallback).
- Download; reopen in Word with the font installed vs without.
Expected:
- EditDocx retains the font name in many everyday cases (lab: names retained)
- Visual line breaks may differ wherever the face is missing
- Reopening on a machine with the font often “fixes” appearance — the bytes were not necessarily wrong
Procedure C — Cross-check the published partial row
Re-run the baseline image + font rows from the lab:
| Feature | Published (2026-07-16) | Your note |
|---|---|---|
| Exact font metrics | partial | |
| Inline images | partial |
Write browser version beside your notes. Partial is not “broken forever”; it is “do not assume Win32 metrics.”
Mitigations that actually work
- Author with common fonts when recipients are unknown.
- Verify downloads on a machine that matches the recipient’s likely fonts.
- Escalate to desktop Word for brand letterhead that depends on locked faces (when desktop Word still wins).
- Do not confuse font substitution with unsupported objects (charts/SmartArt/OLE) — those are hard stops (Features).
What EditDocx is optimizing for
Everyday memos, homework, and light contracts where Calibri/Arial-class stacks dominate. Brand books and packaging proofs are desktop territory. Honesty about metrics is part of the product, not a footnote — see also fidelity failure modes.
FAQ
Does EditDocx embed fonts into the DOCX?
Do not assume full font embedding for every face. Treat missing-font environments as a verification problem.
Is substitution unique to EditDocx?
No. Any browser-based renderer faces the same OS font inventory limits. Cloud suites sometimes host webfonts for their UI; that is a different architecture and often a different privacy boundary.
Why keep the font name if glyphs substitute?
So round-trips back to Word on a properly licensed machine can still request the intended face.
How do I report a surprising break?
Email [email protected] with browser/OS, whether the font is installed, and a redacted sample — not live customer secrets (Contact).
