
这几天,我们让 Office 预览更接近真实交付
持续打磨 Office 在线预览之后,我们越来越清楚一件事:
真正有价值的能力,不只是把文件“打开”,而是在浏览器里尽可能保留那份文档原本的秩序、结构和质感。
表格要像表格,目录要像目录,PPT 要有演示文稿的画面感,Excel 要能快速扫数据。尤其是客户现场那些真实文件,往往比任何测试样例都更复杂。
这几天,我们围绕 Flyfish Office Preview 做了一轮集中迭代。核心方向很明确:继续提升 DOCX、PPTX 的真实渲染效果,同时让 Demo 从“可以验证功能”进一步走向“具备产品观感”。
这篇文章是一篇开发手记,也是一封写给关注这个项目的朋友们的进度说明。
如果你想直接看效果,可以打开产品主页:
https://product.flyfish.group[1]

为什么我们一直盯着渲染细节
Office 文件预览有个很容易被忽略的问题:只要内容稍微复杂一点,“能看到文字”和“能交付给客户”之间差得很远。
比如 Word 文档。
一份测试报告里,标题、目录、缩进、编号、表格、页眉页脚、图片、公式都可能同时出现。目录里的点线如果错位,编号如果变成乱码,表格如果撑破页面,用户立刻会觉得“不像原文档”。
再比如 PPT。
PPT 不只是文字和图片。它有母版、组合图形、文本框、表格、背景、图形裁剪、矢量对象。有些页面的设计感很强,少一个元素都明显。
这就是我们这轮更新的重点:不把精力停留在抽象概念上,而是把时间投入到真实文件最容易暴露的渲染细节里。
DOCX:从“看得到”继续往“看得像”走
DOCX 这次提升比较明显。
我们重点处理了几类问题:
目录制表符和缩进对齐 Word 符号项目符号归一化 EMF 图形渲染 OMML 公式呈现 修订中已删除数学内容的隐藏 段落、表格、分页相关细节
这些点听起来都很细,但它们决定了文档是不是像一份正式 Word。

这张图不是为了展示一个“炫”的页面,而是展示一类更常见、更真实的企业文档:长文档、层级标题、正文段落、表格说明。
很多系统里最常出现的恰恰是这种文件:测试报告、接口规范、验收材料、项目文档、档案说明。它们不花哨,但对版式稳定性要求很高。
对我们来说,DOCX 的目标不是把 HTML 拼出来,而是让用户在浏览器里阅读时,不需要反复怀疑:这个地方是不是渲染错了。
PPTX:演示文稿的画面感要保住
PPTX 这一轮也完成了多项面向真实页面的渲染增强。
重点包括:
DrawingML 文本布局对齐 PowerPoint 表格渲染 组合装饰元素展示 表格样式还原 OLE fallback 展示 EMF / DIB 预览资源处理
PPT 的难点在于,它不是线性文档,而是一页一页设计好的画面。
文字位置、图形层级、背景关系、页面比例,都会影响最终观感。

这轮更新之后,PPTX 在复杂页面上的稳定性有了明显提升。尤其是带图形、带表格、带组合元素的页面,整体结构更接近原始演示文稿。
我们也同步完善了老版 PPT 的表现,包括母版布局、旧图形、分组图片裁剪、字体 fallback、段落间距、日期字段和短文本布局等。
因为真实客户文件不会只给你 .pptx。很多项目里,历史 .ppt 仍然大量存在。
Demo 也换了一种思路
这次 Demo 的变化不只是换了颜色。
以前的 Demo 更像一个测试页:选择文件、触发渲染、查看结果。虽然已经可以完成验证,但离正式产品应有的体验还有距离。
这次我们把 Demo 往更清晰的产品方向整理了一下。

主要变化包括:
左侧导航按文档、演示、表格分组 Word / PowerPoint / Excel 使用不同主题色 内置样例以卡片方式展示 上传文件和内置样例都放在更清楚的位置 渲染状态、耗时、模型、WASM 状态集中展示 诊断信息调整为抽屉形式,让主要预览区保持专注 仅在选择格式后加载对应模块,减少无关资源进入页面
这件事很重要。
因为客户判断一个产品,往往不是先看代码结构,而是先看打开后的第一眼:清不清楚、稳不稳、像不像能交付的东西。
Demo 是第一层信任。
如果 Demo 自身缺少秩序感,用户很难相信它能够自然融入自己的业务系统。
我们想做的是纯前端 Office 预览的标杆
这个目标并不轻松,但它确实是我们愿意长期投入的方向。
Office 预览有很多路线:服务端转换、在线办公套件、浏览器插件、第三方服务、完整协作平台。
这些方案都有价值。
Flyfish Office Preview 选择的是更轻的一条路:尽量在纯前端环境里,把 Word、PowerPoint、Excel 的预览体验做好。
这条路注定需要耐心。
老格式需要长期兼容,PPT 图形需要细致处理,Word 表格和目录需要反复校准,Excel 样式也需要持续完善。与此同时,客户部署环境、文件鉴权、内网域名、CSP、跨域、iframe 嵌入等工程问题,也都需要被认真对待。
但它的价值也很明确:
不必为了预览引入完整在线办公套件 更容易嵌入现有业务系统 更适合私有化和内网场景 交付边界更轻 用户打开附件的路径更短
我们希望它最终成为一种能够顺畅进入项目现场的 Office 预览能力。
它不应该只停留在演示页面里,而应该陪客户一起完成真实文件、真实环境、真实流程的验证。
一次付款后,我们会持续把效果往前推
这里也想把我们的态度说清楚。
Flyfish Office Preview 不是卖完就结束。
一次付款后,我们愿意根据购买客户的实际文件和真实需求,持续做无偿更新,尽力把预览效果推进到客户满意、项目可交付的程度。
这不是一句漂亮话。
Office 预览这类产品,如果不听客户文件、不看真实场景,只靠自己想象,很容易越做越偏。
客户给出的每一份异常文件,都是下一次迭代的线索。
一个表格撑破页面,可能暴露的是行高计算问题。
一个 PPT 图形缺失,可能暴露的是某类 DrawingML 或 EMF 记录没有处理。
一个目录点线错位,可能暴露的是制表位、段落缩进和超链接布局之间的关系。
我们愿意把这些问题逐项沉淀下来,并持续转化为产品能力。
只要需求合理、问题真实,并且对产品长期价值有帮助,我们都会持续投入优化。
这也是我们希望大家支持的原因:这个产品不应该在封闭环境里独自生长,它需要真实用户、真实文件和真实反馈共同塑造。
售后不是交付文件之后就结束
Office 预览真正考验耐心的地方,很多都发生在部署之后。
文件地址要登录态。
客户网关改了响应头。
iframe 嵌入后高度异常。
CSP 或跨域规则拦住资源。
某个历史 .doc 或 .ppt 有特殊对象。
某个客户模板里出现了极少见的版式组合。
这些问题如果缺少有人陪同排查,往往会消耗大量项目时间,也会让原本简单的预览需求变得令人疲惫。
所以我们的售后更偏“部署陪跑”。
从部署、域名、授权、文件访问,到样例文件定位、页面集成、疑难问题处理,我们会陪同完成整个过程,直到预览能力真正达到可使用、可验收、可交付的状态。
软件产品最终比较的不只是功能列表,也包括问题出现时,是否有人愿意认真接住并持续推进。
定制适配也会继续做
这次项目里,我们也继续关注插件式适配能力。
比如可道云这类系统,它不是简单打开一个独立页面就行。它需要从原系统文件列表进入预览,需要接收文件参数,需要处理鉴权,需要保持嵌入体验,还要尽量不破坏原有操作习惯。
Flyfish Office Preview 会继续支持这类定制:
可道云插件式适配 内网私有化部署 指定域名授权 文件接口鉴权打通 UI 风格融合 客户样例文件专项优化 按项目需求扩展预览入口
我们不希望客户为了接入预览,重新调整整个系统。
更理想的方式是:预览能力像一块干净的模块,被放到原有业务流里,然后自然工作。
欢迎提出需求,也欢迎反馈问题
我们很欢迎大家把真实需求提出来。
如果你手上有典型 Office 文件,如果你遇到过某个预览方案解决不了的文档,如果你正在建设 OA、档案、合同、知识库、网盘、CRM、SaaS 附件预览,都欢迎直接交流。
有些问题可以在短期内完成优化。
有些问题需要排期。
有些问题可能会变成产品长期能力的一部分。
但只要方向是让纯前端 Office 预览更稳定、更可交付,我们都会认真看。
接下来还会继续更新
接下来会继续推进几件事:
DOCX 复杂文档细节优化 PPTX 图形、表格、母版、媒体资源完善 DOC / PPT / XLS 老格式兼容 Excel 工作表和样式表现提升 WASM / Worker 链路继续收敛 Demo 交互和移动端体验优化 更多客户样例文件回归 插件式集成能力完善
我们的目标很朴素:让 Office 预览这件经常被低估的体验,在企业系统里变得更可靠、更优雅,也更让人放心。
如果你愿意支持这个方向,欢迎购买,也欢迎直接提需求。
产品主页:
https://product.flyfish.group[2]
购买入口:
https://dev.flyfish.group/shop[3]
售后邮箱:
wybaby168@gmail.com[4]
微信客服:
Yous_Gift
我们会持续投入,也会认真回应每一份来自真实场景的反馈。
希望 Flyfish Office Preview 能成为纯前端 Office 预览里,一个真正拿得出手、能够进入项目现场、也经得住真实文件考验的选择。
引用链接
[1]https://product.flyfish.group
[2]https://product.flyfish.group
[3]https://dev.flyfish.group/shop
[4]wybaby168@gmail.com: mailto:wybaby168@gmail.com
夜雨聆风