Ghostscript / pdfwrite 以彩色 PDF 和 CMYK 颜色而不是 RGB 生成灰色页面
Ghostscript / pdfwrite produces grey page in colored PDF and CMYK color instead of RGB
背景
在 PHP 网络应用程序中，我使用 DomPDF 从 HTML 和 CSS 创建动态 PDF，并使用 Ghostscript 的 pdfwrite 设备将动态创建的 PDF 与两个现有的第三方 PDF。
我有 3 个具有不同 ghostscript 版本的环境：
Dev (Win10) GPL Ghostscript 8.64 (2009-02-03)
Test (Linux) GPL Ghostscript 9.06 (2012-08-08)
Prod (Linux) GPL Ghostscript 8.70 (2009-07-31)
问题
预期
- 所有页面合并到生成的 PDF 中
- 无明显色差
实际结果
- 所有页面合并到生成的 PDF 中
- 颜色在开发和测试环境中看起来符合预期（在 Win10 上使用 Adobe Reader 进行测试）
- 在Prod环境下，动态（创建DomPDF）页面
- 看起来是灰色而不是彩色
- 似乎有 CMYK 而不是 RGB 颜色，如 ImageMagick 6.9.9-34 Q16 x86 所识别：
DOMPDF 创建的 PDF 本身，即此处 gs 的输入，看起来很好。
identify PDF 输出
(ImageMagick 6.9.9-34 Q16 x86)
Dev 上的输出：
XXX.pdf[0] PDF 595x842 595x842+0+0 16-bit sRGB 69761B 0.000u 0:00.010
XXX.pdf[1] PDF 595x842 595x842+0+0 16-bit sRGB 69761B 0.000u 0:00.004
XXX.pdf[2] PDF 595x842 595x842+0+0 16-bit sRGB 69761B 0.000u 0:00.000
Prod 上的输出：
XXX.pdf[0] PDF 595x842 595x842+0+0 16-bit ColorSeparation CMYK 2004080B 0.016u 0:00.013
XXX.pdf[1] PDF 595x842 595x842+0+0 16-bit ColorSeparation CMYK 2004080B 0.016u 0:00.007
XXX.pdf[2] PDF 595x842 595x842+0+0 16-bit ColorSeparation CMYK 2004080B 0.000u 0:00.003
Prod 上 gs 的所有输入 PDF 都是 sRGB，根据 identify:
<third-party-pdf> PDF 595x842 595x842+0+0 16-bit sRGB 65728B 0.000u 0:00.000
<dompdf-created> PDF 595x842 595x842+0+0 16-bit sRGB 29348B 0.000u 0:00.000
注意：我不确定identify的颜色space到底是什么意思（因为PDF文档甚至页面不需要有一种颜色 space AFAIK）。虽然大多数对象是 RGB，但第三方 PDF 也可能包含一些 Pantone 颜色的对象。
到目前为止我尝试了什么
- 初始命令行为
gs -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile={$concatenatedPDFTempFileName} {$pdfsToConcatString}（此处为 PHP 变量语法）
- 花了几个小时试图找到关于此的文档或其他资源
- 所有环境中
gs 选项之间的 3 种差异。
- 尝试组合不同的明显命令开关，如
-sColorConversionStrategy=RGB -dUseCIEColor=true -sOutputICCProfile=default_rgb.icc
- 尝试将测试环境中的确切选项应用到产品上的 ghostscript，但我没有设法以易于重用的格式输出它们（也许有人对此有提示？）
也许有人知道进一步调查最有希望的方法是什么，或者例如，我如何将测试环境的精确 gs 配置应用到生产环境（我怀疑这是 100% 可能的，因为有不同的涉及的版本）。
好吧，使用三个不同的（而且都相当老旧，即使是最新的也有 6 年历史）版本的 Ghostscript 肯定没有帮助。
首先要注意的是 Ghostscript 不 'merge' PDF 文件。实际过程描述here
所以所有的输入文件都将被完全解释，分解成图形基元，然后重新组合成一个新文件。现在一般来说，除非另有说明，否则 pdfwrite 设备将尝试将颜色规格保持在原始颜色 space。你的观点是正确的，一个 PDF 文件可能包含多种不同的颜色 space，所以我会非常谨慎地对待 'identify' 结果。
你没有提供输入文件，也没有提供任何输出文件，所以我无法对它们进行任何分析，所以真的不可能告诉你发生了什么。 Ghostscript 本身和 pdfwrite 设备没有任何 'configuration' 我认为您期望的方式。所有的配置都是通过命令行完成的，所以如果你对所有的安装都是运行相同的命令行，那么你就是运行相同的'configuration'。
我不确定您遇到问题的原因 'appying the exact options'。您当然可以确定您自己的代码正在创建的 Ghostscript 命令行吗？
不管怎样，旧版本显然不如新版本功能丰富和功能强大。可以想象，您的 8.70 版本存在一个特定的错误，这是由于一项新功能，该版本中存在问题（请注意，此处的次要版本号凸起表明发生了重大变化）。这也可以解释为什么您从（非常）旧的版本获得 sRGB 而从新版本获得 CMYK。
如果您提供要查看的文件，我会告诉您有何不同。不过，我的建议是在所有三个平台上使用相同的版本，而且我建议使用不到 6 年的软件可能会有所帮助。尤其是因为您让自己容易受到许多已知的、已发布的安全漏洞的攻击。至少看过其中一篇 'in the wild'.
我也会不使用您提供的一些命令行开关，-dUseCIEColor 是个糟糕的主意，不要这样做（较新版本的 Ghostscript 会特别警告你，如果你这样做）。不要在没有充分理由的情况下更改 ColorConversionStrategy。颜色管理在 8.x 和 9.x 系列之间**完全*发生了变化，在此之前 -sOutptuICCProfile 将没有任何效果，因此您正在尝试应用早期版本中不支持的控件。
背景
在 PHP 网络应用程序中，我使用 DomPDF 从 HTML 和 CSS 创建动态 PDF，并使用 Ghostscript 的 pdfwrite 设备将动态创建的 PDF 与两个现有的第三方 PDF。
我有 3 个具有不同 ghostscript 版本的环境：
Dev (Win10) GPL Ghostscript 8.64 (2009-02-03)
Test (Linux) GPL Ghostscript 9.06 (2012-08-08)
Prod (Linux) GPL Ghostscript 8.70 (2009-07-31)
问题
预期
- 所有页面合并到生成的 PDF 中
- 无明显色差
实际结果
- 所有页面合并到生成的 PDF 中
- 颜色在开发和测试环境中看起来符合预期（在 Win10 上使用 Adobe Reader 进行测试）
- 在Prod环境下，动态（创建DomPDF）页面
- 看起来是灰色而不是彩色
- 似乎有 CMYK 而不是 RGB 颜色，如 ImageMagick 6.9.9-34 Q16 x86 所识别：
DOMPDF 创建的 PDF 本身，即此处 gs 的输入，看起来很好。
identify PDF 输出
(ImageMagick 6.9.9-34 Q16 x86)
Dev 上的输出：
XXX.pdf[0] PDF 595x842 595x842+0+0 16-bit sRGB 69761B 0.000u 0:00.010
XXX.pdf[1] PDF 595x842 595x842+0+0 16-bit sRGB 69761B 0.000u 0:00.004
XXX.pdf[2] PDF 595x842 595x842+0+0 16-bit sRGB 69761B 0.000u 0:00.000
Prod 上的输出：
XXX.pdf[0] PDF 595x842 595x842+0+0 16-bit ColorSeparation CMYK 2004080B 0.016u 0:00.013
XXX.pdf[1] PDF 595x842 595x842+0+0 16-bit ColorSeparation CMYK 2004080B 0.016u 0:00.007
XXX.pdf[2] PDF 595x842 595x842+0+0 16-bit ColorSeparation CMYK 2004080B 0.000u 0:00.003
Prod 上 gs 的所有输入 PDF 都是 sRGB，根据 identify:
<third-party-pdf> PDF 595x842 595x842+0+0 16-bit sRGB 65728B 0.000u 0:00.000
<dompdf-created> PDF 595x842 595x842+0+0 16-bit sRGB 29348B 0.000u 0:00.000
注意：我不确定identify的颜色space到底是什么意思（因为PDF文档甚至页面不需要有一种颜色 space AFAIK）。虽然大多数对象是 RGB，但第三方 PDF 也可能包含一些 Pantone 颜色的对象。
到目前为止我尝试了什么
- 初始命令行为
gs -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile={$concatenatedPDFTempFileName} {$pdfsToConcatString}（此处为 PHP 变量语法） - 花了几个小时试图找到关于此的文档或其他资源
- 所有环境中
gs选项之间的 3 种差异。 - 尝试组合不同的明显命令开关，如
-sColorConversionStrategy=RGB -dUseCIEColor=true -sOutputICCProfile=default_rgb.icc - 尝试将测试环境中的确切选项应用到产品上的 ghostscript，但我没有设法以易于重用的格式输出它们（也许有人对此有提示？）
也许有人知道进一步调查最有希望的方法是什么，或者例如，我如何将测试环境的精确 gs 配置应用到生产环境（我怀疑这是 100% 可能的，因为有不同的涉及的版本）。
好吧，使用三个不同的（而且都相当老旧，即使是最新的也有 6 年历史）版本的 Ghostscript 肯定没有帮助。
首先要注意的是 Ghostscript 不 'merge' PDF 文件。实际过程描述here
所以所有的输入文件都将被完全解释，分解成图形基元，然后重新组合成一个新文件。现在一般来说，除非另有说明，否则 pdfwrite 设备将尝试将颜色规格保持在原始颜色 space。你的观点是正确的，一个 PDF 文件可能包含多种不同的颜色 space，所以我会非常谨慎地对待 'identify' 结果。
你没有提供输入文件，也没有提供任何输出文件，所以我无法对它们进行任何分析，所以真的不可能告诉你发生了什么。 Ghostscript 本身和 pdfwrite 设备没有任何 'configuration' 我认为您期望的方式。所有的配置都是通过命令行完成的，所以如果你对所有的安装都是运行相同的命令行，那么你就是运行相同的'configuration'。
我不确定您遇到问题的原因 'appying the exact options'。您当然可以确定您自己的代码正在创建的 Ghostscript 命令行吗？
不管怎样，旧版本显然不如新版本功能丰富和功能强大。可以想象，您的 8.70 版本存在一个特定的错误，这是由于一项新功能，该版本中存在问题（请注意，此处的次要版本号凸起表明发生了重大变化）。这也可以解释为什么您从（非常）旧的版本获得 sRGB 而从新版本获得 CMYK。
如果您提供要查看的文件，我会告诉您有何不同。不过，我的建议是在所有三个平台上使用相同的版本，而且我建议使用不到 6 年的软件可能会有所帮助。尤其是因为您让自己容易受到许多已知的、已发布的安全漏洞的攻击。至少看过其中一篇 'in the wild'.
我也会不使用您提供的一些命令行开关，-dUseCIEColor 是个糟糕的主意，不要这样做（较新版本的 Ghostscript 会特别警告你，如果你这样做）。不要在没有充分理由的情况下更改 ColorConversionStrategy。颜色管理在 8.x 和 9.x 系列之间**完全*发生了变化，在此之前 -sOutptuICCProfile 将没有任何效果，因此您正在尝试应用早期版本中不支持的控件。