gelphman@adobe.COM (David Gelphman) (08/24/90)
As was previously announced here, Adobe is working on a new PostScript printer driver for the Macintosh. There are some issues which I believe are of interest to application programmers for the Mac and I'm very interested in feedback from you all. a) The new driver will give access to a number of new features, especially those available in PostScript printers such as paper trays, duplexing, and so on. Many applications today save the print record with the document so that when the user prints the document again they get the same result. This is a big convenience to users and will be even more important as users are able to tag their documents with even more printing features. Unfortunately the existing architecture for the print record only allows a fixed length to be returned to the application. We'd like to add the ability for an application to retrieve the extended print record when available so that it can be stored with the document. What other capabilities would application writers like along these lines? Are people interested in these extended print records? b) LASERPREP crimes: We've already encountered a couple of applications which expect specific LaserPrep procedures to be available when they execute custom PostScript using the PostScriptBegin/End PICComments. Apple has stated many times that this is a major print crime. We are writing our driver from scratch and working very hard to optimize things so that we generate PostScript language code which is efficient to execute and is portable to all printers. The strategies employed to convert QD into PostScript language code is significantly different from Apple's existing driver in many ways. The existing LaserPrep procedures do NOT fit into the way our driver works. Please let me know how you are using LaserPrep procedures if you are and let's figure out how to solve these problems. We want to maintain compatibility but applications which rely on LaserPrep in this way are trouble for anyone trying to improve the state of PostScript printing on the Macintosh. So: how are you using LaserPrep procedures and isn't there a better (more compatible) way to get the job done. c) Apple has published the availability of PICComment #196 (PostScriptBeginNoSave) which can be used to send down PostScript code which remains resident (and change the graphics state) after the accompanying PostScriptEnd comment. (normally code executed between PostScriptBegin/End is isolated from the rest of execution). I'm very interested in how people use this comment. The problem with this comment is that it can cause the state of the PostScript interpreter to differ from the state that the driver thinks the interpreter is in. This may not be a problem in some cases; however, there are a lot of ways this can cause problems. By the way, using Apple's pse,psb procedures to hack around the restore normally done by PostScriptEnd is equivalent to using this comment. What PICComments can the new driver define and process which will allow you to avoid these hacks and instead let you get the job done and at the same time let the driver know the state of the printer? d) One of the exciting features of the new driver is the ability to save Encapsulated PostScript files from any application. This will allow Mac users to take a page in any application program and create an illustration which can be imported into applications on any platform which can accept EPS files. Part of the process of creating EPS files is computing the bounding box of the text and graphics on the page. While it is possible to have EPS files which give the bounding box of the page they are to be printed on, it is better to have a true bounding box which only encloses the marks actually made on the page. Applications which generate custom PostScript code using PostScriptBegin/End make it difficult to generate correct bounding boxes since the PostScript code can draw anywhere. In principle the clip in effect at the time of PostScriptBegin limits the size of the graphics drawn using PostScript code (assuming the PostScript code doesn't do 'initclip' or 'initgraphics' or other similar horrible things). At this point we are planning on updating the bounding box we calculate by the bbox of the clip in this manner. This means that an application can help provide an accurate bounding box by clipping to the size of the graphics before PostScriptBegin is executed. Note to those using custom PostScript via these PICComments. You should be following the guidelines for conforming PostScript documents and EPS files which require that you NOT execute things like: initclip, initgraphics, initmatrix letter legal If you need a copy of the EPS guidelines then let me know and I'll be happy to send it to you. It is also available from our file server. To use the server send a message to 'ps-file-server@adobe.com' and make the subject line 'help'. That's it for now. I'm looking forward to hearing from you. David Gelphman Adobe Systems Incorporated