[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#928738: marked as done (printer-driver-cups-pdf Still Produces PDF Files that Lack Searchable Text and are Unusable with pdftotext)



Your message dated Fri, 10 May 2019 20:35:46 +0100
with message-id <10052019200810.63b24537059a@desktop.copernicus.org.uk>
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 owner@bugs.debian.org
immediately.)


-- 
928738: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928738
Debian Bug Tracking System
Contact owner@bugs.debian.org 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 ---

Reply to: