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
Version-Release number of selected component (if applicable):
Fedora core 1, 2 and 3
Steps to Reproduce:
1. open pdf with ggv
3. huge queue size
huge file / queue size
normal file / queue size
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]
attached file, does everthing normally go through ghostscript to generate the
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
An example a pdf (2MB) file producing a large ps file (105MB) is
(printed using ggv)
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).
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
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? :)
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.
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 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.
We might be switching to PDF anyway in the future.