Bug 126446 - ghostscript/kghostview fails to print pdf file
ghostscript/kghostview fails to print pdf file
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: ghostscript (Show other bugs)
2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-06-21 14:46 EDT by Allyn Tennant
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version: 7.07-29
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-06-25 12:39:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Allyn Tennant 2004-06-21 14:46:38 EDT
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:

http://bugs.kde.org/show_bug.cgi?id=61922

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 bug-ghostscript@gnu.org but have heard
nothing back.

This problem has existed from RedHat 9 (at least) through Fedora 2.

                                        Allyn

----------------------------------------------------------------------
*** 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[0] == '/' &&
               (p->width != width || p->height != height))
            ++p;
+ /* If size_name is "null" then decrement pointer back to /letter */
+         if ( p->size_name[0] == 'n' ) --p;
        pprintd2(s, "%d %d ", width, height);
        pprints1(s, "%s setpagesizen", p->size_name);
      }


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.See instructions at http://bugs.kde.org/show_bug.cgi?id=61922
2.
3.
    

Actual Results:  If the resulting PostScript contains the "null setpagesize" then
the printer will flash receiving file but when done, never prints
anything.

Expected Results:  Printer should produce paper with toner fused to it :-).

Additional info:
Comment 1 Tim Waugh 2004-06-25 12:39:26 EDT
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.
Comment 2 Alex Cherepanov 2006-06-04 09:53:48 EDT
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
preferable.
Comment 3 Allyn Tennant 2006-06-06 18:04:46 EDT
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 
size.

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
> preferable.

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.

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