ubuntu 18.10 和 docker 上的 ghostscript pdf/a 转换问题

Question

我正在使用 Ghostscript 使用以下命令将 pdf1.3 转换为 pdf/a-1b：

gs -dPDFA -dBATCH -dNOPAUSE -dNOOUTERSAVE -sColorConversionStrategy=sRGB -sDEVICE=pdfwrite -sOutputFile=output.pdf PDFA_def.ps input.pdf

自定义 PDFA_def.ps 以使用 srgb icc 配置文件。除了变化是GS 9.26自带的标准def文件。

现在是棘手的部分： 1-在 ubuntu 18.10、GS 9.26 上本地运行此转换它工作正常，我得到一个有效的 pdf/a 2- 在 docker 容器（ubuntu 18.10。GS 9.26）中运行相同的命令也会创建一个 pdf/a，这被认为是有效的

但是，在第一种情况下，我可以使用 mustang (https://github.com/ZUGFeRD/mustangproject) 处理文件以创建有效的电子发票。在第二种情况（docker 容器）中，这失败了，因为野马认为该文件不是有效的 pdf。

检查两个 pdf 文件，我原以为它们是相同的，因为我在上面运行相同的转换。然而他们不是。在 dockerfile 中创建的 PDF 小 10 个字节，并在文件本身中显示一些不同的元信息。

我怀疑肯定有一些“隐藏的依赖”使 GS 在我的主机系统上的行为与 docker 容器相比有所不同，但感觉完全错误，我已经没有办法进一步调试了。

有谁知道，GS 是否有更多的依赖可能导致相同的命令产生不同的结果？

Answer 1

答案是“也许”。这取决于 Ghostscript 是如何为初学者构建的。

我假设您正在使用一个包，而不是自己从源代码构建。在这种情况下，有许多依赖项，包括： FreeType、LibJPEG、JBIG2dec、LibTIFF、JPEG-XR、LCMS2、LibPNG、OpenJPEG、Expat、zlib，可能还有 IJS、CUPS 和 X-Windows，具体取决于内置的设备。

其中任何一个或所有这些都可以是系统共享库，而不是使用 Artifex 提供的特定版本构建的。它们也可能是两个系统上的不同版本。

也就是说，我认为这“不太可能”是您的问题。但是，如果没有看到 PDF 文件，我无法告诉您为什么会有差异。元数据中的差异是意料之中的，因为其中包括日期/时间戳。

我真的需要查看原始 PDF 文件和两个输出 PDF 文件的示例才能进一步评论。

[编辑]

查看它们生成的压缩文件（不出所料），如果输入流中存在微小差异，这显然会导致大小差异。所以第一个任务就是解压文件。

我发现它们之间基本上没有区别。其中一个操作系统使用比 UTC 晚 7 小时的时区，另一个使用 UTC，因此其中一个系统使用（例如）

2019-04-26T19:49:01Z

另一个正在使用

2019-04-26T12:51:35-07:00

因此，您得到的不是 Z（对于 UTC），而是 -07:00，这是额外 10 个字节的来源。除此之外，唯一 ID（如您所想）是不同的，流的长度值对于包含日期的流是不同的，并且 startxref 是不同的，因为流的长度不同。

这两个文件都声称与 PDF/A-1b 兼容。简而言之，我看不出它们之间没有真正的区别。由于您正在使用工具来进一步处理文件，我建议您尝试从工作系统中获取 PDF 文件并尝试在非工作系统上处理它，反之亦然，在我看来问题可能出在后期处理而不是 PDF 文件本身。也许您在这两个系统上拥有该工具的不同版本。

对于它的价值，可以诱导 Ghostscript 直接创建 ZUGFeRD 文件，请参阅this 错误报告和this 提交到存储库。