fix: use sequential filenames for embedded fonts#3428
Open
ctjlewis wants to merge 1 commit intodolanmiu:masterfrom
Open
fix: use sequential filenames for embedded fonts#3428ctjlewis wants to merge 1 commit intodolanmiu:masterfrom
ctjlewis wants to merge 1 commit intodolanmiu:masterfrom
Conversation
Embedded fonts with spaces (or other non-ASCII characters) in their family name caused Word to show its "Word found unreadable content" recovery prompt on open. The package zip entries were named after the user-facing family (e.g. `word/fonts/EB Garamond.odttf`), and Word treats those paths as literal filenames that must be plain. Switch to sequential `fonts/font1.odttf`, `fonts/font2.odttf`, … in both the relationship Target and the zip entry. The user-facing family name continues to live in `<w:font name="...">` only. Closes dolanmiu#3019. Refs dolanmiu#2521 (PR dolanmiu#2800 fixed the related fontTable rel-link; this completes the pair). May also help dolanmiu#3120 (LibreOffice silently dropping embedded custom fonts; same package-path encoding plausibly the cause, untested locally).
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #3428 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 310 310
Lines 3173 3172 -1
Branches 716 716
=========================================
- Hits 3173 3172 -1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
ctjlewis
added a commit
to EvolvingPrograms/legalese
that referenced
this pull request
Apr 30, 2026
Five Google Font families ship in `fonts/` and embed into the rendered .docx when selected via `style.font:`: - EB Garamond — classic Garamond serif - Source Serif 4 — modern, very readable - Crimson Pro — tight Garamond alternative - PT Serif — workhorse legal serif - Libre Baskerville — Baskerville substitute Variable-axis TTFs where available (single file covers all weights via the wght axis; modern Word interpolates true designed bold). 2.7MB total — well under the 30MB skill-upload budget. The font embedding requires an upstream docx fix (dolanmiu/docx#3428): docx-js was naming embedded-font zip entries after the user-facing family (e.g. `word/fonts/EB Garamond.odttf`), and Word rejected paths containing spaces/non-ASCII with its "found unreadable content" recovery prompt. The fix switches to sequential `font1.odttf`/`font2.odttf`/... paths, decoupling the package path from the font family name. Until the PR merges, `patches/docx@9.6.1.patch` carries the same change locally — bun applies it on every install. Removing the patch once the upstream release ships. `scripts/fetch-fonts.ts` refreshes the bundle from github.com/google/fonts. Embedding wired in `src/lib/build.ts` — when `style.font:` matches a bundled family, its TTF is read from `fonts/manifest.json` and registered with docx's FontOptions. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Embedded fonts with spaces (or other non-ASCII characters) in their family name caused Word to show its "Word found unreadable content" recovery prompt on open. The package zip entries were named after the user-facing family (e.g.
word/fonts/EB Garamond.odttf), and Word treats those paths as literal filenames that must be plain.This PR switches to sequential
fonts/font1.odttf,fonts/font2.odttf, … in both the relationshipTargetand the zip entry. The user-facing family name continues to live only in<w:font name="...">, so no API change.Closes #3019.
Context
Refs #2521 — that issue reported two problems together. PR #2800 fixed one of them (the missing
Relationshipfromdocument.xml.relstofontTable.xml). The other (spaces in the package filename) was left unfixed and resurfaced as #3019. This PR completes the pair. May also help #3120 — LibreOffice silently dropping embedded custom fonts.What changed
FontWrapper: relationshipTargets are nowfonts/font<N>.odttf.next-compiler: zip entries match the same sequential names.<w:font name="...">— unchanged.Tests
font-wrapper.spec.ts— verifies relationship Targets are sequential.next-compiler.spec.ts— verifies zip entries arefont1.odttfetc., with no family-name paths leaking through.Test plan
vitest run src/file/fonts src/export/packer/next-compiler)EB Garamond(space in family name) opens in Word with no recovery prompt