Red Hat Bugzilla – Bug 126446
ghostscript/kghostview fails to print pdf file
Last modified: 2007-11-30 17:10:45 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.2; Linux) (KHTML, like Gecko)
Description of problem:
There is a problem with ghostscript that prevents kghostview (and
any other software that uses pdf2ps) from printing some PDF files
with certain printers.
The problem and sample files can be found at:
For some files pdf2ps generates PostScript containing "null setpagesize"
when it should generate "/letter setpagesize". Many printers ignore
this and print using the default paper size. However if you have
a picky printer then all the files containing "null setpagesize"
(about half in our experience) just vanish in the printer.
I have chased the problem down to a loop in gdevpsu.c (in the
ghostscript source tree) where it looks up the width and height in
a table. If the current width and height don't *exactly* match a
value in a table, then the code falls though the loop and generates
the "null setpagesize" PostScript ("null" is the last entry in the
table). I have no idea why anyone would think that the width and
height always be found in the table for *all* files. So the real
problem may be deeper...
Below I show the context diff of a very simple (and very dirty) fix
that I put in which works for us. If the code falls though the loop
(without finding a match) I decrement the pointer, which causes
p->size_name to point to "/letter" instead of "null". This is not
really intended to be a general fix, but it works fine for us (in
the USA) and clearly demostrates the nature of the problem.
I sent this information to email@example.com but have heard
This problem has existed from RedHat 9 (at least) through Fedora 2.
*** gdevpsu.orig 2003-01-16 18:49:01.000000000 -0600
--- gdevpsu.c 2004-06-03 15:31:44.024345004 -0500
*** 273,278 ****
--- 273,280 ----
while (p->size_name == '/' &&
(p->width != width || p->height != height))
+ /* If size_name is "null" then decrement pointer back to /letter */
+ if ( p->size_name == 'n' ) --p;
pprintd2(s, "%d %d ", width, height);
pprints1(s, "%s setpagesizen", p->size_name);
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.See instructions at http://bugs.kde.org/show_bug.cgi?id=61922
Actual Results: If the resulting PostScript contains the "null setpagesize" then
the printer will flash receiving file but when done, never prints
Expected Results: Printer should produce paper with toner fused to it :-).
Thanks for this pointer, and the work-around. For the moment I'll put
in your small patch just to get a working interpreter, but I'd
appreciate any information you get back from the upstream maintainers.
The patch (and analysis) is incorrect. Some printers don't support setting the
page using numeric values but a small set of special purpose operators. The
table look-up checks whether there is a predefined page size operatot to set
this page size. When there is no such operator, "null" indicates that the page
size should be set using numeric method.
The patch makes Ghostscript ignore the page size of the document and use US
Letter size for any non-standard document. This is clearly wrong.
Probably, most users would prefer to fit non-standard pages to the paper size.
However, for the printers with expensive media, a PostScript error is
The patch has known problems. However, prior to the patch a third
to half the jobs failed to print on our printer. The printer would
blink for a bit but nothing would come out. From an end-user
point-of-view this is not acceptable. (Windows prints these files
just fine.) After the patch, I have never had a problem printing.
> Probably, most users would prefer to fit non-standard pages to the paper
If by this you mean you mean figure out what standard paper size most
closely approximates the the request, then I agree. For the
non-printing files that I looked at, the requested paper size was
a few pixels off from one of the standard sizes. Clearly for these
cases it would be better to select the standard size that most closely
matches. I considered this but having failed to make contact with
any GhostScript developers, opted for a simple fix that works for
me, which I shared. Maybe you could propose a better fix?
I assume that this patch does not work for you. Maybe you could give
some more details, like how non-standard is your paper and would setting
the pagesize to the closest match be good enough? If you have a fix
where the page size is set numerically, I'd be willing to try that.
How about if there is no match, that we totally omit the "null
setpagesize" commands, would that work? (I'm not sure it would work
for me, but I would be willing to try.) I also think the user should
be able to select the paper size via a print panel, so having it
hardwired in the file may not be the best option.
> However, for the printers with expensive media, a PostScript error is
I think you are trying to say is that *your* printer handles the
original PostScipt error without any problems. I only got involved
in this because I was fed up with PDF files not printing.