GNOME Bugzilla – Bug 711761
Use poppler to write PDF with print settings
Last modified: 2018-05-22 15:24:11 UTC
https://bugs.freedesktop.org/show_bug.cgi?id=71213 contains some patches for adding new poppler glib api to write the pdf file with various printing options applied eg number up, fit to page, shrink to page etc. This bugs contains the evince patches required to use this poppler api. The aim is to pass the PDF directly to CUPS with minimal processing. ie avoid using cairo to regenerate the PDF. This allows printing with color management and avoids bugs and limitations of the cairo PDF output that in some cases result in rasterization of the PDF when it is converted to PostScript.
Created attachment 259401 [details] [review] Use poppler PDF Writer api The first patch switches to the gtkunixprintdialog for poppler printing and replaces the cairo printing code in the poppler backend with new poppler glib api. Currently only print settings already available to the backends are supported.
Created attachment 259402 [details] [review] Add page handling tab to print dialog This patch makes the page handling tab currently used by print operation also work on the print export dialog.
Created attachment 259404 [details] [review] Pass additional print settings to poppler backend This patch passes additional print settings through to the poppler backend. I avoided passing through the page selection print settings that are handled by ev-print-operation.c eg copies,collate,reverse,page set. I'm not sure how easily this can be changed to pass through all the print settings to the poppler backend without breaking any other backends. Ideally the number of copies and collate options should be passed to the CUPS when supported as some printers can probably handle multiple copies more efficiently. A couple of issues I found: ev-print-operation.c appears to have bug when printing multiple copies and number up. The multiple copies are layed out out on each sheet instead of printing multiple copies of each sheet. ev-print-operations changes the page size when the scale is not 100%. This will need to be worked around to provide the original page size to the poppler backend and the poppler PDF writer can handle both the scale and page handling options (fixes bug 646758). Other ideas: The poppler PS exporter could be changed to use the PDF writer first to apply all printing settings then run it through poppler again to get PS output. This would produce PS output that supports all the print options. The PDF writer runs much faster than the PS writer so the additional overhead would not be noticed. The same could also be done to get SVG output. An extra option could be added to the print dialog to allow selecting between direct PDF output and cairo PDF output. May be useful in case of and PDF files that print correctly using one method but not the other.
Review of attachment 259401 [details] [review]: Will this still work on non-unixprint (ie some evince developers want to keep evince working on windows) ? ::: backend/pdf/ev-poppler.cc @@ +152,3 @@ EV_BACKEND_IMPLEMENT_INTERFACE (EV_TYPE_DOCUMENT_LAYERS, pdf_document_document_layers_iface_init); +#ifndef GTKUNIXPRINT_ENABLED EV_BACKEND_REGISTER_WITH_CODE is a macro, and some compilers don't like to have #ifdef within macro expansion. You could do #ifdef GTKUNIXPRINT_ENABLED #define GTKUNIXPRINT_INTERFACE EV_BACKEND_IMPLEMENT_INTERFACE... #else #define GTKUNIXPRINT_INTERFACE #endif and then use GTKUNIXPRINT_INTERFACE here, to avoid duplicating the whole EV_BACKEND_REGISTER_WITH_CODE in the ifdef. ::: libview/ev-print-operation.c @@ +1277,3 @@ + else + export->fc.format = EV_FILE_FORMAT_PS; + The old code made sure that when you name a file ".ps" / ".pdf", then the output format really is PS / PDF. It looks like this change will break that.
Created attachment 259545 [details] [review] Use poppler PDF Writer api > Will this still work on non-unixprint (ie some evince developers want to keep > evince working on windows) ? Yes. Non unix platforms will still print using GtkPrintOperation and cairo. > EV_BACKEND_REGISTER_WITH_CODE is a macro, and some compilers don't like to have > #ifdef within macro expansion. The attached patch fixes the macro problem. > The old code made sure that when you name a file ".ps" / ".pdf", then the > output format really is PS / PDF. It looks like this change will break that. I tested with the old code and it doesn't matter what the filename is. The format is determined by the output format radio buttons.
-- 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/408.