- From: Raph Levien <raph acm org>
- To: gnome-hackers nuclecu unam mx
- Cc: Robert Krawitz <rlk alum mit edu>
- Subject: Gnome printing issues
- Date: Sun, 10 Sep 2000 23:36:45 -0700
Hi Gnome hackers, There's some controversy brewing about Gnome printing issues. I think the proper place for this discussion is here, rather than private conversations. Printing is a difficult and complex issue. Historically, Linux (Unix in general) has done a very poor job of it. There's been some very promising movement, but there's still a long way to go. Some of you know by now, but probably many do not, that I am taking over the maintainership of Ghostscript. I am excited about this, as I feel that Ghostscript has much excellent core technology, especially the high level of conformance to existing standards. It is also weak in a number of important areas. I think that it is possible to fix a lot of those weak spots without a tremendous amount of effort. Some of the controversy here is how much of the overall printing architecture to subsume under the Gnome umbrella, and how much to leave to other people, including Ghostscript. While it's tempting to take the attitude that Gnome will reimplement all components of the complete system architecture, I clearly believe that there advantages to the latter approach. It's possible that my Ghostscript affiliation makes me a bit biased. If so, it's my hope that discussion here can help us reach the right answers, both for the Gnome project and for free software in general. 1. Those who do not understand PDF are condemned to reinvent it, badly. Until a few months ago, I was in favor of using client-side rendering for many printing scenarios, including an inkjet connected to a local printer port. The main reason was that Libart's imaging model was more powerful than any of the popular page description languages available (PostScript and PDF), particularly in the area of alpha transparency. With the advent of PDF 1.4, that situation has changed. PDF 1.4 transparency and blending leaps is a _hugely_ powerful model, adding Photoshop-like blend modes such as Multiply, Hard Light, and so on, as well as the two-alpha-channel knockout groups. These extensions are fairly complex, but I believe that much of this complexity is justified - the result is a richer palette for designers, and a higher-level expression of graphic effects. Thus, I now recommend that PDF be used as a default intermediate representation for documents to be printed, and that Ghostscript be used to rasterize the pages for printing to local inkjet printers. There are a number of advantages to using PDF, and no serious disadvantages. The main advantage is flexibility in spooling. In a networked environment, client side rasterization forces an early commit to rasterization for a specific printer. If it later turns out that it would have been desirable to spool to a different printer, you're screwed. One of the primary advantages of using a page description language is that you can defer rasterization until the page actually reaches the printer (or its associated server). PDF is rapidly becoming _the_ cross-platform format for document interchange. Using it as the intermediate format for printing will make things work much more smoothly in mixed enviroments including Macintosh and Windows machines. The current Gnome Canvas implementation is optimized for rendering at screen resolution. Printing is roughly two orders of magnitude more pixels. In addition, the Gnome Canvas really only handles RGB colors, while for printing you really need to deal with CMYK (and, for graphic arts work, additional color separations and color spaces). Thus, there is a fair amount of extra work to be done to bring client-side rasterization up to a really high level. I believe it is a requirement that Gnome apps be able to produce high quality PDF files. Kudos to Chema for hacking on this! Similarly, it is also a requirement of a complete desktop system to be able to view and print PDF files downloaded from the net. If these requirements are met, then you get printing through PDF "for free." Doing lots of work on client side rendering is wasted effort. In a networked printing scenario, doing the rasterization client-side is potentially a huge performance problem, as rasterized pages can easily run to the hundreds of megabytes (an 8x10 inch page on an Epson 870 printer at 1440 x 720 dpi, six colors, four dot levels is about 250MB uncompressed). One alternative in this case is to use Gnome Print metafiles. However, a serious problem I see here is version skew. If the application and the print server are running different versions of Gnome Print, unless considerable compatibility engineering work is done to avoid problems, the most likely result is breakage. The Gnome Print API is good enough for 95% of applications. However, it is clearly inadequate compared with PDF for graphic arts applications. Separation colors, overprint, and control over halftoning are just some of the issues here. Instead of extending Gnome Print to the point where it subsumes PDF, I'd rather see it remain simple and coherent for the majority of apps that can best use it, while allowing the graphic arts apps of the future to generate PDF directly, in order to access its power. Thus, I'm fairly convinced that we should be using existing standards such as PDF, and existing implementations, such as Ghostscript, rather than trying to invent our own solution. In simple cases, such as a desktop computer running only Gnome, with a locally attached printer, there isn't much difference. The differences become significant as you move to more complex scenarios. I think it makes a lot of sense to have a Gnome Print API call for embedding PDF subdocuments. In the native PDF driver, the implementation should be relatively straightforward. In other cases, it makes sense to call to Ghostscript to do rasterization. 2. The best thing about unified architectures is that there are so many to choose from. The current inkjet driver situation in Linux is a mess. There are two popular collections of inkjet drivers: Ghostscript and Gimp Print (also known as stp). In addition, IBM has released a subset of their Omni printer drivers (the driver framework used in OS/2) under LGPL. There is no clear winner among these frameworks. Here, I will outline what I perceive to be the relative advantages and shortcomings of each. Obviously, in the long run, it is much to the user's advantage for only one to survive. So a clear plan is to pick a winner and put in the work needed to patch the shortcomings. The Ghoscript driver collection is popular, reasonably complete, and well tested. However, image quality tends to suck, and the code is messy, ugly, and non-modular. I'd be delighted to work with people who wanted to improve the situation, and can probably even make some funds available. But, right now, it's not a good solution, and it is far from given that it is going to become one. There was quite a bit of excitement at the Printing Summit about the open sourcing of the IBM Omni driver framework. Perhaps the most exciting thing was the vast archive of supported printers. However, in the actual release, only 100 printers are supported, from only two manufacturers (Brother and Epson). Since most of the driver work was done under NDA, presumably IBM simply failed to obtain permission from the printer manufacturers to release their code. I have no idea whether this is going to change, but until then we should be looking at Omni on its technical merits. From what I understand, image quality in Omni is middling. Newer printers such as the six-color Epsons are not supported at all. Of course, it should be possible to fix this, but somebody (who?) has to write the code. Much of the code already exists in GPL form (both my rinkj experimental Epson drivers and the Gimp Print work), From the Printing Summit presentation, Omni has a very nice data driven database for configuring printers. This is a good thing, as the other frameworks bind printer configuration pretty tightly to the code. The current release of Omni has a dependency on the IBM Java implementation, which appears to be based on Sun's and is not free software. I don't know how quickly IBM is moving to remove this dependency. Finally, Gimp Print has been doing _amazing_ work on image quality. In the last few months, quality has gone from being middling to quite nearly matching the proprietary drivers. Most inkjet printer manufacturers have indicated their preference for providing binary Linux drivers (in one framework or another). I believe that supporting the Gimp Print work is our best bet for ensuring that our complete printing infrastructure remains free. Currently, Gimp Print has a fairly messy code base, and does not have a good database for printer configuration. However, these are priorities for future development. I think it is reasonable to help them with these goals, and also to integrate with Gnome. Miguel has told me that there have been difficulties working with the Gimp Print team. If so, I would like to see these problems resolved. My conversations with Robert Krawitz have left me with the impression that they are very serious about providing a general solution and not just a system for printing pictures from Gimp. 3. Gnome fonts and aa rendering In this section I'm going to provide mostly good news, and not even whine very much. People who are working on aa font rendering should be aware of the aa font implementation I've recently committed to nautilus/librsvg. That work includes wrapper code for Freetype2, as well as a nice glyph cache and some compositing code. I'm not done optimizing it yet (although it's on my list of paid work, thanks Andy!), but already performance is quite impressive - scroll speeds are ridiculously fast, and opaque moves over the window appear rock solid. I'm quite pleased with how it turned out. The code currently has one big limitation - it doesn't support internationalization at all (it simply assumes an ISO-8859-1 encoding). Clearly, it would be desirable to integrate this with Pango. Further, it is also clearly desirable to integrate with the various text widgets and items out there. Lauris already has some of the higher-level frameworks in place in his gnome-font project. I don't have the time to be doing this work myself, but would be more than happy to help people integrate it. People should also be aware of Keith Packard's Render extension for XFree86. One of its features is server-side compositing of aa glyphs. In most scenarios, this compositing will be hardware assisted, for performance virtually indistinguishable from current non-aa fonts. In addition, font management is done entirely by the client, so you avoid entirely the X font suckage problems you see now due to the client having only a vague idea what exact fonts are available, and even less of a hint about their metrics. The path to high quality, high performance aa font rendering is now clear. It's just a small matter of programming to get everything integrated. Conclusion I hope this email brings people up to speed on some of the currently controversial areas of Gnome Printing, and fosters a good, open discussion. With luck, we will emerge with a much clearer picture of what we need to do to all pull together for non-sucky, dare I say exquisite printing, both for Gnome apps and for free software as an entire system. Raph