GNOME Bugzilla – Bug 407947
gtkprinter assume printers are capable of accepting pdf input by default
Last modified: 2011-01-03 13:15:00 UTC
Please describe the problem: In evince 0.6.1, when it is asked to print a PDF file. It checks to see whether to export Pdf format data or not by export_to_ps = !gtk_printer_accepts_pdf (window->priv->printer); However, gtkprinter.c has set accepts_pdf to TRUE by default, Hence, it generates pdf data. Ideally, there should be a API to change this value but there isn't. The only function gtk_printer_set_property() is static. cannot be used in the backend. Steps to reproduce: 1. check out gtkprinter.c 2. 3. Actual results: Expected results: Does this happen every time? Other information: I suspect most printers are still not capable of handling pdf directly. It would be better to have the accepts_pdf default to FALSE. Also allow the backend capability to set this accordingly.
CUPS knows whether a printer is actually capable of accepting PDF and handles the conversion on its own. Sending PDF by default should be fine. Current evince actually seems to always send postscript to CUPS. There are efforts to move to PDF by default, see for instance http://bugzilla.gnome.org/show_bug.cgi?id=560177
I removed CUPS from the complication. Here's the test I just performed: 1) Pop ordinary postscript (+PCL) printer on the network 2) Check that lpr random_postscript_file.ps prints correctly 3) Open an image in Eye of GNOME 2.28.1 4) Print to LPR (Generic printer) 5) Run to the printer to stop reams of pdf code from being generated Workaround: Print to FILE, which then gives you the option of selecting pdf, ps, svg. Print ps to file. lpr file to printer. Computer has gtk 2.18.5 I think that the default output for printing to lpr should be postscript. The problem may be masked for you if your application generates pdf, then cups reconverts the pdf to ps, and then sends the ps to the printer. There is no cups in the above setup.
(In reply to comment #2) > 5) Run to the printer to stop reams of pdf code from being generated Did the printout start with %PDF-1.4 or similar? > I think that the default output for printing to lpr should be postscript. The default for lpr is PostScript. There are two ways gtk+ applications can print. One is using the high level GtkPrintOperation API. In this case the gtk+ print backend will create the cairo surface (see gtk+/modules/printbackends). Currently all print backends create a cairo PostScript surface. The other way is using GtkPrintUnixDialog and creating a GtkPrintJob. GtkPrintJob provides the option of either using gtk_print_job_get_surface() to get the print backend to create the cairo surface. This will always create a PostScript surface. Or using gtk_print_job_set_source_file() to provide a PostScript or PDF file to send directly to the print backend. If using gtk_print_job_set_source_file() the application needs to know if the printer supports PostScript or PDF. gtk_printer_accepts_ps() and gtk_printer_accepts_pdf() should provide this information. However at present both these functions always returns true. eog 2.28.1 is using GtkPrintOperation and should not be affected by the gtk_printer_accepts_pdf() bug. Current version of evince are also using GtkPrintOperation.
Bad timing on my part: I only was near that computer with its setup during the London Gnome hackfest - I thought I would have time to rig up something similar in the meantime, but I think I'll wait until I'm near it at Easter - then it should be easy to answer your "PDF-1.4" question. (It was definitely PDF, but I can't remember the version. (I happily write postscript, so would recognise the difference...)) Sorry for the delay...
What needs to be done to keep compatibility to non-CUPS spoolers is only to emit PDF when the print job gets sent 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 177140 [details] [review] check if backend can handle pdf when setting "accept-pdf" The attached patch fixes this bug by setting "accept-pdf" to true only if supported by the print backend. gtkprintbackendfile.c could be made smarter by setting the "accept-pdf" and "accept-ps" properties based on the selected format.
Created attachment 177174 [details] [review] set file printer accepts-pdf/ps based on selected format The attached patch extends sets the accepts-pdf and accepts-ps properties of the gtkprintbackendfile GtkPrinter based on the selected print format. Also, is gtk_printer_new() supposed to be part of the public API? According to gtkprintbackend.h it is a backend only function.