laser-lovers@uw-beaver (02/26/85)
From: adobe!taft@Shasta (Ed Taft) Here is some additional information about PostScript and about the LaserWriter. As I said in my last message, Adobe will not participate in laser-lovers discussions about the relative merits of competing printer products, though we are glad to see such discussions take place. However, we will respond to technical questions about PostScript and about how it is being used. This message answers some questions that have been raised about fixing bugs, TeX support, and font handling. 1. Fixing bugs One person asked what plans Adobe has to fix bugs that are found in released printer products such as the LaserWriter. This is really a matter to be determined by the printer manufacturer rather than by Adobe. We are continuing to develop and improve PostScript, and we are naturally interested in seeing that the improvements be incorporated into printer products. What this means in terms of firmware retrofits to existing printers, I cannot say. Actually, we already know about several bugs in the LaserWriter; most of them are documented in the back of the LaserWriter Advanced User's Supplement (part of "Inside LaserWriter"). In general, these bugs are very obscure, and it's easy to avoid provoking them. To date, we have not discovered any bugs that are serious enough to warrant a firmware update in the near future. (We DO know of some serious bugs in the QMS 1200A PostScript printer, now in beta test. These bugs will be fixed before final product release.) We have the capability to "patch" many parts of the PostScript firmware, either by replacing two of the 16 ROM devices or by downloading replacement code into RAM from a host. This capability has already proven to be valuable: the entire package of AppleTalk software was introduced as a "patch" after the main body of PostScript had been frozen. We anticipate introducing various new capabilities in the form of programs that can be downloaded from a host. For example, we are already providing an alternative error handler that reports PostScript-level errors by printing a hardcopy page containing the error information in addition to sending the information to the host. This is included in both the "Inside LaserWriter" package and as part of TranScript. 2. TeX support We do not have the resources in-house to provide PostScript support for TeX. However, we are providing technical assistance to a few parties that have approached us about this. We prefer to let these outside parties make their own announcements about plans and availability. We expect that several flavors of TeX DVI to PostScript converters will emerge, from quick and dirty "preview" schemes to more robust and correct translations. At least one of these will support PostScript "specials", so that raw PostScript can be included in a TeX document for illustrations, scanned images, etc. TeX font support presents more interesting issues and alternatives. One possible solution is to teach TeX about Adobe's fonts (by building TFM files for them). This should be fine for many text applications, but the disparity between the character collections of the TeX and PostScript symbol fonts would make the setting of mathematics difficult. Another choice is to download TeX font bitmaps into a PostScript printer. This presents the usual challenges of storage management, etc, but should yield results familiar to users of TeX and TeX fonts on other systems. Eventually, Adobe hopes to offer outline descriptions of the standard Metafont/TeX fonts. We believe that we can generate acceptable outlines for a range of TeX fonts from high-resolution raster data. We expect to do this for a number of design sizes to allay the fears of Metafont enthusiasts. It will then be up to the TeX user and the DVI to PostScript translator to determine which set(s) of outlines to use. Of course, all of these approaches could be used in combination: Adobe Helvetica-Bold for chapter headings, your favorite rasters for AMR10, and an outline form of AMR for all the other sizes. As an aside, I should mention that Unilogic has announced plans to produce PostScript output from Scribe; and support for troff and ditroff is included as part of the TranScript package that has already been described in laser-lovers. 3. Font handling In connection with discussions about font downloading, it's important to understand a few things about how fonts work in PostScript. In particular, it's important to distinguish between the font description and the font cache. A font description is a collection of PostScript programs and data structures, organized in a particular way. It describes what the characters of the font look like in terms of standard PostScript graphical primitives (lines, curves, strokes, filled areas, images, etc.) Fonts provided by Adobe use a proprietary encoding that is compact and includes additional information that permits good-quality rendition in small point sizes at medium resolutions. Nevertheless, fonts themselves (whether Adobe-supplied or user-defined) are not primitive objects, but are built up from more basic graphical primitives. Though there are several different representations of fonts, the only thing that is really special about a font is that it conforms to a particular organization that is understood by PostScript's font machinery. This permits various optimizations to be performed that do not affect the appearance of the results but have a major effect on the efficiency with which those results are produced. The most important optimization is the font cache. This is a data structure that (unlike the font description) is essentially invisible to the PostScript programmer. When a particular character of a particular font is to be imaged, the font machinery first checks to see whether the bitmap for that character (at the correct size and orientation) already exists in the cache; if so, it uses the bitmap. If not, it executes the font description for the character, and stores the resulting bitmap in the cache for subsequent use. Imaging a cached character is typically 1000 times as fast as scan converting it from an outline. Font caching works regardless of whether a font description is built-in or downloaded, and regardless of whether the description consists of outlines, images (including device-resolution rasters), or whatever. Cached bitmaps for built-in or permanently-installed fonts survive from one print request to the next. In fact, idle time between print requests is utilized to scan convert and cache a "standard" selection of characters that may be specified at installation time. A downloadable font description can be introduced into a PostScript printer in one of two ways. It can be installed "permanently" (i.e., until the printer is next turned off); or it can be sent as part of an individual print request. In the latter case, the font description vanishes at the end of the print request, as do all other vestiges of that request. PostScript does not presently offer any mechanisms for automatic management of font descriptions. In general, it is the responsibility of spooling software to download fonts from a host and to determine which fonts should be permanent and which should be downloaded with individual print requests. For example, the TranScript package includes a spooler with such a font management capability. Ed Taft Adobe Systems, Inc. Notices: PostScript and TranScript are trademarks of Adobe Systems, Inc. LaserWriter is a trademark of Apple Computer, Inc. Scribe is a trademark of Unilogic, Ltd. TeX is a trademark of the American Mathematical Society.