2013-04-14

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",
          ....
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
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}

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).

No comments:

Post a Comment