https://bugs.kde.org/show_bug.cgi?id=528458
Bug ID: 528458
Summary: Japanese text is not rendered for PDFs that use
non-embedded CID fonts with obfuscated font names
(UniJIS-UCS2-HW-H) — macOS build
Classification: Applications
Product: okular
Version First unspecified
Reported In:
Platform: macOS (DMG)
OS: macOS
Status: REPORTED
Severity: normal
Priority: NOR
Component: PDF backend
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Summary
Japanese text is not rendered for PDFs that use non-embedded CID fonts with
obfuscated font names (UniJIS-UCS2-HW-H) — macOS build
System
macOS 26 (Apple Silicon, Mac mini M1)
Okular 26.11.70, and also reproduced with the latest nightly build
okular-master-8236-macos-clang-arm64.dmg
Japanese fonts are installed and visible to fontconfig (see below)
Steps to reproduce
Open a PDF whose Japanese text uses non-embedded CID TrueType fonts with
UniJIS-UCS2-HW-H encoding and meaningless/obfuscated font names (such PDFs are
produced e.g. by Japanese delivery/billing services; the sample is an invoice
from Yamato Transport's billing service).
Observe that all Japanese glyphs are missing/blank, while digits and Latin
characters render.
pdffonts output for the affected file:
name type encoding emb sub uni object ID
----------------- ------------- ----------------- --- --- --- ---------
lr CID TrueType UniJIS-UCS2-HW-H no no no 3 0
lrSVbN CID TrueType UniJIS-UCS2-HW-H no no no 6 0
Actual results
Japanese text is not displayed at all. No font-related error is printed on
stderr (only an unrelated Qt warning about a missing "Liberation Sans" family
alias).
Expected results
Japanese text rendered using a substitute Japanese font, as other Poppler-based
tools on the same machine do.
Additional information (isolation tests on the same machine)
The PDF itself is valid: pdftotext (Homebrew Poppler) extracts the Japanese
text correctly, and pdftoppm (Homebrew Poppler) renders the page with Japanese
text perfectly, using font substitution.
Fontconfig on this system sees 60 Japanese fonts (fc-list :lang=ja), including
Hiragino Sans / Hiragino Mincho ProN (system fonts) and user-installed Noto
Sans JP / Noto Serif JP. fc-match resolves Japanese families correctly.
The Okular app bundle does contain Poppler CMap resources
(Contents/Resources/poppler/cMap/Adobe-Japan1/UniJIS-*), so plain missing
poppler-data is unlikely to be the cause.
Adding a user fontconfig config (~/.config/fontconfig/fonts.conf) with the
macOS font directories and a strong Japanese fallback rule for lang=ja did not
change the result.
Launching Okular with FONTCONFIG_FILE=/opt/homebrew/etc/fonts/fonts.conf (the
configuration under which the Poppler CLI tools work) did not change the result
either.
Converting the PDF with pdftocairo -pdf (which embeds the substituted fonts)
produces a file that the same Okular build displays correctly, confirming that
only the substitution path for these non-embedded CID fonts fails.
This suggests that font substitution for non-embedded CID fonts — whose names
give no usable hint ("lr", "lrSVbN") — does not fall back to a Japanese-capable
font in the macOS (Craft) build of Okular/Poppler, while the standalone Poppler
tools handle it.
Note
The original sample file is a personal invoice and cannot be attached publicly;
a redacted/minimal sample can be provided on request.
--
You are receiving this mail because:
You are watching all bug changes.
