GhostScript: Windows 7 conversion succeeds where Linux fails

Question

I am using Ghostscript 9.05 to generate images from PDFs as part of an application (run as a process in Java).

I recently came across an issue where a few PDF to image conversions failed on a linux box with the following error:

**** 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.

With each page throwing a similar error to this:

**** 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.

However, when running the same conversions locally on a Win7 machine the error does not occur.

I know the short and narrow of it is "send the PDF back and get them to send you a working one" - but I am intrigued as to why this would fail on a linux box but succeed without error (and producing error-less images) on a Windows machine?

Any ideas?

I am reluctant to open a bug report at this time as there may be a significant difference between the Linux and WIndows versions of which I am unaware.

Update

After looking how Ghostscript has been built on our Linux box (we are running Ubuntu 12.04 64 bit Long Term Support release), I have gathered the following information:

For jpeg2000 manipulation Ghostscript is using the JasPer JPEG-2000 runtime libraries version 1.900.1-13 (ISO reference implementation of JPEG-2000 Part-1).

JasPer is built using libjpeg-turbo8 libraries.

According to the JasPer website

The JasPer software has been included in the JPEG-2000 Part-5 standard (i.e., ISO/IEC 15444-5), as an official reference implementation of the JPEG-2000 Part-1 codec.

Ghostscript is listed as one of the projects known to use JasPer. It appears Ubuntu are using JasPer, the ISO reference implementation, and the Ubuntu package source for Ghostscript lists JasPer (libjasper-dev) as a dependency for building, not openJPEG. [source]

At the moment it looks like the only option is to try different versions of linux, building ghostscript versions and testing them.

Answer 1

One possibility is that you are running 64-bit Linux and 32-bit Windows binaries.

However the most likely problem is that your Linux distribution has chosen to build Ghostscript with 'shared libraries'. Certain 3rd party libraries used by Ghostscript (eg FReeType, Litle CMS etc) can be linked dynamically instead of statically, and loaded at run-time.

I notice that the images are JPX (JPEG 2000), and these will use the OpenJPEG library. However the source code for OpenJPEG shipped with Ghostscript is not the 1.5 version, it is 1.5 plus some bits pulled from the forthcoming 2.0 plus some fixes we needed to add (and fed upstream, we believe they will be incorporated into 2.0). We hope to be using a standard version of this code in the near future, when the next version is released.

If your Linux distribution has chosen to build Ghostscript with OpenJPEG as a shared library, then you won't get the benefit of those source changes, and the JPX decoder won't work as well. The Windows build of GS doesn't have an 'out-of-the-box' method to build 3rd party libraries as DLLs, and so (unless you do a lot of work yourself) it always uses the source code for the 3rd party libraries which we supply.

If you build GS yourself from source (on Linux), then you may well find that this behaves perfectly well. I would also venture to suggest that there is nothing actually wrong with the PDF files, just the version of OpenJPEG being used.

We do something like 60,000 tests every time we make a commit to the Ghostscript repository, but obviously we do these tests against the code which we actually ship. At least it means we have a reasonable degree of confidence in what we send out, provided you use the code we supply. We don't recommend building Ghostscript with shared libraries, but nothing we say persuades the various Linux distributors otherwise, so its something we have to live with.