Skip to content

Fix 5953 - #535

Closed
valerybokov wants to merge 2 commits into
apache:trunkfrom
valerybokov:fix-5953
Closed

valerybokov wants to merge 2 commits into
apache:trunkfrom
valerybokov:fix-5953

Conversation

@valerybokov

Copy link
Copy Markdown

Problem

Filled-in AcroForm field values (account numbers, amounts, names) rendered as garbled or blank CJK text in a real-world bank-receipt PDF where NeedAppearances is set and the AcroForm/DR font (SimSun) is:

  • not embedded (substituted from the OS), and
  • declared with a predefined, non-Identity encoding (UniGB-UTF16-H), instead of the usual Identity-H.

Root cause

PDCIDFontType2.encode()'s non-embedded branch always wrote the substituted font's own glyph index as the content-stream code, regardless of the font's declared /Encoding. That's only correct for Identity-H/V, where code == GID by convention.

For a Uni...-UTF16-H/Uni...-UCS2-H encoding, the codespace is the raw UTF-16BE Unicode value (verified directly against the UniGB-UTF16-H CMap resource, e.g. <00a4> 167). Writing the substitute font's glyph index there instead produces a code that, once decoded again through the normal CID/Unicode round trip (PDCIDFontType2#codeToGID / PDType0Font#toUnicode), resolves to an unrelated, essentially arbitrary character — hence the garbled/blank text.

Fix

In the non-embedded branch of PDCIDFontType2.encode(), when the font's encoding is a predefined Uni... CMap (and not Identity-*), write the raw Unicode value as the code instead of the substitute font's glyph index, matching what that encoding's codespace actually expects.

Testing

  • Reproduced with the two PDFs attached to the JIRA issue; before the fix, filled-in field values render as garbled/wrong CJK characters (or blank, matching the original report on an older PDFBox version). After the fix, both render correctly.
  • Added PDCIDFontType2SubstituteTest, which encodes a known GB1 character through the actual non-embedded SimSun font from the JIRA fixture and asserts the round trip resolves to the same glyph the substitute font's own Unicode cmap would give directly. Skips (via assumeTrue) if the environment has no suitable CJK substitute font installed.

@valerybokov

Copy link
Copy Markdown
Author

Another issue. It looks like we don't need a method PDCIEDictionaryBasedColorSpace.isWhitePoint.

asf-gitbox-commits pushed a commit that referenced this pull request Sep 28, 2026
…hen the font's encoding is a predefined Uni... CMap (and not Identity-*), write the raw Unicode value as the code instead of the substitute font's glyph index, matching what that encoding's codespace actually expects, by Valery Bokov and Claude Code; closes #535

git-svn-id: https://svn.apache.org/repos/asf/pdfbox/branches/3.0@1938599 13f79535-47bb-0310-9956-ffa450edef68
asf-gitbox-commits pushed a commit that referenced this pull request Sep 28, 2026
…hen the font's encoding is a predefined Uni... CMap (and not Identity-*), write the raw Unicode value as the code instead of the substitute font's glyph index, matching what that encoding's codespace actually expects, by Valery Bokov and Claude Code; closes #535

git-svn-id: https://svn.apache.org/repos/asf/pdfbox/branches/2.0@1938600 13f79535-47bb-0310-9956-ffa450edef68
@THausherr

Copy link
Copy Markdown
Contributor

Thanks, removed

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.

2 participants