使用 gs 8.71，红帽
我在转换嵌入了 jpeg2000 图像的 pdf 文件时遇到问题。部分编码是使用 -c <> setpagedevice 命令将 pdf 图像缩小 10%。如果 pdf 文件没有 jpeg2000 图像，此命令将正常工作；但是，如果 pdf 文件确实有 JPEG2000 图像，ghostscript 命令将挂起并产生“错误：无法处理 JPXDecode 数据。页面将丢失数据”。
如果遇到 jpeg2000 图像，是否有任何参数可以传递给 gs 以使其不挂起？我们可以处理 pdf 文件对于 jpeg2000 图像不正确，但不能处理程序在执行时简单挂起。
我也尝试过编译 gs 9.15 并在 RedHat 下运行（结果更好，但不是很好），但我更喜欢使用 RedHat 的最新版本。
如果您发现一个文件不起作用，您应该将其报告为错误。当然没有任何“MagicDontHang”参数，尤其是因为挂起可能发生在 JasPer（因为您有一个非常旧的版本）或 OpenJPEG（在较新的版本中）。所以除了等待解码器返回数据之外，Ghostscript 无能为力。
此外，RedHat 包几乎肯定会使用系统共享库，我们不建议这样做，我们发布的源代码实际上是作为一个集成整体进行测试的（如果您使用的是系统共享库，显然不是这样），所以我们知道我们发布的版本与我们的代码一起使用。此外，我们确实在某些库中进行了一些修复，特别是 OpenJPEG，它们已在上游提供，但不一定（还）采用，因此我们发布的代码效果更好。
顺便说一句，我不知道你认为'-c <> setpagedevice' 做了什么，但它肯定不会'将 pdf 图像减少 10%'。除此之外，这个确切的命令是不合法的。
所以我的建议是忘记 RedHat 与您的特定 Linux 版本打包的任何版本，从 www.ghostscript.com 获取源代码并构建它，它将立即比 8.71 版好得多（4 年的错误修复和增强) 并且由于它不会使用系统共享库，因此它也会比您从打包程序中获得的更好，即使他们打包了 9.15。
哦，最后，如果通过 pdfwrite 设备运行带有 JPEG2000 图像的 PDF 文件的结果比原始文件小，我会感到非常惊讶，因为输出的 PDF 文件将使用不同的压缩方案。JPEG2000 编码器需要商业许可（它有许多相关的专利），所以我们不能将它用于 AGPL 版本。结果是输出文件中的图像数据几乎肯定会比输入文件大。由于图像数据在包含图像时通常包含 PDF 文件的大部分，这可能会导致输出文件的大小增加。