On Sat 04 Mar 2017 at 21:06:56 +0200, Martin-Éric Racine wrote: > 2017-03-04 20:43 GMT+02:00 Brian Potkin <claremont...@gmail.com>: > > > > The fullest discussion of this I know of is at > > > > https://bugs.launchpad.net/ubuntu/+source/cups-pdf/+bug/820820 > > > > Users should take note of the comment: > > > > > The reasons for not skipping this step are known to you > > > (it will severly impede the functionality of CUPS-PDF). > > > Furthermore, once again, CUPS-PDF is not meant for > > > processing PDF-input (i.e., it is not meant to be a > > > PDF-manipulation tool). > > > > However, cups-pdf is still seen as a general "convert something to a > > PDF" utility. At one time it might have served that purpose, but not > > now. Both text and PDF input produce a below-standard, non-searchable > > output. There is a case for clarifying its purpose as a cups-filters > > plus backend method for getting a decent quality, searchable PDF from > > PostScript input only. (Okular produces PostScript; Evince doesn't). > > As far as I can tell, the reason why the quality of the output has > varied over time is because the quality of Ghostscript itself has > varied a lot.
There could be substance in that. My familiarity with the internals of Ghostscript is zero so I cannot comment. > There might be better filters than Ghostscript we could call to handle > the generic document conversion step. However, that's entirely > upstream's decision. Fair enough, but there might be something the maintainer of the package could do without infringing on upstream's domain. The issues with the visual impact of PDFs produced from a PDF submitted to cups-filters+the cups-pdf backend appear to arise sometimes when the input PDF comes from an application using the GTK printing subsystem; Firefox, for example. Another PDF is generated by Cairo and passes through the pdftops filter of cups-filters (which, by default, uses gs) and is then processed again with gs by the backend. pdftops has a selection of six renderers available. Testing was done with pdftocairo. Deleting the existing queue: lpadmin -x PDF Re-establishing the queue: lpadmin -p PDF -v cups-pdf:/ -E -o pdftops-renderer-default=pdftocairo -m lsb/usr/cups-pdf/CUPS-PDF_opt.ppd Printing to the PDF queue from Firefox produces good quality PDFs. The files were viewed with mupdf and gv and only the text was examined. A bonus is that the PDFs are searchable. More testing is desirable and welome. Printing PDF, PostScript and text files with lp also gave very decent PDFs which are searchable. I am beginning to revise my opinion on how generic cups-pdf is. This is a big step up on using the gs renderer with the queue. Would a change to cups-pdf's postinst be considered? Regards, -- Brian.
