Bug 687434 - /VMerror in --fill--
Summary: /VMerror in --fill--
Status: NOTIFIED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PS Interpreter (show other bugs)
Version: master
Hardware: All All
: P2 normal
Assignee: Dan Coby
URL:
Keywords:
: 687835 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-04-21 09:05 UTC by Jack Moffitt
Modified: 2008-12-19 08:31 UTC (History)
0 users

See Also:
Customer: 710
Word Size: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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