cups-pdf should support the PDF printing workflow

Bug #385709 reported by Till Kamppeter
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
cups-pdf (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Binary package hint: cups-pdf

cups-pdf consists of a PPD file and a CUPS backend. The backend assumes all input data being PostScript and converts the data to PDF. The resulting file is dropped in the ~/PDF subdirectory of the home directory of the sender of the job. The PPD file does not contain any cupsFilter line which makes CUPS assuming that PostScript with embedded printer-specific option settings is expected to be sent to the backend.

All this works fine with the virgin upstream CUPS which performs a PostScript-based printing workflow. All input files are converted to PostScript, then passed through the pstops filter to do page management (N-up, reverse order, selected pages, ...) and embed the PostScript commands for the option settings, and after that the output goes to the backend (in case of PostScript printers or cups-pdf) or to a printer driver filter.

In Ubuntu and Debian CUPS has extra filters and changed filter rules so that a PDF-based printing workflow is implemented. See

http://www.linuxfoundation.org/en/OpenPrinting/PDF_as_Standard_Print_Job_Format

Here all incoming files are converted to PDF and the the pdftopdf filter does the page management. If the PPD accepts PDF by an appropriate cupsFilter line the output gets passed through to the printer driver or to the backend. In case of a PPD without cupsFilter line (like the one of cups-pdf) or only with cupsFilter lines taking PostScript as input format, CUPS calls the cpdftocps filter (the "PostScript printer driver") after pdftopdf filter, so that there is PostScript in the end. This means that in the worst case the following happens for cups-pdf:

Application --PostScript--> pstopdf --PDF--> pdftopdf --PDF-->
  cpdftocps --PostScript--> cups-pdf --PDF--> ~/PDF

So we go forth and back between PDF and PostScript several times.

Now I suggest to add support for the PDF printing workflow to cups-pdf. This can be implemented in a very simple way:

1. Let the cups-pdf backend accept both PostScript and PDF as input. Let it check whether the incoming data starts with the PDF magic string ("%PDF"). If so, do not any conversion, simply drop the file in ~/PDF. If not, convert the file to PDF as before.

2. Let the PPD file tell CUPS that the backend accepts both PostScript and PDF. Add the lines

*cupsFilter: "application/vnd.cups-postscript 100 -"
*cupsFilter: "application/vnd.cups-pdf 0 -"

to the PPD file.

Now on Debian and Ubuntu the following will happen:

Application --PostScript--> pstopdf --PDF--> pdftopdf --PDF-->
  cups-pdf --PDF--> ~/PDF

The file is converted to a different format only once and not three times. With newer applications it gets even simpler:

Application --PDF--> pdftopdf --PDF--> cups-pdf --PDF--> ~/PDF

On all other distros which did not accept the PDF printing workflow yet, nothing gets more complicated, all works as before.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package cups-pdf - 2.5.0-2ubuntu2

---------------
cups-pdf (2.5.0-2ubuntu2) karmic; urgency=low

  * debian/patches/65_cups-pdf-support-pdf-workflow.patch: Added support
    for the PDF printing workflow. PPD changed to let the backend accept
    PDF input. Backend simply drops input data in the destination file
    if it is already PDF (LP: #385709)
  * debian/postinst: Added automatic update of the PPD files of already
    existing print queues.
  * debian/postinst: Removed code for directly editing CUPS config files if
    CUPS is not running. CUPS is running anyway when debian/postinst is
    executed, as the package depends on the cups package.
  * debian/local/apport-hook.py, debian/rules: Added apport hook (LP: #338442).

 -- Till Kamppeter <email address hidden> Tue, 16 Jun 2008 11:32:30 +0200

Changed in cups-pdf (Ubuntu):
status: New → Fix Released
Revision history for this message
Martin-Éric Racine (q-funk) wrote : Re: [Bug 385709] Re: cups-pdf should support the PDF printing workflow

Could this be upgraded against Debian's 2.5.0-3 instead?

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

The changes are already uploaded into the archives, but it should be no problem to apply the changes for 2.5.0-3 (https://merges.ubuntu.com/c/cups-pdf/cups-pdf_2.5.0-3.patch). Only non-comment/whitespace changes are the dependencies in debian/control and the new prerm script.

Why do you introduce the prerm script with the CUPS restart? You are already restarting CUPS directly before actually removing the queue in postrm. This is already enough to achieve the goal. In addition, for removal of a queue you only need a running CUPS daemon. No CUPS restart is required. In general, CUPS also does not need to be restarted for adding or removing a backend, at least from version 1.2.x on.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Now I see that in the Ubuntu package queue removal is in prerm and it seems that the Debian package has it in postrm. It really does not matter when it takes place, as for CUPS' queue removal it does not matter whether the backend is still there or not.

So on the merge with 2.5.0-3 the removal of the CUPS queue should be in the same ...rm script for both Ubuntu and Debian and the other ...rm script does not need anything special for the queue removal.

Revision history for this message
NoOp (glgxg) wrote :
Download full text (3.5 KiB)

Till, I added the new proposed cups from 382379, purged cups-pdf and install the karmic version & now I am getting access errors & pdf's were going into the ether:

$ apt-cache policy cups-pdf
cups-pdf:
  Installed: 2.5.0-2ubuntu2
  Candidate: 2.5.0-2ubuntu2
  Version table:
 *** 2.5.0-2ubuntu2 0
        100 /var/lib/dpkg/status
     2.5.0-1ubuntu1 0
        500 http://archive.ubuntu.com jaunty/universe Packages
gg2xp@gg2xp:~$ apt-cache policy cups
cups:
  Installed: 1.3.9-17ubuntu3.2
  Candidate: 1.3.9-17ubuntu3.2
  Version table:
 *** 1.3.9-17ubuntu3.2 0
        500 http://archive.ubuntu.com jaunty-proposed/main Packages
        100 /var/lib/dpkg/status
     1.3.9-17ubuntu3.1 0
        500 http://archive.ubuntu.com jaunty-updates/main Packages
        500 http://archive.ubuntu.com jaunty-security/main Packages
     1.3.9-17ubuntu1 0
        500 http://archive.ubuntu.com jaunty/main Packages
gg2xp@gg2xp:~$ apt-cache policy poppler-utils
poppler-utils:
  Installed: 0.10.5-1ubuntu2.1
  Candidate: 0.10.5-1ubuntu2.1
  Version table:
 *** 0.10.5-1ubuntu2.1 0
        500 http://archive.ubuntu.com jaunty-proposed/main Packages
        100 /var/lib/dpkg/status
     0.10.5-1ubuntu2 0
        500 http://archive.ubuntu.com jaunty/main Packages
gg2xp@gg2xp:~$ cd /usr/lib/cups
gg2xp@gg2xp:/usr/lib/cups$ ls -l
total 32
drwxr-xr-x 2 root root 4096 2009-06-18 10:19 backend
drwxr-xr-x 2 root root 4096 2009-06-18 07:28 backend-available
drwxr-xr-x 2 root root 4096 2009-06-18 07:28 cgi-bin
drwxr-xr-x 2 root root 4096 2009-06-18 07:28 daemon
drwxr-xr-x 2 root root 4096 2009-05-29 14:04 driver
drwxr-xr-x 3 root root 4096 2009-06-18 09:23 filter
drwxr-xr-x 2 root root 4096 2009-06-18 07:28 monitor
drwxr-xr-x 2 root root 4096 2009-06-18 07:28 notifier

From /var/log/cups/error_log:

D [18/Jun/2009:10:23:39 -0700] cupsdNetIFUpdate: "lo" = localhost:631
D [18/Jun/2009:10:23:39 -0700] cupsdNetIFUpdate: "eth0" = 192.168.4.100:631
D [18/Jun/2009:10:23:39 -0700] cupsdNetIFUpdate: "lo" = localhost:631
D [18/Jun/2009:10:23:39 -0700] cupsdNetIFUpdate: "eth0" = fe80::20c:f1ff:feba:291f%eth0:631
D [18/Jun/2009:10:23:39 -0700] Report: clients=0
D [18/Jun/2009:10:23:39 -0700] Report: jobs=12
D [18/Jun/2009:10:23:39 -0700] Report: jobs-active=0
D [18/Jun/2009:10:23:39 -0700] Report: printers=5
D [18/Jun/2009:10:23:39 -0700] Report: printers-implicit=0
D [18/Jun/2009:10:23:39 -0700] Report: stringpool-string-count=3251
D [18/Jun/2009:10:23:39 -0700] Report: stringpool-alloc-bytes=12888
D [18/Jun/2009:10:23:39 -0700] Report: stringpool-total-bytes=64816
D [18/Jun/2009:10:23:39 -0700] update_cups_browse: Refused 130 bytes from 192.168.4.100
D [18/Jun/2009:10:23:40 -0700] update_cups_browse: Refused 140 bytes from 192.168.4.100
D [18/Jun/2009:10:23:41 -0700] update_cups_browse: Refused 177 bytes from 192.168.4.100
D [18/Jun/2009:10:23:42 -0700] update_cups_browse: Refused 142 bytes from 192.168.4.100
D [18/Jun/2009:10:24:10 -0700] update_cups_browse: Refused 130 bytes from 192.168.4.100
D [18/Jun/2009:10:24:11 -0700] update_cups_browse: Refused 140 bytes from 192.168.4.100
D [18/Jun/2009:10:24:12 -0700] update_cups_browse: Refused 177 bytes from 192.168.4.100
D [18/Jun/2009:10:24:1...

Read more...

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Note that the CUPS package of Karmic has also a fix in the AppArmor configuration of cups-pdf. The line

  capability dac_override,

was added to /etc/apparmor.d/usr.sbin.cupsd. Please restart AppArmor after editing this file.

Revision history for this message
NoOp (glgxg) wrote :

Shall I comment it out?

Revision history for this message
NoOp (glgxg) wrote :

Never mind. Figured out what you were referring to. Sorry.

Restarted apparmor & defaults to complain:

$ cat /sys/kernel/security/apparmor/profiles
/usr/sbin/tcpdump (enforce)
/usr/sbin/cupsd (complain)
/usr/lib/cups/backend/cups-pdf (complain)

PDF's printing fine (including the svg. However still getting "update_cups_browse: Refused" msg in the error_log.

Revision history for this message
NoOp (glgxg) wrote :

I think that the "update_cups_browse: Refused" is a configuration issue... this machine has been updated from gutsy through jaunty, and I do not get the same errors on another jaunty machine with the proposed jaunty cups w/karmic cups-pdf. That machine also prints the svg test to cups-pdf with no issues now. So, please disregard previous comments regarding "update_cups_browse: Refused"... I'll sort that out on my own. Again, thanks for the changes & excellent support!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.