PDF 线性化（Fast Web View）冷门细节：Hint 表、对象排序与 Range 请求

当你在网页里打开体量不小的 PDF，却能几乎立即看到第 1 页，这通常不是「加载很快」，而是文件被 线性化（Linearized / Fast Web View） 了。线性化的核心是：将第一页渲染所需的对象打包到文件头部，并附带一份用于随机访问的 hint 表，以便客户端通过 Range 请求分段拉取后续页面。

它到底做了什么？

1. 对象重排：把第一页的页面字典、内容流、字体子集、图像流等，尽量放在文件开头；剩余对象按页块或资源块顺序布局。
2. Hint 表：在 Header 里记录「某页从哪儿开始、长度多大」，客户端可按需发起 HTTP 分段下载。
3. 单一 xref：为首段与后续段分别组织交叉引用，减少解析与定位成本。

如何判断一个 PDF 是否线性化？

最可靠的方式是工具检查：

# qpdf（跨平台）
qpdf --is-linearized your.pdf && echo "linearized"

# 进一步做一致性检查
qpdf --check your.pdf

或直接看响应是否触发 Range 请求：

# 用 curl 模拟分段请求第一页附近
curl -H "Range: bytes=0-2047" -I https://example.com/your.pdf

# 预期返回包含：
# HTTP/1.1 206 Partial Content
# Accept-Ranges: bytes

制作或修复线性化

生产场景中，你可以在导出环节或上线前做一轮「线性化重排」：

# 将输入 PDF 线性化输出
qpdf --linearize input.pdf output.pdf

# Ghostscript 也能配合（同时压缩图像/子集化字体）
gs -sDEVICE=pdfwrite -dFastWebView=true -o output.pdf input.pdf

注意：如果原文件的字体没被正确子集化，第一页仍可能依赖大量跨页资源，线性化收益会被稀释。

小众但实用的优化点

• 字体子集：确保首屏字形集合最小化；避免整套 CJK 字体打进第一页。
• 图像切片：把大图切分为若干条带或瓦片，首屏只放必要部分，其余延后。
• 对象去重：模板页、重复背景图形用引用，不要多份拷贝，减小首段体积。
• 结构流与标签：对可访问性友好，但别把庞大的结构树挤进文件开头。

浏览器与阅读器的差异

不同实现对线性化的利用程度不同。Chromium 家族的 PDFium、Firefox 的 pdf.js、以及各类原生阅读器，对 hint 表解析与并行拉取策略不一致，因此「是否明显提速」取决于客户端实现与网络时延。

验证与指标

建议至少采集以下指标：

• FPV（First Page Visible）时间：从发起请求到第一页可见的时长。
• Range 命中率：是否出现 206/Accept-Ranges 以及多段抓取。
• 首段体积：线性化后 0~N 字节大小；越小越有利于弱网。
• 总往返次数：渲染前两页需要的分段数，减少 RTT 是关键。

常见坑

• CDN 压缩干扰：开启静态 Gzip 后，某些代理会移除或错误处理 Accept-Ranges，导致分段下载失效。
• 签名与增量更新：对签名过的 PDF 再线性化可能破坏签名；增量更新段也会改变对象布局。
• 表单/注释：交互对象分散各处，若首屏依赖它们，应显式前置。

结语

线性化不是银弹，但在「弱网 + 大文件 + 首屏优先」的组合里，它是最成本可控的优化之一。上线前，用 qpdf 做线性化与一致性检查，用抓包确认 Range 行为，再用真实设备测 FPV，基本就能获得可量化的收益。