The customer reports: The Pdf files causes some problems in the case one tries to convert the file into a pcx or tiff-file with larger dpi (approx. greater than 400). For the case -r400x400 and -sDEVICE= tiffpack a range check error occurs. For the case -r400x400 and -sDEVICE=pcx24b even some access violation occur in our application. With HEAD (r7864) and the tiffpack device I see a 3Gb clist file created (this takes quite a while), then it exits without generating any output. -dNOTRANSPARENCY runs in 20 seconds (tiffpack -r400).
Created attachment 2898 [details] PDF_mit-mehreren_Ebenen.pdf Warning -- this is a 7Mb file
I'm not seeing the same results here. When I run this with NOTRANSPARENCY and tiffpack it still takes approximately 7 minutes. This was run with the following command on peeves: time ./bin/gs -sDEVICE=tiffpack -r400x400 -dNOTRANSPARENCY -o DF_mit-mehreren_Ebenen.tif -I./lib ~/PDF_mit-mehreren_Ebenen.pdf GPL Ghostscript SVN PRE-RELEASE 8.57 (2007-03-15) Copyright (C) 2007 artofcode LLC, Benicia, CA. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Processing pages 1 through 1. Page 1 real 7m17.582s user 6m48.010s sys 0m14.000s
The memory based clist compresses to <700 Mb. 64 bit offsets _should_ work here. This might be a workaround. The clist code needs checking for offsets past the 2Gb limit when we don't have 64-bit file access. Assigning to Igor to fix the limit checking and to investigate WHY the clist is so BIG.
It is a slightly rotated b&w image. The rotation tan is about 1/50. The graphics library converts it into lots of fill_parallelograms, then the clist writer converts them into lots fill_path, each ow which is a 4-segment path.
Created attachment 3244 [details] patch.txt A suggested patch. It had passed a local regression test with comparefiles at 300 dpi.
Created attachment 3249 [details] patch.txt Same patch with improved log message.
Now I see the patch is not fully correct. When running decompr-Bug688631-.pdf, the 2nd shading paints to the clist writer, which at that moment has color_info with 3 color components, and procs.get_color_mapping_procs returns DeviceGray_procs. Thus get_color_mapping_procs does not match to color_info. It is easy to find with setting a breakpoint into pdf14_cmap_cmyk_direct. The 1st passing this breakpoint shows the mismatch. Will attach the test file.
Created attachment 3251 [details] decompr-Bug688631-.pdf A test case for the last comment.
Created attachment 3252 [details] patch.txt An improved patch.
The last patch has been committed to HEAD as http://ghostscript.com/pipermail/gs-cvs/2007-August/007750.html