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.

Amendment: Initially I forgot to list IBM amongst the list of entities who had representatives at the summit; in fact, IBM is not only the vendor of AIX, but also a vendor of digital high end commercial and production printing equipment. Summit participant Claudia Alimpich did not only represent the FSG/Open Printing Group, but also her employer, IBM. Sorry for not having had that right in the first round, and my deep apologies to Claudia and IBM.


so many of the shortcomings you noted (though of course not all of them) are already addressed quite well in kde.

and while kde's print dialog can certainly be better, it's by far not the worst out there. the fact that people can actually use it to get things done that the others simply don't provide is a nice start ;)

as for the custom extensions issue ... this is one place where xembed and some judicious use of IPC (XAtoms or DBUS) might be just what the doctor ordered. it would allow vendors to pick whatever toolkit they wanted and not limit what they can do (save for saying "it appears in this little box/window" ;). i suggested this in portland last year, i believe, actually. i wonder what direction people are looking to take on it?

By Aaron J. Seigo at Mon, 04/17/2006 - 23:16

> so many of the shortcomings you noted (though of course not all
> of them) are already addressed quite well in kde.

Still, a lot of work is still needed.

As a whole, printing in Linux is far from what is current industry standard (and way farther than what people would expect anyways).

> i wonder what direction people are looking to take on it?

More of XML either with precompilation (one per toolkit/desktop whatever) or JIT. All combined with some sort of dynamic language for action (ECMAScript was mentioned).

Embedding different toolkits in the same window is just spells horrific Frankenstein to many.

By Cristian Tibirna at Mon, 04/17/2006 - 23:45

Before I shout "hooray" too loudly for xembed, I'd like first to see a proof-of-concept thingie...

We actually already do "embed" items from 2 different "external" sources in our print dialogs:

  • all print options from the locally installed (or remotely retrieved) PPD, on the "Driver Settings" tab, hidden behind the "Properties" button
  • application specific settings (examples: konqueror, kate, gwenview) on the respective tabs of the main dialog frontside ("HTML", "Text" and "Image" settings)

On Windows, developers can add both these things by providing additional DLLs (or even by replacing the OS-provided base-DLLs alltogether for their drivers or applications); Apple also has a standard way for extending their system provided print dialog (from an application-specific as well as from a printer capabilities perspective).

What we currently do with the PPD-contained device capabilities, is to construct a very simple listing of print options from the parse results of the PPD. Could it be that this "boring" table may be dynamically translated into something more pretty? Also, at the summit the representative from Xerox clearly stated that they do not use PPDs any longer for their most advanced devices; PPDs seemingly do not allow for describing the ambitious stuff they want to achieve in their print GUI. Xerox also uses something based on XML. David Salgado (the Xerox man at the summit, and head of print client development) was very much interested to cooperate with KDE and and find a way to integrate their own needs into KDEPrint's dialogs.

And if we think of Project Portland, and if we want to offer a "printing dialog as a desktop service", that may be called and used by all (not just KDE-native) applications that a user runs on top of a KDE desktop: here we also need to come up with some standard way to embed any additional print option the application may want the user to select and communicate to the driver or spooler down the line.

So there are already 2 different external requirements from 2 different directions that may want to add features to the standard dialog provided by the system: a) the driver, and b) the application wanting to print. The same requirements as for KDEPrint are of course also true for any Gtk-based GUI and set of dialogs the Gnomies will come up with quite soonish (for their first time).

One other way (than xembed) to do it would be to come up with some (standardized) XML-based description of GUI elements that KDEPrint would then render to a nice display of dialog elements that look "native" (and if we can do that for some external "make me a GUI for this and that"-requests -- why not base all of KDEPrint on it? Hrrmm, I may be overshooting the target....)

One thing should be pretty clear: hardly any external vendor would do the same work twice: use Qt and kdelibs to embed his stuff into KDEPrint, and also use Gtk and gnomelibs to do the same for Gnome-Print, and maintain both.

Now if we could point to some Freedesktop.org spec and 2 model implementations (done by, say Firefox and OpenOffice.org) and say "This is the standard way to do it", things would suddenly be much different...

By Kurt Pf. at Tue, 04/18/2006 - 00:27