A Gnome's eye view of printing

Raph Levien and Lauris Kaplinski
24 Jul 2000 -- 100 grit draft

Note: the master version of this document lives in Gnome CVS at white-papers/Printing/print-summit-2000.html. Go there.

This document presents an outline of the current Gnome plans for printing support, as well as discussing some challenges that lie ahead. It will be distributed at the VA Printing Summit in Sunnyvale CA, 27-28 Jul 2000.

This document is being written on a tight schedule, and I'm busy with lots of other stuff. Checkins of changes from printing people within Gnome are welcome.

Background

The Gnome project was founded in 1997 with the goal of providing a fully free desktop environment. It now is one of the two leading contenders for the Linux desktop and is used by many people in their daily work and play.

Gnome has had two distinctive traits from the beginning: an unwavering commitment to free software, and a background of graphical sophistication. One of the co-founders of Gnome (Federico Mena Quintero) and many of its contributors come from the Gimp project, widely to be considered the first free desktop app with a fully modern GUI, and to this day there is considerable overlap between the Gimp and Gnome development communities.

Providing a completely free desktop is an overriding goal of the Gnome project. As such, proprietary software has no place in the Gnome infrastructure. At the same time, the gnome infrastructure supports the freedom for people to develop and run proprietary applications if they so desire. With few exceptions, Gnome libraries are licensed under the GNU Lesser General Public License, while Gnome applications are GNU General Public Licensed.

Printing is a major part of any desktop architecture. A draft API and sample code for Gnome-Print was first published in September 1998. Now, most Gnome applications that print, including the flagship Gnumeric spreadsheet, use the Gnome-Print api. Back-end drivers now exist for PostScript, PCL, PDF, and a Gnome Canvas-based print preview. As the Gnome Canvas is based on the high quality Libart 2D imaging library, print preview is an extremely faithful representation of the printed page. As an integral part of the Gnome infrastructure, it is clear that Gnome-Print will be actively developed and maintained. (mention bonobo stuff here)?

There are a large number of problems with printing in Linux, and Gnome-print does not attempt to solve all of them. In particular, there is little or support in Gnome-Print for printer discovery, job and queue management, feedback from the printer, etc. Further, there are significant issues with font installation and management. Solving these problems well depends on collaboration with people from many different people in the Linux world. We're eagerly looking forward to working with others to get real, solid, permanent solutions to all these problems.

The Gnome project must make decisions about which existing pieces of technology to adopt, which to help bring into existence in collaboration with others, and which to grow primarily within Gnome. These decisions are always very difficult, and are often influenced by personality differences and NIH. However, we are guided by a strong passion to build high-quality infrastructure and provide our users with a good experience, and we do the best we can.

The remainder of this document presents the current inclinations of the Gnome project with respect to the many different standards, interfaces, and other projects involved in printing. Obviously, none of these decisions are set in stone, and we are very open to better ideas.

Imaging API for printing

It almost goes without saying Gnome's choice for an imaging api for printing is Gnome-Print itself. However, there are other definite possibilities, including apps generating their own files in some Page Description Language (PDL), or virtualizing an imaging API designed primarily for screen display, as in the Xprint and QPrinter/QPainter efforts. In addition, the Gdk (Gtk+ Drawing Kit) layer is being virtualized for the upcoming Gtk+ 2.0 release, and could, if desired, support a print target. Here, we describe why we feel that coding to the Gnome-Print API is the best choice for Gnome apps.

First, Gnome-Print has back-end drivers for many different PDL's. Thus, we are able to produce optimized, native reperesentations of the page image directly from the Gnome-Print API. If we standardized on a single PDL, then printers implementing that PDL would be very nicely supported, while other printers would only be supported through PDL transcoders - a source of both performance problems and often incompatibilities and other hassles. With Gnome-Print, we can support very high speed text printing on PCL printers with our native PCL driver (important because many very high-speed laser printers are PCL based), while not sacrificing the graphical sophistication of PostScript or the performance gains enabled by rasterizing PostScript files at high resolution in the printer or imagesetter.

Second, given our desire for the highest printing quality, we do not find any of the existing virtualized screen display API's such as Xprint to be adequate. In particular, none support an adequate font model. The current X font model, in particular, has serious and intractable limitiations, not the least of which is access to font metric data. In addition, these API's tend to be organized around a pixel grid for coordinates, while good quality printing demands a resolution independent coordinates. In summary, we felt that desiging our own new imaging API presented enough significant advantages to be worthwhile.

Page Description Language

The design of Gnome-Print is somewhat agnostic to the actual page description language, and incorporates a number of pluggable back-ends. Even so, we still need to "pick winners" and decide which PDL's to support. These choices, in turn, affect the API design, as there are clear advantages to the API being harmonized with the PDL's supported.

Gnome currently has support in development for PostScript, PCL, and PDF. We feel each of these is well justified. We are also considering rasterization (using the Libart 2D imaging library) for raster devices such as consumer inkjet printers, but there are a number of issues with this approach, so it's not clear we will pursue it.

The Gnome-Print API is closely related to PostScript. In the PS back-end, most Gnome-Print functions are, in fact, thin wrappers for generating tiny bits of PostScript code. We feel that continuing to support PostScript has clear advantages due to the large installed base and continuing desirability of PostScript printers in the Linux world. Having a PostScript implementation in the printer continues to be the best solution for Linux printing for many people, especially for lasers and other page printers.

Even though we could avoid implementing our own PCL driver by using Ghostscript's PS->PCL transcoding capabilities, we feel that a native PCL driver justifies itself. In particular, PCL supports extremely high speed text rasterization, for which an intermediate PS step would merely compromise performance. The current working PCL implementation is raster-only, but a higher level version is in the works.

Lastly, we have decided to generate PDF directly. PDF is increasingly gaining momentum as an interchange format. As above, though we could avoid implementing PDF by using Ghostscript's PS->PDF transcoding capabilities (ie, similar functionality to Acrobat Distiller), we feel that we can optimize both performance and features by generating PDF directly.

Perhaps the most compelling reason to support PDF is the upcoming PDF 1.4 spec with its advanced transparency features. Even though Adobe has not yet published the full PDF 1.4 spec, they have published a tech note on these transparency features. Although the Gnome-Print API supports transparency, its implementation for most PDL's not directly supporting transparency, such as PostScript, is slow and inelegant, generating huge bitmaps for every semitransparent object. PDF 1.4 allows us to use native transparency for back ends supporting it, only falling back to rasterization when transparency features are used. Thus the pages will always print, but with no guarantee of high performance unless a PDF 1.4 back-end is used.

PDF 1.4 seems an ideal candidate for "most favored PDL" status, but there is one potential fly in the ointment. Quoting from the transparency tech note:

The information in this document is subject to the copyright permissions stated in PDF Reference, Section 1.4 [1.7]. Additionally, developers should be aware that many of the transparency extensions to the Adobe imaging model are the subject of patents and patents pending by Adobe Systems. The permission to use the copyrighted material in the PDF specification does not include the right to use any Adobe patents, except as may be permitted by an official Adobe Patent Clarification Notice (published at Adobe's web site or elsewhere).

We are actively watching the patent situation with PDF 1.4 and will be requesting clarification from Adobe. Clearly, a significant risk of Adobe asserting its patents against a free software implementation of PDF 1.4 would be a showstopper.

Direct support for raster devices is being considered, but is controversial. Among other things, there is no standard infrastructure in Linux for doing device color space conversion and dithering, translation of the dithered image to native printer escape codes, and conveying these escape codes to the printer. Most of this functionality as presently implemented in Linux exists as device drivers within the Ghostscript codebase, although there are two other independent sources of implementation we are actively tracking. First, Gimp-print has created a library of printer drivers with considerably higher image quality (optimized for photographic images) than the Ghostscript driver collection. Second, there is a growing trend to implement individual printer drivers as PPM to native printer escape code filters. Pnmtoppa is perhaps the highest profile of these projects. We also see a number of Lexmark printer drivers being developed along the same lines.

We would like to see a nice infrastructure developed for high quality raster imaging on inkjets. Such an infrastructure, we believe, would meet the following goals:

While we feel that such an infrastructure would be desirable, we also recognize that it is a tall order, so much so that we prefer not to have to build it ourselves. Further, we feel that while there are advantages to be had from client-side rasterization (mostly in the area of performance), just generating high-level PS or PDF data and then rasterizing in Ghostscript will work pretty well. Thus, direct rasterization is not a priority for us. For the forseeable future, we feel Ghostscript plays an essential role in driving inkjet printers in Linux.

Print Preview

While print preview is not actually itself a printing function, it is an incredibly important piece of infrastructure for applications. Ideally, print preview should provide a pixel-perfect preview of the page image, at no additional complexity cost to the application itself.

Gnome-Print provides print preview by creating an instance of a Gnome Canvas, then adding elementary canvas objects for each marking operation. The Gnome Canvas supports a high level of imaging functionality, with good overall fit to the needs of print preview. In particular, it contains an advanced Libart-based rendering engine, flicker free scrolling and zooming, and a font renderer for Type1 fonts. A fast but high quality Freetype2 based renderer supporting a much broader range of font formats will soon supersede the current renderer.

Our other major alternative would have been to generate PostScript code and use Ghostscript to display the print preview. However, we chose not to pursue this route, for a number of reasons.

For these reasons, we will likely continue to develop our own print preview.

One of the most exciting developments we are tracking is the XFree86 render project, which promises to provide hardware acceleration for advanced 2D graphics, including antialiased rendering and glyph compositing. We are working to make sure that the Gnome Canvas will be able to take advantage of this extension, which should result in dramatically accelerated print preview as well.

Color management

Gnome-Print does not currently implement any form of color management. However, we consider this to be an important issue. We are very eager to work with others to create a free color management infrastructure and will build our own if necessary.

A generic discussion of free software color management issues is online at http://www.levien.com/gimp/gcmm.html (note that this page originally started life as a project page for a Gimp color management plugin).

The requirements for high-end graphic arts imaging differ considerably from most people's day-to-day printing needs. We feel that it is important for Gnome to support both.

For low-end imaging needs, the sRGB color space is probably ideal, because it is simple, produces reasonably good quality results, and is a standard for many important sources of images, such as Web pages. It should then be the responsibility of the printing infrastructure to produce pages with the highest quality rendering of the source sRGB images (note that the highest quality rendering most emphatically does not mean producing a colorimetric match - if you don't understand this, [GM98] is an excellent reference).

However, sRGB is inadequate for high end printing applications, for a number of reasons:

ICC is a plausible approach to take. However, it has two significant drawbacks: there is a serious patent cloud over use of the technology, and also ICC does not itself specify gamut compression. If Gnome were to adopt ICC, it is likely that we would nail down a standard gamut compression algorithm, almost certainly based on Ján Morovic's PhD thesis.

We have not decided what approach to take. In any case, it's most likely that color management will get hashed out first in the Gimp, and as a good solution emerges, it will get adopted in Gnome.

Network Printing Protocols

We like IPP. It's fairly complex, but much of that complexity is actually motivated by real, nontrivial problems. It is likely that Gnome-Print will incorporate native IPP support.

At this point, we are at best ambivalent about CUPS. While it is a GPL'ed implementation of IPP, we're not happy with the project's emphasis on proprietary, binary only drivers. As stated above, Gnome has a strong commitment to delivering an excellent desktop environment composed entirely of free software. If CUPS develops to the point where it provides an excellent free solution, we will be more enthusiastic about integrating it more tightly. In the meantime, adding IPP client support to Gnome-Print should ensure that users who wish to use CUPS will be able to do so.

Fonts

We like Type1 fonts and their friends. Type1 sucks for i18n, but some of the later related formats such as CFF are better. We don't like TrueType much, largely because of the patent issues. We're tracking OpenType but haven't made up our minds. It's featureful but perhaps overly complex. On the plus side, Werner Lemberg has done some work implementing OpenType as part of the Freetype project. Thus, it may not actually be that painful to get OpenType to work.

Gnome-Print has a mechanism to install and manage fonts client-side. Unfortunately, just about every app on Linux seems to have its own mechanism to do this, and none is compatible with any other. We certainly hope a common font installation mechanism emerges for Linux. When this does, Gnome-Print will enthusiastically support it. With luck, this effort can learn from the good points as well as the failures of the existing Gnome-Print font implementation.

Font support in Gnome-Print is currently evolving into separate Gnome-Font module, developed by Lauris Kaplinski. Gnome-Font will be developed in tandem with emerging technologies such as FreeType 2 and the new X rendering framework. Gnome-Font will provide font services beyond the scope of a basic print library, including a workgroup font server.

Gnome-Font is designed from the start to support high-quality typesetting, font format independence and network-wide font installation and caching. To achieve first goal, we subclassed fonts into separate layout and imaging fonts. A layout font is created from an abstract typeface for a certain specific output device, such as an imagesetter, ordinary printer or display, and it has all metrics adjusted for given device. Usually that means hinting and aligning to the pixel grid. Using layout font metrics, we can render text into device-independent (but master output device optimized) layout glyph lists, which can then be stored, transferred and rendered. For actual rendering, an imaging font is created according to desired rules, and the glyphlist displayed using that. Possible rules are antialiasing, sub-pixel placement, best fitting and best readability. Thus, depending on this setting, screen display can yield identical glyph placement (using full antialiasing), nearly identical results (using subpixel placement), or be aligned to the pixel grid, optimizing for rendering quality over layout accuracy.

For extensibility and network transparency we are developing a rich font API, covering areas from naming to rendering to embedding, with opaque extensible objects for typefaces, fonts, rasterized fonts and glyphs. Using existing Gtk+ inheritance, it is very easy to add support for different font file formats, composite fonts (including user composited ones), multiple master fonts and user transformed fonts. Also, the font API is completely ignorant about text layout issues - that is the responsibility of separate libraries. It only exports handles to numbered glyphs and encoding tables. We plan to add mimicing/exporting OpenType advanced layout features soon - but it is still completely the task of layout library to interpret these.

This will greatly overlap with what FreeType2 is providing. Still we think there are good reasons to implement a separate font API.

An additional idea, still in the conceptual stage, is implementing an X font server on top of Gnome-Font library, so all typefaces are guaranteed to be available in all possible encodings and all transformations for all X programs. Still, as current X font system cannot do anything more than 1-bit fonts, we are at the moment implementing a client-side rendering engine, to draw arbitrary fonts to X drawables (with optional antialiasing) using cached pixmap/bitmap pairs. Still that implementation is slower than using native fonts, so serving fonts for X is most probably good idea for most basic and time-critical tasks, such as text display in a word-processor.

We are very much interested in working with other groups to harmonize Gnome-Font with other applications requiring advanced font services, although obviously not at the cost of compromising typographic quality.

Conclusion

Providing printing services to applications is an important goal of the Gnome project. Gnome-Print currently provides services at a reasonable level for common PostScript-based printer configurations, and is under active development to provide a better experience for color printers, networked printers, and other devices.

Perhaps the most important message for this summit is that the Gnome development team is not sitting around waiting for things to become standardized. Where good standards exist, we follow them. However, where there are voids, we seek to fill them. We invite other people to work with us to make these advanced features integrated with the broader free software environment rather than only Gnome applications.

References

[GM98] Edward J. Giorgianni and Thomas E. Madden. Digital Color Management: Encoding Solutions. Addison-Wesley, 1998.