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