Bug 142253 - huge postscript file generated on print
Summary: huge postscript file generated on print
Alias: None
Product: Fedora
Classification: Fedora
Component: ghostscript   
(Show other bugs)
Version: 3
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-12-08 15:59 UTC by Need Real Name
Modified: 2008-08-02 23:40 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-07-12 15:14:41 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
printconf-tui --Xexport (5.61 KB, text/plain)
2004-12-09 18:31 UTC, Need Real Name
no flags Details

Description Need Real Name 2004-12-08 15:59:23 UTC
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

How reproducible:

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.

Comment 1 Tim Waugh 2004-12-09 14:33:50 UTC
Please attach the output of 'printconf-tui --Xexport'.  Thanks.

Comment 2 Need Real Name 2004-12-09 18:31:48 UTC
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

An example a pdf (2MB) file producing a large ps file (105MB) is
(printed using ggv)



Comment 3 Tim Waugh 2004-12-10 11:16:27 UTC
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).

Comment 4 Need Real Name 2004-12-10 17:23:07 UTC

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? :)



Comment 5 Tim Waugh 2004-12-10 17:40:15 UTC
Do you get "out of memory" errors on the printer when using gimp-print-ijs or
hpijs? (Or is it just slow?)

Comment 6 Need Real Name 2004-12-10 18:33:04 UTC
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.



Comment 7 Need Real Name 2004-12-11 20:13:33 UTC
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.

Comment 8 Tim Waugh 2004-12-13 16:30:46 UTC
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

Comment 9 Alex Cherepanov 2005-03-06 16:36:59 UTC
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.

Comment 10 Matthew Miller 2006-07-10 23:31:25 UTC
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!

Comment 11 Tim Waugh 2006-07-12 15:14:41 UTC
We might be switching to PDF anyway in the future.

Note You need to log in before you can comment on or make changes to this bug.