Volume Number: 13 (1997)
Issue Number: 8
Column Tag: Dialog Box

The Future of MacOS Printing

by MacTech Editorial Staff

Apple has announced an end to its current situation of supporting two completely different printing architectures under MacOS. This much seems sensible. However, they have decided to keep the old, rickety QuickDraw architecture that has been hacked and patched and tweaked and munged and generally abused over the past thirteen years into doing things it was never designed to do. Therefore, dumping the next-generation QuickDraw GX architecture that would have taken MacOS printing into the next century. This letter explains why I think Apple's choice was the wrong one.

Let's get one thing straight: I'm no fan of a technology, no matter how cool it sounds, no matter how many years of work were put into it, if it doesn't actually help people get their work done. QuickDraw GX printing solves real problems for real users.

Every few days without fail on the USENET newsgroups I frequent, somebody asks how to do double-sided printing on a single-sided printer. The easiest solution I'm aware of is my own freeware Duplex Helper. Tell it how your printer prints (on the upper or lower surface of the paper, output face up or down), and it automatically works out which pages to print (odd or even) and in which order (forward or reverse) so you don't have to shuffle any pages around. It works with both PostScript and non-PostScript printers, and with just about any application that can print.

The only way to provide equivalent functionality without GX would be to reinvent this feature in every printer driver, or in every application, or both. Why do you think so few of them bother? I even see Microsoft Windows users asking for a solution to this problem, and not finding one!

I recently did a development job for a company that sells print server software - they needed an extension to install for their Macintosh clients that would obtain information about the print job from the user, and include it in the print job data where the server would collect it for accounting purposes. Without GX printing, I would have to come up with a driver-specific solution. I would have to work out how to patch into, say, the LaserWriter 8.3 driver to get the dialogs to pop up at the start of the print job, append my own information to the generated PostScript, and so on. And my solution would probably have needed to be redone for LaserWriter 8.4. And it would have to work in a completely different way for any other driver. Instead of going to all this trouble, I did the Macintosh client as a QuickDraw GX printing extension. This allowed me to hook into the printing process in a clean, well-behaved way that should work with any application, and any GX printer driver.

Incidentally, the company didn't have too much trouble implementing their Windows client, since Windows supports print queue processors that can modify the output of printer drivers in various ways, without requiring you to replace the drivers. Old QuickDraw printing is one part of the MacOS that makes Windows look good!

GX printing not only solves existing problems, it also makes new things possible that are difficult or impossible to do any other way. For example, I published a proposal for attaching URL tags to GX graphics. I have even released a version of SimpleView, my GX graphics viewer, that supports clicking on these hot links. Now, there is no way that everybody on the Web is going to buy a Mac and install GX just to view these graphics, but through the GX printing architecture, it would be possible to write custom printer drivers that would output these graphics to cross-platform formats such as HTML or Acrobat PDF, translating the URL links accordingly. You could use a small, purpose-built application for attaching these links to particular graphics, then simply paste or drag them into existing word-processing or other applications that need know nothing about GX, after which generating the final, Web-ready output is as simple as using the "Print" command. This is Web authoring, the "component software" way!

Sure, you could define new QuickDraw picture comments to try to provide equivalent functionality under the old QuickDraw printing architecture. However, even ignoring the fact that it is harder to write a QuickDraw printer driver than a GX one, you'd still be stuck with the low quality of QuickDraw graphics, which is particularly embarrassing when you're trying to output to a high-quality format like Acrobat PDF.

GX printing offers full programmatic control over the print job - any option the user can set in the Page Setup and Print dialogs can also be directly queried and changed by the application. Imagine using this to improve the smartness of document formatting - if the user pastes a very wide graphic into a portrait-oriented document, you could automatically reformat just that page in landscape orientation, or using some other wide paper type that you know is available. (Perhaps first putting up a confirmation dialog to let the user know what is going on.) Also, think of vertical market applications like check printing, which can automatically use their own custom paper types with minimal requirement for the user to stuff around in print dialogs.

Apple (and other vendors) may very well try to provide features like these in future versions of their old QuickDraw printer drivers. However, given that you would have to reinvent these features for every driver, what guarantee do you have that they will work the same way from one driver to another? Look at the mess of inconsistencies in the support of existing QuickDraw picture comments between different drivers, and imagine that multiplied tenfold.

One excuse given for canning GX printing has been its limited acceptance among developers and users. This is entirely Apple's fault. Many people were put off installing GX printing because it caused incompatibilities printing with some applications. Most of these incompatibilities came about because GX printing broke so many old hacks that were needed precisely to get around frustrating limitations in the old QuickDraw printing architecture.

Example: GX breaks the "space hack". Old QuickDraw printing offers no public API call to ask for a font to be downloaded to a PostScript printer so you can make use of it in your own PostScript code, which is embedded in the document. However, there is a way to force this to happen. Simply use standard QuickDraw calls to draw a single space character, using that font, somewhere on the page. The dumb LaserWriter driver will obligingly load the entire font into the printer, and leave it there for you to use.

GX printing is much smarter than this. It will load only the minimum subset of the font necessary to print the character, and it will delete it from the printer's memory immediately afterwards! The good news is that GX printing is so resource-efficient that it can successfully print complex documents on elderly, memory-limited PostScript printers that LaserWriter 8 cannot handle. The bad news is that trying to trick the printer driver into downloading the entire font by printing a single character no longer works.

On the other hand, GX offers a powerful function called GXFlattenFont, that allows you to do the font downloading yourself. It will convert any font to a PostScript data stream that you can embed in a print job (or do something else entirely) giving you control over encoding and subsetting, automatically converting TrueType to PostScript - just about anything you might want to do.

Eureka! At last we can consign the space hack to the dustbin of history, where it belongs, right? But there is just one problem - GXFlattenFont is not documented in any of the GX volumes of Inside Macintosh. So, how were developers supposed to find out how to use it?

This is the general problem. GX offers new, better, cleaner ways of doing all the things that you needed those old hacks for, and much more besides, but Apple has done a lousy job of explaining this to developers (and users). The result - people were left to discover GX printing on their own, without any clear idea of what its benefits were about; then as they hit the predictable problems, and little or no help was forthcoming from Apple on what to do about them, GX was allowed to acquire a bad reputation, and people gradually gave up trying to use it.

Compare the situation with the transition from MacTCP to Open Transport. In spite of all the bugs and incompatibilities that users had to suffer in that transition, Apple took pains to keep articulating the benefits to both users and developers, which encouraged them to stick with the new technology, and the end result was positive for everybody.

Apple's efforts seems to be going largely into Rhapsody these days. It's unclear to me how Rhapsody printing will work - it looks like the whole architecture is going to be PostScript-centric. This seems to me to be unwise in the current market. PostScript is admittedly still dominant in publishing, but its presence is tiny (and dwindling) everywhere else. For instance, the vast majority of printers being sold in the mass market these days are inkjets, and very few of those speak PostScript. This is a fact that Adobe seems quite aware of, even if Apple is not. GX printing would be a way to hedge one's bets, since it allows applications to treat PostScript and non-PostScript printers on an absolutely equal basis.

The MacOS has always been, to me, a forward-looking operating system, pioneering features in areas (device-independent graphics and printing, multimedia) which were not traditionally considered to be the domain of the operating system, but which turned out to be important in supporting the innovative, new applications. This case of dropping an important next-generation technology, and going back to an old one, is not the Macintosh Way.

Sure, Apple has had its share of failures that were technologically poor and deserved to fail. Unlike some other companies, Apple cannot afford to keep throwing money at mediocre solutions to force them to succeed. But the problems that GX printing solves are not going to go away. Apple is foolish to squander their resources in this way, by throwing away such a well-thought-out, painstakingly-built solution, and trying to develop another one.

Lawrence D'Oliveiro
ldo@waikato.ac.nz

1. Apple Press Release: http://product.info.apple.com/pr/press.releases/1997/q2/970303.pr.rel.print.html.
2. Freeware Duplex Helper: http://www2.waikato.ac.nz/ldo/sw/index.html#DuplexHelper.
3. Proposal for attaching URL tags to GX graphics: http://www2.waikato.ac.nz/ldo/gx/URLTags.html.
4. SimpleView: http://www2.waikato.ac.nz/ldo/sw/index.html#SimpleView.