Bug 687434

Summary: /VMerror in --fill--
Product: Ghostscript Reporter: Jack Moffitt <jack>
Component: PS InterpreterAssignee: Dan Coby <dan.coby>
Status: NOTIFIED FIXED    
Severity: normal    
Priority: P2    
Version: master   
Hardware: All   
OS: All   
Customer: 710 Word Size: ---

Description Jack Moffitt 2004-04-21 09:05:44 UTC
The attached file fails with Error: /VMerror in --fill-- when rendered by
Ghostscript.
Comment 1 Jack Moffitt 2004-04-21 09:06:52 UTC
Created attachment 630 [details]
vmerror.eps
Comment 2 Alex Cherepanov 2004-04-23 13:45:50 UTC
This is a duplicate of the bug 686904.
Comment 3 Ray Johnston 2004-12-19 20:48:01 UTC
This VMerror occurs during allocation of a pattern accumulation
memory device. I stopped at the first occurence of the problem,
but the width and height for the pattern was [497315, 1250288].
SInce 621,786,976,720 is rather a large number of pixels, we
are at least detecting and returning a reasonable error code.

To fix this, we would need to do one of the following:

1) render the pattern directly into the current device. The
   biggest problem is getting the matrix correct. Also we
   might need to render the pattern more than once depending
   on the pattern box instantiation intersection with the
   area to be filled.

                  - or -

2) Collect a clist (display list) for the pattern and then when
   filling, get bits from the clist device as needed to perform
   the filling.

I suspect we will see this bug several times more.


Comment 4 Raph Levien 2004-12-20 10:28:39 UTC
The original file is requesting a ridiculously large pattern tile:

371194 0 0 -933211 469728 3.28895e+007 pf

In general, I think we will need to record the pattern as high level drawing
commands (perhaps using the clist, perhaps going even higher), then play them
back to render pattern fill. There are three reasons why our pattern
accumulation method is inadequate:

1. The issue of this bug.

2. Halftone phase (in general, the halftone phase will differ for each tile
repeat), so storing in device color space (halftoned) is inadequate.

3. For the general case of PDF 1.4 transparency, the pattern can interact with
the backdrop using arbitrary alpha and blending. Recording high level drawing
commands and playing them back is the correct behavior.

I think we could get away with eliminating the pattern accumulation buffer
altogether, but there may be cases where it is more efficient, so it may be
worth having logic to switch between the two strategies.
Comment 5 Dan Coby 2005-03-15 16:48:20 UTC
*** Bug 687835 has been marked as a duplicate of this bug. ***
Comment 6 Dan Coby 2005-03-23 11:51:26 UTC
The fix is described in:

http://ghostscript.com/pipermail/gs-cvs/2005-March/005336.html