Array too big when printing large image

Ghostscript developer Ralph Giles tells in the referenced Ghostscript upstream bug report that the 64K array size limit is standard in PostScript according to Adobe's specs. Therefore the bug is in Poppler (the creator of the PostScript file with the too big array). Moved bug appropriately.

The Poppler developers have already fixed the bug. I have applied the upstream patch to Jaunties Poppler package and this solves the problem. A debdiff is attached. Please someone with appropriate upload privileges uploadthe fixed Poppler package to Jaunty and to Intrepid -proposed.

For reproducing this bug in Intrepid an Jaunty and for confirming that the new version fixes the bug I attach some files.

Open the file with "eog" and print it with a large page size (A3, or custom 30x40 inches, use "File"/"Page Setup" in eog) into a PDF file. This PDF file displays OK wth Ghostscript, evince and Acrobat Reader. The file is attached.

If you convert this test file to PostScript with the currently installed Poppler ("pdftops testphoto-reichstag.pdf"), you get a line

114642 array dup /ImData_7_0 exch def

(or similar) in the PostScript file. This line defines a too big PostScript array which makes Ghostscript crash. After appying the patch and converting the PDF file again, you get a construction of two nested arrays and with this one Ghostscript works and also all PostScript printers should work.

xpdf duplicates the code of pdftops and of Poppler. Here the patch needs to get applied most probably, too.

Confirmed that pdftops of xpdf has the same problem.

The above-mentioned Poppler patch also fixes the pdftops of XPDF. debdiff for Jaunty (and Intrepid) attached. Please can someone with appropriate upload rights upload the new package to Jaunty and also to Intrepid -proposed? Thanks.

This bug was fixed in the package poppler - 0.8.7-1ubuntu1

---------------
poppler (0.8.7-1ubuntu1) jaunty; urgency=low

  * debian/patches/63_do-not-make-ps-arrays-bigger-than-64k-from-big-images-in-patterns.patch:
    pdftops produced wrong PostScript when a large image is in a pattern in
    the input file (LP: #311982, Upstream bugs #18908 and #19368).

 -- Till Kamppeter <email address hidden> Fri, 2 Jan 2009 14:26:55 +0100

Unless someone wants to go through the hassle of an intrepid SRU for xpdf and involve ~motu-sru, I nack this for intrepid-updates.

Accepted poppler into intrepid-proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

This bug was fixed in the package xpdf - 3.02-1.4ubuntu2

---------------
xpdf (3.02-1.4ubuntu2) jaunty; urgency=low

  * debian/patches/do-not-make-ps-arrays-bigger-than-64k-from-big-images-in-patterns.dpatch:
    pdftops produced wrong PostScript when a large image is in a pattern in
    the input file (LP: #311982, Upstream bugs #18908 and #19368).

 -- Till Kamppeter <email address hidden> Fri, 2 Jan 2009 18:12:55 +0100

Just wanted to note that upgrading libpoppler3 package from intrepid-proposed solved the problem of printing a large image from eog for me.

Thanks!

This bug was fixed in the package poppler - 0.8.7-1ubuntu0.1

---------------
poppler (0.8.7-1ubuntu0.1) intrepid-proposed; urgency=low

  * debian/patches/63_do-not-make-ps-arrays-bigger-than-64k-from-big-images-in-patterns.patch:
    pdftops produced wrong PostScript when a large image is in a pattern in
    the input file (LP: #311982, Upstream bugs #18908 and #19368).

 -- Till Kamppeter <email address hidden> Fri, 2 Jan 2009 14:26:55 +0100

Today I tried to print two 3449x2480 JPEG images using gthumb.
This failed with a very similar error
"Error: /limitcheck in --array--" printed instead of the images.

Printing same sized images used to work on Hardy on the same printer.

The file that ended up in the /var/spool/cups directory now is a
22210129 bytes PDF-1.4 file, which I didn't want to attach here due
to its size.

Neither evince nor Adobe acroread had problems to display this
PDF file, so I assume this file is still correct and the cause of the
printing problem is not directly in gthumb.

Opening the PDF file copied from the cups spool in acroread and
printing it again with Adobe acroread did work around the problem.

But I added the project ``gthumb`` as affected to this bug report,
because users of gthumb might experience this as a bug in the
application and might find this information helpful.

Peter, did you do all updates on your Intrepid system? The mentioned problem is caused by a bug in Poppler which produced invalid PDF. Please check which Poppler version you have installed via

dpkg -l | grep poppler

The version must be 0.8.7-1ubuntu0.1 (or newer).

Hello Till,

Thank you very much for your immediate response. You wrote:
> Peter, did you do all updates on your Intrepid system? The mentioned
> problem is caused by a bug in Poppler which produced invalid PDF. Please
> check which Poppler version you have installed ...
Yes: I still had
  ii libpoppler3 0.8.7-1
on my computer. But adding intrepid-proposed to the package sources wasn't
sufficient to change that. I also had to use "Package->Force Version" in
synaptic to get the updated fixed version
  ii libpoppler3 0.8.7-1ubuntu0.1
installed. That solved the problem with printing larger images for me.
Thanks again!

Regards, Peter
--
Peter Funk, ✉Oldenburger Str.86, D-27777 Ganderkesee
office: ArtCom GmbH, ✉Haferwende 2, D-28357 Bremen, Germany
tel:+49-421-20419-0 cell:+49-179-640-8878 <http://www.artcom-gmbh.de/>

I can confirm this is now fixed in intrepid-updates. Many thanks!

eog also appears to produce oversize arrays when printing large images, resulting in errors like:

D [25/Jun/2009:16:53:00 +0800] [Job 172688] Error: /limitcheck in --array--
D [25/Jun/2009:16:53:00 +0800] [Job 172688] Operand stack:
D [25/Jun/2009:16:53:00 +0800] [Job 172688] 90223
D [25/Jun/2009:16:53:00 +0800] [Job 172688] Execution stack:
D [25/Jun/2009:16:53:00 +0800] [Job 172688] %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1905 1 3 %oparray_pop 1904 1 3 %oparray_pop 1888 1 3 %oparray_pop 1771 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval--
D [25/Jun/2009:16:53:00 +0800] [Job 172688] Dictionary stack:
D [25/Jun/2009:16:53:00 +0800] [Job 172688] --dict:1152/1684(ro)(G)-- --dict:0/20(G)-- --dict:93/200(L)-- --dict:66/75(L)--
D [25/Jun/2009:16:53:00 +0800] [Job 172688] Current allocation mode is local
D [25/Jun/2009:16:53:00 +0800] [Job 172688] Last OS error: 2
D [25/Jun/2009:16:53:00 +0800] [Job 172688] GPL Ghostscript 8.62: Unrecoverable error, exit code 1
E [25/Jun/2009:16:53:01 +0800] PID 21114 (/usr/lib/cups/filter/pstoraster) stopped with status 1!

Hi Craig,

from the information you submitted it is not obvious, which version of
Ubuntu and more precisely which version of libpoppler you used.
From the Ghostscript version 8.62 I guess it is 8.10 (Intrepid).
eog uses libpoppler which suffered from this now fixed bug.
Did you install the fixed version from intrepid-updates.

Regards, Peter.

Ah - I only just noticed that this bug had been targeted specifically at poppler. The issue is on eog 2.26.1 on Jaunty with all updates. I'll file a new bug.

Please disregard my previous report. The CUPS server was finding printers exported by a Debian Lenny box. Lenny's poppler source package lacks debian/patches/63_do-not-make-ps-arrays-bigger-than-64k-from-big-images-in-patterns.patch .

Might I suggest that ghostscript report an error to the effect "input is invalid (64k limit)"
So that the various filters which MIGHT generate this bad input can be highlighted
Rather than ghostscript appearing to be the cause of the problem. I've just hit this on an up-to-date
Debian system ...where the print server runs.
(I'll now go trawling the Debain bug reports ...see if I have patch)