From the Vaults: LaserWriter 8.5.1

The following MacCylopedia article from MWJ 1997.12.01 is adapted and reprinted here at the request of David Gelphman, who survived the ordeal described below and went on to help thousands of developers. Any inline links are from December 1997 and may no longer work.

MacCyclopedia: LaserWriter 8.5.1

New Driver Evolves PostScript Printing

Apple’s recent release of the LaserWriter printer driver, version 8.5.1 (MWJ 1997.11.24), isn’t one of those things that provoke dancing in the streets. Printer drivers seem to be mundane and uninteresting sorts of software, and in some operating systems they are. However, in the Mac OS, there is no printing architecture. Apple may talk about the “classic printing architecture” (to distinguish it from the late and lamented “new printing architecture” now gone from QuickDraw GX), but it’s not an architecture. It’s about two pages worth of assembly language code that loads a printer driver and calls it. Printer drivers do everything related to printing on the Macintosh. If you’re a programmer, and you’ve seen a reference to the “Printing Manager” doing something or another, get over it—the Printing Manager does no more than pass your request directly to the printer driver, no matter how high-level or low-level the request is. ([historical cross references omitted])

So whenever you print to a PostScript printer, generate a PostScript job file, or generate a PostScript EPS file by printing, you’re going through the LaserWriter driver. If you use PageMaker 5.0 or later, you’re using the driver even though you may not think you are—PageMaker 5.0 and later use “back doors” in LaserWriter 8 (or its twin, PSPrinter 8) and later to get the printer driver to convert TrueType fonts and QuickDraw pictures into PostScript, which PageMaker then combines with its own PostScript code and sends to your printer through the printer driver’s features—all instead of using compatible, thoroughly-documented ways of printing in the normal way because PageMaker’s engineers got delusions of grandeur. Such is life in the world of Mac OS printing.

For these kinds of reasons, updates to the LaserWriter driver are important to many Mac OS users, so we thought it prudent to spend a little time discussing the recent developments in the word of PostScript processing. Those of you who do not have or never use PostScript printers or PostScript files may want to skip this article, because frankly, it’s not going to have much in it for you other than general background knowledge.

What The LaserWriter Driver Does

We’ll try not to repeat much that was covered in MDJ 1996.10.31, where the “Printing” article first appeared, but in brief: all printer drivers watch applications “draw” a printed page using standard QuickDraw commands, and then transform those commands into the appropriate printer commands to make the image appear on paper. For printers without Adobe Systems’ PostScript page description language, that generally means drawing the image at the printer’s resolution (such as 360 DPI or 720 DPI) and changing the resulting pixels into codes recognized by the printer to put dots on the paper at precise locations. QuickDraw does all the work, so these kinds of printers are often called “QuickDraw printers.”

PostScript printers, on the other hand, have an entire language in them suitable for rendering graphics and text at very high resolutions. If you want to draw the letter “A” on a page in 12-point Helvetica, a QuickDraw printer driver does a lot of work. It knows your printer’s resolution, and we’ll assume that’s 360 DPI, and it knows that the Mac’s default screen resolution is assumed to be 72 DPI (and applications act this way, whether or not your monitor has smaller or larger pixels). The printer has five times as many dots in each inch as the screen does, so the printer driver asks QuickDraw to draw an “A” in 60-point Helvetica type. That’s five times larger than requested, so the result is five times as large an image. The printer driver then sends those pixels to the printer—and since each printer dot is only one-fifth as large as a screen pixel, the result is very high-resolution twelve-point type.

A PostScript printer, simply gets an instruction to use the Helvetica font and to draw an “A.” The PostScript interpreter in the printer takes care of parsing the font format and drawing the letter at the highest possible resolution. That makes the command stream to the printer much smaller, and puts much of the work on the printer’s shoulders instead of on the computer’s. In these days of very fast, inexpensive computers, that’s not the advantage it was a few years ago, but in the 1980s it was a huge performance win, and that’s when PostScript won the professional design market’s love and respect.

Unfortunately, a PostScript printer driver has to do a lot more work than you might think. If you have some bitmap fonts installed, like a 12-point Helvetica bitmap font, then the 60-point version (probably a TrueType font) may not be exactly five times as large. If so, it’ll mess up the spacing of letters on that line, and the driver has to compensate for that by placing every letter as precisely as possible, or by getting PostScript to make a run of text fit within a given width.

Also, certain operations in QuickDraw are next to impossible in PostScript. QuickDraw handles masking out areas where a program doesn’t want to draw with regions, a QuickDraw concept that is basically an arbitrary collection of pixels. Regions are usually rectangular or polygonal (a region describes the contents of every window you can see on your desktop, even the irregular-shaped areas that show through from windows in the background), but they can be as irregular as a square with ten pixels missing at random, or a curve with a notch out of it. There is no easy way to simulate such areas in PostScript, where all paths are mathematically defined, not created by assembling groups of pixels. (If you’re into graphics, you can think of a region as a bitmap, and a PostScript “path” as a vector representation.) For this reason, some of QuickDraw’s region operations typically just don’t work on PostScript printers unless the regions are rectangular, which PostScript can handle. (Actually, it’s because the PostScript printer driver can easily figure out the geometry of a rectangular region, but using non-rectangular regions is a bit more complex.)

LaserWriter History

When we say “PostScript printer driver,” we really mean the LaserWriter driver. For years, the LaserWriter printer driver from Apple was the only printer driver available to talk to PostScript printers; even manufacturers of printers that competed with Apple’s LaserWriter line had to license the driver from Apple. However, they were still at a disadvantage—each new printer that appeared had new features, and Apple had to modify the printer driver to handle them. For example, the LaserWriter Pro 600 and 630 were the first Apple-branded printers to have optional multiple input trays (in addition to the standard 250-sheet cassette, these printers have optional envelope feeders and 500-sheet cassettes). To get these choices available to you, the user, in the “Print” and “Page Setup…” dialog boxes, Apple had to revise the driver fairly extensively (to make version 7.2 in that case). Previous revisions had more useful features come to play, as well.

The LaserWriter driver has always used a set of PostScript procedures to make its work easier—instead of sending the same code to handle the placement of text characters over and over again for each line, the driver defines a PostScript procedure to do the work and sends it to the printer once, invoking it when needed by a short name, like “dv” or “aw” or something equally unintelligible. Since these procedure calls were sent over the network, Apple tried to keep the names short to avoid unnecessary AppleTalk traffic.

In System 6 and before, all of these procedures were contained in one large file called “Laser Prep,” and the LaserWriter driver sent them to every printer when you first printed anything to that printer. The procedures stayed in the printer’s memory, and didn’t need to be downloaded again until the printer was reset. That was a good idea, but for one problem—each revision of the driver, and there were several, required a new version of Laser Prep, and the versions were incompatible with each other. Folks in an office who weren’t all using the same version of Mac OS (probably because in those days, Apple didn’t recommend the same version for all models) found themselves having “Laser Wars” with office mates by continually getting frustrating dialogs that said, “The printer’s version of Laser Prep is different from yours. Do you want to download your version instead?” Declining meant not printing, so in some places Laser Prep meant increased network traffic.

In LaserWriter 7.0, which shipped just before System 7 (in fact, System 7-level printer drivers were the only difference between System 6.0.7 and System 6.0.8, if you remember back that far), Apple bit the bullet and rolled Laser Prep into the driver itself—from then until today, the driver sends the procedures it needs once per job, and not once per printer. Networks are faster today, so we don’t notice as much, but it completely eliminated Laser Wars. There was little more frustrating than starting to print a long document before lunch, only to come back full and find out that your system had been sitting at a “Laser Prep conflict” dialog for the past hour.

Also new in LaserWriter 7 was the “PostScript File” option. This had been present in the driver for some time, but only as a debugging aid for engineers and a troubleshooting mechanism to diagnose problems in the field. In drivers prior to LaserWriter 7, pressing Command-Option-F just after clicking the “Print…” dialog’s “OK” button would save a file in your System Folder containing the PostScript that should have been sent to the printer, with the name “PostScript00” (later files were named “PostScript 01,” and so forth). Pressing Command-Option-K produced a PostScript file with the Laser Prep dictionary included. In the System 7 version, the “Save as File” option became visible to everyone, and the driver called Standard File to ask where you wanted the file (and with what name).

Those were nifty evolutions to a driver that had been, frankly, slow to evolve. It wasn’t until LaserWriter 6 in 1989 that Apple first presented the “Color/Grayscale” option, allowing people to print in color to the color PostScript printers that had been available for a year or two. Before that, any color information “printed” by the application was simply ignored, because the QuickDraw environment created by the printer driver was a classic graphics port—black and white only. For compatibility, that option had to stick around (since Color QuickDraw wasn’t available on all machines), and it’s still there today—applications see a color graphics port if you pick the “Color/Grayscale” option, or a black-and-white one-bit-deep regular graphics port if you pick “Black and White.” (The Black & White option can let some applications print much faster, by not sending 24 bits of color information with every pixel—some of today’s color inkjet printer drivers, like the Epson and StyleWriter drivers, use this same option to give you access to those faster printing speeds if you know you won’t be using color on a page.)

Adobe’s Driver Rewrite

Still, all in all, this was a barely tolerable situation. Apple could revise the driver to support its printers, but didn’t have the engineering resources (or the desire) to do so for other printers. This was a major problem for Adobe, which was licensing PostScript to over a hundred manufacturers, none of whom could get anything but leftovers on the Mac OS, the world’s most popular publishing platform. Adobe decided in the early 1990s that they needed to do something about the situation—after all, the company was already working on Windows drivers. Adobe’s and Microsoft’s mutual antagonism at the time was well-known, and Microsoft’s support for PostScript was lackluster at best. Adobe wanted PostScript to shine on Windows as well as on the Mac, so they took up the task of creating the killer Windows printer driver for themselves—it wasn’t too much of a leap to take on a Macintosh printer driver.

If only they’d known. Windows printer drivers are straightforward because there aren’t many capabilities. Mac OS drivers don’t have many capabilities in theory, but in practice, it’s a lot more complicated. Programmers wanting to do more than was allowed by the Mac’s printing non-architecture have broken out debuggers, examined PostScript files, tried weird ideas and tried them again, and in general hacked the hell out of the LaserWriter driver to make it do things it was never designed to do. Take Aldus SuperPaint, for example. Please. The program decided that it wanted to generate its own PostScript language code to produce its images on paper, which is certainly an option open to all programmers. However, the programmers chose to generate PostScript code using the procedures in Apple’s “Laser Prep” dictionary, which still survived mostly intact into LaserWriter 7 (albeit inside the driver). SuperPaint also embedded that PostScript into every ’pict’ it created, either through the clipboard or through ’pict’ files. When Adobe started writing their driver, they discovered that all images from SuperPaint (even those pasted into other applications) brought the printer to a halt with a PostScript error, because (having started from scratch) Adobe’s driver didn’t use the same procedures or procedure names. Apple had told developers not to do this for years, but as long as it was working, some didn’t listen.

One of Adobe’s major goals was to support PostScript Level 2 in their new driver, since Apple’s LaserWriter driver only generated the older “Level 1” PostScript, not taking advantages of some new imaging features on newer printers. If the printers couldn’t use the features, buyers saw PostScript Level 2 as an expensive and mostly useless add-on, since its features weren’t available to them in the majority of applications. But Level 2 PostScript generally meant more printer features as well, and Adobe didn’t want to get into the Apple trap of rewriting the driver every time a new manufacturer made a new printer. That’s why Adobe used an older PostScript concept called PostScript Printer Description files, or PPD files, in the new driver. PPD files follow an exact specification (the current edition is even available online) and can be parsed by programs such as a printer driver. Each PPD file describes the capabilities and characteristics of a printer, so the parsing program can know what to expect. By using PPD files to describe each printer, Adobe introduced a new requirement that printers be “set up” in the Chooser before they can be fully used, but they gained the advantages of being able to put printer-specific options like extra paper trays, unusual paper sizes, duplexing capabilities (printing on both sides of the paper) and more into the “Print…” and “Page Setup” dialog boxes. Even better, for existing printer owners, the PPD describes exactly how much of each page can be printed on, instead of forcing the assumptions that the imageable area is no larger than that of the original LaserWriter, as Apple’s driver did. In case you forgot to set up your printer, the driver uses a default “Generic PPD,” built into the driver, if no other one has been chosen. The Generic PPD emulates the page sizes and choices of the original LaserWriter, for compatibility.

(There’s still some of this built into the driver at large. You may have noticed in LaserWriter 8 that the default is “US Letter Small”—that’s because it’s the same size as the older driver’s only US Letter page size. “US Letter” gives you the maximum imageable area for your particular printer. This is also why the “larger imageable area” option of the older driver is eliminated—the PPD file gives you exact capabilities, not compromise guesses.)

Adobe also decided to support the Encapsulated PostScript graphics file by adding it as an option in the “Save to File” feature. In Apple’s driver, the only PostScript file you could save was a “job” that, when sent to a PostScript interpreter, would reproduce the pages as if you’d printed them. With Adobe’s driver, you could save a page as an EPS file, and then import that file into a number of graphics and publishing programs. That essentially made any program a creator of high-quality “clip-art” files you could use in desktop publishing work—if you have an image in a program that doesn’t export to a useful file format, you could now use the Adobe driver to save it as an EPS file and import it that way. Even here, though, Adobe ran into compatibility problems. EPS files contain a “preview” image, because they can’t be displayed except by a PostScript interpreter. What you see on screen is really a QuickDraw ’pict’ stored in the resource fork of the eps file. Instead of using a 72 DPI bitmap as the preview, as was the custom, Adobe gave the option to use an “enhanced” preview, which was really a QuickDraw ’pict’ of all the drawing commands used to create the image as issued by the printing application.

For example, if an application printed a square, a circle and a triangle, a standard (bitmap) preview image would contain all the pixels used in those images, and the resulting bitmap wouldn’t scale very well on the screen, although the PostScript in the actual EPS image itself would scale fine on PostScript printers. An “enhanced” preview, however, would contain just the three QuickDraw calls to fill a rectangle (the square), an oval (the circle) and a polygon (the triangle). That preview would scale to any resolution on-screen as well as it would on paper. Yet Adobe’s engineers found, to their amazement, that some applications had come to expect that the preview ’pict’ would only be a bitmap; other applications couldn’t handle a preview image at higher resolutions than 72 DPI and drew imported EPS images at four times their normal size. Still other applications ignored the warning that preview images were optional and refused to import files without a preview, and the driver allowed you to create those. Like we said, printing on the Macintosh has never been easy, as the engineers discovered.

PSPrinter and LaserWriter 8

The work on the driver was started as a kind of side project by David Gelphman, a senior Adobe engineer working in Adobe’s Developer Technical Support group. He was helped along by Richard Blanchard, at that time a contract programmer with Adobe. As the project grew and grew, a full engineering and quality assurance team was assembled, with some of the best PostScript programmers available on the Mac OS platform then or now. Poor Gelphman, however, got so burned out on the project that he eventually took a sabbatical and then left to work for General Magic. Blanchard, on the other hand, formed his own software consulting firm in the East San Francisco Bay area, named “RBI Software Systems, Inc.” David Gelphman now works for RBI, hopefully under much less pressure than before.

There was pressure on the project because Adobe had promised the Level 2-supporting driver to PostScript licensees long before it was ready—the whole project took somewhere in the neighborhood of four years to complete. During that span, Adobe discovered that some of the features of the LaserWriter driver just couldn’t be emulated satisfactorily, so they asked Apple for help. Apple and Adobe formed a partnership for the driver—both companies would work on it, with Adobe doing most of the engineering work but either company having the right to issue revisions. Apple would supply testing, other resources, and the source code to the LaserWriter driver for use in creating the compatible new version. (This is also how Adobe got PrintMonitor compatibility in 1992 when Apple only released the technical details this year.)

The two companies had different needs for the driver—Apple, of course, wanted to use the famous Dogcow(TM) in the “Page Setup” dialog box to show the effect of options like horizontal and vertical flips (known within Apple as “Dogcow tricks”), but as both the Dogcow and its uttering “Moof!™” are registered trademarks of Apple Computer, they weren’t available for Adobe’s version of the driver (which wound up using the stylized lowercase “a” as seen in Adobe Type Manager). Adobe, at one point, wanted to support Hewlett-Packard’s “PJL” printer control language, but Apple didn’t want those confusing options in dialogs for its printers, so Adobe’s version had it by default where it was turned off by default in Apple’s version (although by playing with the ’PRFS’ resource, you could change the defaults, and you can still find nifty things in that resource today, although PJL support is no longer one of them in Apple’s version).

Even the icons were different—Adobe’s being related to the PostScript name, and Apple’s a variant on the classic LaserWriter logo but with two ampersands to show Level 2 support. To facilitate that, the two drivers have different names— “PSPrinter” for Adobe, a variation on the working name “PSWriter” which didn’t pass Adobe’s legal department, and “LaserWriter 8” for Apple—and two creator types (’vgrd’ for LaserWriter 8, based on the Apple project code name “Vanguard,” and ’rbDG’ for Adobe, immortalizing the initials of Richard Blanchard and David Gelphman).

LaserWriter 8 was released in 1992 to a rocky start—whenever you change something as all-powerful as the printer driver, there are going to be problems with some applications, and there certainly were. We’ve discussed in MDJ how the key to getting slightly-incompatible technology accepted is to require it—Open Transport succeeded where QuickDraw GX and PowerTalk did not (see “Lessons from GX Printing,” MDJ 1997.03.03). Apple fudged on this at first, shipping both LaserWriter 7 with System 7.1, but by System 7.5.3, the company had officially dropped the older LaserWriter driver. Not only had compatibility improved, but the company also benefited from printer sales. Every Apple LaserWriter since LaserWriter 8’s release has required the new driver, with no guarantees of compatibility with the old driver. Furthermore, as noted, PageMaker 5 and later require either LaserWriter 8 or PSPrinter, and that didn’t hurt adoption either.

What did hurt adoption was two-pass printing. To generate the best possible PostScript, the new driver spooled all of the application’s drawing commands to disk while counting important parts like colors used and fonts used. Then, knowing what to expect, the driver read the commands back from disk and generated efficient, correctly-formatted PostScript following all of Adobe’s rules. This caused many desktop publishers to scream bloody murder—programs like QuarkXPress generate their own PostScript that can’t be improved by the two-pass model, so these folks saw time and disk space wasted as PostScript was spooled to disk and then sent to the printer. They wanted LaserWriter 7’s one-pass model, which generated suboptimal PostScript but didn’t require any disk space. Ironically, the back-door methods used by PageMaker 5 avoided the problem, but those using other programs had to keep enough disk space free to let the driver spool files that could turn out to be very large. Adobe and Apple promised a fix to this, but it didn’t materialize until the release of LaserWriter 8.4.1 in 1996, and even that didn’t come from Adobe.

As the years went by, Adobe stopped investing as much in the PSPrinter driver, and it’s remained at version 8.3.1 for a few years now. Apple, on the other hand, wanted to continue to enhance the driver in ways that Adobe wouldn’t agree to—for example, Apple wanted to put printer-specific icons in the PPD files so Desktop Printing software could use them in the Finder, but Adobe’s PPD definition explicitly rules out things like resource forks (where Macintosh icons are stored) because they can’t be read on other platforms. PSPrinter and LaserWriter 8 had kept in sync for more than three years, but when these disagreements couldn’t be resolved, Apple exercised its option to develop new versions of the driver on its own (although Adobe gets the source code to any changes if they want it), and, working with RBI Software Systems (home of many former LaserWriter 8 engineers), they created the new “paneled” LaserWriter 8.4.1 driver in 1996. It’s this driver that’s been expanded upon in the new LaserWriter 8.5.1, and the changes are clearly evolutionary but are nonetheless nice touches.

What’s New In LaserWriter 8.5.1

When you first install LaserWriter 8.5.1, you probably won’t notice anything different. That’s because most of the changes are behind the scenes, or aren’t available to you if you’re running Mac OS 8. That’s an unfortunate story—some of the enhancements in LaserWriter 8.5.1 involve Desktop Printing, and the real code for Desktop Printing is built into Finder 8. The “Desktop Printing Extension” in earlier Mac OS versions was what’s known as a “Finder extension”—it was really a plug-in to the Finder that was so specifically tied to a given Finder version that just recompiling the Finder might necessitate recompiling the Finder Extensions. This was a huge headache for Apple, and they gave up on it in Finder 8, rolling all the extensions (which were never externally documented in any case) back into the Finder itself. Unfortunately, this was happening as work on LaserWriter 8.5 was going on, and the parallel development schedules would have meant delaying Mac OS 8, maybe significantly, to get the changes to Desktop Printing into Finder 8. Instead, the changes work with Mac OS 7.6 (which isn’t changing, after all) and will work with Mac OS 8.1 and later. Right now, though, Mac OS 8 users can only read about the desktop printing changes.

Desktop Printing Changes

The normal method of creating a desktop printer—picking an AppleTalk printer in the Chooser—still works as before. However, if you use the new “Desktop Printer Utility” (not available under Mac OS 8), you can create desktop printers without using the Chooser. That means the printers aren’t tied to AppleTalk printers, and that opens up some interesting possibilities. When using the Utility, you can create four new kinds of desktop printers:

  • Virtual Printers have no printer connection whatsoever. This is for people who often print PostScript files to disk—and while you can do this without LaserWriter 8.5.1, remember that just to create a desktop printer otherwise requires the Chooser and a PostScript printer on an AppleTalk network. Those who want access to the PostScript file functionality didn’t have an easy way to get it until the Desktop Printer Utility. Virtual Printers always save PostScript files to disk.
  • Hold Printers are even stranger—they work like regular printers, but they’re always in “hold” mode. The idea is that PowerBook users can switch to a “hold printer” while on an airplane, print what they want, and then later copy the spool files to a connected desktop printer icon for printing when a network and printer are available. (Desktop Printing lets you copy spool files between printers that use the same driver, unlike QuickDraw GX, which let you copy spool files between any printers and view them in SimpleText.) This always struck us as ten times more work than simply clicking the “hold” button in the printer queue, but to each his own.
  • LPR Printers are a wonderful new feature for those who have unix-based tcp/ip networks. PostScript printers generally connect to unix machines through a protocol called “lpr”, based on the unix “line printer” command. Using Desktop Printer Utility, you can create a desktop printer that connects to a PostScript printer via the lpr protocol over tcp/ip. If you have a printer similarly equipped, using tcp/ip can be much faster than AppleTalk over either LocalTalk or Ethernet. These desktop printers use either the printer’s name or it’s ip address to connect to the printer via tcp/ip and lpr.
  • Custom Desktop Printers are the “catch-all” feature intended to solve most other problems. When printing to a custom desktop printer, the LaserWriter 8.5.1 driver creates a PostScript file, and then launches a specified application, handing it the newly-created PostScript file for some kind of post-processing. The most obvious use of this is something like Acrobat Distiller—if you created a Distiller custom printer, then just by printing to that printer, the LaserWriter 8.5.1 driver would automatically make a PostScript file and send it to Distiller, which would then make a PDF file from it, saving you one or two steps. As it turns out, there’s an even better way to make Distilled PDF files in LaserWriter 8.5.1, but the custom desktop printer feature could come in handy.

    (For example, think about things like Infowave’s StyleScript, an Adobe PostScript Level 2 interpreter for color inkjet printers. StyleScript could come with a custom desktop printer tied to a StyleScript application—you’d print with the LaserWriter driver and get a PostScript file that’s then sent to your inkjet printer as it’s rasterized, making one-step printing possible again.)

To handle all this, Apple had to risk compatibility—they made changes to the format of the ’papa’ resource, which has (since the beginning of time) held networking information about the current printer. The old ’papa’ resources were 103 bytes long and contained (packed tight, with extra space as padding at the end) the printer’s name, the printer’s network type (usually “LaserWriter”), and the printer’s zone (usually “*” if you have no zones on your network). That’s all unchanged, but the new resource may have more information starting at the 104th byte—a series of tagged values holding parameters for the currently-chosen desktop printer, such as the IP address for an LPR printer or the zone name for an AppleTalk printer. The tag format, discussed in an Apple Technical Note, actually includes support for infrared/IrDA printers, but that doesn’t seem to be implemented in Desktop Printer Utility at this time, and maybe not in LaserWriter 8, either. The thought of a room full of invisible PostScript rays beaming back and forth to printers is almost too much to bear.

Custom Page Sizes

Adobe and Apple had primitive support for custom page sizes in LaserWriter/PSPrinter 8.1 and later, but Apple removed it from version 8.4 because of difficulties with users and with some printers. It’s now back in LaserWriter 8.5.1, and with improvements. “Custom Page Sizes” is a panel in the “Page Setup” dialog box, and from there, you can choose existing custom page sizes, edit them, or create your own.

Some high-end PostScript devices have the ability to use roll-fed media, meaning that the substance to be imaged upon (paper or film, for example) comes in a roll. With these devices, you can typically specify any kind of page size you want, compared with smaller inkjet or laser printers that require cut sheets of only a few given sizes. Even some cut-sheet printers, however, can handle varying paper sizes, usually through special machinery and special adjustable input trays. If you have one of these devices, you need a way to tell the printer exactly how big the “page” really is, because the actual “paper” may go on for hundreds of yards. That’s what custom page sizes are for.

Even though the new interface is improved, it’s still slightly confusing. You enter the name of your custom page size and its width and height in the units of your choice (inches or centimeters), and that’s pretty straightforward. Then you specify top, left, right and bottom margins, which doesn’t seem so hard. But there are also things called “width offset” and “height offset,” and it’s not clear what those are if margins are what they ought to be. Here’s the scoop.

PostScript’s handling of custom page sizes requires all of these items, so the LaserWriter 8.5.1 driver has to give you a way to enter them. Let’s suppose you’re trying to print a 3″ X 5″ card on a device that supports custom page sizes. For width, you’ll enter three inches, and for height you’ll enter five inches. The “offset” values specify how far over and down the image should be moved on the media itself. If you want your card to print two inches from the left edge of the media and three inches from the top, you’ll enter values of 2″ and 3″ for width offset and height offset, respectively. If you leave the offset values at zero, the image will print in the upper left corner of the printer’s imageable area.

If that’s hard to picture, imagine that your device has a special adjustable tray that takes US Letter size paper as a maximum paper size. Therefore, your printer can’t use any page larger than US Letter paper, which is 8.5″ wide by 11″ long—but suppose the adjustable paper tray lets you move all four sides of the paper carrier, so you can adjust the left, top, right and bottom sides. If you want to print 3″ X 5″ cards, you can leave two sides in their maximum positions and move the other two sides, or you can move all four sides to position the cards in the middle of the tray (you might want to do this so that the entire cards can be printed upon—most printers don’t print edge to edge, so leaving the cards at the edge might restrict how much ink you could put on them). The width offset is the amount you move the left edge of the tray in, and the height offset is the amount you move the top edge down. If you don’t move either of those edges, you set the offsets to zero. It’s obscure, but you can see that PostScript might want to give you the choice of image placement, and this is how it does it.

The margins are there to prevent you from doing edge-to-edge printing if you so choose—by setting margin values other than zero, the printer must create a margin inside the custom paper size of the width you specify on each side, refusing to print in that area. (If the application tries to draw in that area, the driver or device is required to ignore it, or “clip” out any pixels that extend into the margins.)

Most of you will never see this panel in the “Page Setup” dialog, because LaserWriter 8.5.1 only presents it if the current printer’s PPD file indicates that the printer supports custom page sizes. Since most printers don’t, you’ll rarely get the option to deal with it (although we must nostalgically point out that QuickDraw GX let you create your own custom paper sizes and types for all printers—it just printed them through the regular paper mechanisms and didn’t actually send the PostScript code to make high-end devices trim roll-fed media to the right size). However, if you get a document from someone who used a custom page size on his printer, it will show up as the “Other” paper size in the “Page Setup” dialog—if you change to a different paper size and click “OK,” you’ll lose the ability to go back to the custom page size. Also note that if you have an appropriate printer and define custom page sizes, they’re shared among all the printers you have that support custom page sizes—in other words, the page sizes you define are stored in the driver’s preferences file, not in the desktop printer file.

Support for More of QuickDraw

As discussed earlier, there are some imaging operations in QuickDraw that the LaserWriter driver has mostly ignored to date because they’re very hard to translate to PostScript. David Gelphman is apparently well-rested now, because he and his RBI colleagues have managed to implement some of these features in LaserWriter 8.5.1. This is a bit technical, and those who don’t remember our QuickDraw examinations in MDJ 1996.10.24 may find this hard to follow, but we’ll give it a shot.

One of the things QuickDraw uses regions for is clipping, or letting programmers specify which areas of an image are affected by drawing commands. You can draw a red square that’s ten inches square, but if you draw it into a graphics ports whose clipping region is a circle with a one-inch diameter, all you’re going to see is a one-inch diameter red circle. QuickDraw “clips out” any drawing to areas that aren’t included in the clipping region. In fact, each graphics port has two clipping regions—the “clip region” and the “visible region”—and drawing only takes place in places they both include. (This is for help with window manipulations—the system maintains the visible region to mask out portions of windows that are currently obscured, and the application gets the clip region to help with its own drawing.)

Because regions are seriously difficult to emulate in PostScript, the LaserWriter driver has always mostly ignored them—instead of using the clipping region itself, the LaserWriter driver clips PostScript drawing to the smallest rectangle that surrounds the clipping region (in our example, that would be a one-inch square). All clipping was done through rectangles, making drawing some complex images harder than it might have been.

In truth, though, the techniques for changing regions into PostScript paths have become more refined over the years—in fact, Apple solved the problem for QuickDraw GX printing. They had to, because clipping regions from non-GX applications were internally changed into QuickDraw GX paths, which are very similar to PostScript paths, and folks printing to “QuickDraw” printers expected non-rectangular clipping regions to work because, without PostScript’s limitation, they always have. The folks at RBI and Apple have taken similar approaches to solving the clipping problem with LaserWriter 8.5.1, but there’s a catch—most clipping is done through a graphics port’s clip region, as we said, and that region is still treated the old way (as its boundary rectangle). So many applications over the years have come to “expect” clipping not to work on PostScript printers that some of them now rely on it. For example, they’ll use LaserWriter driver features to print rotated text, but they’ll also rotate the text themselves as a bitmap for non-PostScript printers, and use clipping region tricks to make it draw on QuickDraw printers but get clipped out on PostScript printers. Until Apple can get older applications to stop doing that—always a tricky problem—the main clipping features are mostly unenhanced.

What has been improved is a specific use of clipping. The monster QuickDraw routine for handling bitmaps of all sizes and shapes is “CopyBits,” and CopyBits takes a clipping region of its own (called a “mask” region, which should be familiar to Photoshop users). That region has always been completely ignored when printing through the LaserWriter driver—until now. Version 8.5.1 respects this region, giving application programmers one more way to get cool images onto the PostScript page. Some programmers have stayed away from the mask region altogether, since it’s not good to make images that print to inkjet printers but not to PostScript printers; this may give them the ability to start using the feature in all kinds of applications.

The driver uses mathematical techniques to build a PostScript path—a mathematical definition of areas—that matches the mask region at the printer’s resolution. The problem is that older printers may not like it. PostScript Level 1 printers have an absolute limit of 1500 segments in any given path; if a region is particularly complicated, the driver won’t be able to simulate it in less than 1500 segments and the mask region will be ignored as it was before. Level 2 printers have no hard-coded limit, but path sizes are limited to available memory and, again, very complex paths encountered when the printer is low on memory could cause the feature to fail.

PostScript Level 3, however, has a new imaging extension called a “deep mask” operator. Photoshop users know that if you copy an image through a mask, you can do more than just set each pixel in the mask to black or white to allow or deny the image to come through at that point. You can set the mask pixels to some amount of gray to let some portion of the image through. If you have an RGB mask, you can let certain portions of the image’s red, blue and green components through, all measured separately. That gives you lots of control over images. PostScript Level 3 includes an operator to perform these kinds of “deep mask” operations (so named because the mask can be “deeper” than one bit per pixel)—a programmer provides the PostScript interpreter with a bitmap image in full color to use as a mask, and PostScript does the right thing. On Level 3 printers, LaserWriter 8.5.1 uses this feature to perform the masking—the mask region is drawn as a bitmap and handed to the printer. This never runs out of memory and has no limits, so it will always work on Level 3 devices.

The new driver uses these same techniques in one other place. QuickDraw supports a transparent transfer mode—when drawing a source image onto a destination, any pixels in the source that are the same as QuickDraw’s currently-set background color aren’t copied to the destination, letting the destination image “poke through” in those places. The LaserWriter driver has always ignored this, because it had no easy way to build (essentially) a masking region to avoid copying the parts with the background color. Now that the region-to-path code is in place for Level 1 and Level 2 printers, and the deep masking operator is present in Level 3 printers, the driver can do this as well, and now it does. The only catch is in background colors—if you’re drawing an image with a palette of 256 colors, and twelve of those colors are identical to the background color, QuickDraw will make all twelve of them transparent. The LaserWriter driver will only make the first of them transparent, leaving eleven colors that show up transparent on screen but not on paper. If you use this feature, as an artist or as a programmer, try to use only one transparent color in each palette for best results.

Miscellaneous Features

There are more new features in LaserWriter 8.5.1, but they’re a bit easier to explain.

  • ColorSync 2.1 support is new in this version, with support added for local names of color-matching profiles, support for the programmer-level way of turning color matching on and off (regardless of what you pick in the “Print…” dialog) and the ability for an application to figure out what color-matching profile you’ve selected. The driver also lets you override the system profile’s intentions for color matching, allowing you to choose between the four ColorSync/ICC models (perceptual, relative colorimetric, saturation, and absolute colorimetric). The “automatic” option in this menu uses saturation intent on text and line objects but perceptual intent on bitmaps and images. We covered Color & ColorSync in MDJ 1997.03.20.
  • Media handling is slightly improved as well. If a printer’s PPD asserts that it supports multiple media types (that means selecting different input media for reasons other than its size—maybe paper vs. transparencies or letterhead vs. scratch paper), then the supported media types are included in the “Paper” pop-up menu in the “Print…” dialog box.
  • First pages arrive faster in LaserWriter 8.5.1 thanks to a change in the PostScript creation. In earlier versions of the driver, all fonts used in a document were downloaded before the first page was sent to the printer, insuring that pages could be reordered in the PostScript stream without problems. It turns out that no one does this, so no one cares. Now the driver sends fonts before the first page where they’re actually used. If your documents have fonts that don’t show up on page one, you’ll typically see the first page come out of the printer a little faster than before. Overall document printing times haven’t changed with this, of course, but if you’re standing by the printer, you want to see the first page.
  • Collation is supposed to be better as well, but we can’t prove it. Printing multiple copies works differently on QuickDraw printers than it does on PostScript printers. Normally an application looks at the number of copies you entered in the “Print…” dialog box and prints the document that many times. PostScript printers, however, can easily turn out multiple copies of the same page—once a page is ready to print, it’s a trivial matter to say “print it a few times.” So the LaserWriter driver has always lied to applications and said you wanted one copy of the document—if you in fact wanted more, it just repeated each page as many times as you wanted. That made multiple copies much faster, but left them uncollated. Some printers have collation features, meaning they can separate the multiple copies just like high-end photocopiers. If they can, their PPD files say so, and the “Printer Specific” panel of the driver has always had a “Collate” option for those devices

    Now, according to Apple, you’ll get a “Collate” checkbox in the “General” panel of the driver if no collation option is present in the PPD file. If you check it, the LaserWriter driver apparently stops lying about the number of copies and, just like for QuickDraw printers, lets the application print the document as many times as you want instead of letting the printer do it the easy way. It’s going to be slower, but the pages will come out in the right order

    There are two problems here. First, Apple’s documentation says the driver prints the document multiple times, but there’s really no way for it to do that—especially if you’re in one-pass mode, where no spool file is written to disk. We suspect that the driver just lets applications do the real work, and that may mess up some programs. Like most things in printing, the real number of copies has been hidden away by the driver, but some applications go and find it for their own purposes (like counting how many pages you’ve printed); this change may break such programs

    The second problem is that, as far as our staff can tell, it just doesn’t work. Nothing we did could make the “Collate” checkbox appear in any panel of the “Page Setup” or “Print…” dialog boxes. We walked a staff member through trying it with a program that uses the new LaserWriter 8.4 and later “extensible print record,” in case the driver needed a place to store more information, but that didn’t do it; neither did hacking up a PPD file to include a “no collation” option in case that’s what Apple meant. We’ve seen reports that collation doesn’t work until Mac OS 8.1, but for the life of us, we can’t think of any reason why. It shouldn’t depend on anything in the Finder or other parts of system software. Either the documentation is wrong and it doesn’t work, or a bug is preventing our staff from seeing it on the equipment they have. That’s why we don’t know exactly how it works—for us, it doesn’t.

  • Print to PDF is a new option in the “Save as File” panel of LaserWriter 8.5.1. Acrobat Distiller seems to be the main consumer of PostScript files on most systems these days, and rather than force you to create a separate desktop printer for it (even though you can now, except under Mac OS 8), Apple and RBI built PDF support into the driver itself. When you pick “Acrobat PDF” as the file format, you get a panel letting you set some Acrobat Distiller parameters. Upon printing, you’re prompted for the eventual location of the PDF file. The LaserWriter driver prints to a PostScript file in the Temporary Items folder (so you’ll need to have available disk space on your startup volume) and then launches Acrobat Distiller, giving it the PostScript file as input and telling it where to put the results. When Distiller is done, the driver deletes the temporary PostScript file

    As mentioned in this issue’s Q&A, this requires the printing application to support high-level events, or else the driver can’t send an Apple event to Acrobat Distiller. Adobe worked around this by creating a background-only application to handle such communication; Apple instead disables foreground printing if the application doesn’t support high-level events. Using background printing forces the activation of Desktop PrintMonitor, which is high-level event aware, and it can communicate with Acrobat without difficulty. Most applications are high-level event aware today, but if you find one that’s not, you’ll need space on your boot volume for both the spool file and the resulting PostScript file—or you’ll need to use ResEdit or Resorcerer to edit the ’prfs’ resource in a copy of your drive and change field 7, the one that says “Always use 2 pass for print to file,” to “off.” That might work

    If you just want a quick Acrobat file, the best choice is probably still PDFWriter. Remember, however, that while PDFWriter can convert anything coming from QuickDraw, it can’t handle anything that has PostScript sent by an application or created by an external source, like an embedded EPS file. For those tasks, Distiller is best, and now you can get to it directly from the “Print…” dialog box. (Provided, of course, that you have Adobe Acrobat Distiller installed on your system. If you don’t, the “Acrobat PDF” option is disabled.)

LaserWriter Futures

The LaserWriter driver is one of those pieces of software that’s caught in the middle of politics and technology. The modern code and design, PPD-driven and almost entirely written in C (as opposed to the older driver’s ten-year-old mix of assembly language, Pascal and C) has led to significant advances for users and developers in a relatively short timeframe, compared to the difficulties formerly encountered in changing the old driver for nearly any reason. However, it still can’t make up for the fact that there is no printing architecture on the Macintosh, and the one hope for solving that (QuickDraw GX Printing) has been abandoned by Apple.

There are also rumors that Apple is de-emphasizing, if not outright ditching, printer manufacturing altogether. If that happens, Apple will have no bottom-line related reason to continue to invest in LaserWriter driver revisions; right now that work is apparently being funded by the group that works on printers. Adobe could take the revisions and run with them, but it’s not certain they’d want to do so either, since Adobe and Apple have different needs and different reasons for wanting the driver in the Mac OS world. And it goes without saying that Apple is cutting every engineering project possible—although removing resources assigned to the LaserWriter driver might create a stir in their “core market” of “content creators” and therefore be politically unwise.

If Adobe were to extend the driver, logical choices for future expansion include support for the PostScript-like “PrintGear” architecture, designed to create low-cost printers without full-blown PostScript, and also for the high-end “Supra” or “PostScript Extreme” architecture, which divides parts of PostScript jobs among several interpreters to speed processing. More detailed support for PostScript Level 3 is also an option, as are more GX-like features such as more support for clipping and masking, better GX (and OpenType) font support, and so on.

It’s just not clear that anyone is interested in making these adjustments. LaserWriter 8.5.1 was originally supposed to be released last summer (MDJ 1997.06.02), and it’s just getting out the door in November. If Apple keeps making PostScript printers, the future of LaserWriter 8 is probably safe for a few years in its current evolutionary form. If they stop, things are much less clear—so if you have problems with the current driver, report them to Apple while you can. Better to be safe than sorry.