Bug#928738: closed by Brian Potkin (Re: Bug#928738: printer-driver-cups-pdf Still Produces PDF Files that Lack Searchable Text and are Unusable with pdftotext)
Just want to point out that the solution on removing and reinstalling printer-driver-cups-pdf didnt worked for me on my buster system which i upgraded from stretch. i have this issue since then and was happy to find this solution which unluckily didnt work for me. i managed to find a very old print job in the pdf qeue which maybe the cause for this failure in the update process. "cancel" this old job and repeting the solution didnt work either. so i followed the advice in the debian wiki https://wiki.debian.org/CUPSDebugging and issued "lpadmin -p -o pdftops-renderer-default=pdftocairo" to the (in my case named) queue "PDF" that solves the problem. lpoptions -d PDF shows the correct output and the printing is as expected. thanks to neil and brian who directed me in the right direction :-) kind regards steve
Bug#928738: closed by Brian Potkin (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-deb1...@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
Bug#928738: closed by Brian Potkin (Re: Bug#928738: printer-driver-cups-pdf Still Produces PDF Files that Lack Searchable Text and are Unusable with pdftotext)
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
Bug#928738: closed by Brian Potkin (Re: Bug#928738: printer-driver-cups-pdf Still Produces PDF Files that Lack Searchable Text and are Unusable with pdftotext)
reopen 928738 retitle 928738 Upgrading from stretch to buster leaves stretch print queue in place thanks On Fri 10 May 2019 at 16:27:14 -0500, Neil Ormos wrote: > Debian Bug Tracking System wrote: > > > This is an automatic notification regarding your Bug report > > which was filed against the printer-driver-cups-pdf package: > > > #928738: printer-driver-cups-pdf Still Produces PDF Files that Lack > > Searchable Text and are Unusable with pdftotext > > > It has been closed by Brian Potkin . [...] > > > [...] Sorry, Neil, but you are not using a > > 3.0.1-5 version of cups-pdf. I have no option > > but to close this report. > > Hi Brian: The feedback and level of detail is appreciated. > 1. Thanks for the hint. I removed and reinstalled the package. Lo and > behold, > > pdftops-renderer=pdftocairo > > now appears in the report from lpoptions, "cairo" appears in the creator > field reported by pdfinfo, and the PDF file contains searchable text. Excellent. We have spent some time and effort in getting to this stage. Let us hope it holds up for some time. > 2. BEFORE removing and reinstalling, I checked dpkg -l, which reported: > > ii printer-driver-cups-pdf 3.0.1-5 amd64 printer driver > for PDF writing via CUPS > > And I also checked /var/log/dpkg.log, which included this line from > yesterday: > > 2019-05-09 16:26:18 status installed printer-driver-cups-pdf:amd64 > 3.0.1-5 > > I saw nothing in the log that suggested that the original installation > failed. > > 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. Many thanks, Brian.
Bug#928738: closed by Brian Potkin (Re: Bug#928738: printer-driver-cups-pdf Still Produces PDF Files that Lack Searchable Text and are Unusable with pdftotext)
Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the printer-driver-cups-pdf package: > #928738: printer-driver-cups-pdf Still Produces PDF Files that Lack > Searchable Text and are Unusable with pdftotext > It has been closed by Brian Potkin . [...] > [...] Sorry, Neil, but you are not using a > 3.0.1-5 version of cups-pdf. I have no option > but to close this report. Hi Brian: 1. Thanks for the hint. I removed and reinstalled the package. Lo and behold, pdftops-renderer=pdftocairo now appears in the report from lpoptions, "cairo" appears in the creator field reported by pdfinfo, and the PDF file contains searchable text. 2. BEFORE removing and reinstalling, I checked dpkg -l, which reported: ii printer-driver-cups-pdf 3.0.1-5 amd64 printer driver for PDF writing via CUPS And I also checked /var/log/dpkg.log, which included this line from yesterday: 2019-05-09 16:26:18 status installed printer-driver-cups-pdf:amd64 3.0.1-5 I saw nothing in the log that suggested that the original installation failed. 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. Anyhow, thanks for the help. Best regards, --Neil Ormos
