OFD ⇄ PDF 双向转换实测系列总目录

数据来源全部为仓库实测，非厂商宣传口径：

• ofd-benchmark/docs/ofd-to-pdf.md
   —— OFD→PDF，8 个转换器
• ofd-benchmark/docs/pdf-to-ofd.md
   —— PDF→OFD，6 个转换器
• ofd-benchmark/docs/ofd-libraries.md
   —— 66 个 OFD 库能力/许可证全景表
• ofd-benchmark/README.md
   —— 项目索引与复现入口

基准参考输出来自 数科版式阅读器 导出的 test/testdata/*.pdf。这组 PDF 同时扮演两个角色：OFD→PDF 的 对比基准，PDF→OFD 的 输入样本。双向测试因此落在同一组文档上，结论可以横向对照。

全部结论按 相对排名 表述，不是 绝对性能承诺。测试的已知局限（单次运行、无方差、未记录机器规格、JIT 未预热）写在 05 篇，请勿把毫秒数当 SLA。

〇、⚠️ 数据快照声明（引用前必读）

本系列所有数字只对下列版本成立。 OFD 生态多在 0.x/1.0 早期阶段，迭代很快，新版大概率修掉本文的若干短板。

版本跨度 5 个月（2026-04-27 → 2026-09-28）。同一次测试里，有的库三天前刚发布，有的半年没更新 —— "转换失败"有时反映的是维护状态，不是实现能力。

一个已经发生过的过期实例：go-ofdgo 的 PDF→OFD 方向，在 2026-09-25 15:21 一次提交里修掉三个 bug（非 Identity-H 复合字体编码 / Stamp 注解 / nil panic），从不确定变成 7/7 全通过。本文关于 go-ofdgo 的数据，有效期可能只有几天。

哪些结论不会过期：

✅ 许可证状态（无许可证就是无许可证）✅ 路线层面的固有限制（轮廓化必然丢文本、栅格化必然丢文本和矢量）✅ 指标解读方法（像素 vs 文本该怎么一起看）⚠️ 任何具体库的成败、排名、速度、体积

复现时必须锁版本，否则你得到的是"当前版本"的数据 —— 锁法见 05 篇「局限 9.5」。

一、一句话预告：两个方向不是同一道题

OFD → PDF   已知版式 → 有损重新表达    库普遍在 100% 成功，但「文本还能不能搜/复制」天差地别PDF → OFD   逆向推断 → 无损几乎不可能  6 个库里只有 1 个既保真又保住可提取文本

这不是"谁更努力"的问题，而是信息论层面的不对称：OFD 的绘制语义（路径、TextCode、字型、CTM）是显式声明的，转 PDF 只需换一套表达；PDF 只记录"画完是什么样"，不记录"原本是什么对象"，逆向时能拿到的只有像素和已抽好的字形。

二、怎么用这份地图

三、分组目录

四、按角色的推荐路径

A. 业务方 / 采购（想 10 分钟搞懂）

01（第 1 节 + 第 2 节）→ 04（第 1 节决策树）→ 05（免责）

B. 后端 / 服务端工程师（要接进系统）

01 → 02 → 03 → 04 → 05

C. 前端 / Node 栈

01 → 02（node 行）→ 03（node 行）→ 04

D. 算法 / 质量团队（关注保真与回归）

01（第 4 节 指标口径）→ 02（第 4、5 节）→ 03（第 5 节 还原度）→ 05（第 1 节 局限 + 第 6 节 指标）

E. Java 栈（政企最常见）

01 → 02（ofdrw 行）→ 03（ofdrw 行）→ 04

结语

OFD→PDF 的难点是"表达降级"，PDF→OFD 的难点是"语义逆向"；榜单只描述样本，不描述你的业务。

数据出处：ofd-benchmark/（Ubuntu 26.04.1 LTS，已装 fonts-wqy-zenhei、fonts-noto-cjk）