Bug 18908

Summary: pdftops produces a wrong PS when a large image is in Patterns.
Product: poppler Reporter: Koji Otani <sho>
Component: generalAssignee: poppler-bugs <poppler-bugs>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium CC: sanjoy, till.kamppeter
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: a patch fixes this problem.
new patch
patch2
pdf file test case to show pdftops producing a too-large array
a patch fixes the another problem

Description Koji Otani 2008-12-05 19:43:17 UTC
When a large image is in Pattern, pdftops produces a wrong PS with which
Ghostscript produce an error like following.

ERROR: /rangecheck in --array--
Operand stack:
   522208

There is the following code in that PS.

522208 array dup

This is over the limit of array size in Ghostscript.

I attached an example PDF causes this problem.

This pdf is produced by cairo 1.8.0.
Cairo always put images into Pattern!!
Comment 1 Koji Otani 2008-12-05 19:48:09 UTC
I've failed to attach the example PDF because of too large.
Comment 2 Koji Otani 2008-12-05 19:54:05 UTC
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.
Comment 3 Albert Astals Cid 2008-12-06 03:35:14 UTC
Could you send the pdf in private to me?
Comment 4 Albert Astals Cid 2008-12-07 07:16:09 UTC
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?
Comment 5 Koji Otani 2008-12-07 22:59:28 UTC
Created attachment 20885 [details] [review]
new patch
Comment 6 Koji Otani 2008-12-07 23:09:43 UTC
(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.
Comment 7 Albert Astals Cid 2008-12-08 03:38:01 UTC
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?
Comment 8 Koji Otani 2008-12-08 19:03:45 UTC
I'm trying to fix the level1 problem.
Please wait.

Comment 9 Koji Otani 2008-12-09 01:29:16 UTC
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.
Comment 10 Albert Astals Cid 2008-12-09 14:35:17 UTC
The patch brings a regression with the file at bug #17645

Can you have a look at it?
Comment 11 Koji Otani 2008-12-09 20:43:18 UTC
Created attachment 20972 [details] [review]
patch2
Comment 12 Koji Otani 2008-12-09 20:47:19 UTC
Sorry, I attached the patch2.
The regression caused by wrong number of `pop`s and not handling inline images.

Comment 13 Albert Astals Cid 2008-12-16 15:37:52 UTC
Commited
Comment 14 Till Kamppeter 2009-01-02 06:00:30 UTC
*** Bug 19368 has been marked as a duplicate of this bug. ***
Comment 15 Sanjoy Mahajan 2009-07-13 06:43:07 UTC
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.
Comment 16 Sanjoy Mahajan 2009-07-13 06:44:32 UTC
Created attachment 27628 [details]
pdf file test case to show pdftops producing a too-large array
Comment 17 Albert Astals Cid 2009-07-13 10:49:58 UTC
Koji? Till?
Comment 18 Till Kamppeter 2009-07-13 10:56:14 UTC
Otani-san, you did the first patch, can you also fix the other places the same way? Thanks.
Comment 19 Koji Otani 2009-07-14 00:46:00 UTC
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 ?  

Comment 20 Koji Otani 2009-07-14 22:58:40 UTC
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".
Comment 21 Albert Astals Cid 2009-07-25 07:34:45 UTC
Commited your patch with a minor modification that was causing the use of an uninitialized var in some cases.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.