LibreOffice 26.8 发布后，再看 BaseMetas FileView 的 Office 转 PDF 技术路线

​2026 年 8 月 26 日，The Document Foundation 正式发布 LibreOffice 26.8。这个版本最受关注的变化包括 Paragraph Composer、复杂文字系统支持、OpenType Variable Fonts、文档交换保真度以及大文档性能优化。官方甚至直接把这一版本的三个重点归纳为：排版质量、全球书写系统支持和与其他 Office 软件交换文档时的保真度。

如果只是把 LibreOffice 当成一套免费的桌面 Office，这些变化或许只是一次普通的大版本升级；但对于 BaseMetas FileView 这样的文件在线预览产品，它还有另外一个更重要的身份：Office 文档排版与 PDF 转换引擎。

在BaseMetas FileView 中，DOC、DOCX、PPT、PPTX，以及经过格式识别和规范化后的部分 WPS/WPT 等文件，可以通过 LibreOffice 完成服务端解析、排版和 PDF 输出，最终再交给浏览器进行统一预览。这条技术路线看起来传统，但直到今天，它在版式还原、格式覆盖、稳定性以及综合转换效率方面，仍然远比直接把 Office 文件解析成 HTML，再交给 Tiptap 等富文本编辑器渲染更加适合“文件预览”这个场景。原因并不只是 LibreOffice 功能更多，而是：两者从底层解决的根本就不是同一个问题。

一、文件预览首先是“版式还原”，而不是“内容编辑”

很多在线文档方案最初容易走向这样一条路线：DOCX➜解析 XML➜转换为 HTML / JSON➜Tiptap / ProseMirror / 富文本编辑器➜浏览器渲染。对于知识库、在线笔记、轻文档和 AI 生成内容，这种方案非常合适。因为这些产品更关心：标题、段落、列表、图片、表格和内容结构是否正确。但文件预览面对的问题不同。用户上传一个合同、公文、投标文件、财务报告或者几十页 Word 文档时，他真正期待的是：“打开以后应该尽可能和原文件一样。”这里要求还原的不只是内容，而是一整套物理页面布局：字体+字号+字符宽度+段落间距+行距+分页+分节+页边距+页眉页脚+脚注尾注+表格跨页+文本框+图片锚+浮动对象+目录与域+页面方向。对于 PowerPoint，还要继续处理：母版+版式+文本框+图形+图片+图表+层级+旋转+坐标+动画对象。这已经不再是普通意义上的“富文本”。它实际上是一个完整的：Document Layout Engine。

二、LibreOffice 和 Tiptap 的本质区别，不是桌面端与 Web，而是 Layout Engine 与 Editor Model

Tiptap 建立在 ProseMirror 之上，其核心非常适合表达结构化内容。文档可以表示为 JSON，再映射成 HTML 和浏览器 DOM。Tiptap 官方同样提供 HTML 与 JSON 之间的转换能力。其典型模型更接近：

Document
 ├─ Heading
 ├─ Paragraph
 │    ├─ Text
 │    └─ Bold
 ├─ Image
 ├─ List
 └─ Table

这是一个非常优秀的逻辑文档模型。但是 Microsoft Word 文档不仅有逻辑结构，还有物理页面。例如同样一个段落：这是一段合同正文……。最终位于第一页还是第二页，并不是 DOCX 中直接写死的。排版引擎需要根据：

页面宽度
 - 左右页边距
 - 字体真实宽度
 - 字号
 - 字符间距
 - 标点规则
 - 行距
 - 前后段落
 - 相邻对象
 = 当前页面还能放多少内容

动态计算。一个字符宽度稍有变化，就可能造成：第 18 行多出一个字符➜产生额外换行➜段落整体变高➜表格下移➜分页位置变化➜后面几十页全部发生偏移。这就是 Office 排版最麻烦的地方。LibreOffice Writer 本身就是完整的文字处理器，它拥有成熟的字体测量、段落排版、分页、表格、浮动对象和页面布局系统。因此它处理 DOCX 时实际上进行的是：DOCX➜Office Import Filter➜LibreOffice Document Model➜Font / Paragraph / Table / Object Layout➜Page Layout➜PDF。而不是：DOCX➜HTML➜CSS➜Browser。这就是两种路线最大的区别。

三、现在的 Tiptap 已经有 Pages，但也恰恰说明 Office 排版有多复杂

需要说明的是，到了 2026 年，已经不能简单地说“Tiptap 没有分页”。Tiptap 现在已经推出 Pages，可以实现 A4 等页面尺寸、页边距、页眉页脚、分页以及 DOCX/PDF 导入导出。这说明 Web 富文本编辑器正在越来越接近传统 Office。但同时，Tiptap 官方目前仍将 Pages 标记为 Beta，而且公开文档中明确列出了一些限制，例如部分不可拆分 Block 的跨页处理、脚注跨页、多栏布局、页面级模板等能力仍不完整。甚至 DOCX 的 Page Size、Margins 等信息，在部分 Conversion 链路中也还不能完整直接还原。这其实反过来说明了一件事情：把一个富文本编辑器逐步做成 Office，本质上就是重新实现一套 Office Layout Engine。

因此对于 BaseMetas FileView 这种目标是“查看已有文件”而不是“重新发明 Word”的产品来说，更合理的工程选择仍然是：直接利用成熟 Office 引擎完成版式计算。

四、LibreOffice 26.8 的排版升级，对文件预览有什么实际意义？

LibreOffice 26.8 最大的排版变化之一，是新的 Paragraph Composer。传统文字处理器通常逐行计算两端对齐，而新的 Paragraph Composer 会综合连续多行计算词间距，使一个段落的整体视觉效果更加均匀。对于 BaseMetas FileView 来说，它的意义并不是：LibreOffice 26.8 从此完全解决中文 Word 兼容问题。此前实际对比已经可以看到，复杂中文 DOCX 的排版还原度，LibreOffice 与 Microsoft Office、WPS 之间仍然存在差异。但它说明 LibreOffice 的底层 Layout Engine 仍然在持续演进。而文件预览真正依赖的，正是这些能力：字体测量➜字符布局➜段落布局➜表格布局➜页面布局➜最终 PDF。相比增加一个新的工具栏按钮，这类底层变化对“Office→PDF”反而更有价值。

五、Variable Fonts、复杂文字和字体识别，也会直接影响 PDF 结果

26.8 还原生支持 OpenType Variable Fonts，并继续改善复杂文字、RTL、竖排 CJK 和字体名称识别。这些变化看起来离普通文件预览很远，但实际上字体正是 Office 转 PDF 最容易产生差异的环节之一。同一个 DOCX：原字体存在➜字宽 = A➜一行 34 个字符。如果字体缺失发生替换：Fallback Font➜字宽 = B➜一行只能放 32 个字符➜重新换行➜重新分页。最终差异可能从一个字体逐渐扩散到整个文档。

所以对于 FileView 来说，LibreOffice 26.8 的字体、复杂文字和排版能力优化，真正提升的是：最终 PDF 的版式稳定性。当然，产品部署时仍然需要提供完整的中文字体环境，否则再先进的排版算法也无法解决字体缺失造成的页面偏移。

六、26.8 对大文档的性能优化，对 Office→PDF 更有现实意义

对于文件预览产品来说，另一个非常重要的指标是：转换速度。Office 转 PDF 大致可以拆成三个阶段：文件读取与解析➜文档布局计算➜PDF Export。

LibreOffice 26.8 官方特别提到：Writer 打开包含大量图片的超大文档已经显著加快。虽然官方说的是“打开速度”，但对于服务端转换来说，打开文件本身就是转换流水线的前半段：loadComponent➜解析 DOCX➜加载图片➜建立 Document Model➜Layout➜Export PDF。因此，大文档加载优化会直接减少部分 Office→PDF 任务的前置耗时。特别是实际业务中经常遇到：

• 几十甚至数百页 Word；
• 大量扫描图片；
• 高分辨率照片；
• 大量表格；
• 图片型合同；
• 复杂页眉页脚。

这类文件比普通十几 KB 的测试文档更能体现这种优化的价值。

七、为什么服务端 LibreOffice→PDF，整体预览体验反而可能更快？

这里需要区分两个概念：转换速度和用户感知的预览速度。如果只是一个非常简单的 DOCX：DOCX ➜ HTML。当然可能比：DOCX ➜ LibreOffice ➜PDF更快。因此不能简单得“LibreOffice 一定比 Tiptap 快”。但复杂 Office 文件真正追求的是：速度 + 还原度。如果使用浏览器富文本路线，完整链路可能变成：下载 DOCX➜解析 ZIP / XML➜转换为 Editor Schema➜生成 DOM➜加载图片➜浏览器字体测量➜CSS Layout➜分页算法➜持续 Reflow。而 FileView 采用 PDF 中间格式以后：Office➜服务端 LibreOffice➜PDF➜缓存➜PDF.js 按页加载。

第一次访问需要付出 Office→PDF 的成本，但后续访问直接复用转换结果。对于多人查看同一附件的 OA、合同、档案和知识库场景，这个差别非常重要：

第一次访问
Office → PDF

第二次访问
PDF

第100次访问
还是 PDF

而不是每个用户的浏览器重新解析一次 Office。所以从整个生命周期计算：服务端一次转换 + 结果缓存，往往比客户端重复解释 Office 文件更加经济。

八、LibreOffice 天然适合服务化转换

LibreOffice 官方本身就提供 Headless 模式以及命令行文件转换能力，例如：

soffice --headless
soffice --convert-to pdf

同时还可以通过 UNO API 由外部程序控制 LibreOffice。PDF Export Filter 也支持页面范围、水印、PDF 版本、安全等参数。因此在文件预览系统里，可以进一步封装成：BaseMetas FileView➜Conversion Service➜LibreOffice Worker Pool➜Writer / Impress➜PDF Export➜ Preview Cache➜PDF.js

实际部署时通常不需要每个文件都重新启动 LibreOffice，而可以使用常驻进程池，通过 UNO 等方式重复利用已经启动的 Office Worker这样可以把：

JVM / Process Start
LibreOffice Start
Font Init

这些冷启动成本摊薄到多个任务中。对于批量转换系统来说，真正影响吞吐量的往往不是某一个 API 调用快几十毫秒，而是：进程是否复用、并发是否受控、大文件是否隔离、字体是否预热以及转换结果是否缓存。

九、PDF 作为在线预览中间格式，本身就是一个很重要的优势

Office 文件最大的问题，是它并没有一个完全统一的浏览器渲染标准。PDF 则完全不同。一旦 LibreOffice 已经完成：DOCX➜排版➜分页➜PDF。后续预览就不再需要理解 Word。前端只需要理解 PDF。这使整个架构从：

前端需要理解
DOC / DOCX / PPT / PPTX / WPS / WPT

变成：

服务端解决格式差异
        ↓
统一 PDF
        ↓
前端统一预览

对于 BaseMetas FileView 来说，这种“能力收敛”非常重要。因为文件预览产品最终追求的并不是：浏览器能解析多少种 Office XML。而是：无论上传什么文档，最终用户看到的预览行为尽可能一致。

十、LibreOffice 26.8 对 PDF 输出本身也更加重视

LibreOffice 26.8 还有一个不太显眼、但对文件转换产品很有价值的变化：官方自动化测试开始使用 VeraPDF 验证 PDF 输出。这并不意味着 LibreOffice 导出的所有 PDF 从此都不会出现问题，但至少说明：PDF 已经不仅仅是一个附带 Export 功能，而是持续进入自动化质量保障体系。对于 BaseMetas FileView 这种把 PDF 当作预览中间格式的产品而言，这类底层质量建设往往比 UI 功能更新更重要。

十一、没有生成式 AI，对转换服务反而是一种优势

LibreOffice 26.8 还特别强调：自身不包含生成式 AI，正常工作不依赖网络。对于桌面办公软件来说，这个选择可能存在争议。但对于一个后台文件转换引擎来说，这反而非常合理。转换服务真正需要的是：输入文件➜稳定解析➜稳定排版➜稳定输出。根本不需要：账号登录、云服务、AI Provider、外部模型调用、互联网连接。所以 LibreOffice 可以比较容易地运行在：

• Docker；
• Kubernetes；
• 政务内网；
• 企业私有云；
• 无互联网环境。

这与 FileView 作为基础文档服务的定位天然契合。

十二、WPS/WPT 等格式，更应该先识别真实格式再决定转换引擎

还有一个工程问题不能忽略。文件后缀并不一定代表真实格式。

例如 .wps、.wpt 在历史上可能对应不同来源、不同版本，甚至可能与 Word 二进制格式存在兼容关系。LibreOffice 官方转换过滤器也能够识别部分以 WPS/WPT 为扩展名的 Word 兼容文件。

LibreOffice 应该是整个转换体系中的重要引擎之一，而不是所有 Office 文件唯一的处理方式。这也更符合实际工程场景。

十三、为什么不能只依赖 LibreOffice？

LibreOffice 很适合作为 Office→PDF 的核心转换引擎，但它同样不是万能的。首先，复杂中文 DOCX 的排版结果仍然可能与 Microsoft Office、WPS 存在差异。其次，以下场景依然容易成为高风险文件：

• 超高分辨率图片；
• 超大表格；
• SmartArt；
• 复杂图表；
• OLE；
• 嵌入对象；
• 特殊字体；
• 宏；
• 异常 DOCX；
• 损坏的二进制 Office；
• 私有 WPS/WPT 格式。

LibreOffice 26.8 对部分新型 Microsoft OOXML 图表目前甚至仍然只能保留原始结构，而无法真正渲染，因此转换成 PDF 时这些对象也无法完整呈现。所以成熟文件预览产品更合理的架构不是：所有文件➜LibreOffice，而应该是：文件➜真实格式识别➜风险扫描➜复杂度判断➜引擎路由➜ LibreOffice / 其他转换能力➜PDF➜统一预览。这也是“文件预览平台”和简单调用 soffice --convert-to 最大的区别。

十四、真正的优势：LibreOffice 已经替你做了几十年的“脏活”

回到最开始的问题：

为什么到了 2026 年，BaseMetas FileView 这种文件预览产品仍然值得使用 LibreOffice 作为 Office 转 PDF 引擎？

答案其实不是因为：LibreOffice 能打开 DOCX。真正重要的是，它背后已经拥有一整套成熟的：

Office Format Parser+Font Engine+Text Layout+Paragraph Layout +Table Layout+Page Layout+Drawing / Image+Presentation Engine+PDF Export。如果采用普通富文本编辑器实现 Office 预览，那么这些能力最终还是要重新补回来。从：分页开始，然后是：

页眉页脚
→ 表格跨页
→ 脚注
→ 分节
→ 多栏
→ 浮动对象
→ 字体测量
→ Word兼容规则

最后实际上就是：重新做一套 Office 排版引擎。对于在线笔记和轻文档，这当然没有必要。但对于 BaseMetas FileView 这样的文件预览产品，核心目标不是改变原文档，而是尽可能忠实地呈现原文档。因此更合理的技术路线仍然是：Office 文件➜成熟 Office Layout Engine➜高保真 PDF➜统一 Web Preview。LibreOffice 26.8 的意义也正在这里。

Paragraph Composer、字体系统、复杂文字、大文档加载性能以及 PDF 自动验证等更新，看似是桌面 Office 的普通版本升级，但放到文件预览产品中，它们改善的恰恰是最底层、最难重新实现的能力：解析、排版、分页和输出。所以对于 BaseMetas FileView 来说，LibreOffice 的价值从来不只是“一个免费的格式转换工具”。更准确地说，它是：一套可以服务化部署、持续演进，并经过多年真实文档验证的开源 Office 排版与转换基础设施。而这，才是它在文件在线预览体系中最难被 Tiptap、普通富文本编辑器甚至简单 DOCX→HTML 方案替代的真正原因。

相关资料

BaseMetas 介绍：https://basemetas.com/

社区版

• BaseMetas Fileview GitHub：https://github.com/basemetas/fileview

​