Session printing

There has been a discussion on the Fedora devel mailing list recently about user session printing: why that might be useful, and in what circumstances it makes sense.

Where I can see it can make some sense to have printing entirely in the user session is for PDF printing to smart services hosted elsewhere: e.g. the office CUPS server, or Google Cloud Print.  Applications produce PDF, so for printing to these types of service there is nothing to do but send the PDF (along with any print options).

A little about Google Cloud Print: this is a service that allows you to register your local printers with their service, and share those printers with other people.  It currently works as part of Chrome: it maintains an XMPP connection to Google so that incoming jobs can be received and passed on to the local CUPS queue.  For printing jobs to it, it is simply an authenticated web service.

The GTK print dialog supports multiple print backends, and currently ‘cups’ is the one we use for printing.  This communicates with the locally-running cupsd.

Printing is more than simply getting capabilities and submitting jobs though: we also need to monitor the status of submitted jobs, and perform actions on those jobs such as pause, resume, and cancel.

Currently job status monitoring is performed in gsd-printer, which displays notifications when a job has completed etc, and job management actions are implemented in the “Printers” panel of the Systems Settings
application.

Adding support for printing to PDF-capable print services directly from the session could be implemented as follows.

A new session service for printing could be created, providing methods for obtaining a list of printers, explicitly adding/removing printers, and with properties for finding out the current state of each printer and whether it is reporting problems.  It could also provide methods for retrieving the list of jobs for each printer, performing actions on those jobs, and have properties for the state of each job.

This service could have plug-ins for dealing with the locally-running cupsd; with CUPS/IPP servers on the network; and with Google Cloud Print.

For the “network IPP” plug-in, it could discover available CUPS (and IPP Everywhere) queues using Avahi, and show in the list of printers only those queues that handle PDF.  Additionally, the print dialog could
allow IPP print servers to be added by hostname (for CUPS) or URI (for network printers which speak IPP and handle PDF).

For the “cloudprint” plug-in, it could interrogate the Google Cloud Print server to determine the list of available queues. (The “Online Accounts/Google” part of System Settings knows how to log in.)

For job status feedback, gsd-printer could instead query the new service. (Or perhaps the service would be implemented in gsd-printer?)

For job management, the printer panel in System Settings could perform actions through the new service.


Posted

in

by

Comments

7 responses to “Session printing”

  1. mx avatar
    mx

    > The “Online Accounts/Google” part of System Settings knows how to log in.)

    No work in Fedora 16 !
    https://bugzilla.redhat.com/show_bug.cgi?id=800206
    https://bugzilla.redhat.com/show_bug.cgi?id=758632
    etc

    its BAD !

  2. tim avatar

    mx: it works fine for me, and that report is just a bug to be fixed.

    If anyone has any comments about the *design* I’d like to hear those.

  3. Rick Richardson avatar
    Rick Richardson

    Fedora 14…

    FYI, Cloud Print service:

    $ git clone https://github.com/armooo/cloudprint.git
    Cloning into cloudprint…
    remote: Counting objects: 109, done.
    remote: Compressing objects: 100% (107/107), done.
    remote: Total 109 (delta 47), reused 0 (delta 0)
    Receiving objects: 100% (109/109), 31.77 KiB, done.
    Resolving deltas: 100% (47/47), done.

    $ cd cloudprint
    $ root python setup.py install
    [snip]

    $ root pip-python install daemon
    Downloading/unpacking daemon
    Running setup.py egg_info for package daemon

    Installing collected packages: daemon
    Running setup.py install for daemon

    Successfully installed daemon

    $ cloudprint -d
    Skipping test-raw
    Updated Printer test-1020
    Updated Printer test-c310dn
    Updated Printer mc2530
    Updated Printer mc1600Wc
    Updated Printer aaaa
    Updated Printer mc2300c
    Updated Printer test-1500
    Updated Printer test-okiC110
    Updated Printer test-clp315
    Updated Printer cp1025nw
    Updated Printer test-p1505
    Updated Printer xrx6110
    Updated Printer test
    Updated Printer test-Oki-C3100
    Updated Printer p1505n
    Updated Printer test-p1102
    Updated Printer test-cp1025
    Updated Printer test-C3300
    Updated Printer test-1680MF
    Updated Printer clp315
    Updated Printer test-hp2600
    Updated Printer hp1020
    Updated Printer p1102w
    Updated Printer HP-LaserJet-Professional-P1102w
    Updated Printer hp2600
    Updated Printer cp1215
    Updated Printer p1102-hpcups
    Updated Printer Cups-PDF
    Updated Printer test-clp300
    Updated Printer GnomeManualDuplex
    Updated Printer p1005
    Updated Printer test-m1319
    Updated Printer HP-LaserJet-1000
    Updated Printer test-p2035
    Updated Printer mc2530c
    Updated Printer xrx6110c
    Updated Printer test-CLP-610
    Updated Printer test-KM-1635
    $

    Then:
    $ firefox http://www.google.com/cloudprint/manage.html

    And on your Android tablet:
    https://market.android.com/details?id=com.pauloslf.cloudprint

  4. tim avatar

    Rick: right, that’s for sharing your existing printers with other people using Google Cloud Print.

    This design is for the other side of it; being able to print *to* a Google Cloud Print shared printer, or to an arbitrary IPP printer (or CUPS machine).

  5. John avatar
    John

    Interesting. My big question is why we would need YAD (Yet Another Daemon) when we already have CUPS? Why not add a Google Cloud Print backend to CUPS? Doesn’t CUPS already handle IPP? This almost seems like a replacement to CUPS?

    Another question is how this could relate to the ever-promised never-delivered Common Print Dialog which I believe also uses a DBus daemon?

    Cheers!

  6. John avatar
    John

    Actually, looks like someone already has written a backend:

    http://www.niftiestsoftware.com/cups-cloud-print/

  7. tim avatar

    This (the in-session printing service) isn’t a daemon in the sense of a long-running program. It’s a service that is activated on demand, and which would terminate when no longer used.

    It isn’t really replacing CUPS but is instead an alternative path for printing jobs. If you already have smart network print services available to you, there is no need to have local spooling or local job format transformation.

    Thinking about Google Cloud Print specifically, this is a service which requires authentication and which comes in two parts: the print client part for submitting jobs to the service, and the registration part for allowing the service to print to your local printer.

    Given that Google Cloud Print is a smart service which does not require most of what CUPS is able to do, and given that the desktop would need to know the authentication details in order to provide the registration part, it seems natural to use those authentication details directly with Google Cloud Print when submitting jobs rather than passing them to a local spooler to do it.

    It has no relationship with the Common Print Dialog. D-Bus is simply the mechanism for communicating between the components.