Summary: | Regression: Ghostscript takes up all disk space when rendering eog or GIMP PDF output in 1200 dpi | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Till Kamppeter <till.kamppeter> |
Component: | PDF Interpreter | Assignee: | leonardo <leonardo> |
Status: | NOTIFIED FIXED | ||
Severity: | blocker | ||
Priority: | P2 | ||
Version: | 8.63 | ||
Hardware: | PC | ||
OS: | Linux | ||
Customer: | Word Size: | --- | |
Attachments: |
eog.pdf
patch |
Description
Till Kamppeter
2008-10-24 02:52:48 UTC
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). |