Array too big when printing large image
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
GS-GPL |
Invalid
|
High
|
|||
Poppler |
Fix Released
|
Medium
|
|||
gThumb |
Invalid
|
Undecided
|
Unassigned | ||
eog (Ubuntu) |
Invalid
|
Low
|
Unassigned | ||
Intrepid |
Invalid
|
Undecided
|
Unassigned | ||
poppler (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Intrepid |
Fix Released
|
Undecided
|
Unassigned | ||
xpdf (Debian) |
Fix Released
|
Unknown
|
|||
xpdf (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Intrepid |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
Binary package hint: cups
Printing large (3264x2448) JPEG images from eog or F-Spot worked fine under Hardy but is broken after upgrading to Intrepid, with all updates and pending updates applied, using CUPS 1.3.9-2ubuntu6 and 1.3.9-2ubuntu4.
When I print a large image from eog or F-Spot to an HP DeskJet 6980, I get "/usr/lib/
In the cups log, I get
(/usr/lib/
Starting renderer with command: "gs -sstdout=%stderr -dBATCH -dPARANOIDSAFER -dQUIET -dNOPAUSE -sDEVICE=ijs -sIjsServer=hpijs -sDeviceManufac
Error: /limitcheck in --array--
Operand stack:
114642
The PDF produced in d00122-001 renders fine with evince, but when I run it through cpdftocps the PostScript it produces contains the lines:
xpdf begin
114642 array dup /ImData_7_0 exch def
but the limit for GhostScript is 65535 elements in an array, so it throws a limitcheck.
The same happens when I run gs on the output manually. When I scale the image down to 1632x1224, it prints fine. When I print the image to PDF, that PDF prints fine.
The cpdftocps command line is
/usr/lib/
I have the PDF and PostScript output, but they are 20MB and 33MB respectively, so I haven't attached them.
Changed in ghostscript: | |
importance: | Undecided → Medium |
Changed in gs-gpl: | |
status: | Unknown → New |
Changed in poppler: | |
status: | Unknown → Confirmed |
Changed in poppler: | |
status: | Confirmed → Fix Committed |
Changed in xpdf: | |
status: | Triaged → Fix Committed |
Changed in gs-gpl: | |
status: | New → Invalid |
Changed in poppler: | |
status: | Confirmed → Invalid |
Changed in gthumb: | |
status: | New → Invalid |
Changed in eog (Ubuntu): | |
importance: | Undecided → Low |
Changed in xpdf (Debian): | |
status: | Unknown → New |
Changed in xpdf (Debian): | |
status: | New → Fix Released |
Changed in poppler: | |
importance: | Unknown → Critical |
status: | Invalid → Unknown |
Changed in poppler: | |
importance: | Critical → Unknown |
Changed in poppler: | |
importance: | Unknown → Critical |
Changed in gs-gpl: | |
importance: | Unknown → High |
Changed in poppler: | |
status: | Unknown → Invalid |
Changed in poppler: | |
importance: | Critical → Unknown |
status: | Invalid → Unknown |
Changed in poppler: | |
importance: | Unknown → Medium |
status: | Unknown → Fix Released |
See
https:/ /bugs.launchpad .net/ubuntu/ +source/ ghostscript/ +bug/311982
pdftops (version 3.00 of Poppler) is called by the pdftops CUPS filter in Ubuntu Intrepid and this filter is called by Intrepid'd cpdftocps filter in the mentioned Ubuntu bug report. In other system configurations CUPS can also call its pdftops filter directly.
If the input PDF contains a large bitmap (for example when printing a full-page photo with high resolution), Poppler's pdftops produces the lines
xpdf begin
114642 array dup /ImData_7_0 exch def
in its PostScript output. This defines an array with 114642 in PostScript. According to Adobe's specs PostScript only supports arrays with a maximum number of 65536 elements. So many PostScript interpreters will crash on this output. GhostScript gives a "/limitcheck" error.
This bug prevents from high-resolution photo printing in many cases, especially with newer application version which output PDF instead of PostScript when printing.