[BUG] WPS-desktop DOCX: parser fails on settings.xml mc:AlternateContent, silently falls back to image OCR and rewrites text (旻→曼, 艮→良)

Summary

Uploading a .docx saved by WPS Office desktop causes the file parser to fail and silently fall back to rendering the pages as images and transcribing them with a vision model. The transcription rewrites the text: visually similar characters get substituted (王小旻 → 王小曼, 艮位 → 良位), line breaks are merged, and Markdown markers such as ## appear where the source had none.

The file itself is valid and opens correctly in Microsoft Word, LibreOffice, and python-docx. The failure is in the parsing layer — but the real problem is that the fallback is silent: the user receives plausible-looking text with no indication that it was image-transcribed rather than extracted.

This looks related to #1634 (DOCX parsed incorrectly / XML artifacts leaking into text).

Minimal reproduction

Two files with byte-identical visible text (probe strings 王小旻 ×39, 艮位八方守关人 ×39, 235 paragraphs), differing only in the structure described below:

File	mc:AlternateContent in settings.xml	Result
repro_V0_broken.docx	present	❌ text corrupted
repro_V1_fixed.docx	removed	✅ text correct

(Contact me and I will send both files. Both open fine in MS Word.)

Root cause

WPS Office desktop (not the mobile build) appends this to word/settings.xml:

<mc:AlternateContent>
  <mc:Choice Requires="wpsCustomData">
    <wpsCustomData:typoFeatureVersion val="1"/>
  </mc:Choice>
</mc:AlternateContent>

with the namespace xmlns:wpsCustomData="http://www.wps.cn/officeDocument/2013/wpsCustomData".

Note there is no mc:Fallback. To be clear: this is legal. Per ISO/IEC 29500-3, mc:Fallback has minOccurs="0" — it is optional. A conforming consumer that does not understand wpsCustomData should simply not select that mc:Choice branch and continue parsing the rest of the document.

DeepSeek instead appears to abort the whole document extraction and take an image-OCR path.

Evidence that the output is generated, not extracted

These artifacts cannot be produced by any text extractor — they are only possible if a generative model re-typed the content:

Observed	Why it rules out text extraction
## 关于原野 appears (source has no ##)	An extractor reading <w:t> cannot insert characters
Heading and body merged onto one line	<w:p> boundaries are preserved by any XML extractor
------ → ——, \...\... → ...	Punctuation normalised — i.e. rewritten
A 6-page document reported as 12 pages	Re-laid-out by the model
旻 → 曼, 艮 → 良	Classic visual confusion pairs

Why this is worse than a parse error

1. No error is surfaced. The user is never told the document could not be read.
2. The result is indistinguishable from the original. Unlike mojibake, the substituted characters form a valid, plausible name. One user spent two hours trying to fix their "typo" — converting to .txt, changing fonts, re-saving templates, re-creating the file on mobile — because the output looked like their own text.
3. Loss is guaranteed, not incidental. Handing an 80,000-character document to a vision model will always introduce substitutions, silently.

This is compounded by the fact that the model, when asked about the cause, explained it as a customXml metadata problem and produced a plausible-sounding but incorrect diagnosis — the actual trigger is a different XML part entirely.

Suggested fix

• Do not fall back to image/OCR transcription silently. Either fail loudly, or label the result: "This document could not be parsed; the text below was read from page images and may contain errors."
• Ideally, make the extractor robust to unknown mc:AlternateContent branches in settings.xml. settings.xml contains no user text; a single unrecognised element there should not invalidate the entire document.

Workaround (for other users hitting this)

Remove the mc:AlternateContent block above from word/settings.xml, or re-save the document with WPS mobile, which does not write it.

Environment

• Client: DeepSeek web chat
• OS: Windows 11
• Files created with: WPS Office 桌面版 12.1.0.28505 / 12.1.0.26895 (docProps/app.xml: WPS Office_12.1.0.28505_...)
• Working files: WPS mobile (Application = WPS Office_0.0.0.0_..., lastModifiedBy = iPhone)

---

中文摘要

WPS 电脑版保存的 .docx 上传后，解析失败，平台静默退化为把页面渲染成图片、再用视觉模型转写，导致形近字被替换（王小旻→王小曼、艮位→良位）、换行被合并、凭空出现 ## 等 Markdown 标记。

文件本身合法：微软 Word、LibreOffice、python-docx 均能正常读取。触发点是 word/settings.xml 里的 <mc:Choice Requires="wpsCustomData">（无 mc:Fallback）——注意这写法是合规的，mc:Fallback 在 ISO/IEC 29500-3 中是可选元素，不认识的消费者跳过该分支即可。

关键问题不在"解析失败"，而在失败后不报错：用户拿到的是一份看起来完全正常的文本，无法察觉它来自图像识别。有用户为此排查了两个小时。

建议：解析失败时明确报错或标注来源，不要静默降级为图像识别。