Red Hat Bugzilla – Bug 142253
huge postscript file generated on print
Last modified: 2008-08-02 19:40:32 EDT
Description of problem: When printing a huge postscript file / print queue is generated causing slowdowns and numerous printer 'out of memory' type problems example printing a 2.2MB pdf generates a 108MB .ps file under /var/spool/cups Version-Release number of selected component (if applicable): Fedora core 1, 2 and 3 How reproducible: Always Steps to Reproduce: 1. open pdf with ggv 2. print 3. huge queue size Actual results: huge file / queue size Expected results: normal file / queue size Additional info: tested on HP4200 with jetdirect and HP4000 using lpd -- any suggestions or workarounds are really appreciated as this is a showstopper for me.
Please attach the output of 'printconf-tui --Xexport'. Thanks.
Created attachment 108241 [details] printconf-tui --Xexport attached file, does everthing normally go through ghostscript to generate the .ps file? As I am getting a much larger printer queue size when printing all files. Files with images tend to be the worst for ps output / print queue vrs original file. An example a pdf (2MB) file producing a large ps file (105MB) is http://www.oracle.com/solutions/mid/ebs_se_na.pdf (printed using ggv) Thanks Walt
The PostScript conversion will almost always be larger than the original file it was generated from, just by the nature of it -- especially so for images. The problem arises from the printer having to keep an entire page in memory before any ink can touch the page. I would suggest either: a) buy more memory for the PostScript module in your printer, or b) try a raster-based driver instead, such as gimp-print-ijs or hpijs (you can do this by going to the "Printer driver" tab in the edit print queue dialog).
Hi I tried the other printer options before posting... with the same result. Maybe it is regenerating the PS file as 1 big image instead of text and images? Maybe it is generating postscript at a high resolution without taking into account the resolution of images in the original file? I don't know enough about it to tell.... expect postscript will be a larger file - maybe even 4 times but > 50 times is excessive. It isn't just about printer memory either generating and then shifting 100MB+ files around cause problems and slowdowns generally. I am sure I can't be the first person to raise this as an issue what do other companies do? - are there any alternative printing systems / methods of printing you could suggest? :) Thanks Walt
Do you get "out of memory" errors on the printer when using gimp-print-ijs or hpijs? (Or is it just slow?)
either way the ps file and queue sent to the printer is large, the out of memory error on the printer is dependent on the printer used though. Of course if 10 people print 1x 4 page pdfs that is over a GB to be shifted. looks to me like when it is printed generate /tmp/file.ps (huge file) move file.ps to /var/spool/cups/ send the thing to the printer so the problem stems from the size of /tmp/file.ps generated - issues being why this file is so large and how to reduce it. does the file generation take into account the src file (resolution of images etc) and the destination (like a greyscale .ps file for the greyscale printer). - probably way off track here.... Is there any way to adjust settings for output in a conf file somewhere? Something along the lines of when generating ps files all images are at a fixed resolution specified and output is to be in greyscale. Thanks Walt
I reckon all this is some strange way ggv converts the file to ps before printing, because I actually get a sane printer queue size (2.5MB queue from a 2MB source file) when I print with xpdf.
Oh, I see, the pdftops output is indeed much smaller than the gs-generated output. Incidentally, 'lpr file.pdf' uses pdftops when it needs to convert to PostScript.
PostScript generator in Ghostscript is inefficient. The exact size of the file depends on the color model and resolution. The PS file is highly redundant and can be compressed to 15% of the original size. PostScript language has build-in decompressors and can use compressed streams directly. Currently GS developers work on a high level PS generator that will produce PS streams similer in size to PDF files. Hovever, the progress is slow for the lack of funding. I can help with high level PS generator development if Red Hat agrees to support it.
Fedora Core 3 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC5 updates or in the FC6 test release, reopen and change the version to match. Thank you!
We might be switching to PDF anyway in the future.