GNOME Bugzilla – Bug 585442
Evince should output PDF instead of PostScript when printing
Last modified: 2018-05-22 13:34:05 UTC
Please describe the problem: See http://bugzilla.gnome.org/show_bug.cgi?id=560177 We are changing the printing workflow from PostScript-centric to PDF-centric. PDF has more compact files, allows reliable page management (separate and rearrange pages), color management, transparency, ... So printing gets much improved by not pushing the print jobs through the PostScript bottleneck. Unfortunately, the fix of the above-mentioned bug report/feature request does not affect evince. evince needs to be modified by itself. But the modification to do is simple. It is only a 2-line-change patch. See https://bugs.launchpad.net/bugs/258421 for the patch. Perhaps one should put the change into a conditional and allow a switch between PostScript or PDF printing by the ./configure script. Steps to reproduce: Set "LogLevel=debug" in /etc/cups/cupsd.conf and restart CUPS (or run "cupsctl LogLevel=debug"). Then print a file from evince. Look into /var/log/cups/error_log for the logging of this print job. CUPS tells that it has received PostScript. What we want to have is that CUPS receives the job in PDF format. Actual results: Expected results: Does this happen every time? Other information:
That "patch" on launchpad is a joke, right? Commenting out some code? (And the same for the gtk+ "patch".) And it's probably breaking printing to file in the user-selected format. At a minimum, the code must check gtk_printer_accepts_pdf() on the selected printer.
Sorry for referencing to this bad patch. This report is more to ask for switching the print output to PDF in evince, not to present a particular solution on how to do so. I tested the patch now and found out that in fact it breaks the printing into a PostScript file. A check whether the printer accepts PDF is not needed as one of the features of CUPS is that it does all hardware-specific and applications can send the jobs in a hardware-independent format. CUPS does all conversions needed. Qt sends for example PDF on all systems which use CUPS 1.2 or newer.
(In reply to comment #2) > A check whether the printer accepts PDF is not needed as one of the features of > CUPS is that it does all hardware-specific and applications can send the jobs > in a hardware-independent format. CUPS does all conversions needed. Qt sends > for example PDF on all systems which use CUPS 1.2 or newer. But CUPS is not the only gtk printing backend. So a check is definitly needed; it's just that with CUPS it will always be TRUE.
A better approach of a patch was added to the ubuntu bug report. It checks the PDF capability (I hope the function assumes PDF capability if the printer is a CUPS queue) of the print queue and it also respects the user-selected format for printing to a file.
I have tested the last patch attached by Johan Brannlund to the Ubuntu bug report on 06/20 and it works perfectly for me. When printing to a file I get the requested format and when printing to a CUPS queue I get PDF.
Attaching the above-mentioned patch here for reference.
Created attachment 137275 [details] [review] Make evince output pdf on supported printers
Fixed in git master. Thanks!
Re-opening since the patch was reverted in 0ea65770661ff5769d7539afb77dd634a78e9fd4 (master) and fd77f2e6058da799bbe0c705e710402f8644f9d2 (gnome-2-28), with reference to https://bugs.launchpad.net/ubuntu/+source/evince/+bug/451265 .
The ubuntu bug referenced in the revert is incorrect. It should be https://bugs.edge.launchpad.net/ubuntu/+source/cups/+bug/443026 There are two bugs that need to be fixed before PDF output can be restored without introducing regressions: https://bugzilla.gnome.org/show_bug.cgi?id=599401 http://bugs.ghostscript.com/show_bug.cgi?id=690823
The bug http://bugs.ghostscript.com/show_bug.cgi?id=690823 was fixed 2011. According to the comments, there should not be regressions now.
(In reply to comment #11) > The bug http://bugs.ghostscript.com/show_bug.cgi?id=690823 was fixed 2011. > According to the comments, there should not be regressions now. I forgot to mention, the fix is in http://bugs.ghostscript.com/show_bug.cgi?id=689150
Can the fix for this bug get applied now? All bugs blocking this one are fixed now.
BTW, Evince should not alter PostScript or PDF files when printing them; it must submit the files as-is to cups. Anything else guarantees damaged output. (There is no such thing as bijective conversion between the two int he floss world. No floss-ware exists which can take an arbitrary ps document and output a pdf which will print the same, nor do any exist which can take an arbitrary pdf and convert it to identical ps. Simple files may convert OK, but the important ones will not. And if such a conversion is required due to limitations of the printer, that is cups' job, not evince's. The prints shouldn't look different just because they were printed from evince rather than from lp(1) or lpr(1) or any other app.) For DVI files and the commics files evince supports, it should ask cups what the print queue prefers and generate that. (If the queue is to a postscript printer which cannot also handle pdf, it is better to generate ps; if the queue is handled by ghostscript it is better to generate pdf, etc.)
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/evince/issues/92.