Bug 18908

I've failed to attach the example PDF because of too large.

Created attachment 20848 [details] [review]
a patch fixes this problem.

I attached a patch fixes this problem too.
This patch makes arrays for images nested.

Could you send the pdf in private to me?

From what i understand you changed it to do N loops of 65535 right? Do you think this is safe enough to go into the stable branch?

Created attachment 20885 [details] [review]
new patch

(In reply to comment #4)
> From what i understand you changed it to do N loops of 65535 right? Do you

Yes 

> think this is safe enough to go into the stable branch?
> 

Sorry, the patch is correct only in Language Level option 2 (default).
I attached a new patch which is correct in Language Level option 2 and 3.

But, in case of Language Level option 1, there is another problem to draw image in Pattern.
This problem is exist in current poppler.
I don't understand detail of this new problem yet.

Do you plan to work on that issue?

Do you want me to add your current patch to poppler or do you prefer me to wait until the Level 1 problem is fixed?

I'm trying to fix the level1 problem.
Please wait.

Sorry, I've found too many changes to fix the level1 problem.
Anyway, current pdftops produce incorrect PostScript when images are in pattern for Language Level1.
So, if the current patch is applied, it doesn't become worse.
Please apply the current patch.

The patch brings a regression with the file at bug #17645

Can you have a look at it?

Created attachment 20972 [details] [review]
patch2

Sorry, I attached the patch2.
The regression caused by wrong number of `pop`s and not handling inline images.

Commited

*** Bug 19368 has been marked as a duplicate of this bug. ***

I had trouble printing a pdf file using CUPS (v1.3.10 on Debian GNU/Linux), and after some debugging, traced the problem to CUPS's pdftops producing too-large arrays thereby throwing a /limitcheck in ghostscript.  

The same problem occurs with the non-CUPS pdftops on my system (v0.10.6, packaged as part of the Debian poppler-utils 0.10.6-1 package):

$ pdftops page1.pdf - | grep array
  3 1 roll 2 array astore
/funcCol { func n array astore } def
  func n array astore
  func n array astore
94468 array 0   /* gs complains about this array being > 65536 */
4 array 0
1736 array 0
1228 array 0
1736 array 0
4 array 0
116 array 0
2368 array 0

That version of pdftops and libpoppler has the 'patch2' fix to use nested arrays.  But running the page1.pdf test file through pdftops (using gdb) showed up two more locations that need a similar fix.  Both are in PSOutputDev::doImageL2() and are the same statement:

    writePSFmt("{0:d} array 0\n", rectsOutLen * 4);

In the problematic case, rectsOutLen=23617, requiring a 94468-element array.

I didn't try to make a patch myself, since I don't fully understand all the ins and outs of the earlier patch, but I'm happy to test patches.

Created attachment 27628 [details]
pdf file test case to show pdftops producing a too-large array

Koji? Till?

Otani-san, you did the first patch, can you also fix the other places the same way? Thanks.

In this case, an array has rectangles which used by a rectclip operator.
So, we can't simply use nested arrayes as I did in the first patch.
 If we use nested arrayes and multiple rectclip operators, result clippath is an intersection of rectangle-arrayes instead of an union that we expect. 
Do you have any idea to get union-clippath of rectangle-arrayes ?  

Created attachment 27707 [details] [review]
a patch fixes the another problem

I attached a patch fixed this problem.
I gave up using array in this case. 
When it would be over the limit of array size,
 the patch make each rectangle path and "clip".

Commited your patch with a minor modification that was causing the use of an uninitialized var in some cases.