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

Bug#793989: marked as done (cups: printing PDF file with Boomaga PPD not possible)

Your message dated Sun, 31 Dec 2017 15:44:34 +0000
with message-id <31122017151142.6e65fc6b20e8@desktop.copernicus.org.uk>
and subject line Re: Bug#793989: cups: printing PDF file with Boomaga PPD not possible
has caused the Debian Bug report #793989,
regarding cups: printing PDF file with Boomaga PPD not possible
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.)


-- 
793989: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793989
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: cups
Version: 2.0.3-10
Severity: normal

Dear Maintainer,

when printing a PDF file to a printer set up with the attached PPD file
"tofile-boomaga.ppd" and the CUPS "file" backend, no output file is actually
created.

Steps to reproduce:
* allow setting up file devices in CUPS by adding/modifying the
  following line in /etc/cups/cups-files.conf:
  FileDevice Yes
* restart CUPS to make that change active
* set up a printer with the attached PPD file and the CUPS file URI:
  $ sudo lpadmin -p tofile-boomaga -v file:${HOME}/tofile-boomaga -E -P tofile-boomaga.ppd  
* print any PDF file to the printer:
  $ lp -d tofile-boomaga test.pdf

Result:
nothing happens, no file "${HOME}/tofile-boomaga is created

Expected result:
The PDF file should be "printed to" (i.e. saved as) the file
"${HOME}/tofile-boomaga".


When I print a text file instead, the file "${HOME}/tofile-boomaga" is
created as expected and holds the content of the text file that was sent
to the printer by the command "lp -d tofile-boomaga test.txt". (The resulting
file is a PDF file.)

"Printing" a PDF file as described above still works on wheezy, but not
on jessie or sid.

This does not only affect printing PDF files directly but more use cases,
as many applications produce PDF output when printing a file.
Possibly, this might be a general problem when printing PDF files to
printers that receive PDF input if no additional CUPS filters are involved.

The problem might have to do with the fact that the printed file is already
in PDF format and the PPD file specifies that PDF is expected as input for the
printer and so no real CUPS filters are processed.


The Boomaga project can be found on GitHub here:
https://github.com/Boomaga/boomaga

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cups depends on:
ii  cups-client            2.0.3-10
ii  cups-common            2.0.3-10
ii  cups-core-drivers      2.0.3-10
ii  cups-daemon            2.0.3-10
ii  cups-filters           1.0.71-1
ii  cups-ppdc              2.0.3-10
ii  cups-server-common     2.0.3-10
ii  debconf [debconf-2.0]  1.5.57
ii  ghostscript            9.06~dfsg-2
ii  libavahi-client3       0.6.31-5
ii  libavahi-common3       0.6.31-5
ii  libc-bin               2.19-19
ii  libc6                  2.19-19
ii  libcups2               2.0.3-10
ii  libcupscgi1            2.0.3-10
ii  libcupsimage2          2.0.3-10
ii  libcupsmime1           2.0.3-10
ii  libcupsppdc1           2.0.3-10
ii  libgcc1                1:5.1.1-14
ii  libstdc++6             5.1.1-14
ii  libusb-1.0-0           2:1.0.19-1
ii  lsb-base               4.1+Debian13+nmu1
ii  poppler-utils          0.26.5-2
ii  procps                 2:3.3.10-2

Versions of packages cups recommends:
ii  avahi-daemon                     0.6.31-5
ii  colord                           1.2.1-1+b2
ii  cups-filters [ghostscript-cups]  1.0.71-1
ii  printer-driver-gutenprint        5.2.10-3

Versions of packages cups suggests:
ii  cups-bsd                                   2.0.3-10
pn  cups-pdf                                   <none>
ii  foomatic-db-compressed-ppds [foomatic-db]  20150411-1
ii  hplip                                      3.14.6-1+b2
ii  printer-driver-hpcups                      3.14.6-1+b2
pn  smbclient                                  <none>
ii  udev                                       222-2

-- debconf information:
  cupsys/backend: lpd, socket, usb, snmp, dnssd
  cupsys/raw-print: true

--- End Message ---
--- Begin Message --- 
On Thu 30 Jul 2015 at 17:50:18 +0200, Michael Weghorn wrote:

> Hello Brian,
> 
> thank you very much for your quick reply.
> 
> > Can we think in terms of bug #771259? I've tested with cups 1.7.0-2 and
> > ${HOME}/tofile-boomaga is produced. Not so with cups 1.7.1-1.
> 
> The cause indeed seems to be the same. I just rebuilt the CUPS packages
> currently in Jessie (version 1.7.5-11+deb8u1) with the patch attached to
> #771259 and the problem does not occur with this modified version.

I have closed #771259 because upstream clearly states that raw queues
with file: device URIs are not supported. The boomaga PPD contains the
line

 *cupsFilter: "application/pdf 0 -"

which will cause a PDF to be sent directly to the printer (a file device
in your case) without any filtering. I'd suggest this causes the daemon
to see the queue you set up as raw. (The error_logs for a boomaga queue
and a raw queue are much the same). In this event, this bug reduces to
#771259 and hence I am closing the report.

A test file *will* be filtered (texttopdf), so will be printed to file.

Cheers,

Brian.

--- End Message ---
Reply to: