A first summary of topics discussed at OSDL Desktop Linux Printing Summit

Exhausted, but happy about the work we've done I'm now back in Stuttgart. I have attended the 3 intensive days of discussions and work that were the Desktop Linux Printing Summit, jointly organized by OSDL (John Cherry) and Linuxprinting.org (Till Kamppeter). It was held in Atlanta, hosted by Lanier at their Education Center. The hosting was made possible by Uli Wehner. Uli is one of Lanier's senior support and testing engineers (responsible for Lanier's ever-growing business of non-Windows system printing); he is also quite active on the Linuxprinting.org user support forums.

Altogether we had nearly 40 people there. They represented a broad range of backgrounds. See yourself:

• printer hardware vendors: Lanier, Ricoh, Sharp, HP, IBM, Xerox, Lexmark, Epson
• Linux distributions: Novell, Debian, Mandriva
• other operating system vendors:Apple, IBM, Sun
• desktop environment projects: Gnome, KDE
• printer driver development projects: Gutenprint, HPLIP
• application developers and Independent Software Vendors: Mozilla Corporation, Easy Software Products, Scribus
• printing consultants: Tykodi Consulting, Danka
• standards defining organisations: Linux Standard Base, Printer Working Group, Free Standards/Open Printing Group
• usability professionals: OpenUsability.org, Relevantive AG
• developers of core Linux printing software: CUPS, Ghostscript
• other organizations: OSDL DTL, Beijing Software Testing & QA Center

For links to the respective websites, have a look at the OSDL printing summit website. A huge amount of presentation materials created by participants is listed in the preparation material section.

Waldo already leaked it: we had a very cooperative atmosphere, and a lot of common ground was found. We identified 7 major areas which need attention for the future development and efforts by everyone involved with making Linux printing better, some of which must be addressed from inside KDE (and from inside Gnome or other applications) by the respective developers:

Printer and Driver Installation:

Setting up printing is still much too difficult, even for power users and administrators, let alone the home user who is no Unix expert. Very often there is no automatic device discovery, nor the correct display of available drivers. Users who have a working printer, and are familiar with the setup tool used by their distro, find themselves completely hanging in mid-air as soon as they are tasked to install the same model on a different distro using a different setup tool. Some distros don't even ship PPDs, thus rendering the CUPS web interface (which usually works flawlessly) completely useless for installation tasks.

Error Messages and General Feedback:

Error messages frequently are very in-comprehensive (mostly using the standard, yet cryptic official IPP error codes); job progress feedback is not good enough or simply non-existent. Finding help is not obvious. Some distros have patched and completely crippled the CUPS web interface without documenting their changes at an easy to find place and telling users how to setup the modified system.

Usability Experience:

Across different desktop environments and applications users experience too much inconsistency; each of KDE, Gnome, Mozilla/Firefox, OpenOffice.org, Scribus, Acroread and more use their own self-rolled print dialogs; what's worse even: none of these dialogs is the obvious best one from a usability point of view either.

Print Dialog Extensibility:

Hardware vendors were asking for an easy (and standard) way to plug in their own extensions into the print dialogs provided by the desktops. This can be done on Windows and Mac OS X quite easily (on Windows, driver developers can add their own DLLs to the Microsoft provided ones, and even completely skip these). Linux printing lacks a mechanism like this. High end production printers from vendors like Xerox are not able to map their device options into the (limited) standard syntax of PPDs -- they use a different, XML-based method to make their driver GUIs display options to their users.

Printer Driver Development:

As can be seen from looking at some of the efforts made by hardware vendors who provide Linux printer drivers for their boxes, the knowledge about a preferred and recommended architecture of printer drivers has not yet trickled down into their ranks. One can see very wild and non-standard ways to design printer drivers as well as installing these into the various Linux systems.

Print Job Data Transfer Format:

PostScript is no longer seen as the core format for print jobs to be spooled and transferred from print client to print server to printer device, or from customer to professional print shop. However, currently Linux printing is still centered around this legacy format, and all non-PostScript devices are only supported by converting PS to the printer's native raster or PCL language.

Buying a Printer:

When buying a printer, choice is difficult: many models do not work perfectly with Linux; OTOH, many work fine, but they don't say so on the box; some do carry a Tux logo on their wrapping, but very often the manual doesn't say how to install the driver; some come with proprietary drivers which do not blend in well with CUPS, or which do not install on all distributions. Searching Linuxprinting.org database is a too complicated step for many to succeed in.

It will not be easy to fix each and every one of these; and it will not be done within a few months. But the meeting heard a few very good proposals for all these points, and we will be working on them in the future. Also, the upcoming CUPS 1.2 series (the 3rd release candidate for 1.2.0 will be out in the next couple of days, and the final release likely 2 weeks after that) has a few improvements on board which will greatly help with some of the problems listed above.

I wonder if we could try and transform one or more of the above problem fields into a tangible set of tasks, that we could announce as a Google Summer of Code challenge, and this way find one or two new coders for Linux printing stuff?

Over the next few weeks I will write up a more detailed summary for each of the above identified points, including some of the proposed solutions that were discussed at the summit.

If you are interested to keep an uptodate view of the ongoing work or better: if you want to contribute in either one of the named problem fields, please join the OSDL desktop printing mailing list. Over the next few months a lot of the ideas for solutions we discussed in Atlanta will be thrashed out and refined there; also, the next summit which will take place in October is going to be prepared via the discussions taking place on this list.