When generation Postscript with following command: gswin.exe -o out.ps -sDEVICE=pswrite -dNOPAUSE -dBATCH Dryer2.pdf the interpretation of Dryer2.pdf fails with following message: Error: /rangecheck in --.discardtransparencygroup-- Operand stack: --dict:13/22(L)-- 1 false Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval- - 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- fa lse 1 %stopped_push 1921 1 3 %oparray_pop 1920 1 3 %oparray_ pop 1904 1 3 %oparray_pop --nostringval-- --nostringval-- 2 1 1 --nostringval-- %for_pos_int_continue --nostringval-- --nostringval-- false 1 %stopped_push --nostringval-- --nostringval-- Dictionary stack: --dict:1160/1684(ro)(G)-- --dict:2/20(G)-- --dict:75/200(L)-- --dict:75 /200(L)-- --dict:107/127(ro)(G)-- --dict:273/300(ro)(G)-- --dict:21/25(L)- - --dict:4/6(L)-- --dict:21/40(L)-- --dict:1/1(ro)(G)-- --dict:1/1(ro)(G )-- --dict:7/8(L)-- --dict:1/1(ro)(G)-- Current allocation mode is local
Created attachment 3966 [details] Dryer2.pdf
I cannot reproduce this problem: the file works fine on v, 8.60 and higher including the current development version. At the default resolution of pswrite the file takes 1.7G of memory and can run out of memory on small systems. However, this causes /VMError , not /rangecheck . Please check that the right file is attached to the bug report. If so, how your Ghostscript is different from the standard build?
The large allocations are due to the pdf14 device compositor transparency buffers. For example, step 1330 or allocates about 400Mb. Since the pswrite and ps2write devices don't directly support transparency, we would probably be better off converting the page to a raster image (RGB?) using the clist logic, then putting out the full page image.
I am getting this same error when trying to convert an AI file, using GS 8.62 on Windows.
By the way, this works fine in GS 8.54 - I only saw the problem after upgrading to 8.62.
This bug may still exist in Ghostscript 8.63 on Ubuntu intrepid 8.10. Since the original PDF, that was created on a Konica Minolta bizhub C253 Multifunction Copier/Printer/Scanner, failed to print correctly from evince 2.24.1 to a HP Color LaserJet 4600, I printed to PDF, using "Print to file", in evince 2.24.1 and then opened the result PDF in gv 3.6.4 which gave the following error: Error: /rangecheckGPL Ghostscript 8.63: Unrecoverable error, exit code 1 in --.discardtransparencygroup-- Contact me for further details or the sample document.
Ole: please attach the redistilled document if you want us to look at this.
When run using HEAD with -dPDFDEBUG I get : [a+]gs_malloc(large object chunk)(251270376) = 0x0; failed followed by : Error: /rangecheck in .discardtransparencygroup. So I believe the problem is simply lack of memory as already mentioned. Possibly the error message returned depends on precisely where the interpreter is when memory is exhausted. Since the memory usage is caused by flattening the transparent content (as we must for PostScript output) reducing the resolution should reduce the memory usage. By setting the resolution to 72 dpi (-r72) I was able to run the job to completion. The resulting PostScript appears to be satisfactory. Oddly the page size seems incorrect, and half the job disappears. I probably need to set a custom page size before doing the conversion. For me 100 and 300 dpi also worked, though obviously with correspondingly larger output files. I'm re-assigning this to support for a decision on whether we should close this issue, or convert it into an enhancement to use the clist to render the entire page as an image when the job contains transparency, os something else.
Discussed at today's bug meeting. We intend to address this further, however it is a complex issue requiring a transparency compositor to convert the transparency to an image, and will take some time. Sadly this will not be resolved in the short term.
*** Bug 688473 has been marked as a duplicate of this bug. ***
*** Bug 688919 has been marked as a duplicate of this bug. ***
*** Bug 689571 has been marked as a duplicate of this bug. ***
There is no 'leonardo@artifex.com' email address, nor is there a 'raph.levien'
Tried with r9974 on Windows XP SP3 + VS2008 Express SP1 on VMware Fusion with 512MB memory configuration. The job still fails but the failing operator was --run-- instead of -- .discardtransparencygroup--. C>bin\gswin32c -o out.ps -sDEVICE=pswrite -dNOPAUSE -dBATCH Dryer2.pdf GPL Ghostscript SVN PRE-RELEASE 8.71 (2009-08-01) Copyright (C) 2009 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 [a+]gs_malloc(large object chunk)(314087960) = 0x0: failed Error: /rangecheck in --run-- Operand stack: --dict:13/22(L)-- 1 12 false Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval- - 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- fa lse 1 %stopped_push 1862 1 3 %oparray_pop 1861 1 3 %oparray_ pop 1845 1 3 %oparray_pop --nostringval-- --nostringval-- 2 1 1 --nostringval-- %for_pos_int_continue --nostringval-- --nostringval-- false 1 %stopped_push --nostringval-- --nostringval-- Dictionary stack: --dict:1154/1684(ro)(G)-- --dict:1/20(G)-- --dict:75/200(L)-- --dict:75 /200(L)-- --dict:106/127(ro)(G)-- --dict:285/300(ro)(G)-- --dict:22/25(L)- - --dict:4/6(L)-- --dict:22/40(L)-- --dict:1/1(ro)(G)-- --dict:1/1(ro)(G )-- --dict:7/15(L)-- --dict:1/1(ro)(G)-- Current allocation mode is local Last OS error: Not enough space GPL Ghostscript SVN PRE-RELEASE 8.71: Unrecoverable error, exit code 1 C>
*** Bug 689137 has been marked as a duplicate of this bug. ***
Bug still reproducible in Ghostscript 9.03
Assigning to Ray as he knows *much* more about clists than I do. After discussion on irc, also changing status to enhancement.
The approach I'm thinking of (as mentioned on IRC) is similar to what we do for patterns that exceed MaxPatternBitmap and that have transparency. Since the playback of the clist uses the transparency compositor only on the band, we avoid having to allocate the large area transparency buffers.
To solicit comments on the approach (for those that subscribe to gs-bugs), I am going to use clist mode in the case where the estimated transparency buffer storage exceeds 'MaxBitmap'. This parameter currently is in the space params in the gx_device_printer, so these need to be moved to the gx_device_common. We don't need to move the rest of the gx_device_printer_s stuff since we will instantiate a gx_device_printer and apply the appropriate pdf14_clist_device to it as the compositor. Then, once the POP_DEVICE occurs, we will playback bands to the put_image of the "real" target device (such as 'pswrite', or even the 'display' device). Since the target devices never really got any data until the POP_DEVICE did the put_image anyway, the only difference to the target device is that they will get multiple 'put_image' calls, one for each band. Any comments welcome here, by email, or in IRC.
*** Bug 693214 has been marked as a duplicate of this bug. ***
*** Bug 693310 has been marked as a duplicate of this bug. ***
*** Bug 693663 has been marked as a duplicate of this bug. ***
*** Bug 693927 has been marked as a duplicate of this bug. ***
Fixed (along with all of the duplicate bugs) with: commit 4e44c995bcc7a2aa6c32e23cb73fd532a93f5b1c This particular file required 1501 Mb previously. After this commit, with the default 4Mb BufferSpace, the total memory used was 42Mb. Your mileage may vary. As mentioned in the log message and Use.doc, -dMaxBitmap=____ can be used to set the threshold and as with other uses of the clist, -dBufferSpace=___ can be used to increase the band size and _may_ improve performance. Both the MaxBitmap and BufferSpace can accept "multiplier" suffixes of 'k' (1024), 'm' (1024*1024) or 'g' (1024*1024*1024) -- NO SPACES. It's a lot easier to type -dBufferSpace=32m instead of -dBufferSpace=32000000.
*** Bug 690945 has been marked as a duplicate of this bug. ***