laser-lovers@uw-beaver (02/16/85)
From: Mendelson.es@XEROX.ARPA The principal purpose of this message is to correct an omission plus a few minor inaccuracies that were introduced when my response to Rob Warnock was edited within Xerox. It also deals with some Interpress and PostScript implementation issues. I make specific reference here to implementation considerations because I believe that it is important that we clearly separate the issues of the qualities of the languages from the qualities of any specific language implementations. In looking back at earlier messages, it appears that we have been guilty of not maintaining this clear separation in our past discussions. First, an item of omission. My statement of similarities between the two languages was illustrative, not exhaustive. But there was one point of similarity between Interpress and Postscript that I should not have omitted because it is critical to the translation issue. Both languages use identical imaging models. Hence there is nothing in the nature of image generation that cannot be translated from one language to the other. Now for the corrections to my earlier message. One paragraph of my message, describing one of the differences between Interpress and PostScript lost some information in transit. It should have read as follows: "There are several major and significant differences. Here are a few. Interpress is constructed so that page independence is guaranteed. A reference frame, called the PageFrame, that contains the constructs that are global to a document is created at the beginning of the document, e.g. the PageFrame contains fonts or procedures that are used throughout the document. The PageFrame is made available to every page. Nothing else that is unique to a page is permitted to influence the description of any other page. Each page described by Interpress starts with a clean slate plus the PageFrame. This structure enables the use of utility routines to construct documents made from pieces of other documents without having to know the content of those documents, and without having to parse and/or execute their way through those documents to determine the execution state that exists at the beginning of any particular page. While PostScript enables the creation of documents that exhibit this characteristic it does not ensure that all documents possess this characteristic." In another part the edited message said, "By comparison, the Xerox 9700 decompresses the bit-map fonts and prints a whole page in that one second." The correct statement should have read, "By comparison, the Xerox 9700 decomposes a complete Interpress description of a page and prints a whole page in that one second." Here are some further observations on the characteristics of the specific Adobe PostScript implementation relative to the specific Xerox Interpress implentation to be found in the 8700/9700 printers. The main point here is that any implementation of a language like Interpress or PostScript makes adaptations and compromises according to its application environment. Xerox has implemented two different subsets of Interpress that are appropriate to their application environments, one for the 8040/5700 environment, the other for the 8700/9700 environment. The 9700 environment is high volume, production oriented. Its document content is multi-font, conventional text combined with bit-mapped graphics, i.e. half-toned scanned images or scanned graphics. The latter do not generally occupy a large percentage of a page. Documents can vary widely in their font requirements from document to document. The flow of documents through the printer is continuous. In that environment the 9700 version Interpress interpreter can decompose and print an entire Interpress-represented page in the one second period that I understand it takes the PostScript interpreter to scan convert a single character. An ingredient of this performance is the use of bit-mapped font representations. These bit-maps are not compressed. In making this implementation choice Xerox has sacrificed the ability to print any page, no matter what its content might be, for the ability to print the pages of its 9700 working environment at very high speed. For example, the 9700 could not print a character that was rotated at some angle that was not an integral multiple of 90 degrees. Nor does it currently print vector graphics (a deficiency that is currently being corrected.) Hence, it would be easy to create a page, expressible in Interpress, that the 9700 could not print. Any page would print correctly for all characters whose rotation was an integral multiple of 90 degrees, but all characters at other rotations would not print. Neither would graphic constructs. The document would print with blank spaces appearing in place of the non-implemented constructs. An appearance warning would be noted on its accompanying cover page. Such a document would print absolutely correctly if equivalently expressed in PostScript representation and passed through the Adobe PostScript interpreter, but at a greatly reduced throughput rate. Conventional documents that the 9700 could also print are also printed at reduced throughput rate. This is an instance where Xerox and Adobe have chosen to optimize for different environments, and that's perfectly appropriate. Adobe has chosen to provide what I term an "unlimited printer" implementation. Such an implementation contains a full page image buffer, 8.415 megabits for an 8.5 x 11 page at 300 bit per inch resolution. That would take up slightly more than one megabyte (out of the 1.5 megabytes of RAM provided with their implementation) less any space saved by not preempting memory space for large white areas of the page. Such an implementation can print any page that the language can describe because the decomposer can grind away for as long as it takes to construct the page image. Adobe provides an elegant solution for a "print anything" environment where print throughput rate is not a major issue. As part of that implementation Adobe has chosen to use outline fonts, fonts whose character shapes are described by higher order curves, rather than bit map fonts. Outline fonts have at least two significant virtues. They occupy much less storage space than raster fonts. They may be arbitrarily scaled and rotated before they are scan converted for printing. They have the drawback that this delayed scan conversion can cause significant printing delays. Adobe partially avoids these delays by caching the scan converted outlines of those characters that it prints so that scan conversion need only be done the first time that a character is encountered in a document. Since even with this discipline scan conversion would significantly delay first copy out time they probably further reduce the delays through the use of anticipatory algorithms that lead to pre-caching of high likelihood characters in popular sizes and orientations for popular fonts. They also could make use of available processor time to anticipate and scan convert other characters before they are encountered in the document. For example, once one character of a given font in a given size and at a given orientation is encountered they might scan convert other high likelihood characters, such as vowels, of that same size and orientation even though they had not yet been encountered. Thus the character cache memory builds up a reservoir of high probability usage raster scanned characters. The cache memory can occupy a significant portion of the remaining 0.5 megabytes of RAM, limited only by the space that is available after allocation of space for the decomposer software, its working environment, I/O buffers, etc. When the cache space is filled replacement algorithms can be used to determine which characters should be replaced by new ones. Even with this large memory space, and elegant anticipatory algorithms, start-up delays must of necessity be encountered in this form of implementation. For most documents with reasonable font usage the cache memory will rapidly be filled with the required character bit maps, and this delay will not be experienced for the later pages of a document. For an environment with a sequence of documents whose font requirements are widely different the delays in rebuilding the font cache can be significant. One final comment is perhaps in order. I would like to assure those of you who do not know me that I am an engineer and not a marketeer. I entered the computer field in 1948 and recently retired from Xerox as a Xerox Engineering Fellow. I am currently acting as a technical consultant to Xerox. I have spent my entire career working as a computer and computer systems architect. I was the chief architect of the team that designed the Scientific Data Systems Sigma series computers. Jerry Mendelson