Aug 97 Dialog Box
Volume Number: 13
Issue Number: 8
Column Tag: Dialog Box
The Future of MacOS Printing
by MacTech Editorial Staff
An Open Letter To Apple Computer
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
Relevant URLs
1. Apple Press Release:
http://product.info.apple.com/pr/press.releases/1997/q2/970303.pr.rel.p
rint.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.