Bug 689805 - /rangecheck in --.discardtransparencygroup--
Summary: /rangecheck in --.discardtransparencygroup--
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PDF Interpreter (show other bugs)
Version: 8.63
Hardware: PC Windows XP
: P2 normal
Assignee: Ray Johnston
: 688473 688919 689137 689571 690945 693214 693310 693663 693927 (view as bug list)
Depends on:
Reported: 2008-04-28 07:38 UTC by artifex
Modified: 2014-08-26 00:16 UTC (History)
10 users (show)

See Also:
Customer: 870, 581
Word Size: ---


Note You need to log in before you can comment on or make changes to this bug.
Description artifex 2008-04-28 07:38:13 UTC
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
Comment 1 artifex 2008-04-28 07:38:55 UTC
Created attachment 3966 [details]
Comment 2 Alex Cherepanov 2008-04-29 06:00:58 UTC
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?
Comment 3 Ray Johnston 2008-05-01 09:50:11 UTC
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.

Comment 4 Martin 2008-07-02 08:03:52 UTC
I am getting this same error when trying to convert an AI file, using GS 8.62 
on Windows.
Comment 5 Martin 2008-07-02 09:18:15 UTC
By the way, this works fine in GS 8.54 - I only saw the problem after upgrading 
to 8.62.
Comment 6 Ole 2008-10-29 09:32:09 UTC
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.
Comment 7 Ralph Giles 2008-10-29 10:14:17 UTC
Ole: please attach the redistilled document if you want us to look at this.
Comment 8 Ken Sharp 2008-12-24 08:04:45 UTC
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.

Comment 9 Ken Sharp 2009-01-13 10:00:21 UTC
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.
Comment 10 Ken Sharp 2009-06-09 09:52:49 UTC
*** Bug 688473 has been marked as a duplicate of this bug. ***
Comment 11 Ken Sharp 2009-06-09 09:56:47 UTC
*** Bug 688919 has been marked as a duplicate of this bug. ***
Comment 12 Ken Sharp 2009-06-09 09:57:28 UTC
*** Bug 689571 has been marked as a duplicate of this bug. ***
Comment 13 Ray Johnston 2009-06-09 12:43:51 UTC
There is no 'leonardo@artifex.com' email address, nor is there a 'raph.levien'
Comment 14 Masaki Ushizaka 2009-08-11 20:16:54 UTC
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 --

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

Comment 15 Ken Sharp 2009-08-19 01:54:34 UTC
*** Bug 689137 has been marked as a duplicate of this bug. ***
Comment 16 Shailesh Mistry 2011-07-30 16:23:19 UTC
Bug still reproducible in Ghostscript 9.03
Comment 17 Ken Sharp 2012-03-30 16:19:28 UTC
Assigning to Ray as he knows *much* more about clists than I do. After discussion on irc, also changing status to enhancement.
Comment 18 Ray Johnston 2012-03-30 16:50:06 UTC
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.
Comment 19 Ray Johnston 2012-04-19 17:25:33 UTC
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.
Comment 20 Ray Johnston 2012-07-23 18:28:31 UTC
*** Bug 693214 has been marked as a duplicate of this bug. ***
Comment 21 Ray Johnston 2012-08-30 16:48:10 UTC
*** Bug 693310 has been marked as a duplicate of this bug. ***
Comment 22 Ken Sharp 2013-02-26 17:07:14 UTC
*** Bug 693663 has been marked as a duplicate of this bug. ***
Comment 23 Marcos H. Woehrmann 2013-07-23 09:22:20 UTC
*** Bug 693927 has been marked as a duplicate of this bug. ***
Comment 24 Ray Johnston 2014-01-29 12:53:17 UTC
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.
Comment 25 Hin-Tak Leung 2014-08-26 00:16:39 UTC
*** Bug 690945 has been marked as a duplicate of this bug. ***