18. What's missing?

18.1. Plumbing

There's a general problem with getting all the parts to talk to one another; especially in a spooler-independent way. This problem manifests itself most noticably in the pathetic application support for control over all the "usual" printing features. There is simply no way for an application writer to get information about printers, jobs, etc; no standardized way to submit jobs; no good way to get job status back; nor even really a standardized way to generate print data (although most of the new desktop systems offer desktop-specific facilities for doing this).

Work to define a sensible API for applications to use for printing will undoubtedly center around Corel's sysAPS library, which provides a rudimentary implementation of several queueing and printer information features.

18.2. Fonts

Font handling on free systems is rather awkward. The display, the printer, the application, and the data files should ideally all have access to the same fonts. Unfortunately this is simply not the case. Plans are afoot to remove font handling from the X server, simplifying part of the problem, but good printer font to application font mapping is still a problem. No project really seems to be underway to address this; currently application writers simply embed their own fonts into printed data.

18.3. Metadata

Applications or spoolers need to learn about printer and driver properties somehow. The current standardized scheme, implemented on Windows, the Mac, and in CUPS, is to use Postscript Printer Description files to drive a programatic interface and user interface. This had trouble for non-Postscript printers, for obvious reasons, so the IEEE's Printer Working Group has a project to specify "Universal Printer Driver Format", or UPDF, files. Thus far they have constructed a sample file in an XML format. The sample file strongly resembles a PPD file, and is missing all sorts of driver and platform specific information; so much so that UPDF is currently not useful. IBM has a fully parameterized driver architecture for OS/2 which is available as free software; once this is released it is bound to be a useful source of ideas or code, and possibly a good enough system to just use outright. Even this system, however, provides no defined mechanism for communicating interesting properties from the driver space up to the application. Some XML format, and/or an API for fetching assorted properties, is bound to appear at some point.

18.4. Drivers

The state of free software drivers is rather poor. Fortunately, several projects are underway to correct this, and impressive results can now be had on printers using that code. The eventual goal seems to be to provide both good drivers and a good framework for the frequently duplicated (and hard!) parts of driver code—dithering, for example—to be shared.

Printer vendor cooperation will be an important part of achieving this goal. Vendors currently do not provide the minimum documentation necessary to operate their devices well. At the Printing Summit 2000, many vendors were present, and some small headway was made on this point. Vendors are mainly concerned with keeping the dithering and related algorithms secret; these software components are what produces such remarkable inkjet output, and the vendors are of course competing. Those vendors present at the summit should now have a clearer picture of how free software works and what we want from them. This isn't much; bt it sets the stage for future progress.