philip@pescadero.Stanford.EDU (Philip Machanick) (07/06/90)
Maybe a brief description of how printing is programmed on the Mac would help Wolfgang understand the Mac approach better. I'll give a sketchy outline, because I haven't looked at this stuff for a while. Comments, additions, corrections welcome. In essence a Mac printer driver is a QuickDraw emulator. To print, you conceptually draw to a "window" belonging to the printing manager, rather than to the screen. The currently selected driver intercepts the QuickDraw calls, and converts them to appropriate output for the printer. For the ImageWriter, the bitmap is generated and downloaded; for a PostScript printer, PostScript calls are substituted (the file LaserPrep contains procedure definitions which are downloaded once, after the printer is booted). The consequence of all this is the programmer only needs to know one imaging model: QuickDraw. In addition, with suitable design, code for initially generating screen data, handling update events, redrawing areas which are uncovered during scrolling, and for printing can be reused. MacApp, Apple's class library/application framework, for example, does a lot of this for the programmer. An application can also ask the printer driver for current settings, such as page size. This is essential in a WYSIWYG environment, where the on-screen page dimensions should reflect the printed version. QuickDraw includes an escape mode for storing information not specifically intended to be printed: PICT comments. This mechanism is used for grouping objects in some applications, and can be used to embed printer-specific information. In this way, PostScript code can be attached to a PICT object. A PostScript driver recognizes PostScript comments, and sends them to the printer, instead of translating the QuickDraw they are attached to. All of this is not quite as easy as it sounds. The Mac printer driver architecture is due for a major overhall in some respects. Nonetheless, I think the concept is good. Once you've got printing working, you should have no problems with any driver using the standard architecture. Of course, if you assume PostScript is _the_ standard, Display PostScript would be an even better solution (presumably it's really easy to program printing on a NeXT?). So how do applications talk to a printer driver on Windows? Philip Machanick philip@pescadero.stanford.edu