The attached file fails with Error: /VMerror in --fill-- when rendered by Ghostscript.
Created attachment 630 [details] vmerror.eps
This is a duplicate of the bug 686904.
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.
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.
*** Bug 687835 has been marked as a duplicate of this bug. ***
The fix is described in: http://ghostscript.com/pipermail/gs-cvs/2005-March/005336.html