mathtype-re-render：把 .eqp 真正应用到 Word 公式

EQP 配置 -> MTEF 二进制审计/修补 -> 二进制完整性证明
         -> 唯一 WMF 映射 -> x86 OLE 渲染
         -> WMF 替换 + Word 几何同步 -> 最终审计/渲染 QA

​

怎么用

npx skills add LIziak112/mintlify -s mathtype-re-render

调用 mathtype-re-render skill。

使用“C:\路径\目标.eqp”作为公式预设，处理“C:\路径\源文档.docx”，结果另存为新的 .docx。
不要覆盖源文件。跑完整流水线：审计、修补、完整性证明、预览重渲染、几何同步，并做全页视觉检查。

python .\run_full_pipeline.py target.eqp source.docx refreshed.docx `
  --work-dir .\work\job-name `
  --cache .\cache `
  --batch-size 25

​

能解决什么

​

不适用

• 静态图片公式（PNG/EMF）
• Office 原生 OMML 公式
• 改写公式数学内容——只改配置和显示
• 非 Windows，或未注册 MathType 32 位 OLE 服务端
• 未知字体映射——会停下，先做对照样本，不猜测

​

环境要求

• Windows，已安装并注册 MathType 32 位 OLE server
• Python（跑流水线脚本）
• 输入：含可编辑 Equation.DSMT4 的 .docx + 标准 .eqp（8 项 Sizes + 30 项 Spacing）
• 输出：始终写新 DOCX；禁止源路径等于输出路径

​

七道门槛（概览）

1. 预检：对照 .eqp 枚举所有 owner part 中的公式偏差（退出码 2 = 有偏差，待修时属预期）
2. 修补：只改可解析的 EQN_PREFS / 已验证字体记录，并同步长度与 mini-stream 元数据
3. 证明：偏差归零；非目标部件与 OLE 流不变
4. 映射：按 OOXML 关系定位 OLE↔WMF；必要时拆分共享预览
5. 重渲染：构建/调用 x86 OlePreviewRenderer，按缓存批量刷新 WMF
6. 几何审计：WMF、VML、dxaOrig/dyaOrig 一致，预览阶段 OLE 哈希不变
7. 全页 QA：检查漏公式、旧框、变形、裁剪、重叠、基线漂移与异常分页

• 配置错且预览旧 → 跑全流程
• 配置已修补并验证 → 从映射 + 重渲染开始，不要再补一次
• 仅预览陈旧、配置已合规 → 跳过修补，仍要映射、拆分、刷新、审计
• 渲染器不可用 → 诊断 x86 构建与 MathType 注册；绝不把可编辑公式静默换成 PNG

​

交付时要报告什么

• 使用的 EQP
• 公式对象数与唯一公式数
• MTEF 已改 / 未改数量
• 共享预览拆分数量
• 新渲染数与缓存命中数
• 几何审计结果
• 预览阶段 OLE 保持结果
• 全页视觉 QA 状态

​

相关阅读

• MathType Re-render 技术深潜：三层数据模型与 5758 公式实测
• MathType 批量格式化为何慢：官方批量格式化的通信路径
• word-format skill：习题册版式迁移（与公式配置互补）