The customer reports and I've verified that Ghostscript generates an error when converting the file Schufenster.pdf. All versions of Ghostscript that I tried, including 8.70 and head (r10824), produce the same error: GPL Ghostscript SVN PRE-RELEASE 8.72 (2010-02-11) Copyright (C) 2010 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Processing pages 1 through 1. Page 1 jasper (code 0) jpc_dec_decodepkts failed jasper (code 0) error: cannot decode code stream unable to decode JPX image data. **** Warning: File has insufficient data for an image. **** This file had errors that were repaired or ignored. **** The file was produced by: **** >>>> Corel PDF Engine Version 3.0.0.739 <<<< **** Please notify the author of the software that produced this **** file that it does not conform to Adobe's published PDF **** specification. I've only been able to duplicate this issue on 32 bit Linux (both Ubuntu 09.10 and Debian 5.0) but not on Mac OS X 10.6 or 64 bit Ubuntu, even when building with -m32. The command line I'm using for testing: bin/gs -sDEVICE=ppmraw -o test.ppm ./Schufenster.pdf The Schufenster.pdf file is too large to attach, it can be found in /home/marcos on briareus (one of the systems on which I've been able to duplicate the error).
Ghostscript allocates 3.8 GB to process this file. Reassigning to Masaki Ushizaka, who already works on similar issues. See bug 690543 and bug 691122 . The sample file can be found on spectre.ghostscript.com in /home/marcos directory.
I've moved the file from /home/marcos to /home/support/691153 (still on spectre.ghostscript.com).
I tried this on r11088 and on ubuntu 32 bit. It aborted after running about 3 minutes, printed "Killed" and exit code was 137. I think I exceeded some limitation for a process. I also tried r11088+luratech decoder. It finished the job without an error and had a correct result. Then I tried this with OpenJPEG (branches/jpx_openjpeg/gs, r11006). It finished the job. However resulted image was not correct. (Grayish garbage I reported in Bug 690543.) If I could get rid of that gray garbage problem, OpenJPEG could be a solution for this issue.
I also should note that the images on this pdf file (Schufenster.pdf) ware tiled iamges. (598 tiles and 1680 tiles) Rendering JPEG2000 images by each row of tiles may also solve this issue, as well as bug 691122.
If this is something which the Luratech decoder will improve the customer should be notified that is an option.
Luratech decoder decreases memory usage to 674M Virtual and 467M Resident memory on my GNU/Linux box. The process takes 35s to complete.
This is another problem where the customer should be given the luratech decoder and the problem downgraded to P4 non-customer. We don't plan to fix memory problems in jasper, we hope this will improve when openjpeg is integrated.
(In reply to comment #7) > This is another problem where the customer should be given the luratech decoder > and the problem downgraded to P4 non-customer. We don't plan to fix memory > problems in jasper, we hope this will improve when openjpeg is integrated. Correction, the customer should be directed to the August 2011 release which will have the luratech JPX decoder included. There were several problems in the API which were fixed fairly recently, best to wait for a fully tested release.
I've notified the customer about the August 2011 release. I've removed the customer designation and changed the bug to P4. When the openjpeg code is integrated this bug should be retested. Also the the test file from Bug 691122 should be tested with openjpeg.
*** Bug 691122 has been marked as a duplicate of this bug. ***
I believe this now works adequately with OpenJPEG.