|
|
|
|
|
MWJ 1997.12.01 (December 1, 1997)
Top of the Week
This Week's IntrigueFollow-Ups
[ancient discount offer removed] Press Watch
Business News
Macintosh News
Software ShowcaseInternet Software
Macintosh Software
Q&AA Dip Into the RUQ-Sack One way we try to remain responsive to your Macintosh concerns is by answering your questions. Since we reminded readers of this a couple of weeks ago, the questions have been pouring in (sometimes eight or nine in one letter), so we're a bit swamped. Fortunately, some of you have similar questions, and if a few people write in with a single question, it probably means that more people are wondering the same thing. Unfortunately, the first of these common questions is something we thought we covered a few weeks ago, but apparently didn't do so very well. We'll tackle it first. File System BarnaclesQ You've pointed out (MWJ 1997.11.11) that the Mac OS file system is so creaky that Apple doesn't compare the new G3-based machines to Windows NT for anything that requires extensive disk access, because Windows NT will trounce it. Why is this? Couldn't Apple just make the new "HFS+" file system PowerPC-native and overcome the speed problems? A No. We mentioned some of this in MWJ 1997.09.29, but some of you weren't reading at that time, and a concrete example might make the point more strongly anyway. So for the next several paragraphs, close your eyes (not literally, unless someone is reading this to you) and imagine that you are a Web server. Not the hardware or the network connection, but the software that delivers the information over said network connection. Like all Mac OS applications, you are composed of a series of very low-level instructions for the system's microprocessor (let's say you're a PowerPC-native Web server). The microprocessor looks at each instruction, in turn, and executes it, performing tasks like adding numbers or calling the Mac OS to perform tasks or just spinning its wheels waiting for something to happen. Now a Web server, in particular, is a tricky piece of software—it must respond to network requests, but otherwise, it doesn't have to much of anything. When a network http connection requests a given page, the server has to send that information over the network, and that's pretty much the entire purpose of the server, meaning you. Computers are generally designed fairly well—to do your job as a server, you don't have to spend all your time looking at the network connection to see if there's a request waiting for you. Instead, you'll probably tell Open Transport to look out for such connections on its own, and to interrupt you if one of them comes through. A computer has so many pieces of hardware connected to it that it's simply impractical to force the microprocessor to scan all of them, one by one, looking for interesting happenings. If the processor got tied up in a program that selfishly counts to fifty bazillion without bothering to look for interesting happenings, your keyboard and mouse (and network connection) would appear to freeze. That's not suitable. Instead, hardware devices generally connect to something called the computer's "interrupt" line. The signal goes directly to a similarly-named line on the PowerPC chip, and when it's triggered, the PowerPC says, "OK, something's up! I need to pause after the instruction I'm currently executing and go investigate it." The chip finishes the immediate task at hand, saves its state so it can come back later without disturbing the current program, and transfers control to the Mac OS (through a pre-defined mechanism), which then starts asking the hardware devices one by one which one triggered the interrupt. It does this by calling software routines called interrupt handlers, and one is supposed to be associated with each hardware device that can cause an interrupt. The handler looks at its associated hardware to see if it caused the interrupt, and if it did, it handles whatever problem that hardware felt was so important that it required immediate attention. Typical interrupt sources are mouse movement (which moves your cursor on the screen), keyboard input (which goes into the event queue for later processing), network packets (which have to be read before the data vanishes from the wire) and scsi devices signalling that long transfers are done. So far, so good. As a Web server, you ask Open Transport to tell you when an http request arrives, and Open Transport's interrupt handlers in turn call special parts of the Web server code when such requests materialize. You then get control, and your job is to return the information over the network as quickly as possible. This is where the three File Manager historical barnacles on the hull start to cause problems. Not Interrupt SafeFirst, the File Manager (the part of the Mac OS that handles all file-based requests) is not what the programmers call interrupt-safe. When a program is interrupted, the operating system and all interrupt handlers (or routines) have to make sure that they do nothing that would disturb the operation of the program that was interrupted. For example, if you were adding a column of dollar values in memory, and an interrupt handler came along and changed the numbers, upon resumption you'd calculate an inaccurate total. Even if the interrupt handler meant to change the numbers, the total would likely still be inaccurate because you'd have already computed part of it before the changes happened. The rules are pretty clear—interrupt handlers can't do any tasks that would compromise other programs like that in any way. One of the rules for interrupt handlers is to avoid "moving memory" in the Mac OS. You may recall from a very early MacCyclopedia article (MDJ 1996.06.28), the part of the Mac OS that handles the allocation of your ram is called the Memory Manager, and one way it gets the best use out of available ram is to divide it up into blocks, based on what programs like you (the Web server) request. Which part of ram each request gets is irrelevant; what matters is whether the requests are filled or not. However, to fill as many requests as possible, the Memory Manager prefers that you request ram in movable chunks—if it needs to shuffle the blocks around in ram to consolidate gaps to fulfill other requests, it wants to be able to do so. That means the location of a given block of ram might change, and the location of the numbers you're adding up could change with it (the Memory Manager moves the contents of the block when it moves the block, of course). That would also be bad, so blocks of memory can only move at predetermined times, so programs won't have to constantly and paranoiacally check to see if a block they're using has moved. If you've read a file you want to serve into memory, you'd be pretty annoyed if you had to check to see if it had moved between sending each byte, wouldn't you? Of course you would. You expect things to remain stationery unless you give them an opportunity to move, and that's how it works. The cardinal rule of interrupt routines, or any routine called by an interrupt routine, is that it may not move memory. Period, end of discussion, no exceptions. Programs like you depend on this, so any routine that violates the code is buggy by definition. It is never correct to cause memory to move during interrupt time. The vast majority of Mac OS routines, at some point or another, reserve the right to move memory around (by calling the Memory Manager or other Mac OS routines that eventually do so), so most interrupt handlers are extremely limited in what they can do. And this is the first problem the File Manager faces—it's not "interrupt-safe", meaning that it can't be called from within an interrupt routine. Every File Manager routine moves memory—some File Manager routines always do so, and some do so only in certain cases—and that makes them completely unacceptable to call from an interrupt handler. As a Web server, this is an extremely annoying problem for you. You might be trying to handle 200 simultaneous connections, each requesting a different file. Open Transport will happily notify you as each request is made, but you get that notification in a routine called by an interrupt handler, and you can't respond by sending the page at that time. Instead, you're forced to do the program equivalent of tying a string around your finger. When the interrupt is over and you get full control of the computer again, then next time you look to see what needs to be done (that could be a few million instructions from now, but the computer can execute up to one instruction per clock cycle, and 200MHz means 200,000,000 cycles per second), you'll notice the string and send the file. During normal program operation, you can use the File Manager all you want, but you can't touch it from an interrupt routine. Instead of starting to send files as they're requested, you have to queue the requests and send them later. By contrast, the file management code in operating system like unix and Windows NT is interrupt safe, and you could start file transfers immediately if you wanted to do so. That's problem number one. Not MultithreadedThe second problem seems similar but is actually quite different. There's been a lot made of the fact that the Mac OS doesn't have preemptive multitasking. "Multitasking" simply means "performing more than one task at the same time," and that's something of a misnomer on most systems anyway. The vast majority of personal computers have only one microprocessor, and that processor can only execute one instruction at a given time (although modern processors are minimizing this problem more in each generation). No matter how fancy the operating system is, the processor is doing one thing. The controversy is how the processor's time is divided. In preemptive multitasking, the operating system generates interrupts to take control every so often, and when the OS gets control, it may choose to send the processor on to another program rather than letting the program that was interrupted have control back right away. If a given program is doing nothing but twiddling its thumbs, wresting control away through an interrupt is the only way to stop it. The Mac OS, by contrast, has cooperative multitasking, which means that any application has to explicitly give up control of the processor before another application can have it. Interrupt routines still exist, and they can be pretty complicated, but at the end of each interrupt, the interrupted application always gets control back in the Mac OS. If a program is locked up, it stays that way unless you force it to quit through a debugger or another brute-force method like Command-Option-Esc. There's still just one processor, and since each application may get interrupted more frequently, preemptive multitasking can actually slow things down rather than speed them up. However, it always makes your system more responsive—one program can't keep control for 25-30 seconds and not let you do anything about it. It's easier on programmers, too—with cooperative multitasking, programmers have to make sure that they give control back to the OS on a regular basis to avoid making the machine seem unresponsive. With preemptive multitasking, it's reversed—programmers have to mark the areas that can't be interrupted safely instead of the ones that can. That doesn't mean the Mac OS doesn't have any mechanisms like this. It does, through a component called the Thread Manager. The Thread Manager lets any application break itself up into several parts that can execute simultaneously, even preemptively (with the operating system causing interrupts and giving control to other parts, or threads, as required). This can simulate preemptive multitasking within a single application—as a Web server, you're probably already multithreaded. When a new request for a file comes in, you create a new thread to serve that particular file, and destroy the thread when the file is served. That lets the operating system manage the details of your simultaneous connections instead of forcing you to do it yourself. This is where problem number two comes in. Even if the Mac OS had preemptive multitasking, or even if you could call File Manager routines from an interrupt routine, the File Manager is still not multithreaded. When one of your threads asks the File Manager to read (or write) a given file, or to read a directory, or to delete a file, the File Manager cannot perform any other tasks until that request is completed. Ideally, you'd want Open Transport to notify you of a new connection and instantly send that file, but even if you could call the File Manager from the interrupt routine, you won't be able to ask the File Manager to do anything if the interrupted program was using it—or if one of your own threads was reading a file at the time. The Mac OS can handle many threads and many applications at once, but only one request to the File Manager from all of them at any given time. Again, operating systems like unix and Windows NT don't have this problem. They can make file requests at any time, and they can make as many simultaneous requests as they want. In turn, their OS capabilities for scheduling and dividing processor time let several files be served at the same time. You, by contrast, have to read all files from your main application (not any preemptive threads)—when your main application is running, you have full use of the File Manager, for one request at a time. This is why your colleagues, like WebSTAR, try so very hard to read files into memory and leave them there. Files on most Web sites don't change all that often, and if the entire Web site will fit into ram, the server can avoid having to make File Manager requests at all to handle most requests. That avoids most of the trouble. Of course, unix and Windows NT servers can do the same things, sometimes with better results because their entire operating systems were designed for tasks like these. The Mac OS wasn't. There's another problem that kills Web server performance on Mac OS machines, although it's not totally the File Manager's fault. Since so many Web server add-ons (like CGI scripts) are handled by AppleScript or by external applications, the server has to give up control of the machine to other applications more often than it would like. Since it won't get control back until those programs are done, and since those programs have the same File Manager performance limitations outlined here, using any of those add-ons can really make performance suffer—unless they implement the same kind of extensive caching that high-end Mac OS Web servers do. That makes development trickier and therefore raises the prices of the programs. Not PowerPC NativeThe last problem is the one most people focus on, but it's the least of the worries in making a modern and fast File Manager. Most of the existing File Manager is written in hand-tuned 68K assembly code, and many of the drivers that it calls to talk to disk devices are also written in 68K assembly code. This isn't how you get the most speed out of PowerPC systems. So why don't they just make the File Manager native? Doing so is a monumental task that carries risks with it. Anytime an engineer rewrites a working piece of code in another language (the PowerPC versions would likely be in a high-level language for easier maintenance—fixing bugs in the existing File Manager has driven more than one Apple engineer to the brink of insanity), he or she introduces a risk of creating new bugs. The old code might have some side effects that don't seem important, but which programs like Microsoft Word or Adobe Photoshop depended upon for correct operation. Furthermore, the speed increase might not materialize unless the drivers called by the File Manager were also made PowerPC native. Apple could do that for their own drivers, but not for the third-party drivers that abound in the world of Mac peripherals. In fact, the switch between PowerPC and emulated 68K code is so complex and long that, if it happens often (as it would with a native File Manager but emulated drivers), the performance might actually be slower than with an emulated File Manager and emulated drivers. You can probably imagine the press overreaction if Apple released an OS update that performed file tasks more slowly than its predecessor did, no matter what the reason. However, if they chose to make the switch (perhaps at some future point when HFS+ is well-established), companies like FWB and La Cie would clean up by selling driver upgrades to people stuck with older peripherals. As we've shown, though, these changes simply won't eliminate the problems of interrupt safety and multithreading. Those aren't as easy to fix. Applications today assume that the File Manager behaves the way it always has, and they won't react well if those behaviors unexpectedly change. (For example, if there were both preemptive multitasking and a multithreaded File Manager, another program could rename a file you wanted to open between the time you found it and the time you tried to open it, confusing the heck out of you, the Web server.) If these assumptions change, applications that implicitly count on them will start to break, and that's more publicity Apple doesn't need. That's why the company is positioning Rhapsody, based on unix, as a server operating system. If you want to run Web or File or any kind of server on PowerPC hardware, Apple intends to provide the easiest-to-use version of unix available, with Mac OS compatibility, so you can take advantage of the OS designed from the ground-up for multiple simultaneous uses. Note that Mac OS programs running in Rhapsody's "Blue Box" will still face old File Manager limitations—but a "Yellow Box" Web server running alongside the "Blue Box" will get the full advantages of unix while the Mac OS applications in the "Blue Box" continue to work, albeit with no new features like multithreaded file access. That's the plan—old applications work as before, new applications get to use new features. For those wanting high performance servers out of Mac OS hardware, Rhapsody can't arrive fast enough. Where'd My RAM Go?Q As I use Adobe Illustrator 7.0 (French version), I keep the "About This Computer" window open in the Finder, and I have room to see it during Illustrator's operation. To my dismay, the amount of memory used by Illustrator keeps increasing as I use it. I have Illustrator's partition size set to 25MB, but after startup, "About This Computer" says it's using 26.5MB. As I do more complex work, the number grows to 28MB, but when I close the file it drops back to 25MB. Is it really doing this, or is it a bug in the Finder's "About This Computer" display? A Actually, it's the elimination of what several have considered a long-standing bug in the Finder's display of how much RAM any given program is using. You seem to know already that the Mac OS divides your computer's total RAM into partitions, with each application getting its own. This is a throwback to the original Macintosh days, when only one program ran at a time, and each program thought it took over the whole machine. When MultiFinder came out in 1987, the designers compensated for this by making a separate partition for each program. If you gave Microsoft Word 1.0 (available in 1987) a 700K partition, it thought it was running on a Mac with 700K of memory. Each program's use of memory comes from within its own partition. The system's chunk of memory to use, known as the system heap, was moved outside of the application's partition to its own area, equal to all the application partitions. With the system heap gone from each application's "heap," many applications could successfully run on less memory than they needed before—an application that was labeled "Requires 1MB of RAM" might work fine in a 700K partition on a 1MB machine. However, as time went on, Apple gave programmers the ability to use memory outside their application's partition. At first, programs were not allowed to use such memory when they gave control back to the Mac OS to let other programs have some time, and the name temporary memory has stuck, even though applications can now allocate temporary memory and hold it as long as they want. There are some caveats, though—since temporary memory comes out of the same "pool" used to allocate partitions for newly-launched applications, an application that uses too much temporary memory may prevent the system from launching new programs when the space ought to be available. Programmers must make a delicate balance between allocating memory in their own partitions, or using temporary memory for larger uses. Some programs use nothing but their own heap; others (like BBEdit) have very small partitions and allocate most of what they need from temporary memory. Most programs are somewhere in the middle, using temporary memory as necessary when space might be tight within their own partitions. Most of this has been invisible to you, the user, because the "About This Macintosh" or "About This Computer" displays never tracked the use of temporary memory. BBEdit could be running in a 700K partition and using 5MB of temporary memory to hold dozens of open Web pages, but "About This Computer" would only show BBEdit as "using" 700K of RAM. This is one reason Apple actually recommended against wholesale use of temporary memory—if you're trying to take charge of your own RAM usage, the "hidden" temporary memory made it much harder to do so. In Finder 8, Apple has fixed the problem at the source—the "About This Computer" display finally shows you both the application's partition size (which doesn't change while a program is running), and the amount of temporary memory it's using (which can). To avoid confusion, the Finder only shows the total of these two numbers, but by subtracting the partition size assigned to each program, you can see how much temporary memory is in use. Well, usually. If memory is tight, a program won't get the preferred partition size, but it won't get a partition smaller than the "minimum" size shown in each application file's "Get Info" window in the Finder. If 900K of RAM is available and your application's preferred partition size is 1000K, but the minimum size is 700K, you'll get a 900K partition size—give or take some room the system leaves free for the use of system-wide resources like QuickTime. The Finder also subtracts a portion of the application partition known as "stack space," used by the processor for quick access of information (and that's a huge oversimplification), but the stack space is typically not more than 100K or so (it defaults to 24K and that's generally enough for most programs). The Finder 8 number is much more representative of how much RAM a program actually uses. Try comparing the numbers from "About This Computer" with the partition sizes shown in Bob Fronabarger's mind-numbingly useful free utility Memory Mapper 1.4, and you'll see how much temporary memory each application uses. You'll be surprised how many of them go to temporary memory when their own partitions are largely empty—so maybe bumping up their partition sizes didn't have the effect you hoped for after all. Food for thought. DistAsst What?Q An Adobe product (I don't know which one) installs an application named "DistAsstDaemon" on the "Startup Items" folder on your hard drive. I know that "daemon" is the name used by unix people for an application without an interface; I presume that "Dist" is for "distance" and "asst" for "assistance," but can you tell me what this program does? Are there other cases of daemons in our Macintosh world? A In the Macintosh world, "daemons" are called "faceless background applications" and they're all over the place. Any program that doesn't appear in the Application menu is a faceless background application. Examples include File Sharing Extension, QuicKeys Toolbox, Web Quick's application component, and there are hundreds of others. We suspected what "DistAsstDaemon" was, but we asked a staff member to check out a system and look for it anyway. He found it in the System Folder (not the Startup Items folder) and asked Conflict Catcher 4 what it was. CC4's Reference had a description: "This allows users to transparently 'distill' documents in one step by using the Adobe PSPrinter 8.3.1 print driver. Installed by Adobe Acrobat 3.0." The new LaserWriter 8.5.1 driver (see MacCyclopedia, this issue) has a similar feature, but it doesn't use a faceless background application to do the work; it just piggy-backs an Apple event on the printing application and notifies Distiller that there's something to do. This approach won't work for applications that don't support high-level events like Apple events, but Apple apparently thought this was a small problem. Adobe didn't, and they created a faceless background application to handle the job. If you don't use Adobe's version of the PSPrinter driver, you don't need to keep DistAsstDaemon ("Distiller Assistant") active. MacCyclopedia: LaserWriter 8.5.1New Driver Evolves PostScript PrintingApple'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. (For a detailed MacCyclopedia look at printing, albeit from before the QuickDraw GX debacle, check out MDJ Recap #2, available via anonymous ftp in both pdf and setext formats.) 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 DoesWe'll try not to repeat much that was covered in MDJ Recap #2 (or 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 e 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 HistoryWhen 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 RewriteStill, 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 8The 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.1When 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 ChangesThe 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:
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 SizesAdobe 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 QuickDrawAs 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 Recap #2 (or 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 FeaturesThere are more new features in LaserWriter 8.5.1, but they're a bit easier to explain.
LaserWriter FuturesThe 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.
MWJ, The Weekly Journal for Serious Macintosh(TM) Users, is published by GCSF, Incorporated. Copyright © 1997 GCSF, Incorporated. All rights reserved All trademarks are the property of their respective holders and owners. GCSF, Incorporated. P.O. Box 1021 El Reno, OK 73036-1021 (405) 262-1399 Fax: (405) 262-1560 mwj@gcsf.com© 2008, GCSF, Incorporated. All Rights Reserved. |
||||||||||
