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.
Brian:
Thanks very much for your help and for reopening and retitling this bug report.
I offer the following summary for anyone who might experience this issue and
finds this report before the package is fixed:
Some versions of printer-driver-cups-pdf, including the 2.6.1-22 version now
distributed in Stretch, produce PDF files that do not contain searchable text
and cannot usefully be processed with pdftotext. That problem has been fixed
in a subsequent version. The 3.0.1-5 version now available in Buster includes
the fix. However, in some cases, an upgrade to 3.0.1-5 will leave the old
print queue in place, which effectively defeats the fix. This condition can be
detected by running
lpoptions -d PDF
and looking for the string "pdftops-renderer=pdftocairo". If that string is
absent, the old print queue remains. In that case, removing
printer-driver-cups-pdf 3.0.1-5 and reinstalling the same version should create
the correct PDF queue. This can be confirmed using lpoptions.
Best regards,
--Neil Ormos
