See https://bugs.launchpad.net/ubuntu/+source/ghostscript/+bug/288570 When printing PDF files generated with eog or GIMP in 1200 dpi (photos) Ghostscript takes up all disk space with one of the two temporary files (/tmp/gs* or /var/spool/cups/tmp/gs*) it creates. To quickly reproduce the problem, run the following two command lines with the attached file: 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 problem usually disappears when reducing the resolution to 600 dpi. Th PDF input files seem to be OK, as Ghostscript and Adobe Reader display them on the screen without problems. So it is not a bug of the printing facility of GTK.
Created attachment 4539 [details] eog.pdf 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").
A small correction: The first command line example must read (1200dpi): gs -dFirstPage=1 -q -dBATCH -dPARANOIDSAFER -dQUIET -dNOPAUSE -sDEVICE=lj5gray -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=842 -dDuplex=false -r1200 -sOutputFile=- eog.pdf > output Printing with 600 dpi works for me (1.2 GB free space, do not know how much gets occupied on a 600-dpi print).
I was unable to reproduce any problems with the lj5gray device at 600 or 1200 dpi. A 1200 dpi lj5gray device completes in a DEBUG=1 build (which is slower than an optimized build) in 11 seconds. Since I'm running on Windows, I don't have the 'ijs' server. As I understand this device it sends the data via a pipe, so it shouldn't create a large temporary file. The file attached to 690133 is strange. First, it establishes a page level transparency group, then never does any transparency operations. PDFDEBUG shows: %Resolving: [6 0] << /Type /Page /Parent 1 0 R /MediaBox [ 0 0 595.275574 841.889771 ] /Contents 3 0 R /Group << /Type /Group /S /Transparency /CS /DeviceRGB >> /Resources 2 0 R >> endobj Second, it draws the image (1704 x 2272) by defining a (large) pattern tile then painting a rectangle with that pattern. A stoopid way to paint an image if you ask me. Luckily since 8.62 Ghostscript did not have to store the entire pattern in RAM, but instead creates a memory based clist for the large pattern tile. Even if it used large RAM, that wouldn't explain a big temp file.
oops. I meant to close this as WORKSFORME
I have tried now to reproduce the bug with the current SVN trunk of Ghostscript, running on my x86_64 Ubuntu Intrepid system, to exclude effects of distro-specific patches. The problem is still there. As I have 7.2 GB free currently, the command exited successfully but needed several minutes to finish and has taken up more then 2 GB (perhaps even 3 or 4 GB) for temporary files, which is still too much, as many systems do not have this ammount of free disk space. It is also too much when one thinks about a 5.8 MB PDF file to be converted to an 8.8 MB PCL file. I did CFLAGS='-fPIC' ./configure --prefix=/usr --sysconfdir=/etc --with-ijs --with-jbig2dec --with-jasper --with-x --disable-gtk --enable-dynamic --with-omni --enable-cups --disable-compile-inits --with-drivers=ALL --disable-cairo --with-fontpath=/var/lib/defoma/gs.d/dirs/fonts:/usr/share/cups/fonts:/usr/share/ghostscript/fonts:/usr/local/lib/ghostscript/fonts:/usr/share/fonts make and after that GS_LIB=./Resource/Init/:./lib/ bin/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 It takes 2:14.75 on my Dual-Core laptop, with only 17% CPU, so most of the time wasted for I/O to write and read the huge temporary file.
When downgrading to Ghostscript 8.61 the problem disappears. This means that the bug came in in 8.62 or 8.63.
This file apparently broke starting with r8770: Version Time Tempfile r8769 0:05 15 Megs r8770 0:52 1400 Megs ... r9251 0:53 1400 Megs The command line I'm using for testing: bin/gs -sDEVICE=tiff24nc -o test.tif -r1200 ./eog.pdf
Tried the command line gs -sDEVICE=tiff24nc -o test.tif -r1200 ./eog.pdf on Intrepid with the supplied GS 8.63. GS filled up the free 7.2 GB of the disk in 8 minutes. Current Ghostscript from SVN generates also 1.4 GB on my box, needs 2 min for generating the temp file (after that the file stops growing). The total process ends successfully after 3:30 min, producing a 417 MB output file (TIFF is probably not compressed at all). It seems that 8.63 was even worse than the current SVN state of GS. Or the CJK patches of Ubuntu's GS have also a bad influence, but only taking these out would leave us still with 1.4 GB and 3:30 min (on my box) and it worked also with these patches in GS 8.61.
Now I have also tested the shared library version (this way we build it in Ubuntu) of the current SVN state, using the same ./configure line as before and then doing make so LD_PRELOAD=./sobin/libgs.so GS_LIB=./Resource/Init/:./lib/ time sobin/gsc -sDEVICE=tiff24nc -o test.tif -r1200 ./eog.pdf This takes a total of 2:36 minutes and the temp file goes up to 2.4 GB. The Ubuntu package with the CJK patches excluded takes also all 7.2 GB and then crashes due to lack of more space.
With Ghostscript 8.63, built and run as in the previous comment (no Ubuntu patches at all) also fills up all my disk space completely. So it seems that in 8.63 the situation was even worse than in current SVN.
Remark to comment #9: The temporary file with the current SVN state and shared library build is 1.4 GB and not 2.4 GB, so it is the same as Marcos got in his tests. This means that in 8.63 there must be something additional broken which makes the situation even worse.
Comment #10 is correct; my initial analysis was incomplete. This one is better: Version Time Tempfile r8769 0:05 15 Megs r8770 0:52 1400 Megs ... r8850 0:52 1400 Megs r8851 inf inf ... r8929 inf inf r8930 0:49 1400 Megs ... r9251 0:53 1400 Megs
My analysis in Comment #12 appears reasonable. One of the comments for r8930: 2. Revert the revision 8851 change, which was a temporary workaround for the problem, The default value for MAX_PATTERN_BITMAP_SIZE is now restored back to 1Mb.
Can you provide me a patch which brings Ghostscript 8.63 into the state of revision 8850/8930 and as soon as you have solved the rest of the bug a patch which brings it into the state of revision 8769 (in terms of temp file size). I will use them for a stable release update of Intrepid.
Created attachment 4636 [details] patch Patch requested in Comment #14.
Thank you for the patch. I have applied it to the Ghostscript 8.63 of Ubuntu Jaunty and it brings me indeed to the state of trunk. So part 1 of the fix of the bug is done. One can print 1200 dpi photos at least on modern PCs (not on netbooks) but still slowly and with rather high chances to fail.
Reproduced with rev 9221 with this command line : ..\..\gs-hd\bin\gswin32c.exe -IF:/AFPL/gs-hd/Resource/Init;f:\afpl\fonts - r1200 -dNOPAUSE -dBATCH -sDEVICE=tiff24nc -sOutputFile=cur.tif eog.pdf4 The problem happens due to distributing a big pattern through bands. The pattern is clist based having the size 11648087 bytes. Ity is copied to all 144 bands. So the multiple is over 1.5G bytes. The problem is hardly visible on a big comp because the file is created for few seconds. The consumed RAM size is within 50Mb.
Patches to HEAD : http://ghostscript.com/pipermail/gs-cvs/2008-December/008852.html http://ghostscript.com/pipermail/gs-cvs/2008-December/008853.html
Thanks for the quick fix, Can you backport this fix to GPL Ghostscript 8.63 and post an appropriate patch? I would like to apply the patch as a stable release update for Ubuntu Intrepid.
As our source boilerplate says, GPL Ghostscript is unsupported. The patches are available (and are released as GPL patches), so if you wish to backport them to 8.63 (or earlier), you are welcome to do so. We (Artifex Software, Inc.) only provide patches for older releases to paying OEM customers. If the Ubuntu linux group wishes to sign up as a supported customer, please contact us. Note that this patch (and all others) will be part of the Feb 2009 release. Artifex Software has switched to a release every 6 months (Feb and Aug) and all releases are simultaneous GPL and Artifex releases (i.e., the release includes ALL patches).