幽灵脚本和jpeg2000图像

Question

使用gs 8.71，RedHat

我在转换包含jpeg2000图像的pdf文件时遇到了问题。部分编码是使用-c <> setpagedevice命令将pdf图像减少10%。如果pdf文件没有jpeg2000图像，则此命令将正常工作；但是，如果pdf文件确实有JPEG2000图像，幽灵脚本命令将挂起并产生“错误:无法处理JPXDecode数据。页面将丢失数据”。

如果遇到jpeg2000映像，是否有任何参数可以传递给gs以使其不挂起？我们可以处理的pdf文件是不正确的jpeg2000图像，但不能处理程序只是挂在执行时。

我还试过编译gs 9.15并在RedHat下运行(结果更好，但不太好)，但我更喜欢使用来自RedHat的最新版本。

Answer 1

如果您找到一个无法工作的文件，您应该将其报告为bug。当然没有任何'MagicDontHang‘参数，尤其是因为挂起可能发生在JasPer (因为您的版本非常旧)或OpenJPEG (在更新的版本中)中。因此，除了等待解码器返回数据外，Ghostscript没有什么可以做的。

而且，RedHat包几乎肯定会使用系统共享库，我们不推荐它，我们提供的源代码实际上被测试为一个集成的whoel (如果您使用的是系统共享库，显然不是这样)，所以我们知道我们随代码一起发布的版本。另外，我们在某些库中确实有一些修复，特别是OpenJPEG，这些库是上游提供的，但不一定采用(还没有)，所以我们提供的代码工作得更好。

顺便说一句，我不知道你认为'-c <> setpagedevice‘做什么，但它肯定不会’将pdf图像减少10%‘，除了其他任何东西，这个精确的命令是不合法的。

因此，我的建议是忘记RedHat与您的特定版本Linux一起打包的任何版本，从www.ghostscript.com获取源代码并构建它，它将立即比8.71版本(4年的bug修复和增强)要好得多，而且由于它不会使用系统共享库，所以它也会比您从包中获得的更好，即使它们打包了9.15。

哦，最后，如果通过pdfwrite设备运行带有JPEG2000图像的PDF文件的结果比原来的要小的话，我会非常惊讶，因为输出PDF文件将使用不同的压缩方案。JPEG2000编码器需要一个商业许可(它有许多相关的专利)，所以我们不能将它用于AGPL版本。结果是，输出文件中的图像数据几乎肯定比输入的要大。由于图像数据在包含图像时通常包含PDF文件的大部分，这很可能导致增加输出文件的大小。