质量对比 · Quality Comparison
PDF 合并前后：质量对比测试怎么做 / PDF Quality Before and After Merge: How to Test It
做 PDF 质量对比，先把变量固定住：同一份源文件，合并前存一页基准图，合并后再导出同一页，在同样的缩放比例下并排看。合并本身不重新编码图像，正确的对比结果应该几乎看不出差别。
阅读约 7 分钟 · 7 min read
一句话结论
做 PDF 质量对比，先把变量固定住：同一份源文件，合并前存一页基准图，合并后再导出同一页，在同样的缩放比例下并排看。合并本身不重新编码图像，所以正确的对比结果应该几乎看不出差别。如果你测出了明显掉画质，问题多半出在合并前后多跑的那一次压缩，而不是合并这一步。
A useful PDF quality comparison holds every variable still. Save a reference page from the source, export the same page from the merged file, and look at both at the same zoom level. A merge copies encoded image streams rather than re-encoding them, so the two should look the same. If they do not, the loss came from an extra compression pass, not from the merge.
对比测试怎么搭 / Setting up a comparison you can trust
多数人做的对比是无效对比：拿手机上截的图跟电脑上的原件比，缩放比例还不一样。这样比出来的差异全部来自观察和截图过程，跟合并没关系。
- 合并前先把源文件的目标页导出一张基准图，命名带 before
- 合并完成后，从成品里导出同一页，命名带 after
- 缩放固定在 100% 和 400% 两档，不要用「适应窗口」，它会按窗口大小重采样
- 用同一个阅读器、同一台机器看，换渲染器引入的差异比合并本身大得多
- 关掉「平滑图像」「增强细线」这类显示选项，它们专门用来掩盖画质问题
- 比图片本身，不要比整页截图，整页截图等于又重采样了一次
Most comparisons people run are not valid. One screenshot comes from a phone, the other from a desktop viewer, at different zoom levels. Every difference you see comes from the viewing and the screenshot step, not from the merge. Export a reference image of the target page before merging, name it before, export the same page after the merge and name it after. View both at 100% and 400%, never at fit-to-window, which resamples to the window size.
该看哪六个指标 / Six numbers worth checking
肉眼并排看只能发现明显问题。下面这几项能读出数字，每一项都对应一种具体的失败模式。
| 指标 | 合并前 | 合并后预期 | 异常说明 |
|---|---|---|---|
| 图像分辨率 / DPI | 300 | 完全一致 | 下降说明图像被重新编码过 |
| 页面尺寸与旋转 | A4 / 0° | 一致 | 出现旋转说明页面树被重建 |
| 文件大小 | 12.4 MB | 约等于两份之和 | 暴增说明字体或图像被重复嵌入 |
| 文字可选性 | 可选可搜 | 仍然可选 | 变成图片说明页面被栅格化 |
| 色彩空间 | sRGB | 一致 | 改变说明发生了色彩转换 |
| 书签与内部链接 | 3 层 | 保留 | 丢失说明结构信息被丢弃 |
DPI 这一项最该盯。数值下降就意味着图像流在链条上被解码又重新编码过，后面几项多半也会跟着出问题。
DPI should come out identical. A drop means the image stream was decoded and re-encoded somewhere in the chain. File size should land near the sum of the two sources, and a big jump usually means fonts or images got embedded twice.
三种会带偏结论的测法 / Three ways the test misleads you
- 拿压缩后的成品比合并前的原件。这样比出来的是压缩的损失，合并替压缩背了锅。要比就全程不压，或者两边各压一次。
- 用截图工具取图。截图工具按屏幕分辨率重新采样，300 DPI 的页面截下来只剩 96 DPI，你在比的是截图器。
- 在不同阅读器之间比。各家渲染器对细线和渐近色的处理不一样，同一份文件在两个阅读器里的差异，往往比合并带来的差异大一个量级。
Comparing a compressed result against an uncompressed original measures the compression, not the merge. Screenshot tools resample to screen resolution, so a 300 DPI page comes out at 96 DPI and you end up comparing the screenshot utility. Different viewers also render thin lines and gradients differently, often by a wider margin than anything a merge produces.
一次成型的本地流程 / A local workflow that tests cleanly
把对比放进流程里，而不是等出问题再回头查。文件全程不出本机，也不用为了验证画质去在线工具上反复上传。
- 合并前导出基准页，存好 before 版本
- 按最终阅读顺序排列源文件，一次排好，避免事后返工
- 在本地完成合并，先输出全分辨率版本
- 导出同一页的 after 版本，与 before 并排比对
- 逐项核对上表的六个指标，不只看肉眼
- 确认无误后再决定要不要压缩，压缩只做一次
- 成品与母版分名存两份，别互相覆盖
压缩与合并的先后顺序见 /blog/compressed-pdf-merge-quality-loss 里的说明；涉及几百 MB 的材料，先读 /blog/large-pdf-merge-500mb 会省不少时间。
在 pdfmergenext.shop 合并 PDF，合并前后自己验一遍 →更多 PDF 质量对比的做法见 /blog。
常见问题 / FAQ
合并后的 PDF 画质为什么会变差？
多数情况不是合并造成的。合并把已编码的图像流搬进新容器，不动像素。变差通常是因为合并前或合并后又跑了一次有损压缩。要验证就全程不压，比一次纯合并。
为什么同一页在两个阅读器里清晰度不一样？
各家渲染器对细线和抗锯齿的处理不同。做 PDF 质量对比时固定在同一个阅读器、同一缩放比例下看，否则测到的是阅读器差异，不是文件差异。
400% 下看文字边缘有毛刺，是不是合并的问题？
先看源文件本身在 400% 下是什么样。扫描件放大后本来就会显出毛刺，那是扫描分辨率的边界。把 before 和 after 并排放，两边一样就说明合并没有额外损失。
Does merging PDFs reduce image quality?
Not by itself. A merge copies encoded image streams into a new document. Softening appears when lossy compression runs before or after the merge, so test with compression out of the picture first.
What zoom level should I use when comparing?
100% for overall sharpness and 400% for edges and thin strokes. Skipping fit-to-window matters more than people expect, since that mode resamples to whatever window size you happen to have open.
Why is my merged file larger than the two sources combined?
Usually duplicated font subsets or repeated image objects. Check the DPI first. If the resolution is unchanged, the extra bytes are structural rather than a quality problem.