Office 版式不保证完全保真

Beta 状态的明确含义

ZenConverter README 模块状态表里，Office 转换明确标为 Beta：

Beta：usable, but edge cases are expected.

翻译成日常语言就是：能用但别指望完美。

Beta 和 Stable 的区别在 support-matrix 里有五个状态标签（见"诚实比万能更重要"页面）。Office 路线在 Beta 状态已经做了真机验证、核心场景能跑通，但复杂文档的版式还原不保证。

为什么版式可能不对

Office OOXML 格式（DOCX/PPTX/XLSX）表面上是"基于 XML 的标准格式"，但实际上每个 Office 应用（Microsoft Word、WPS、Pages、Google Docs）对同一个 XML 文件的渲染有细微差异——这就是为什么你在 Word 里排版好的文档用 WPS 打开可能略微变形。

ZenConverter 的 libzen_office2pdf.so 是第三方 Office 渲染引擎（不是 Microsoft 官方引擎），它对 Office 的理解是逆向工程和规范实现的结合。它做不到 Microsoft Office 那样"精确还原"。

常见的"不完美"场景

场景	可能的表现	说明
复杂 PPTX（多层动画、自定义主题）	文字重叠、图形错位	不支持动画，只渲染静态帧
复杂 XLSX（合并单元格、条件格式）	合并单元格被拆开、公式只显示静态值	不执行公式计算
嵌入媒体（PPTX 里的视频/音频）	媒体对象丢失或变成占位符	Office2PDF 不处理嵌入媒体
特殊字体（系统没装）	用替代字体渲染，版式偏移	见"中文渲染选项"
复杂排版（脚注、批注、修订模式）	可能丢失或位置错误	不支持修订、批注
大文档（接近 64 MiB）	慢且可能 OOM	源文件硬上限 64 MiB

源文件 64 MiB 上限

Office 转换引擎整个输入文件一次性读入内存。为了避免 OOM，设定了 64 MiB 硬上限：

超过 64 MiB 的 Office 文件会直接失败，不会尝试处理；
这个上限是安全策略，不是功能限制——ZenConverter 选择明确失败而不是让进程被 LMK 杀掉。

64 MiB 对于绝大多数 Office 文档是绰绰有余的（50 页 Word ≈ 几 MB，复杂 PPTX 嵌很多图可能到十几 MB）。只有极端情况（PPTX 嵌了几十张高分辨率照片）才会逼近这个上限。

中文渲染：系统字体 vs Noto CJK

Office 转换路线在 v0.2.0 版本做了一个重要优化：系统字体优先 + 按需下载 Noto CJK。

策略	下载量	精度	说明
默认：系统字体	0 MB	好（大多数场景）	自动发现设备可用字体路径
可选：Noto CJK	约 30.8 MB	最好（衬线字体准）	需要手动下载

系统字体策略覆盖了中简、中繁、日、韩——大多数 Android 设备的系统字体里已经包含这些。Noto CJK 适合对衬线字体（宋体、仿宋、明体）的精确渲染有要求的场景。

对用户意味着什么

你应该有合理预期：

简单文档（几页 Word 报告、纯文字 PPT、纯数字表格）→ 大概率能正确转换，版式 OK；
中等复杂文档（带几张图、几个表格）→ 可能有轻微偏移，但主要内容正确；
复杂文档（多层动画 PPT、大 Excel 模型、嵌视频的文档）→ 用 Microsoft Office 更靠谱。

ZenConverter 的定位是在手机上临时预览和轻量转换 Office 文档，不是做桌面端 Office 的完整替代。

为什么不承诺

README 里的那段话写得很直白：

No fidelity guarantee for Microsoft Office layout; overlapping text, shifted shapes, and degraded slide/spreadsheet layout remain expected on complex files.

ZenConverter 不假装自己能完美还原 Office 版式，是因为：

假装会让用户失望；
明确 Beta 状态 + 已知边界 → 用户知道什么场景能用、什么场景别指望；
这和 ZenConverter "诚实比万能更重要"的整体设计哲学一致。