|
|
Topics of InterestPrint API aka PAPIWhat is PAPI?PAPI isn't just another nickname for your dad. PAPI is a collaborative effort to create a print service independent API for application / print service interaction. The current draft of the API (v1.0), http://sf.net/projects/openprinting/, contains a set of printing related objects or data structures and a set of operations or functions to manipulate the objects. The functions include support for querying the print service, submitting/modifying/canceling jobs, and much more. Where did PAPI come from?About five years ago, several people working on printing related technology and Open Source got together in San Jose, CA. to meet and discuss work and deficiencies in the state of Unix/Linux printing. Several teams were created to focus on areas that needed to be addressed. On and off, these teams have been working on interfaces under the auspices of the Free Standards Group. The Job/Spooler API group came up with the PAPI, which has been largely unchanged for the last 2+ years. See: http://www.openprinting.org/Wiki/OpenPrinting/PAPI Why do I care about PAPI?Because PAPI is intended to be print service independent, PAPI provides applications a single interface for print service interaction. This means that applications can be written to use this interface and work with a variety of print services without requiring changes to the applications. Applications are no longer tied to a particular print service (LP/CUPS/LPRng/...). Instead, print services can easily be replaced on a system without impacting the layers above. Ultimately, print services can be both developed and selected based on specific needs. What's going on with PAPI?There are a number of things actively happening with PAPI. v1.0 of the specification is complete and on it's way to becoming an FSG OpenPrinting standard. Once that completes, additional work has been identified to be included in a follow-up revision of the specification. This will include support for documents, notification, and more. This work is being coordinated through the FSG OpenPrinting team. See: http://www.openprinting.org/Wiki/OpenPrinting/PAPI Development of implementations of the API and consumers is progressing on SourceForge. Solaris already ships PAPI support for interaction with Solaris LP (lpsched) and RFC-1179 (bsd/lpd protocol) based servers. There is also support interacting with CUPS servers using libcups and native IPP client side support is virtually complete. Along with this API support, there are re-implementations of several common BSD and SYSV printing commands. The new command implementations are layered on the PAPI and as a result will work with a number of print services already. Part of this development includes server side support for IPP also layered on top of the API, but implemented as a set of protocol specific libraries and an Apache module (1.X and 2.X). Like the command implementations, the IPP listening service can be used with any print service for which there is PAPI support. RFC-1179 server side support is also on the horizon. See: http://sf.net/projects/openprinting Applications are being converted to make use of the PAPI. Back about a year ago, Sun contributed modifications to libgnomeprint that allow it to use the PAPI for print service interaction. These changes are present in the version of libgnomeprint on Solaris 9 Update 6, Solaris 10, Solaris Express and version yet to come. They are also in the main libgnomeprint source base. See: http://cvs.gnome.org/viewcvs/libgnomeprint/ The files are here: http://cvs.gnome.org/viewcvs/libgnomeprint/libgnomeprint/modules/papi/ Additional work is planned to add PAPI support to other applications and toolkits like Mozilla, Xprint, OpenOffice, KDE/Qt, and more. |