GNOME Bugzilla – Bug 560177
Applications should send print jobs to CUPS in PDF format and not in PostScript
Last modified: 2011-01-03 14:35:44 UTC
I am Till Kamppeter, leader of the OpenPrinting work group at the Linux Foundation. As you can see on [1] OpenPrinting has agreed on switching from PostScript to PDF as standard print job format. This decision was made between printing system and driver developers, application developers, desktop developers, and many major printer manufacturers. I want to ask you whether you can switch from PostScript to PDF as print job output format also in the printing facilities of the GTK and GNOME libraries, as many desktop applications use these. The change should not be very complicated as the GTK printing functionality is already capable of rendering the printing output into PDF files. Print jobs can be sent in principle as PDF on all Linux and Unix systems with CUPS 1.2 or newer. Even if CUPS does not process them in PDF format it works as CUPS converts them to PostScript then. You could make it run-time configurable (via "Edit"/"Preferences") or depending on whether the system is Linux or Unix with CUPS 1.2.x or newer (this way they do it in Qt). As you can also see on [1], KDE and Qt applications already send jobs in PDF and OpenPrinting has organized the development of the CUPS filters for the PDF printing workflow. Debian and Ubuntu already include CUPS packages with PDF-based printing workflow. [1] https://www.linuxfoundation.org/en/OpenPrinting/PDF_as_Standard_Print_Job_Format
Many, but not all GTK/GNOME applications (for example gedit, standard print dialog of GIMP) can be made generating print jobs in PDF by the simple patch attached to this Ubuntu bug report: https://bugs.edge.launchpad.net/ubuntu/+source/gtk+2.0/+bug/258421 Probably the GTK and/or GNOME libraries and also some individual applications need also to be modified so that they send print jobs in PDF. Some one who is more knowledgeable about GTK and GNOME than me, please add appropriate bug reports and CC me. Thank you.
Well, the patch you have there is clearly not good enough. It ignores the comment right above your changes: /* TODO: check if it is a ps or pdf printer */ Which is exactly what I told you the mailing list...
If we are using CUPS 1.2 or later we do not need to care about what the printer understands. CUPS takes care for us and converts to the format needed by the printer. So we can always send PDF and CUPS makes the best out of it calling the appropriate filters. With CUPS every printer is a PostScript/PDF/JPG/TIFF/PNG/text/... printer. Sending PDF and not PostScript has a lot of advantages. See https://www.linuxfoundation.org/en/OpenPrinting/PDF_as_Standard_Print_Job_Format I suggest to proceed like Qt does: On Linux/Unix systems with CUPS 1.2.x or later send PDF by default, otherwise PostScript.
I don't necessarily agree that it is a good idea to rely on whatever black shellscript magic cups runs to convert. The basic principle should be the fewer conversions the better, I'd say. And anyway, your current patch does not even do the cups 1.2 check...
The patch is a simple approach which I have made for the Ubuntu Intrepid distribution, where CUPS does a full PDF printing workflow: PDF input is preprocessed with the pdftopdf filter and afterwards pdftoraster or foomatic-rip 4.0 let the PDF get directly converted to the printer's native format. A general approach would be checking what the environment is. Instead of checking for CUPS 1.2 or newer one could also check for the presence of the pdftopdf CUPS filter, which tells that a PDF printing workflow is used. CUPS filtering is not black shell script magic. CUPS filtering is intended to make it unnecessary for applications to know which data format a printer accepts. It gives the possibility for the application to send the same data format to every available print queue, independent of the printer hardware. Only the CUPS server (the machine where the print queue is actually defined) needs to know about the hardware. And now where we can send the same data format into every print queue, we can choose the most sophisticated, which makes the further processing most reliable, which is more compact, allows color management, ... and this is PDF. And as GTK is already capable to send print jobs in PDF format, the implementation of this feature request is simple, only changing the defaults for a certain selection of operating systems. Perhaps one should implement it simply by a switchable option in an /etc/... file, so that the Linux distributor or system administrator can simply set the default.
Created attachment 150335 [details] [review] use PDF format The attached patch makes CUPS printers use PDF format when the CUPS version is >= 1.2. As I understand it, CUPS is now converting PS jobs to PDF then performing all filtering in PDF format. So by not outputting the job in PDF format we are incurring an additional processing step. Using PDF format also has obvious advantages when the printer supports printing in PDF format. Many of the newer HP color laser printers now support PDF. One thing this patch does not address is the gtk_printer_accepts_pdf() function. This function always returns TRUE. Is this a bug or am I not understanding how gtk_printer_accepts_pdf() is meant to work? I was also not sure about whether gtk_printer_get_capabilities() should be setting GTK_PRINT_CAPABILITY_GENERATE_[PS|PDF] in its return value.
I don't see the advantage of using PDF over PS from the printers point of view. It seems like yet another layer of complication in which bugs can reside. Effectively you know have application --> cups --> printer pdf ps instead of application --> (cups or lpr) --> printer ps ps And just to show that this isn't theoretical, I have a reproducible problem where I have a standard issue bulk network postscript printer, and try to print an ordinary postscript file. lpr works on all computers. ubuntu jaunty and hardy's versions of cups don't mangle the postscript file on the way through and printing is successful. The computers upgraded to karmic fail to print said ordinary simple postscript file. lpr from those computers works, and all cups systems have the same ppd for the printer. Moral: Keep It Simple (BTW the only bromide film printing engines I know contain postscript rips, and don't understand pdf, if you want a leaf from "professional printing")
(In reply to comment #7) > I don't see the advantage of using PDF over PS from the printers point of view. > It seems like yet another layer of complication in which bugs can reside. > Effectively you know have > > application --> cups --> printer > pdf ps > > instead of > > application --> (cups or lpr) --> printer > ps ps > CUPS is now converting to PDF before filtering. So it is actually application --> (cups or lpr) --> (cups filters) --> (pdftops) --> printer ps pdf pdf ps The problem here is that PS does not support transparency and other PDF features. So if drawing some text with transparency that can not be flattened by cairo (eg if it intersects with other parts of the drawing), the PS output will contain fallback images. If printing to a PDF capable printer this increases the printing time and reduces the quality of the output compared to native PDF printing. > And just to show that this isn't theoretical, I have a reproducible problem > where > I have a standard issue bulk network postscript printer, and try to print an > ordinary postscript file. lpr works on all computers. ubuntu jaunty and hardy's > versions of cups don't mangle the postscript file on the way through and > printing is successful. The computers upgraded to karmic fail to print said > ordinary simple postscript file. lpr from those computers works, and all cups > systems have the same ppd for the printer. Moral: Keep It Simple What is the Ubuntu bug number for this issue? Bugs are a side effect of introducing new functionality. That doesn't mean we should not add any new functionality to a working system. Over time the bugs will be fixed.
I didn't realise the transparency issue. From where I am sitting, every office I have ever been in has had a postscript printer (yes, rs232 connected apple laserwriter II in the beginning), but I have yet to see a PDF printer. (So I'm more worried about "working" than "speed") My bug report was: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/404214 but a quick search for "print karmic postscript" in the ubuntu launchpad gives a rather long list. (I also like the simplicity of "send generic postscript to the printer which will understand without trying to do better") I still think there is a bug here, because I generated lots of waste paper simply by clicking "Print to LPR" in Eye of gnome... (surprised!)
(In reply to comment #9) > My bug report was: > > https://bugs.launchpad.net/ubuntu/+source/cups/+bug/404214 I've written a patch to fix that bug. It was a bug in poppler. > but a quick search for "print karmic postscript" in the ubuntu launchpad gives > a rather long list. I did a search for "print karmic postscript" at https://bugs.launchpad.net/ubuntu and got 13 results. None of them appeared to mention problems with printing PostScript files directly. Can provide the bug numbers of any bugs similar to the above bug? > (I also like the simplicity of "send generic postscript to the printer which > will understand without trying to do better") You can always use "lpr -o raw". > I still think there is a bug here, because I generated lots of waste paper > simply by clicking "Print to LPR" in Eye of gnome... (surprised!) Can you provide (in a new bug report) the steps to reproduce and the PS output you are getting.
(From your patch fix to poppler (Thank you!) you see how surprised I might be that PDF came into the picture at all) https://bugzilla.gnome.org/show_bug.cgi?id=407947#c2 contains the steps to see the PDF output I am getting, which reaches the generic postscript printer which can't cope. Hence the ubuntu bugs are relevant because they seem puzzled by their applications no longer being able to print to a postscript printer. A combination of your poppler fix, and whatever you come up with for 407947 will presumably make all of them happy. (cf all the comments about "same PPD file")
What needs to be done to keep compatibility to non-CUPS spoolers is only to emuit PDF when the print job gets emitted through CUPS. On non-CUPS systems PostScript is more adequate as that spoolers are usually not capable to convert incoming PDF to PostScript.
Created attachment 177141 [details] [review] use PDF format where supported by CUPS backend Rebasing my patch to git master. From: Adrian Johnson <ajohnson@redneon.com> Date: Wed, 29 Dec 2010 01:31:53 +1030 Subject: [PATCH] Use PDF format in CUPS backend CUPS 1.2 or later accepts PDF print jobs. As CUPS is now using PDF as the print job format, all PostScript jobs are converted to PDF before filtering and converting to the printer format (PCL, PostScript, PDF etc). Using PDF as the print job format avoids the PS->PDF conversion step and also avoids rasterizing transparency on printers that support PDF. This should improve printing performance by eliminating an unnecessary processing step as well as improving the output on newer laser printers that accept PDF format.
Committed a slightly different patch.