Ghostscript eats all hard drive space and prints errors when printing with 1200 dpi

When the disk got full by such a job, can you post the output of

ls -l /tmp/gs*
ls -l /var/spool/cups/*
ls -l /var/spool/cups/tmp/*

and also attach /var/log/cups/error_log

This helps us to see in which stage a temporary file grows infinitely.

ls -l /tmp/gs*
-rw------- 1 lp lp 32768 2008-10-24 03:40 /tmp/gs_6PXapd
-rw------- 1 lp lp 4220620800 2008-10-24 03:40 /tmp/gs_ETqX1m

ls -l /tmp/foomatic*
-rw------- 1 lp lp 1115706 2008-10-24 03:39 /tmp/foomatic-5lAEq5

ls -l /var/spool/cups/*
-rw------- 1 root lp 758 2008-10-24 03:34 /var/spool/cups/c00099
-rw------- 1 root lp 758 2008-10-24 03:34 /var/spool/cups/c00100
-rw------- 1 root lp 757 2008-10-24 03:35 /var/spool/cups/c00101
-rw------- 1 root lp 757 2008-10-24 03:35 /var/spool/cups/c00102
-rw------- 1 root lp 894 2008-10-24 03:40 /var/spool/cups/c00103
-rw-r----- 1 root lp 1115669 2008-10-24 03:39 /var/spool/cups/d00103-001

ls -l /var/spool/cups/tmp/*
(this directory does not exist)

I have to mention that sometime, huge cups temporary files are stored in /tmp, and sometime in /var/spool/cups/tmp. This might be caused by me, because I deleted /var/spool/cups/* many times.

I could reproduce the bug. Ghostscript indeed makes too big temporary files when feeding it with the print job output (PDF) of eog or GIMP and choosing a resolution of 1200 dpi. PDF files of other apps are OK. This is not a bug of GTK, as the PDFs generated by GTK (the toolkit eog and GIMP are based on) can be displayed on the screen without problems, using Adobe Reader or Ghostscript. It is also not a problem of HPLIP, as the same problem occurs when using Ghostscript's built-in "lj5gray" driver with 1200 dpi (PCL-XL raster driver). This is a bug of Ghostscript.

To reproduce, take the attache PDF file and execute the following Ghostscript command lines:

gs -dFirstPage=1 -q -dBATCH -dPARANOIDSAFER -dQUIET -dNOPAUSE -sDEVICE=lj5gray -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=842 -dDuplex=false -r600 -sOutputFile=- eog.pdf > output

gs -dFirstPage=1 -q -dBATCH -dPARANOIDSAFER -dQUIET -dNOPAUSE -sDEVICE=ijs -sIjsServer=hpijs -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=842 -sDeviceManufacturer="HEWLETT-PACKARD" -sDeviceModel="deskjet 5550" -dDuplex=false -r1200 -sIjsParams=Quality:Quality=3,Quality:ColorMode=2,Quality:MediaType=2,Quality:PenSet=2,Quality:FullBleed=1,PS:MediaPosition=7 -dIjsUseOutputFD -sOutputFile=- eog.pdf > output

Note that if you have really plenty of disk space (for /tmp) it is possible that the commands finish successfully.

The attached file is the PDF produced when printing a 10 MP photo from eog with 1200 dpi selected in the printer settings. It was taken from the CUPS spool directory /var/spool/cups/ (file with name starting with "d").

Same Problem here...

I have this issue as well. With a HP Photosmart C6280.

I worked around the issue by backporting an older version of Ghostscript to Intrepid:
deb http://ubuntu.pcode.nl/ubuntu intrepid ghostscript

That solved my issue.

I also have been experiencing: "/usr/lib/cups/filter/foomatic-rip failed" whenever I tried to print large photographs to either my Deskjet 970Cxi or my Photosmart C6250.

In my case, the problem appears to have been solved by installing the latest PPDs from Intrepid. My Intrepid computers have all been upgrades and the PPDs for my installed printers in /etc/cups/ppd were from either Hardy or Fiesty.

These new PPD files show the file version as follows:
*FileVersion: "hpijs 2.8.7"

The old ones were:
*FileVersion: "hpijs 2.8.2"

BTW, I have plenty of disk space; the spooler files often exceed 10 gigabytes but printing high density images does work.

TK, so you have still the bug, too. 10 GB as temporary file for converting a < 10MB PDF to a < 10MB PCL is too much.

Printers such as HP's Deskjet series have very limited image processing capabilities. For images, the host computer is providing the rasterising. Each dot of ink on the page is defined by a bit in the file being sent to the printer. An HP Deskjet 970Cxi is a CMYK printer (four inks) while an HP Photosmart is a CcMmYK printer (six inks). Each color of ink will require it's own array of bits.

When printing at 1200 dpi, each square inch of printing will require 1,440,000 bits per ink color. For graphics printing, the temporary spool file will by necessity be large because it is the raster image in PCL of what is to be printed.

Here is HP's PCL manual. Chapter 15 covers raster images and compression techniques:
http://h20000.www2.hp.com/bc/docs/support/SupportManual/bpl13210/bpl13210.pdf

TK, this is not the problem, as I told earlier in this bug report the size of the PCL output is smaller than 10 MB. And in addition, HP's inkjets are not so dumb as most others. Most of them take an RGB image and the printer converst it to CMYK or CcMmYK. In addition, the big temporary files occur also with the "lj5gray" driver, a driver for monochrome laser printers.

The Ghostscript developers have done more investigation now and found out which change exactly caused the big temporary files. So there is really a bug in Ghostscript. Note that older Ghostscript releases worked correctly.

I'm not saying there isn't a defect in the ghostscript code; I was experiencing the same error message and extremely large dead spool files in my tmp directories. After deleting these dead spool files I had plenty of empty disk space but would still experience the "/usr/lib/cups/filter/foomatic-rip failed" for large image files. Similar symptoms, but a different cause. I thought my post might be useful to some but not everyone who is experiencing the error message.

But I do have a two questions. Your example pdf file contains a 1704x2272 RGB image scaled at 220 dpi. You desire to print this at 9295x12393 at 1200 dpi. This will also require interpolating extra bits of resolution and color space conversion from RGB to CMYK or CcMmYK.

For photo quality image printing in Linux:

Where does the interpolation take place? In the driver or the printer?

Where does the color space conversion take place? In the driver or the printer?

I rebuilt Debian gs_8.62.dfsg.1-3.1 for Intrepid, and things still seem fine...

So the bug probably slipped in between 8.62 and 8.63...

Thank you, Pascal, and as you can see in the upstream report the Ghostscript developers have already found the exact commit which caused the bug and it was indeed between 8.62 and 8.63.

TK, the interpolation takes place in the computer and the color space coversion is done by the printer (at least for most color lasers and HP inkjets). This does not mean that the full page needs to be stored uncompressed in a file or in memory. Ghostscript for example devides up the page into bands and renders only one band at a time and sends it off to the printer before it renders the next band. In addition print data transfer is often done compressed.

You can see in the upstream bug report in comment #7 (http://bugs.ghostscript.com/show_bug.cgi?id=690133#c7) that Ghostscript 8.62 and older needed only 15 MB as temp file space for the job discussed here, Only after a certain change which the Ghostscript developers have already localized the space need jumped into the order of GB. And the released Ghostscript 8.63 seems to take even more space than earlier and later development snapshots of Ghostscript.

Thanks for the update, I hope a fix will still make it into Intrepid...

This bug was fixed in the package ghostscript - 8.63.dfsg.1-0ubuntu12

---------------
ghostscript (8.63.dfsg.1-0ubuntu12) jaunty; urgency=low

  * debian/patches/65_too-big-temp-files.dpatch: Ghostscript produced much too
    big temporary files (> 10 GB) when printing photos from GNOME apps in
    1200 dpi. Part 1 of the fix which reduces the temp file size to less than
    2 GB (LP: #288570, Upstream bug #690133).

 -- Till Kamppeter <email address hidden> Wed, 3 Dec 2008 23:37:45 +0100

The upload does only a partial fix. By fixing one of the two bugs which caused the problem it reduces the former temp file size of more than 10 GB to less than 2 GB, but still more than 1 GB. This raises the probability of a photo getting printed on a modern PC, but for netbook users there is still no chance. So the other bug needs to get fixed, too. See upstream bug report.

Till, thanks for working on this update and your answers to my questions. These two sites also helped me better understand how Ghostscript, hpijs, and CUPS relate to one another.

http://www.linuxprinting.org/show_driver.cgi?driver=hpijs

http://hplipopensource.com/node/125

My spooler files with ghostscript 8.63.dfsg.1-0ubuntu12 are now in the 1 - 2 Gigabyte range which is acceptable for my notebooks and desktops.

I'll stick with the 8.61 backport for now. I hope this can be reduced to sub-100MB for Jaunty again...

This bug was fixed in the package ghostscript - 8.63.dfsg.1-0ubuntu13

---------------
ghostscript (8.63.dfsg.1-0ubuntu13) jaunty; urgency=low

  * debian/patches/70_take-into-account-data-in-stream-buffer-before-refill.dpatch:
    Certain files lead to a Ghostscript error due to wrong handling of the
    stream buffer (LP: #306125, upstream bug #690090).

  * debian/patches/67_too-big-temp-files-2.dpatch: Complete fix for the too big
    temporary files. Now the bug is completely fixed. Temp files are not much
    bigger than the jobs themselves now (LP: #288570, upstream bug #690133).

 -- Till Kamppeter <email address hidden> Sun, 14 Dec 2008 15:37:45 +0100

I got a patch backported to Ghostscript 8.63 from upstream now and applied it. It works perfectly. The command line

gs -sDEVICE=tiff24nc -o test.tif -r1200 eog.pdf

produces the correct output file in around 15 seconds and a maximum temp file size of 11 MB.

This fix should be SRUed for Intrepid. A Hardy SRU is not needed, as there the bug is not present.

Till Kamppeter : Will you take care of the SRU? If not, I can prepare a tested debdiff for intrepid-proposed and subscribe sponsors for main.

Accepted 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!

I printed one page in "photo" quality that failed all the time in the past and it started to print within 1 second, and the result is perfect. So far the fix works flawlessly.

I just installed ghostscript 8.63.dfsg.1-0ubuntu6.1 from proposed, and it works like a charm.

Will this make it into mainline 8.10?

Yes, it will move to -updates soon. Thanks for testing!

I've just installed version 8.63.dfsg.1-0ubuntu6.1 to see if it fixes Bug #159389; it appears that it does.

This bug was fixed in the package ghostscript - 8.63.dfsg.1-0ubuntu6.1

---------------
ghostscript (8.63.dfsg.1-0ubuntu6.1) intrepid-proposed; urgency=low

  * debian/patches/70_take-into-account-data-in-stream-buffer-before-refill.dpatch:
    Certain files lead to a Ghostscript error due to wrong handling of the
    stream buffer (LP: #306125, upstream bug #690090).

  * debian/patches/65_too-big-temp-files-1.dpatch,
    debian/patches/67_too-big-temp-files-2.dpatch: Ghostscript produced much too
    big temporary files (> 10 GB) when printing photos from GNOME apps in
    1200 dpi (LP: #288570, upstream bug #690133).

  * debian/patches/62_onebitcmyk-pdf.dpatch: Check the whole Decode array to
    detect special cases of identity and inverse decoding in PDF files
    (Upstream bug #690178).

  * debian/patches/50_lips4-floating-point-exception: Fixed floating-point
    exception in "lips4" and other drivers (Upstream bug #690122).

 -- Till Kamppeter <email address hidden> Mon, 15 Dec 2008 09:01:22 +0100