PDF文件中英文字体有加粗、斜杠、颜色变成乱码或者翻译错误

[Tommy1Tang]

Before you submit

• I have searched existing issues
• I spent at least 5 minutes investigating and preparing this report
• I confirmed this is not caused by a network issue
• I have fully read and understood the README
• I am certain that this issue is with BabelDOC itself and can be reproduced through the BabelDOC cli
• I have uploaded the original file, or confirmed that this issue is unrelated to the original file
• I have uploaded the log.
• I confirm that the latest version of BabelDOC is being used.
• I am aware that the issue section of this project is only for submitting bugs that are clearly related to the BabelDOC core, with complete reproduction steps and relevant logs attached.** Otherwise, issues will be closed directly.

Environment

- OS:
- Python:
- BabelDOC:沉浸式翻译版本

Describe the bug

在翻译的PDF文件中，如果英文的字体发生了变化或者字体有加粗、斜杠、有颜色的情况会导致翻译变成乱码或者翻译错误

Steps to Reproduce

直接用我提供的PDF进行翻译即可

Expected Behavior

能够正确识别并正确翻译

Relevant Log Output or Screenshots

Original PDF File

LO060_EN_46C_FV.pdf

Additional Context

No response

[zeweihan]

The deeper failure here isn't the garbled glyphs — it's that the font-variant run is exactly where legal documents encode binding signal, and this bug silently corrupts that layer.

Three places this hits regulated corpora hardest:

1. Defined terms are typographically marked. Agreements render Agreement, Effective Date, Recurring Charges in bold at first use; that bold run is the canonical identifier downstream extraction keys on. When the subset font corrupts the run, defined-term resolution can't bind the short form back to its definition — the text is present but no longer findable as the defined term. Same shape as lost provenance: correct text, broken join.

2. Track-changes / redlines are color + strike + underline. In negotiated contracts the editorial layer (insertion vs deletion) is carried entirely by color and styling. Color-run corruption means a deleted clause reads as active text — the inverse of silent loss, and strictly worse for due diligence: plausible-and-current instead of obviously-stale, no error raised.

3. The translation path compounds it. Per the recovery in fix(parser): recover unencoded core font subsets #606, the corrupted source stream is what gets sent to the translation service — so the corruption lands on precisely the high-signal runs (bold defined terms, emphasized obligations), and the translation is most wrong on the parts that matter most. Nothing upstream tells the translator the input glyph stream is unreliable.

The exit-code-0 framing across the sibling reports is the through-line: a parser emitting plausible-looking text for a bold/italic/colored region, with no per-region confidence, is indistinguishable from a correct parse at the API boundary.

A small ask that would make this recoverable for regulated corpora: when the parser falls back to StandardEncoding (or any recovery path that can't round-trip the original glyphs), emit a per-run flag in the output metadata — e.g. encoding_source: fallback / glyph_confidence: recovered — rather than silently substituting. That converts a silent mis-encoding into an informed one: a reviewer can demand re-OCR or human eyes on exactly the flagged runs instead of trusting a translation of corrupted bold text.

Happy to share a redacted contract page (bold defined terms + a colored redline) if it helps stress-test the recovery path.