Skip to content

backend/pdf: separate the font-file key from its object number - #52

Merged
timzifer merged 1 commit into
mainfrom
fix/pdf-fontfile-key
Sep 22, 2026
Merged

timzifer merged 1 commit into
mainfrom
fix/pdf-fontfile-key

Conversation

@timzifer

Copy link
Copy Markdown
Owner

The FontDescriptor of an embedded TrueType font was written as /FontFile22 0 R instead of /FontFile2 2 0 R: the key ran into the object number. PDF readers then treat the font as not embedded (MuPDF: "non-embedded font using identity encoding"), and gofpdi scrambles the dictionary when importing the page into another document. The CFF branch only worked because its key carried a trailing space.

  • The separating space moves into the format string; both keys are bare.
  • TestTheDescriptorReferencesTheFontProgram follows the reference for TrueType and CFF and checks it lands on the font-program stream. Red before the fix, green after.

Found while importing figure pages into an fpdf report (terminal-mk2).

🤖 Generated with Claude Code

The FontDescriptor was written as "/FontFile22 0 R" for an embedded
TrueType font: the key and the object number ran together into one name
followed by a stray "0 R". Readers then treated the font as not embedded,
and a PDF importer that re-serialises the dictionary (gofpdi) scrambled
it. The CFF branch only worked because its key happened to carry a
trailing space. The space now lives in the format string for both.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@timzifer
timzifer merged commit a08a157 into main Sep 22, 2026
18 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant