【问题标题】:Why would pdfs generated by the same automated process be different on different machines?为什么同一自动化流程生成的 pdf 在不同机器上会有所不同?
【发布时间】:2014-07-16 20:40:18
【问题描述】:

我有一个自动生成 pdfs which we then compare to a known version via approval tests 的过程来验证该管道中的任何内容都没有损坏。 I normalize mismatching fields 就像创建/修改的日期和时区以及本地所有内容始终匹配 100%。但是由于某种原因,在我们的构建服务器上生成的 pdf 与我在本地生成的相比非常不同,有时我在本地生成的 PDF 会大 20%。

在 winmerge 中比较文件时的第一个区别是 /FontName 字段,如下所示:

本地生成

/FontName/QOAAAA+TimesNewRomanRegular

生成的构建服务器

/FontName/QYAAAA+TimesNewRomanRegular

之后,我们在/FontBBox、长度和二进制数据方面存在差异。我看到了几个这样的块。

我怀疑两台机器上的字体略有不同,并且被选择并嵌入到 pdf 中,但我不知道上面的 Q*AAAA 代码是什么意思,也不知道如何验证这个假设。

编辑:

pdffonts 报告两者的字体相同,但不能只是相同嵌入字体的不同版本吗?

W:\xpdfbin-win-3.03\bin64> .\pdffonts.exe w:\...\PhantomRasterizer\Can_rasterize_html_to_pdf.slide_with_table_and_svg.approved.pdf
name                                 type              emb sub uni object ID
------------------------------------ ----------------- --- --- --- ---------
TimesNewRomanRegular                 CID TrueType      yes no  yes      7  0
ArialBold                            CID TrueType      yes no  yes     12  0
ArialRegular                         CID TrueType      yes no  yes     17  0
W:xpdfbin-win-3.03\bin64> .\pdffonts.exe W:\...\PhantomRasterizer\Can_rasterize_html_to_pdf.slide_with_table_and_svg.received.pdf
name                                 type              emb sub uni object ID
------------------------------------ ----------------- --- --- --- ---------
TimesNewRomanRegular                 CID TrueType      yes no  yes      7  0
ArialBold                            CID TrueType      yes no  yes     12  0
ArialRegular                         CID TrueType      yes no  yes     17  0

【问题讨论】:

  • 您能比较每个位置使用的确切字体吗?它可能类似于更广泛的 UTF 字符集。可以是相同字体的不同版本一样简单。
  • @DavidWoods 我如何找出嵌入到 pdf 中的字体?
  • 您可以尝试使用@font-face CSS 来强制使用本地提供的特定字体。这可以消除二进制字体差异作为罪魁祸首。
  • 我发现开头的六个字符是随机生成的,它们的存在表明嵌入是字体的子集,而不是整体。这些定义线本身是否不同?字符集应包含在此处的定义中。

标签: pdf


【解决方案1】:

请阅读我对这个问题的回答:Why are PDF files different even if the content is the same?

您的问题相当于“为什么HashMap 中的条目顺序在不同的 JVM 上不同?”答案很简单:因为HashMaps 就是这样设计的。 HashMap 不是 TreeMap

您现在专注于字体,更具体地说是字体子集(关于字体子集名称中的随机字符,ISO-32000-1 规定“字母的选择是任意的”,因此您在挑战 ISO 标准你的问题)。但是,这是您的麻烦中最少的。 PDF的ID也应该不同,字典中的条目顺序就像HashMap中的条目一样。阅读 ISO-32000-1 的第 7.3.7 节:

字典中的条目代表一个关联表,因此 即使可以施加任意命令,也应是无序的 当它们写入文件时。该顺序应被忽略。

对象编号也是如此。我已经看到检查对象编号为 1 的对象是否是这个或那个字典,以及对象编号为 2 的对象是这个或那个数组的测试。但是:对象编号无关紧要。您可以在一个系统中创建一个 PDF 文档,其中第一个对象是一个字典,第二个对象是一个数组,而相同的 PDF 文档使用相同的代码,但反过来。我们最近注意到,在使用 Java 8 而不是 Java 7 测试我们的软件时,我们的一项测试很糟糕。一旦更改 JVM,您的测试就会遇到同样的问题。

您的验证错误。当我们测试 PDF 时,我们使用完全不同的方法。

【讨论】:

  • 我在一般意义上同意你的说法,但在 OP 问题的框架内不同意。如果在两种环境中使用相同的自动化过程,则可以合理地预期文件可以在比通常工作的低得多的级别上进行比较;这也是 OP 提供的细节所暗示的。
  • 非常感谢您的帮助。正如大卫所说,这些文件是由相同的自动化过程在不同的机器上生成的。我知道 ID、日期和时区 and normalize for these。在我们将开发人员添加到团队并开始在其他位置运行测试之前,这一直非常有效。现在看来我需要对听起来像您可能有更好的建议来验证 2 个 pdf 在视觉上相同?
  • 我们使用参考 PDF 并从该 PDF 创建图像。然后,我们生成一个新 PDF 并为该新 PDF 创建一个图像。最后,我们逐个像素地比较两张图像。这样PDF语法是从左到右还是从右到左画一条线都没有关系,只要这条线是正确的,测试就通过了(这就是我们想要的)。我们还通过 COS 模型爬取以检查注释等内容。
  • 伙计...我希望你不要这么说。哦,好吧,它是转换为 tiff :)
  • 不同的 ID、哈希、排序等。我明白了。但是所有这些的大小应该是相同的。一个系统上的六字符 ID 是另一个系统上的六字符 ID。根据定义,散列产生固定长度的输出。所以这些差异并不能解释文件大小的 20% 差异。它也不会解释不同的 FontBBox。
猜你喜欢
  • 2012-03-22
  • 2021-06-23
  • 1970-01-01
  • 1970-01-01
  • 2019-09-05
  • 2015-09-29
  • 1970-01-01
  • 2017-01-07
  • 1970-01-01
相关资源
最近更新 更多