Supporting Level 2 Functionality Adobe Developer Support Technical Note #5110 31 March 1992 Adobe Systems Incorporated Adobe Developer Technologies 345 Park Avenue San Jose, CA 95110 http://partners.adobe.com/ PN LPS5110
Copyright 1991 1992 by Adobe Systems Incorporated. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written consent of the publisher. Any software referred to herein is furnished under license and may only be used or copied in accordance with the terms of such license. PostScript, the PostScript logo, Display PostScript, Adobe, and the Adobe logo are trademarks of Adobe Systems Incorporated which may be registered in certain jurisdictions. AppleTalk is a registered trademark of Apple Computer, Inc. Other brand or product names are the trademarks or registered trademarks of their respective holders. This publication and the information herein is furnished AS IS, is subject to change without notice, and should not be construed as a commitment by Adobe Systems Incorporated. Adobe Systems Incorporated assumes no responsibility or liability for any errors or inaccuracies, makes no warranty of any kind (express, implied or statutory) with respect to this publication, and expressly disclaims any and all warranties of merchantability, fitness for particular purposes and noninfringement of third party rights.
Contents Supporting Level 2 Functionality 5 1 Introduction 5 2 Deciding Which Features to Support 5 Level 1 Support 6 Level 1/Level 2 PostScript 7 Level 1/Level 2 Binary Support 9 Advanced PostScript Level 2 Support 10 3 Deciding the Type of Code to Output 12 Target Printer Issues 12 Save-to-Disk Issues 13 Spooler Issues 13 Typical Scenarios 13 Appendix: Changes Since Earlier Versions 15 Index 17 iii
iv Contents (31 Mar 92)
Supporting Level 2 Functionality 1 Introduction With the advent of PostScript Level 2, powerful new printer features have become available for use by applications. This raises an obvious question for an engineer who is writing or upgrading the PostScript printer driver for an application: How can the driver provide language-level compatibility in an environment in which both Level 1 and Level 2 printers co-exist? After all, the strongest feature of the PostScript language is its device independence. As in the past, there should be only one PostScript language driver for all PostScript printers. This paper is a starting point. It examines strategies for providing support for both Level 1 and Level 2 in the same driver. It emphasizes a step-by-step approach starting with a basic driver and adding functionality. We suggest that you add features to the driver only if they are important to the application. New Level 2 language features that can be emulated in Level 1 are examined first and then features specific to Level 2 are discussed. Because printers have differing capabilities, the type of output to generate differs depending on the output scenario. Whether the output is going directly to the target printer, is saved to disk, or is sent to a spooler will affect its format. 2 Deciding Which Features to Support There are many Level 2 features and extensions to Level 1 that can be part of a new or revised driver. It can be difficult to decide which features to support and how to provide backwards compatibility. This section discusses a structured approach for improving an already existing driver and adding new functionality. This also applies to new drivers. It is important to build a driver that generates quality PostScript language code and then improve the functionality in logical steps. 5
2.1 Level 1 Support Most of the PostScript printer drivers in existence support the base level of functionality, PostScript Level 1. Drivers undergoing a rewrite or revision to add Level 2 support might need to be re-examined. A solid basic driver is the key to adding functionality properly. This is also true if a driver is being written for the first time. Fonts Fonts and their proper usage are important in the creation of a successful driver. Layout of text and font usage optimization is discussed in PostScript Language Program Design, Chapter 7, The Mechanics of Setting Text, and in Technical Note #5041, Simple Text Setting Calculations for PostScript Language Drivers. An overview of the issues involved in using downloadable fonts with Post- Script interpreters is given in Technical Note #5040, Supporting Downloadable PostScript Fonts. Related issues concerning memory allocation are presented in PostScript Language Program Design, Chapter 13, Memory and File Resource Management. Optimization How you optimize your driver will largely depend on where your driver can stand improvement. Optimization of an existing driver is dealt with in Technical Note #5042, PostScript Printer Driver Optimization Case Study. Other optimizing techniques are discussed in Technical Note #5126, PostScript Language Code Optimization: Rectangles. See Technical Note #5120, Timing Techniques for a discussion on timing the execution speed of the output from your driver. 6 Supporting Level 2 Functionality (31 Mar 92)
Printer Specific Features Printer specific features such as using multiple paper trays, stapling, duplex, binding, and so forth, are useful options that should be available to the user of an application. Technical Note #5117, Supporting Device Features, discusses how to determine and activate the features available on the target printer. The PostScript Printer Description Files Specification, Version 4.0 describes PPD files that detail the device specific features available on each printer. In general, PostScript Level 1 language files offer the benefit of being printable on any PostScript device and, if written correctly, can be completely portable. The major disadvantage to using strictly Level 1 code is the inability to use newer PostScript language features that optimize performance for specific types of pages. 2.2 Level 1/Level 2 PostScript After ensuring a robust basic driver, a first step in adding functionality is to consider adding support for features of Level 2 that can also be used under Level 1. Patterns, forms, rectangles, automatic stroke adjustment, calibrated RGB, indexed color spaces (color lookup tables), accurate halftone screens, and resources can all be satisfactorily emulated. The disadvantage to using emulations is that they are rarely as efficient as their Level 2 counterparts. If the target printer is a Level 1 printer, the emulations are included in the PostScript language code at the time it is sent to the printer. If the target printer is a Level 2 printer, only the PostScript language code is sent to the printer. If the language level of the target printer is unknown or the file is being saved to disk, the driver should output configurable procset code. Note Some veneer definitions might need to be included as well. Veneer definitions allow for consistent syntax when using Level 2 features under both Level 1 and Level 2. Configurable procset code defines procedures using the Level 2 features, if available, and installs the Level 1 emulations if they are not. Whether or not a particular procedure refers to the Level 2 operator or its Level 1 emulation should be transparent to the driver; this results in a consistent interface and simpler PostScript drawing code. Appendix D, Compatibility Strategies, in the PostScript Language Reference Manual, Second Edition, outlines how to create an emulation and define configurable code. 2 Deciding Which Features to Support 7
The following is a list of emulations written by Adobe Systems Developer Support that can be added easily to a base driver. Refer to the individual technical papers for in-depth information about the emulation and its usage. Patterns Patterns allow the painting of a shape with a replicated pattern cell, much in the same way that a color is used. Both colored and uncolored patterns are available, along with different tiling types and stepping values that can be combined for a variety of effects. More information about the use of patterns under Level 2 can be found in section 4.9, Patterns, of the PostScript Language Reference Manual, Second Edition. A pattern emulation and performance analysis are presented in Technical Note #5112, Emulation of the makepattern and setpattern Operators. Forms Forms are self-contained descriptions of graphical objects that are painted multiple times on each of several pages or several times at different locations on a single page. A good example of a form is a name badge or a 1040 tax form. More information about using forms under Level 2 can be found in section 4.7, Forms, of the PostScript Language Reference Manual, Second Edition. A discussion of when to use forms, a forms emulation, and a performance analysis are presented in Technical Note #5113, Emulation of the execform Operator. Rectangles Rectangles are used frequently in document, and a set of operators has been created to paint rectangles more quickly and conveniently. More information about using rectangles under Level 2 can be found in section 4.6.5, Rectangles, in the PostScript Language Reference Manual, Second Edition, and a sample emulation of rectangle operators can be found in Appendix D, Compatibility Techniques, in the same manual. Automatic Stroke Adjustment Automatic stroke adjustment produces strokes of uniform thickness to compensate for uneven line widths due to rasterization effects. This can be especially useful for applications that produce graphics. More information about activating automatic stroke adjustment under Level 2 can be found in section 6.5.2, Automatic Stroke Adjustment, in the PostScript Language Reference Manual, Second Edition. A setstrokeadjust emulation for Level 1 and a performance analysis can be found in Technical Note #5111, Emulation of the setstrokeadjust Operator. 8 Supporting Level 2 Functionality (31 Mar 92)
Choosing to use a Level 1/Level 2 support strategy can result in additional features being available for use on Level 1 printers and faster performance of print jobs on Level 2 printers. 2.3 Level 1/Level 2 Binary Support One of the main performance factors in some printer communications environments is simply transmitting the PostScript language file to the printer. A significant reduction in transmission time can occur if binary data is used when downloading fonts (especially composite fonts) and image data (including images used in forms and patterns). Slower transmission channels like serial channels can obtain good performance gains from a driver that supports binary data. A side benefit to binary data is reduced storage costs for PostScript language files on the host system or spooler. The major disadvantage to representing data as binary is that it is inherently less portable. Using binary data on a transparent channel (for example, AppleTalk ) is relatively simple. Binary support becomes more difficult on channels where certain 8-bit values can interfere with the communications protocol (for example, parallel and serial). One strategy for downloading font and image data involves converting the binary data to hex to avoid conflicts with the communications protocol. This has the disadvantage of expanding the binary data by a factor of two, increasing the file size and transmission time. This strategy works on all PostScript Level 1 and Level 2 devices, but does not make full use of the binary capabilities of some printers. There are a variety of printers (some Level 1 and all Level 2) that have the ability to use the Adobe Binary Communications Protocol. This protocol defines an escape character (ASCII SOH) to quote binary values that would interfere with normal communications. For more information about how to activate and use the binary communications protocol, see Technical Note #5081, Adobe Binary Communications Protocol. Supporting binary data in the transmission of fonts and images is an easy modification to make to a driver and can result in an immediate performance improvement. 2 Deciding Which Features to Support 9
2.4 Advanced PostScript Level 2 Support Many of the new features incorporated into Level 2 are extensions created for PostScript Level 1. Your driver may already support some Level 2 features. Extensions to PostScript Level 1 include support for CMYK color, the Display PostScript system, and composite fonts. These extensions are now part of the base functionality for Level 2, that is, they are found in all Level 2 printers. In this section we discuss features of Level 2 that cannot be emulated satisfactorily in Level 1. In these cases, the driver must determine whether to output a Level 1 or a Level 2 data stream at print time, rather than outputting a data stream that is compatible with a self-configuring Level 1/Level 2 emulation as discussed in section 2.2, Level 1/Level 2 PostScript. Features that cannot be emulated satisfactorily include user paths, ASCII base-85 representations of binary data, data compression and other data filters, binary token protocol, CIE color spaces, and device independent color. Because these features cannot be used on Level 1 printers, the driver must take care when generating output: It must either restrict user choices or substitute an equivalent when the target printer is Level 1. For example, CIE color space values can be mapped to RGB device space values before the job is sent to a Level 1 printer and the setrgbcolor operator can be used instead of setcolor. The following include technical papers written by Adobe Systems Developer Support that discuss when and how to use these more advanced features. User Paths User paths are a special way of defining a path so that it can be cached and drawn more quickly. This feature delivers performance improvements of approximately 10% to 250% depending on the printing situation. Information about using user paths under Level 2 can be found in section 4.6, User Paths, of the PostScript Language Reference Manual, Second Edition. An in-depth look at user paths, including binary and encoded user paths, along with a performance analysis, usage hints, and sample code can be found in Technical Note #5114, Advanced Path Construction Using Level 2 Features. 10 Supporting Level 2 Functionality (31 Mar 92)
ASCII Base-85 ASCII base-85 is an encoding of binary strings in a base 85 ASCII representation that incurs an expansion penalty of 1.25 as opposed to hex s 2.0. This means that font, image, rectangle, color space, and user path data can be portable across communications channels (among Level 2 printers) and are less bulky than hex. The technical papers dealing with filters and advanced path construction also discuss using ASCII base-85. Filters Filters provide a special operation that applies a transformation to the data from a file or procedure as it passes through the filter. This transformation can be any combination of several image compression schemes, or hexadecimal or ASCII base-85 data representations. Filters can be concatenated, so that a driver can output a compressed data stream that is 7-bit compatible by using both a compression such as LZW (Lempel-Ziv-Welch) and a representation filter such as ASCII base-85. Information about using filters under Level 2 can be found in section 3.13, Filtered Files Details, of the PostScript Language Reference Manual, Second Edition. An in-depth look at filters, including CCITT fax, run length encoding, ASCII 85, hexadecimal, and LZW compression methods, along with a performance analysis, usage hints, and sample code can be found in Technical Note #5115, Supporting Data Compression in PostScript Level 2 and the filter Operator. A discussion of the DCT filter can be found in Technical Note #5116, Supporting the DCT Filters in PostScript Level 2. Binary Token Encoding Binary token encoding (BTE) is method of writing out numeric data and PostScript language operators as binary tokens. This results in a smaller output file size with no change in execution time. For producers of large PostScript language files this might be a good feature to exploit. Information about the use of binary token encoding under Level 2 can be found in section 3.12.1, Binary Tokens, of the PostScript Language Reference Manual, Second Edition. Technical Note #5114, Advanced Path Construction Using Level 2 Features, also discusses BTE and presents sample code for conversion of data and operators to BTE format. 2 Deciding Which Features to Support 11
3 Deciding the Type of Code to Output Now that the driver supports a variety of features including Level 1/Level 2 code and some Level 2 specific features, there is the question about the type of code to generate at print time: Level 1, Level 1/Level 2, or strictly Level 2 PostScript language code. Three situations arise when generating the output file: Output is either sent to the target printer, saved to disk, or sent to a spooler. 3.1 Target Printer Issues A driver must determine the characteristics of the target printer. Is it a Level 2 printer? Does it support certain Level 1 extensions? What is the communications channel? What type of features does it support? The answers to these questions determines the type of code sent to the printer. One way to answer these questions is through a PostScript language query sent over a bidirectional communications channel immediately prior to sending the print job. A query is a special type of print job that requests that information about the printer be sent back to the driver. Query strategies and issues are discussed in the PostScript Language Reference Manual, Second Edition, Appendix D, Compatibility Strategies, and in Appendix G.8, Document Structuring Conventions. Another method of determining printer capabilities is to read the PostScript Printer Description (PPD) file for the target printer. This file is installed on the host computer in a special directory for use by the driver. These files can be invaluable when constructing the user interface for the driver. PPD files are specified in the PostScript Printer Description File Specification, Version 4.0. An in-depth look at PPD files and their use can be found in Technical Note #5117, Supporting Device Features. A PPD parser is provided in source code in the PostScript Language Software Development Kit and is described in Technical Note #5127, PPD File Parser: Application Programmer s Interface. Now that the capabilities of the printer are known, the driver must decide how to satisfy the feature requests of the application. If a Level 1 printer is the target printer, emulation code might have to be sent along with the print job. Some features cannot be used at all; appropriate adjustments must be made. For example, user paths are not available on Level 1 printers. The driver must output regular paths instead of user paths. If a Level 2 printer is the target, however, advanced features can be used and emulations are unnecessary. 12 Supporting Level 2 Functionality (31 Mar 92)
3.2 Save-to-Disk Issues Saving an output file to disk is often considered a worst case scenario. It is not known what the user will do with the file once it has been generated. It can be sent down to a printer at a later time, it can be archived or sent to a different corporate site, or it can be sent to a service bureau for final printing. Portability is a key issue. We suggest that Level 1/Level 2 configurable code be the default output format in these situations because this retains the greatest PostScript language functionality while still being portable. 3.3 Spooler Issues An intelligent spooler might know the type of destination printer currently available for printing, the capabilities of the ultimate target printer, and be able to respond to queries. It can also act as a virtual printer itself. Target printer issues become important if this type of spooler is detected. On the other hand, the spooler might not be able to answer queries or know where the file will ultimately be printed. In this case, sending output to the spooler should be similar to saving an output file to disk. More information about spoolers can be found in the following documents: Appendix G, Document Structuring Conventions Version 3.0, of the PostScript Language Reference Manual, Second Edition Chapter 13, Writing a Print Spooler, of PostScript Language Program Design 3.4 Typical Scenarios If the driver supports Level 1/Level 2 PostScript only, no user interface issues should exist. If it s possible for your application to determine the language support of the target printer, either the PostScript Level 1 or Level 2 code should be sent to the printer. If the target printer is not known (for example, save-to-disk or dumb spooler), then use self-configuring code. Using configurable procset code will ensure that the user receives the best performance and highest level of functionality, whether the file is ultimately sent to a PostScript Level 1 or a Level 2 printer. If the driver supports binary output (for example, binary data in fonts and images), a dialog with the user of the application may be necessary. When the target printer and the type of communications channel are known, the driver can generate binary data as appropriate. In save-to-disk or dumb spooler situations, the driver may ask the user to choose between binary and 3 Deciding the Type of Code to Output 13
ASCII output. The user is then responsible for the format of the generated PostScript file and can still take advantage of the space and time savings that binary data offers. In the case of a driver that supports Level 2-only features such as image compression and device-independent color, the user might be presented with another set of choices. As in the previous scenarios, if the target printer and its capabilities are known, the driver can choose the appropriate type of PostScript language code and features. If the target printer is not known, the driver might present a dialog box to the user describing the various output options available. Figure 1 Sample dialog box File Format Level 1/Level 2 Level 2 ASCII Binary OK If the user definitely wants to use special Level 2 features, then the user can select the Level 2 radio button. This indicates to the driver that PostScript Level 2-only code can be generated without regard for emulation for or conversion to PostScript Level 1. If the user knows that an 8-bit transparent channel is the only type of channel to be used, the user can select the binary radio button. The driver is then free to generate binary PostScript language code. 14 Supporting Level 2 Functionality (31 Mar 92)
Appendix: Changes Since Earlier Versions Changes since May 3, 1991 version Expanded the section on Optimization in section 2.1, Level 1 Support. Document was reformatted in the new document layout and minor editorial changes were made. 15
16 Appendix: Changes Since Earlier Versions (31 Mar 92)
Index A Adobe Binary Communications Protocol 9 ASCII base-85 11 automatic stroke adjustment 8 B binary data 9 converting to hex 9 reduced storage costs 9 transparent channel 9 binary token encoding 11 BTE. See binary token encoding C configurable procset code 7 D driver 14 supporting binary output 13 supporting PostScript Level 1 and Level 2 13 supporting PostScript Level 2 only 14 E emulations automatic stroke adjustment 8 forms 8 patterns 8 rectangles 8 F filters 11 forms 8 P portability 13 PostScript language file transmitting to printer 9 PostScript Level 1 fonts 6 optimization 6 printer specific features 7 supporting functionality 6 PostScript Level 1 and Level 2 adding functionality 7 binary support 9 emulations, disadvantage 7 PostScript Level 2 advanced support 10 ASCII base-85 11 binary token encoding 11 driver improving 6 features that cannot be emulated 10 filters 11 patterns 8 supporting functionality 5 14 user paths 10 PostScript Printer Description files 12 PPD. See PostScript Printer Description files Q query 12 17
R rectangles 8 S save-to-disk issues 13 setrgbcolor 10 setstrokeadjust 8 spooler issues 13 T target printer issues 12 U user paths 10 V veneer definition 7 18 Index (31 Mar 92)