GNOME Bugzilla – Bug 636128
Printing: If input file is PS, file gets directly passed to CUPS, if it is PDF an ugly rerendering happens
Last modified: 2018-05-22 14:05:55 UTC
There are many complaints at Ubuntu about printing PDF files from evince not working or being much too slow, especially if the PDF files have embedded images (JPEG worst here). Sending the PDF files directly to CUPS (like with "lpr file.pdf") usually prints these PDF files quickly. The problem is that if one opens a PDF file with evince and sends it to the printer via "File" -> "Print", evince regenerates the PDF file with the help of libcairo and libcairo generates PDFs in a very ugly, unefficient way. If one opens a PostScript file though, the file is simply passed through. The file sent to CUPS is nearly the same as the original file (only few lines different, and they are even all comments). So what I like to have is that PDF files also get passed through when printing them (the original PDF sent to CUPS). This way one works around the problems of libcairo and more important even, evince works much more efficiently with big and complex files. Example bug reports in Ubuntu: https://bugs.launchpad.net/bugs/680628 https://bugs.launchpad.net/ubuntu/+source/cups/+bug/419143 https://bugs.launchpad.net/ubuntu/+source/ghostscript/+bug/668800 (comment #21) https://bugs.launchpad.net/bugs/373796 https://bugs.launchpad.net/bugs/394266
How would that work for any print that transforms the file, e.g. n-up, or duplex, or printing only a range of pages instead of the whole document? If cairo generates bad pdf, it's cairo that should be fixed, not evince that should work around it. Also, have you checked if this happens with pristine upstream of gtk+, evince, poppler, cairo, and cups, or only when using the ubuntu versions? (I'm thinking esp. of ubuntu's gtk+ patch 061_use_pdf_as_default_printing_standard.patch.)
Christian, the applications (like evince) do not need to do n-up, duplex, page selection, ... This is all done by the CUPS filters (pstops or pdftopdf). So one only needs to send the original file to CUPS with appropriate options, like number-up=2, duplex=DuplexNoTumble, page-ranges=1,2,4,7-56, ... I checked only with the Ubuntu version, so the mentioned patch is probably applied. I know that Cairo must be fixed in the first place, especially as it generates the bad PDF also when printing from applications where the input data is not PDF (for example photo managers), but if one has the opportunity to pass an input file directly through to CUPS, one can remove a filter step and so the losses caused by it (in our case not image quality but efficiency of the data organization in the file).
I agree that now that CUPS is converting anything non PDF to PDF and processing it internally as PDF if makes sense for evince to pass the PDF directly to CUPS if for no other reason than it avoids an unnecessary PDF to PDF conversion. However as pointed out in comment 1, CUPS would need to support all options available in the evince print dialog. Have you checked that all printing options in evince (including the new page scaling options in the Page Handling tab) are available in CUPS? One of the biggest problems with the poppler/cairo PDF to PDF conversion is the cairo PDF output is limited by the capabilities of the cairo API. I've been looking into ways of extending the PDF capabilities of cairo using an external library but at the current rate of progress it will be years before this will be ready. As for the bugs you refer to, I can't fix bugs that I don't know about. If you find PDFs where the poppler/cairo output produces crappy or unprintable output, please file a poppler or cairo bug. These are the only two products that I subscribe to all bug reports. I don't see the Ubuntu bug reports unless it is linked from a poppler or cairo bug report.. Which photo manager product is producing bad cairo output?
-- 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/191.