我们团队在Shopware 6店铺里生成的发票PDF遇到了个头疼的问题：在Chrome、Firefox浏览器和Ubuntu自带的PDF查看器里显示都完全正常，但放到Acrobat Reader里就不对劲了——本该显示logo和订单明细的地方，只露出一小部分内容。更奇怪的是，查看文件属性时，test.pdf标注是PDF 1.7版本，却显示“0 pages”，这明显和实际内容不符。

我们已经做了一些排查尝试，想和大家交流下思路：

已用工具检测情况 #

我们用了Datalogics的pdfchecker工具做了全面检测，运行的命令是：

./pdfchecker -i example.pdf -j CheckerProfiles/everything.json

检测结果里有几个值得注意的点：

• 实际PDF页数是1，生成工具是dompdf 1.0.3 + CPDF
• 检测到包含透明内容，提示透明效果并非所有PDF查看器都支持，建议用PDF Optimizer扁平化
• 发现两个无法提取文本的字体，字体名显示成了乱码（比如SUBAAB+匀漀甀爀挀攀匀愀渀猀倀爀漀ⴀ刀攀最甀氀愀爀），但我们的发票里根本没用到中文字体，这大概率是字体生成过程中出了编码问题
• 存在低分辨率的彩色和灰度图片，还有未压缩的流，不过这应该不是显示异常的核心原因
• 整体检测下来没有明确的“错误”提示，只有一些优化建议

环境差异排查 #

目前我们没法提供可复现的PDF文件，因为这个问题只在生产环境出现——就连同一服务器上的staging环境都完全正常。同事对比后发现，生产环境的source_sans_pro_normal.ufm.php文件和staging的不一样，这个文件是dompdf自动生成的字体配置文件，我们正在追踪这个差异是怎么产生的。

后续排查思路（求建议） #

现在我们打算从这几个方向继续深挖：

• 先尝试扁平化PDF的透明层，看看Acrobat Reader能不能正常显示，验证透明内容是不是罪魁祸首
• 重点排查生产环境的dompdf字体生成逻辑：为什么会出现乱码的字体名？是不是字体源文件损坏，或者生成时的编码环境有问题？
• 彻底对比生产和staging环境的dompdf配置、字体文件权限、生成时的服务器环境变量，找出source_sans_pro_normal.ufm.php差异的根源
• 考虑更新dompdf到最新版本，看看是不是旧版本（1.0.3）存在和Acrobat Reader兼容的bug
• 换用Adobe官方的PDF Preflight工具做检测，说不定能找出pdfchecker没发现的Acrobat专属兼容性问题

有没有遇到过类似问题的朋友，给点经验或者其他排查方向呀？

备注：内容来源于stack exchange，提问作者Alex