[Poppler-bugs] [Bug 18908] pdftops produces a wrong PS when a large image is in Patterns.

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=18908


Sanjoy Mahajan <sanjoy at mit.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sanjoy at mit.edu
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |




--- Comment #15 from Sanjoy Mahajan <sanjoy at mit.edu>  2009-07-13 06:43:07 PST ---
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.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.