0

Using gs 8.71, RedHat

I'm having trouble converting pdf files that have jpeg2000 images embedded within. Part of the coding is to reduce the pdf image by 10% using the -c <> setpagedevice command. This command will work properly if the pdf file does NOT have a jpeg2000 image; however, if the pdf file does have a JPEG2000 image, the ghostscript command will hang and produce a "ERROR: Unable to process JPXDecode data. Page will be missing data".

Is there any parameter I can pass to gs to allow it to not hang if it encounters a jpeg2000 image? We can deal with the pdf file being incorrect for a jpeg2000 image, but cannot deal with the program simply hanging when executing.

I have also tried compiling gs 9.15 and running under RedHat (with better, but not great, results) but prefer to use the latest greatest from RedHat.

Sam
  • 1
  • 1

1 Answers1

0

If you find a file which doesn't work you should report it as a bug. There certainly isn't any 'MagicDontHang' parameter, not least because the hang is probably happening in JasPer (because you have a really old version) or OpenJPEG (in a newer version). SO there's nothign Ghostscript can do except wait for the decoder to return the data.

Also, the RedHat package will almost certainly be using system shared libraries, which we don't recommend, the source we ship is actually tested as an integrated whoel (which it clearly isn't if you are using system shared libraries), so we know the versions we ship work with our code. Also we do have some fixes in certain libraries, specifically OpenJPEG, which have been supplied upstream but not necessarily adopted (yet), so the code we ship works better.

By the way, I don't know what you think '-c <> setpagedevice' does, but it certainly doesn't 'reduce the pdf image by 10%'.Apart from anything else, that exact command isn't legal.

So my advice would be to forget whatever version RedHat are packing with your particular version of Linux, get the source from www.ghostscript.com and build it, it will immediately be considerably better than version 8.71 (4 years worth of bug fixes and enhancements) and since it won't use system shared libraries, it'll be better than what you would get from the packagers too, even if they packaged 9.15.

Oh, finally, I'd be very surprised if the result of running a PDF file with JPEG2000 images through the pdfwrite device is smaller than the original, as the output PDF file will use a different compression scheme. The JPEG2000 encoder requires a commercial licence (it has many associated patents), so we can't use it for the AGPL release. The result is that the image data will almost certainly be larger in the output file than the input. Since image data often comprises the greater part of a PDF file when it contains images, this will likely result in an increased size of output file.

KenS
  • 30,202
  • 3
  • 34
  • 51