Bug#928738: closed by Brian Potkin <claremont102@gmail.com> (Re: Bug#928738: printer-driver-cups-pdf Still Produces PDF Files that Lack Searchable Text and are Unusable with pdftotext)
la 11. toukok. 2019 klo 22.00 Neil R. Ormos (ormos-deb1110@ormos.org) kirjoitti:
>
> Brian Potkin wrote:
> > Neil Ormos wrote:
>
> >> I have no idea why the new print queue including the
> >> pdftops-renderer=pdftocairo option was not established, as
> >> expected, during the original installation, by the
> >> printer-driver-cups-pdf.postinst script. I wonder if, somehow,
> >> the old PDF queue was not fully removed when I removed the old
> >> printer-driver-cups-pdf (2.6.1-22) package.
>
> > I can reproduce your experience on unstable. Purged
> > printer-driver-cups-pdf. Installed the stretch package and then
> > upgraded. The stretch print queue was left intact, so the renderer
> > option was not applied. "Skipped automatic creation of the PDF
> > queue" was displayed onscreen.
>
> > Any fix to the package is above my pay grade and is for a maintainer
> > to deal with. I hope it can make it into buster.
>
> However, in some cases, an upgrade to 3.0.1-5 will leave the old print queue in place, which effectively defeats the fix.
The key issue precisely is that no attempt whatsoever is made to
upgrade the PDF queue to use the pdftocairo backend. As Brian implied,
scripting this backend swap for upgrades is not easy.
Please note that manually configuring earlier CUPS-PDF versions to use
the pdftocairo backend is possible if desired. Here is a sample
command line stanza:
sudo lpadmin -h localhost -p CUPSPDF -v cups-pdf:/ -m
lsb/usr/cups-pdf/CUPS-PDF_opt.ppd -o
pdftops-renderer-default=pdftocairo -o printer-is-shared=no -o
PageSize=a4
Martin-Éric
Reply to: