为什么 PDF 阅读器给不了答案
用任何阅读器打开 PDF,屏幕上的每一种颜色都是 RGB——包括文件中声明为 CMYK 的颜色,也包括 Pantone 专色。这不是显示层面的便利,而是发生在解析阶段:pdf.js 在求值页面时会把 setFillCMYKColor 改写成 setFillRGBColor。等到画面呈现出来,原始的颜色模型早已消失。
因此本工具不看渲染结果。它解析原始内容流,读取制作方真正写下的操作符——g、rg、k、cs 与 scn——通过 /Resources /ColorSpace 解析命名空间,并读取每个图像 XObject 自身的 /ColorSpace 与 /BitsPerComponent。
文字、矢量与图像分开看
「第 4 页有 RGB」帮不上忙。「第 4 页的标志图像是 RGB,而该页所有文字都是 CMYK」才是可以据以修改的结论。对象同时按类型和颜色模型分类,因此可以立刻看出问题出在置入的照片、遗留的色块,还是正文文字。
CMYK 文件里的 RGB JPEG 是最常见的印前问题,它有专门的警示。
可点击的色块
每一种找到的颜色都以色块显示,并附上实际数值——C 90 M 20 Y 0 K 5、R 217 G 38 B 51、K 35——按模型分组并计数。点击其中一个,页面预览会高亮所有使用该颜色的对象。
灰度检查
声明为 CMYK 与实际上是 CMYK 是两回事。只用黑色、或用等量 C、M、Y、K 绘制的页面,可以只用一块版印刷——这是实实在在的价格差异。渲染灰度检查单独按需运行,因为每页都要栅格化一次。
局限
统计的是绘制操作,而不是视觉元素:一个标志可能由三百个填充组成。文字的高亮框是近似的,要精确定位需要每种字体自身的字形宽度数据。
隐私
所有处理都在浏览器中完成,文件不会被上传。
Tiny Online Tools







