A Simple Request To Print Feature

Support has been merged into the default branch for IPP [printing] operations. This functionality will be available in 0.1.49 provided the "pycups" modules is installed on the host(s).

The first part of IPP support is the addition of a workflow acction printToIPPAction. With the printToIPPAction a workflow message can be queued to a specified queue on an IPP server. An advantage of IPP over LPR [which OIE has supported for some time via the printToLPRAction] is that most IPP servers can deal intelligently with various content types. For exampe PDF, JPEG, and PNG content can usually be spooled as a print job without any client-side processing. The printToIPPAction supports setting the media size (default is "Letter") and specifying the fit-to-page feature supported by most IPP servers. In conjunction with capturing e-mail attachments or generating documents using RML the capability to spool messages to print queues allows the automation of processes which require hard-copy documents.

The second part of IPP support is the "/ippprint" HTTP protocol bundle. Using the "/ippprint" protocol HTTP clients can discover a list of available printers as well as request documents be queued to a specified print queue.

To retrieve a list of available printers a GET request for "/ippprint/.ls" is performed, this returns a JSON encoded dictionary of the print available print queues. Keys are queue names and the referenced dictionary is a standard IPP printer queue definition.

{ "dc": { "printer-is-shared": true,
          "printer-info": "dc",
          "printer-state-message": "Ready to print.",
          "printer-type": 8433756,
          "printer-make-and-model": "Brother MFC-9840CDW BR-Script3", 
          "printer-state-reasons": ["none"],
          "printer-uri-supported": "ipp://ipp.example.com:631/printers/dc",
          "printer-state": 3,
          "printer-location": "",
          "device-uri": "ipp://ip6B43FF.example.com"},
  "hp": { "printer-is-shared": true,
          "printer-info": "HP Laser Printer",
          ....

Text 1: Example JSON report of available printers.

Requesting a document id be printed to a specified queue is performed in a similar manner: "/ippprint/queue/objectid?mediasize=Letter&fittopage" where "queue" is the name of the print queue and "objectid" is the OpenGroupware object id of the document. Read access to a document is required in order for request the document be printed. Output size can be specified via the "mediasize" parameter and the "fitopage" option is also available. If a media size is not specified the default is "Letter" - note that, especially with PDFs, some documents may specify a media size internally which if not overridden can pause a printer if that media size is not physically available [this behavior is determined by the configuration of the IPP server and the printer itself - OpenGrouwpare Coils has no control over that aspect of printer operation].

The printer server used by OpenGroupware is set by the DefaultIPPServer server default; if not provided a value of "127.0.0.1" will be assumed - an IPP service on the same host.

coils-server-config --directive=DefaultIPPServer --value=ipp.example.com

Text 2: Change the server's configuration to use the IPP service provided by ipp.example.com. The specifed IPP server must be reachable by the OpenGrouwpare Coils node which is providing HTTP services; check your firewalls.

Unfortunately most IPP servers can only automatically process common [at least quasi-] Open file types such as PDF and PNG/JPEG images. For this reason the /ippprint protocol applies a filter, based on MIME type, for the types of documents it will allow to be queued. When a document is requested to be queued via /ippprint the type of that document will be compared to the list of MIME types found in the server's IPPPrintableMIMETypes default. If not configured the value of IPPPrintableMIMETypes is [ "application/pdf", "image/jpeg", "image/png" ]. This type list can be overwritten using coils-server-config to match the capabilities of your IPP service. Should an HTTP client request a document be queued whose MIME type is not specified in IPPPrintableMIMETypes a NotSupportedException will be raised (HTTP result code 501). A successful queue request will result in a text/plain HTTP 200 response containing the job name of the queued job [/ippprint will generate a job name and provide it to the IPP service].

With IPP queuing support simple HTTP clients are still oblivious to the document types that can be successfully queued for printing. Making a request and checking the result code is the only reliable way to 'discover' the print-ability of a document. In order to make this more intuitive for users, and easier for the generally very lazy web developer, a new "IPPPRINTABLE" flag is now included in the FLAGS attribute of the Omphalos representation of a document.

{'FLAGS': ['WRITE', 'OWNER', 'IPPPRINTABLE'],
 'creation': ,
 'creatorObjectId': 10000,
 'entityName': 'File',
 'fileSize': 90566,
 'fileType': 'pdf',
 'filename': 'BasicManagementOfEFIBootLoaders',
 'folderObjectId': 10160,
 'lastModified': ,
 'mimetype': 'application/pdf',
 'objectId': 289850,
 'ownerObjectId': 10000,
 'projectObjectId': 10140,
 'status': 'inserted',
 'title': 'BasicManagementOfEFIBootLoaders.pdf',
 'version': 1}

Text 3: Omphalos representation of a File [Document] having the "IPPPRINTABLE" flag due the MIME type of the file's contents.

By simply checking for this flag HTTP clients retrieving document lists via XML-RPC, JSON-RPC, or ".ls" requests to WebDAV can toggle on and off the availability of any request-to-print feature.

Request to print via HTTP can provide an easier path to producing hard-copy over downloading the document to the client, opening it [hopefully] in an appropriate application, and then printing it to a printer that must be configured on the client (and potentially selected by the user).