Output: Printers, RIPs and Fonts
TWO POSTSCRIPT-related issues surfaced at the Conference. The first concerns who will control the future development of the PostScript language. As readers know, we believe that when it comes to software standards of any sort, there are considerable commercial advantages to being in the driver's seat. Ever since Microsoft and Apple announced their font and PDL alliance last year, it has been clear that a showdown with Adobe was in the offing.
The second issue is how to divided the processing load between the workstation and the printer. At one extreme is the old Macintosh Plus/LaserWriter combination: the printer's controller was a smarter computer than the Mac, and nearly all of the processing involved in printing a PostScript page was handled in the printer. The argument in favor of this approach is that the workstation can send the page out and get on with other work. At the other extreme, Sun and Microsoft favor putting all the processing in the workstation and driving a dumb (controllerless) printer. The argument here is that the workstation has computing power to spare, so it makes sense to save money by doing the rasterizing in the workstation and driving the cheapest possible print engine.
This, it seems to us, is a tactical question rather than a strategic one. The advantage clearly used to be with smart printer controllers because the workstations of three years ago didn't have much surplus power. Now, with '040, '486 and Sparc chips, workstations can get a fair amount of background processing done without noticeably slowing the foregound application. So there is a solid rationale for dumb printers.
We think the pendulum will swing again: embedded controllers will become cheap and incredibly fast (due to hardware font rasterizer chips and the like), while applications will be written that need every bit of speed the workstation can deliver. (Think of voice- and video-annotated documents, photorealistic ray-traced graphics and other goodies.) So don't …