Bug#847462: the problem is with CUPS
On Sat 04 Mar 2017 at 21:06:56 +0200, Martin-Éric Racine wrote:
> 2017-03-04 20:43 GMT+02:00 Brian Potkin <claremont102@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.
Reply to: