patent-complex-converter · 专利复杂元素转图 Skill

> 把 DOCX 交底书 / 说明书里的 表格、公式、附图 渲染成国知局合规图片（JPEG/TIFF）。
> 本 skill 是 patent-xml-builder 的搭档，专责"复杂转换"这一子问题；不负责 XML 案卷包组装。

> ## ⛔ 扫描件红线（务必先看，关乎你交的是不是"成品"）
> 本 skill 处理图片 / PDF 扫描件时，产出的只是「人工校对底稿，不是成品」——
> - 不重建表格结构：OCR 只给文字行与坐标，表格的行列/合并关系无法从位图还原，转录稿里原表格会变成普通段落；
> - 不自动裁附图：整页原图作为附图抽取时是"整页一张图"，需你手动裁剪后再当 FIG；
> - 不提供置信度：Windows OCR API 本身无置信度字段，识别成功 ≠ 识别正确；
> - 工程图内标注（尺寸/引线/图例）位图识别率天然很低，请一律以原件为准。
>
> ✅ 正确用法：把扫描件喂进来 → 逐字对照原件人工校对转录稿 → 再转图。切勿直接把 OCR 转录稿当定稿提交。

一、定位与边界（先看清能做什么、不做什么）

设计铁律：本 skill 不重新发明 XML 组装。它只把"难转的复杂元素"变成图，通过统一命名（FIG/TAB/FOR + 序号）交给 patent-xml-builder 的 --merge 接口，自动缝成完整包，不手工拼合。

二、经典三层架构（减 token、稳复用）

┌─────────────────────────────────────────────────────────────┐
│ ⓪ 扫描件入口层  scan_intake.py（仅当输入是 图片/PDF 时启用）  │
│   预处理(放大/去噪/提对比) → 本地 OCR(Windows OCR/tesseract) │
│   → 版面归并成段落 → 可编辑 DOCX 转录稿 + 原图附页 + 报告     │
└─────────────────────────────────────────────────────────────┘
            ↓ 产出可编辑 DOCX（人工校对后）
┌─────────────────────────────────────────────────────────────┐
│ ① 交互层  convert.py（CLI 入口）                            │
│   · --engine auto|libreoffice|com|matplotlib                │
│   · 报告顶部告警 + 后续动作提示                              │
│   · 友好文案，不专业术语堆砌                                 │
└─────────────────────────────────────────────────────────────┘
            ↓ 编排
┌─────────────────────────────────────────────────────────────┐
│ ② 业务/转换层  （确定性、可复用、token 主消耗区）           │
│   docx_extract → render_engine ┬ com_render → image_check → 报告│
│   解析 DOCX       回退重绘      └ 高保真渲染   规格校验       │
└─────────────────────────────────────────────────────────────┘
            ↓ 依赖
┌─────────────────────────────────────────────────────────────┐
│ ③ 基础设施/安全层                                           │
│   deps_probe（引擎/OCR 探测）  airgap_check（离线自检）      │
└─────────────────────────────────────────────────────────────┘
        横切保障贯穿各层：离线不联网 / 异常不崩溃 / 用户友好 / 免责FAQ

三、渲染引擎：高保真优先，逐级回退（四层）

核心原理（迷你文档法）：不再"在整篇 PDF 里猜元素位置"（不可靠），而是把目标元素
原样复制进一个只含它的空白 DOCX → 由 Office 引擎渲染成 PDF → 转位图。
排版交给 Word/WPS/LibreOffice 自己做，所以字体、合并单元格、公式符号与原稿一致。
跨页表格会自动纵向拼接成一图（解决"跨页表转换易错"的老问题）。

当您的环境不适合 LibreOffice 时（最常见）——三种情况都有出口：
1. 装了 WPS / Word（国内 Windows 机器多数如此） → 自动启用 COM 高保真路线，效果与 LibreOffice 同级，无需任何操作。
2. 两者都没有 → 自动回退纯 Python 重绘，仍能出合规图；代价是"非原排版"，报告已强提示人工核对。
3. 想要 LibreOffice → 下载 https://www.libreoffice.org/download/ 默认安装即可，下次运行自动探测启用（优先级最高）。

任何一条高保真路线在单个元素上失败，都只把该元素降级为重绘并标注 fallback，不影响其余元素、不中断整批（异常处理要求）。

四、输入 / 输出

• 输入（可编辑 DOCX）：python convert.py <input.docx> [--out DIR] [--engine auto|libreoffice|com|matplotlib] [--dpi 220] [--profile invention|design|pct|reexamination] [--no-trim]
• 输入（扫描件 图片/PDF，自动走 OCR）：python convert.py <扫描件.jpg|.png|.pdf> [--out DIR] [--profile ...]
  （等价于先跑 python scan_intake.py <输入> --out DIR 再把转录稿喂给 convert.py）
• 单独使用扫描件入口：python scan_intake.py <图片|PDF|目录> [--out DIR] [--lang zh-Hans-CN] [--engine auto|winocr|tesseract|none] [--no-pages]
• 交互向导（自然语言调度 scan → 校对 → 转图）：python wizard.py [路径] [--out DIR] [--profile invention|design|pct|reexamination] [--run] [--yes]
• 不带参数进入交互模式：用中文/英文指令驱动（如「扫描」「校对」「转图」「运行」「状态」「退出」；也认 scan/proof/convert/run 及单字母 s/p/c/r）；直接粘贴文件路径即设为输入。
• 图样约束切换（自然语言）：外观设计 / pct / 国际 / 复审 / 无效 / 发明 —— 决定尺寸上限/色彩/整页规则，影响转图。
• python wizard.py <图片/PDF> --run：一步到位——扫描 →（人工确认校对）→ 转图。
• python wizard.py <docx> --run：DOCX 无需扫描，直接转图。
• python wizard.py <图片/PDF> --run --yes：非交互/自动化场景，等同 skip 校对确认（事后仍须人工核对转录稿）。
• 「校对」环节强制人工确认（OCR 不保证正确），不会静默跳过。
• 非交互安全：当 stdin 不可交互（管道 / 重定向 / 无 tty）时，向导不会因 input() 抛 EOFError 而崩溃，而是明确提示并继续后续步骤（可用 --yes 显式跳过）。
• 输出目录：
• FIG-00N.jpg —— 说明书附图 / 嵌入图片。按图号编号：FIG-003 即说明书里的「图3」（从图片题注自动识别图号；抓不到图号的图补最小未占用号）。此规则与 patent-xml-builder 完全一致，保证 --merge 精确对位。
• TAB-00N.jpg —— 表格图（含表格内嵌的图片，会自动注入并重映射 rId，不会渲染成空白）
• FOR-00N.jpg —— 公式图（高保真路线整段原样渲染，OMML/旧式公式均可出；回退路线按文本尽力重绘）
• 转图清单.json —— 机器可读清单（ID、类型、引擎、渲染状态、规格、疑似扫描件 标记）
• 转图结果与操作说明.txt —— 人读报告（顶部告警 + 每元素状态 + 后续动作 + 环境提示）
• 离线自检报告.txt —— 离线自检结果
• 扫描件入口的额外产物（在 --out/_intake/）：
• <名称>_扫描转录稿.docx —— OCR 转录稿（正文段落 + 末尾附整页原图，供人工校对与附图裁剪）
• 扫描件识别原始结果.json —— 逐页逐行原始 OCR 数据（含词级坐标，可追溯）
• 扫描件识别报告.txt —— 识别量、告警、疑似误识行清单、后续动作

输入形态（重要边界）

图样约束 profiles（发明 / 外观 / PCT / 复审无效）

同一份附图，不同申请类型/程序的尺寸、色彩、页面规则不同。--profile 把这些差异数据化，
驱动 image_check 校验与 render_engine 缩放/整页合成。约束值来自公开指引口径（非法律意见）。

• 用法：convert.py <输入> --profile pct；向导中自然语言 pct / 外观设计 / 复审 切换。
• pct 会自动把每幅图缩放后居中合成到白底 A4 页（符合 PCT Rule 11bis 整页提交要求）。
• design 不强制转灰度（允许保护色彩）；其余三类 RGB 图会提示"建议转灰度/黑白"。
• 尺寸/色彩超范围只在报告里告警（不否决）；仅"无法读图/格式不符"算硬错误。
• 约束来源写入 转图清单.json（字段 profile_cite），便于追溯口径。

扫描件入口（scan_intake.py）怎么工作

疑似识别异常的三类启发式标记（负责"提醒你重点看哪里"，不负责"替你改对"）：

> ⚠️ 这三类是启发式，非穷举。没有告警 ≠ 没有错误；图形区文字（尺寸标注、引线、图例）位图识别率天然很低，请一律以原件为准。

五、与 patent-xml-builder 的闭环（两步）

专利-xml-builder 第1步：生成纯文本包 → 检测复杂元素 → 占位 + 报告顶部提示"用复杂转换 skill 或人工"
        ↓
本 skill：convert.py 交底书.docx → 产出 FIG/TAB/FOR 图片
        ↓
专利-xml-builder 第2步：build_package.py <输入.json> --merge <本skill输出目录> --out <最终包>
        → 按 ID 自动融合，无需手工拼合

命名体系（FIG/TAB/FOR + 3 位序号）两边一致，所以 --merge 能精确对位。已实测：本 skill 产出的 4 张图（FIG-001/002、TAB-001、FOR-001）被 patent-xml-builder 准确并入其案卷包。

> 🔑 编号铁律：FIG-NNN 的数字 = 说明书图号（FIG-003 即「图3」），不是"文档里第几张图"。
> 图号从图片题注（如"图3 结构示意"）自动识别；抓不到图号的图补最小未占用号。
> 这样即使交底书没有独立"附图说明"段、或正文引用顺序与插图物理顺序不一致，回传 --merge 也能对位。
> （2026-09-11 修复：此前按文档物理顺序编号，在上述场景下会"报告显示全部融合成功、实际图贴错"的静默错配。）

六、已知局限（诚实，不夸大）

1. 纯 Python 回退路线下，表格/公式为"按结构重绘"，非 Word 原排版，需人工核对内容。
2. 高保真路线依赖本机 Office 引擎（LibreOffice / WPS / Word）：三者皆无时只能走重绘路线。
3. COM 路线会短暂启动 Office 进程（无窗口、只读打开迷你文档，用完即退出）；若本机 Office 有弹窗拦截或未激活，可能失败并自动降级——报告会标注 fallback。
4. embedded 图片不区分"附图/配图/logo"，全部抽取，请在报告中剔除无关项（如页眉 logo）。
5. 旧式 OLE 公式对象（非 OMML）无法抽取为文本，高保真路线仍能整段渲染；纯 Python 路线会标"需人工"。
6. 超大表格压缩后（报告会给出 scale 与最终 mm 尺寸）若仍超 165×245mm，会被等比压到上限，文字可能偏小，请核对清晰度或考虑拆表。
7. ID 对齐前提：FIG-00N 按图号编号（题注自动识别），TAB-00N/FOR-00N 按"该类型元素在文档中出现的顺序"编排。图号识别依赖图片题注文字(如"图3 …")；若题注缺失或写在图下方很远，可能识别不到而补号，请核对 转图结果与操作说明.txt 与 patent-xml-builder 的 复杂元素清单.txt 是否一致。
8. OCR 转录稿不是成品：扫描件入口产出的是"人工校对底稿"。OCR 不提供置信度（Windows OCR API 本身无此字段），因此报告不会给出可信度数字——识别成功 ≠ 识别正确，必须逐字对照原件。
9. 表格结构无法从位图还原：OCR 只能得到文字行与其坐标，不重建表格的行列/合并关系；转录稿里原表格会变成普通段落。表格请对照末尾原图人工重排。
10. 扫描件的附图需人工裁剪：整页原图作为附图抽取时是"整页一张图"，无法自动裁出图区；请人工裁剪后再作为 FIG-00N.jpg。
11. OCR 引擎依赖本机：默认用 Windows 自带 OCR（中文需系统已安装"光学字符识别"语言功能）；若无该功能且未装 tesseract，扫描件入口会明确报错并给安装指引，不会静默产出空稿。

七、用户 10 条要求的落地映射

八、依赖与安装

# 在隔离 Python 环境
python -m pip install -r requirements.txt
# 需要：lxml Pillow python-docx matplotlib numpy
# 可选（高保真）：安装 LibreOffice（默认路径即可被自动探测）
# 扫描件入口：**不需要额外依赖** —— 默认调用 Windows 系统自带 OCR（离线、免安装）
#   若系统未安装中文 OCR 语言功能，可选装 Tesseract-OCR（含 chi_sim 语言包）作为替代引擎

九、诚实状态小结

• ✅ 已实测：
• WPS/Word COM 高保真路线——迷你文档 → PDF → 合规图，表格边框/中文/公式排版与原稿一致（本机 WPS 12.0 实测）。
• 跨页表格自动纵向拼接（45 行长表 → 2 页 PDF → 1 张合规图，73×245mm）。
• 纯 Python 回退路线、逐图规格校验、离线自检（脚本零网络调用）。
• 扫描件入口（新增）——真实扫描件（HDPE 管道交底书 JPEG，2000×2828）实测：Windows 自带 OCR 离线识别 → 31 行/22 段落/399 字转录稿 + 整页原图附页；R1/R2/R3 三类启发式标记精准命中（第丨页、依巛图号、端凵、刃 OZ数 等）；JPEG 直喂 convert.py → 自动 OCR → 转图 FIG-001.jpg 全链路贯通。
• 端到端闭环：本 skill 出图 → patent-xml-builder --merge → 自动融合成完整案卷包（110101.xml 经官方 XSD 校验通过，List.xml 登记全部图片，说明书占位引用自动替换）。
• ⚠️ 未实测（本机无该软件）：LibreOffice 路线（soffice 调用已实现并经过代码审查 + 功能性探测加固）。因本机未安装 LibreOffice，无法做运行时实测；装有 LibreOffice 后本 skill 会自动探测（先验证 soffice --version 可运行再选用），并在其单次转换失败时自动降级为 matplotlib 重绘，不整批失败。
• ⚠️ 扫描件路线的能力上限（如实）：OCR 只出文字，不重建表格结构、不裁图；工程图内标注识别率低；无置信度可给。故扫描件入口定位是"把不可处理的输入变成可人工校对的底稿"，而不是"全自动出成品"。
• 所有产物本地生成、不触网，符合"申请前技术交底书本地处理"的硬约束（OCR 亦为本地引擎，无云端 API 调用）。