Your message dated Fri, 10 May 2019 20:35:46 +0100
with message-id <[email protected]>
and subject line Re: Bug#928738: printer-driver-cups-pdf Still Produces PDF
Files that Lack Searchable Text and are Unusable with pdftotext
has caused the Debian Bug report #928738,
regarding printer-driver-cups-pdf Still Produces PDF Files that Lack Searchable
Text and are Unusable with pdftotext
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
928738: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928738
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: printer-driver-cups-pdf
Version: 3.0.1-5
Severity: important
Dear Maintainer,
In prior bug reports, users complained that CUPS-PDF or printer-driver-cups-pdf
produced PDF files in which text was represented in image format, or was not
searchable.
In a message posted
"Thu, 09 Mar 2017 13:40:21 +0000",
closing bugs 658004, 813618, 847462, and 857165, there was a reference to
printer-driver-cups-pdf_3.0.1-3, and in another message there was a suggestion
that the problem is fixed in that version.
I have installed printer-driver-cups-pdf_3.0.1-5 (the current version
distributed in Buster), and it appears that *whatever* is stored in the PDF
files produced by printer-driver-cups-pdf, it's not searchable text. Also,
when these files are processed by pdftotext, the results do not contain
recognizable text.
This was not a problem with the cups-pdf version 2.5.0-16 in Squeeze.
I tested using Firefox 44.0b3 to print an extremely simple HTML page to the
CUPS PDF "driver". (That particular ancient version of Firefox runs in both
Squeeze and Stretch.)
Can this be fixed, short of installing a non-Debian version of CUPS-PDF-to-PDF
or the like, such as that advertised at
https://github.com/alexivkin/CUPS-PDF-to-PDF
?
Thank you.
-- System Information:
Debian Release: 9.7
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968)
(ignored: LC_ALL set to C), LANGUAGE=en_US.UTF-8 (charmap=ANSI_X3.4-1968)
(ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages printer-driver-cups-pdf depends on:
ii cups 2.2.1-8+deb9u2
ii cups-client 2.2.1-8+deb9u2
ii ghostscript 9.26a~dfsg-0+deb9u1
ii libc6 2.24-11+deb9u3
ii libcups2 2.2.1-8+deb9u2
ii libpaper-utils 1.1.24+nmu5
printer-driver-cups-pdf recommends no packages.
Versions of packages printer-driver-cups-pdf suggests:
ii system-config-printer 1.5.7-3
-- no debconf information
--- End Message ---
--- Begin Message ---
On Fri 10 May 2019 at 13:05:51 -0500, Neil R. Ormos wrote:
> Brian Potkin wrote:
>
> > Please post the output of 'lpoptions -p PDF'
>
> ############################################################
> copies=1 device-uri=cups-pdf:/ finishings=3 job-cancel-after=10800
> job-hold-until=no-hold job-priority=50 job-sheets=none,none
> marker-change-time=0 number-up=1
> printer-commands=AutoConfigure,Clean,PrintSelfTestPage printer-info=PDF
> printer-is-accepting-jobs=true printer-is-shared=false printer-location
> printer-make-and-model='Generic CUPS-PDF Printer' printer-state=3
> printer-state-change-time=1557509283 printer-state-reasons=none
> printer-type=10678348 printer-uri-supported=ipp://localhost/printers/PDF
> ############################################################
Here is the output on my (cups-pdf working) machine:
copies=1 device-uri=cups-pdf:/ finishings=3 job-cancel-after=10800
job-hold-until=no-hold job-priority=50 job-sheets=none,none
marker-change-time=0 number-up=1 pdftops-renderer=pdftocairo
printer-commands=AutoConfigure,Clean,PrintSelfTestPage printer-info=PDF
printer-is-accepting-jobs=true printer-is-shared=false printer-location
printer-make-and-model='Generic CUPS-PDF Printer (w/ options)' printer-state=3
printer-state-change-time=1557509001 printer-state-reasons=none
printer-type=10547276 printer-uri-supported=ipp://localhost/printers/PDF
The difference is that I have "pdftops-renderer=pdftocairo". This comes
about because in
/var/lib/dpkg/info/printer-driver-cups-pdf.postinst
my installation set up a print queue with
lpadmin -h localhost -p $queue /
-v cups-pdf:/ -m lsb/usr/cups-pdf/CUPS-PDF_opt.ppd /
-o pdftops-renderer-default=pdftocairo /
-o printer-is-shared=n /
-o PageSize=$size 2>/dev/null
Note "-o pdftops-renderer-default=pdftocairo". That is why my lpoptions
output shows it.
> > and, for a printed HTML
> > page, what 'pdfinfo <PDF_file> gives.
>
> Results of pdfinfo on the file produced on a system running Stretch:
> ############################################################
> Title: (file:///home/uuu/zzz-scratch-0510-2/foo1.html)
> Author: (uuu)
> Creator: GPL Ghostscript 926 (ps2write)
> Producer: GPL Ghostscript 9.26
This confirms that the processing does not involve cairo.
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.
Regards,
Brian.
--- End Message ---
