我使用Ghostscript 9.05作为应用程序的一部分从PDF生成图像（在Java中作为进程运行）。
我最近遇到一个问题，在Linux机器上发生了一些PDF到图像转换失败，出现以下错误：
**** This file had errors that were repaired or ignored.
**** The file was produced by:
**** >>>> Acrobat Distiller 8.3.1 (Macintosh) <<<<
**** Please notify the author of the software that produced this
**** file that it does not conform to Adobe's published PDF
**** specification.
每个页面都会抛出类似的错误：
**** Warning: File has insufficient data for an image.
%%BoundingBox: 77 36 797 1082
%%HiResBoundingBox: 77.760003 36.720001 796.320030 1081.440041
Page 141
warning: ignoring invalid option raw
error: cannot decode code stream
unable to decode JPX image data.
但是，在Win7计算机上本地运行相同的转换时，不会发生错误。
我知道它的简短之处是“发送PDF并让他们发送给你一个工作的” - 但我很感兴趣为什么这会在linux机箱上失败但是在Windows机器上成功没有错误（并生成无错误的图像）？
有什么想法吗？
我不愿意在此时打开错误报告，因为我不知道的Linux和WIndows版本之间可能存在显着差异。
在了解了如何在我们的Linux机器上构建Ghostscript之后（我们正在运行Ubuntu 12.04 64位长期支持版本），我收集了以下信息：
对于jpeg2000操作，Ghostscript使用的是JasPer JPEG-2000运行时库版本1.900.1-13（JPEG-2000 Part-1的ISO参考实现）。
JasPer是使用libjpeg-turbo8库构建的。
JasPer软件已包含在JPEG-2000 Part-5标准（即ISO / IEC 15444-5）中，作为JPEG-2000 Part-1编解码器的官方参考实现。
Ghostscript被列为已知使用JasPer的项目之一。看来Ubuntu正在使用ISO参考实现JasPer，而Ghostscript的Ubuntu包源将JasPer（libjasper-dev）列为构建依赖项，而不是openJPEG。 [source]
目前看起来唯一的选择是尝试不同版本的linux，构建ghostscript版本并测试它们。
答案 0 :(得分：3)
一种可能性是运行64位Linux和32位Windows二进制文件。
然而，最可能的问题是您的Linux发行版选择使用“共享库”构建Ghostscript。 Ghostscript使用的某些第三方库（例如FReeType，Litle CMS等）可以动态链接而不是静态链接，并在运行时加载。
我注意到图像是JPX（JPEG 2000），它们将使用OpenJPEG库。 然而随Ghostscript一起提供的OpenJPEG的源代码不是1.5版本，它是1.5加上从即将到来的2.0加上一些我们需要添加的一些修复（并且向上游馈送，我们相信它们将是纳入2.0）。我们希望在不久的将来，当下一个版本发布时，使用此代码的标准版本。
如果您的Linux发行版选择使用OpenJPEG构建Ghostscript作为共享库，那么您将无法从这些源更改中获益，并且JPX解码器也无法正常工作。 GS的Windows版本没有“开箱即用”的方法来构建第三方库作为DLL，所以（除非你自己做了很多工作）它总是使用第三方的源代码我们提供的图书馆。
如果您自己从源代码构建GS（在Linux上），那么您可能会发现这种情况非常好。我还冒昧地建议PDF文件没有任何问题，只是正在使用的OpenJPEG版本。
每次我们提交Ghostscript存储库时，我们会做60,000次测试，但显然我们会针对实际发布的代码进行这些测试。至少这意味着只要您使用我们提供的代码，我们对发送的内容有合理的信心。我们不建议使用共享库构建Ghostscript，但我们所说的并不是说服各种Linux发行商，所以我们必须接受它。