Rochester Institute of Technology RIT Scholar Works
Theses
1988
Performance analysis of text-oriented printing using PostScript
Thomas Kowalczyk
Follow this and additional works at: https://scholarworks.rit.edu/theses
Recommended Citation Kowalczyk, Thomas, "Performance analysis of text-oriented printing using PostScript" (1988). Thesis. Rochester Institute of Technology. Accessed from
This Thesis is brought to you for free and open access by RIT Scholar Works. It has been accepted for inclusion in Theses by an authorized administrator of RIT Scholar Works. For more information, please contact [email protected]. Rochester Institute ofTechnology School ofComputer Science and Technology
Perfonnance Analysis of
Text-Oriented Printing
Using POSTSCRIPT®
by Thomas L. Kowalczyk
A thesis, submitted to The Faculty ofthe School ofComputer Science and Technology, in partial fulfillment ofthe requirements for the degree of Master ofScience in Computer Science
Approved by: Guy Johnson Professor and Chairman of Applied Computer Studies
Dr. Vishwas G. Abhyankar instructor
Frank R.Hubbell instructor
October 10, 1988 Thesis Title: Performance Analysis of Text-Oriented Printing Using POSTSCRIPT®
I, Thomas L. Kowalczyk, hereby grant permission to the Wallace Memorial Libra.ry, of R.I.T., to reproduce my thesis in whole or in part under the following conditions:
1. I am contacted each time a reproduction is made. I can be reached at the fol1mving address: 82 Brush Hollow Road Rochester, New York 14626 Phone # (716) 225-8569
2. Any reproduction will not be for commercial use orprofit.
Date: October 10,1988
i
Pennission Statement Apple, Appletalk, LaserWriter, and Macintosh are registered trademarks of Apple Computer, Inc.
Fluent Laser Fonts and Galileo Roman are trademarks of CasadyWare Inc.
Helvetica, Palatino, and Times are registered trademarks of Linotype Co.
ITC Avant Garde, ITC Bookman, ITC Garamond, ITC Zapf Chancery, and ITC Zapf Dingbats are registered trademarks of International Typeface Corporation
POSTSCRIPT is a registered trademark of Adobe Systems Incorporated.
Interpress in a registered trademark of Xerox Corp.
u
Trademarks Abstract
POSTSCRIPT is a page description language which is used to transmit printing information from a host computer (i.e. Apple Macintosh) to a printer (i.e. Apple LaserWriter Plus). It has the ability to describe pages consisting of text, vector graphics, and scanned bit-map images. Printing text is the area of concentration for this thesis. Specifically several variables that affect the printing speed of a common POSTSCRIPT printer, the Apple LaserWriter Plus, are looked at when printing text in a variety of fonts, sizes, and orientations. The variables that affect printer performance include:
- use of outline vs. bit-map fonts;
- the outline font rasterization process;
- the use of pre-cached bit-map fonts;
- background outline font rasterization;
- arbitrary scaling and rotation;
- downloading host-resident fonts;
- Adobe and Third Party host-resident downloadable fonts vs. printer-resident fonts;
- Appletalk vs. RS-232 communications interfaces;
- use of the POSTSCRIPT show, ashow, and widthshow instructions;
- targeting the POSTSCRIPT instructions at a particular engine resolution;
- print engine overhead
A sequence of POSTSCRIPT files were transmitted to the Apple LaserWriter Plus printer. The experiments were carefully constructed to exercize each of the variables listed above. Performance measurements were carefully recorded and analyzed. Where applicable, improvements were proposed to improve printer performance.
in
Abstract Tfl!?lP of Contents Page
Permission Statement '
Trademarks n
Abstract '
Table of Contents iv
1. Introduction 1
1.1. Background 1
1.2 "PDL" Defined 1
1.3 History of Interpress and POSTSCRIPT 2
1.4 A Comparison of Outline vs. Bitmap Fonts 4
1 .5 Text, Vector Graphics, and Bitmap Images 8
1.5.1 Text 8
1.5.2 Bitmap Images 9
1.5.3 Vector Graphics 10
2. Problem Description 13
2.1 Variables that Affect Performance 14 problem description and expected results
2.1.1 Font Formats: Outlines vs. Bitmaps 14
2.1.1.1 Outline Font Rasterization and Caching 15
2. 1 . 1 .2 Pre-Cached Bit-Maps 15
2.1.1.3 Background Outline Font Rasterization 16
2. 1 . 1 .4 Effect of Scaling and Rotation 17
2. 1 . 1 .5 Variations of Font Style 19
iv Table of Contents (continued) Page
2.1.2 Downloaded Fonts 20
2.1.2.1 Downloaded Bitmaps vs. 21 Printer Resident (Cached) Bitmaps
2.1.2.2 Adobe Downloaded Outlines vs. 22 Printer Resident (Internal) Outlines
2. 1 .2.3 Adobe Downloaded Outlines vs. 23 Third Party Downloaded Outlines
2.1.2.4 Appletalkvs.RS-232 25
2.1.3 Methods of Printing Strings 26
"Targeting" 2.1.4 Resolution vs. Total 27 Resolution Independence
2.1.5 Effect of Varied Page Complexity on POSTSCRIPT 28 Processing Time
2. 1 .5. 1 Effect on the Inter-Page Time Delay 28 Program sec
2.1.5.2 Effect on the Compilation and Rasterization 29 of Text Pages
2.2 Performance Measurement and Calculation 30
2.2.1 Communications 31
2.2.2 Interpretation (Compilation) and Rasterization 35
2.2.3 Print Engine Paper Ejection 44
2.3 Programming Tasks 45
2.3.1 Extraction of Font Widths from 45 Apple Laser Writer Plus
2.3.2 Batch Composition Program 47
2.3.3 Downloadable POSTSCRIPT Bitmap Font Program 49
2.3.4 Installing Downloadable POSTSCRIPT Outline Fonts 54
2.4 Assumed RIP Architectural Model 55
v
Table of Contents Tahlp of Contents (continued) Page
3. Analysis of Experimental Results 59
3.1 Font Formats: Outlines vs. Bitmaps 59
3.1.1 Red Time Outline Font Rasterization and Caching 59
3. 1 . 1 .A Experimental Results 3.1. LB Analysis 3.1. l.C Proposed Improvements
3.1.2 Pre-Cached Bit-Maps 65
3. 1 .2.A Experimental Results 3.1.2.B Analysis
3. 1 .2.C Proposed Improvements
3.1.3 Background Outline Font Rasterization 67
3 . 1 . 3 . A Experimental Results 3.1.3.B Analysis 3.1.3.C Proposed Improvements
3.1.4 Effect of Scaling and Rotation 71
3. 1 .4.A Experimental Results 3.1.4.B Analysis
3.1 .4.C Proposed Improvements
3.1.5 Variations ofFont Style 78
3.1.5.A Experimental Results 3.1.5.B Analysis
3. 1 .5.C Proposed Improvements
3.2 Downloaded Fonts 81
3.2.1 Downloaded Bitmaps vs. Printer Resident 81 (Cached) Bitmaps
3.2. 1 .A Experimental Results 3.2. LB Analysis
3.2. 1 .C Proposed Improvements
3.2.2 Adobe Downloaded Outlines vs. 86 Printer Resident (Internal) Outlines
3.2.2.A Experimental Results 3.2.2.B Analysis 3.2.2.C Proposed Improvements
vi
Table of Contents Table of Contents (continued) Page
3.2.3 Adobe Downloaded Outlines vs. 91 Third Party Downloaded Outlines
3.2.3.A Experimental Results 3.2.3.B Analysis 3.2.3.C Proposed Improvements
3.2.4 Appletalk vs. RS-232 97
3.2.4.A Experimental Results 3.2.4.B Analysis 3.2.4.C Proposed Improvements
3.3 Methods of Printing Strings 102
3.3.A Experimental Results 3.3.B Analysis 3.3.C Proposed Improvements
"Targeting" 3.4 Resolution vs. Total Resolution Independence 111
3.4.A Experimental Results 3.4.B Analysis 3.4.C Proposed Improvements
3.5 Effect of Varied Page Complexity on POSTSCRIPT 115 Processing Time
3.5. 1 Effect on the Inter-Page Time Delay Program sec 115
3 . 8 . 1.A Experimental Results 3.8. LB Analysis 3.8. l.C Proposed Improvements
3.5.2 Effect on the Compilation and Rasterization 118 of Text Pages
3.8.2.A Experimental Results 3.8.2.B Analysis 3.8.2.C Proposed Improvements
4. Conclusions 123
4.1 Scan Converting Outline Fonts vs. Caching Bitmap Fonts 123
Hints" 4.2 Scan Converting Font Outlines with "Quality Applied 124
4.3 Font Style Complexity 124
4.4 Downloading Fonts 125
4.5 Methods of Printing Strings 125
4.6 Resolution Targeting 126
vii
Table of Contents TflhiP of Contents (continued) Page
4.7 Printer Induced Delays
127 5. Glossary
6. References
133 7. Bibliography
1. Equipment and Software Tools
Evaluation Equipment Configuration 1 . 1 POSTSCRIPT
2. Support Programs
2.1 PostScript Font Widths
2.1.1 Font Extraction Program
the Laser Writer Plus 2. 1 .2 Printed Font Width Tables from Apple
Width Table CH 2. 1 .3 Times-Roman Font (AS File)
2.2 Generation of POSTSCRIPT Text Pages
2.2. 1 Batch Composition Pseudo-Code
"Content" 2.2.2 Input Data File
"Style" 2.2.3 Input Markup File
2.2.4 Text PostScript File
2.2.5 Printed Text and Timing Pages from the Apple Laser Writer Plus
viu
Table of Contents 1. Introduction
1.1 Background
An electrtonic publishing system is made up of three main parts: the front-end, the RIP, and the print engine. Figure 1.1 is a block diagram of a typical electronic publishing system.
Page Description External Bit-Map fe- Front Language ^ Print n formi ri n n RIP W w' Input End Engine Engine Control
Electronic Publishing System Block Diagram figure 1.1
The front-end provides interfaces to the user and to other computer systems. The user interface handles input of text, graphics, and bit-map (scanned) images, and provides the merging and page layout of these pieces in either a batch or interactive (WYSIWYG) mode. The computer interface provides a communications interface with other information input systems (ie. word processors, illustration stations). This information is filtered by the front-end to yield the internal page format of the electronic publishing system. Ultimately, the output of the front-end language" processor" is the "page description (PDL) file which is sent to the "raster image (RIP). The PDL file describes the marks on the printed page.
The Raster Image Processor (RIP) inputs a PDL file for a page or a set of pages generated by the front-end. The RIP then generates the corresponding bit-map image(s) and sends it to the print engine, usually in a raster form. The print engine prints the bit-map page.
image" The Page Description Language (PDL) is the interface between the "soft world of the "hard-copy" front-end and the world of the RIP and the print engine. One particular PDL is quickly becoming an industry defacto standard: POSTSCRIPT.
1.2 "PDL" Defined
PDL stands for Page Description Language. The term PDL applies to the set of printing commands that describe the printing of text and usually vector graphics on a printed page. The "mark" location on a page is specified and a is placed at that location. That mark can be a dot, a character, a string of characters, a line segment, a curve segment, or a bit-map. The PDL has text" no knowledge of a "line of or a "carriage return". Subsequently, conventional tine printers are not considered to use PDL's. Detennining where the line of text begins and ends is die responsibility of the front end application. A typical sequence of PDL (pseudo)code to print out a simple string of text goes as follows:
Move cursor to the (x,y) coordinate of the page.
"current" Select a font, size, and orientation; make it the font
Print the string "abc"; letters are automatically advanced using proportional spacing.
Some of the more recent PDL's, like POSTSCRIPT, offer fully scalable and rotatable outline fonts. The older PDL's, like imPRESS, provide a limited number of discrete font sizes and the language" four quadrant orientations. The PDL is the "assembly of electronic printing. 1
Section 1.1 Introduction 1.3 History of Tnternress find PostSPRTPT (1)
Interpress POSTSCRIPT Bob Sproull first Figure 1.3 shows how and began. "PRESS" at Xerox. John Warnock developed a printing language called while Independently to Xerox John Warnock put developed his own graphics/printing language. After coming concurrent at Xerox Palo together a similar language he called JaM. A third activity printing Graphics" research program. Alto Research Center (PARC) was the "Cedar graphics Interpress" "Research was based on all three of these activities.
publication of a paper Xerox allowed some of their work to become public. Xerox permitted Graphics" was written based on the work conducted in the "Cedar research program. It by Graphics John Warnock and Doug Wyatt and was called "A Device Independent Imaging Stanford Model for Use with Raster Devices". Secondly, Xerox allowed Leo Guibas, a Interpress course material for a professor, to use some of the -related research work as course at Stanford. John Warnock used the public information disclosed by Xerox in addition to die work that he did prior to coming to Xerox as a basis for starting his own company, Adobe Systems, Inc., and continued the development of a language which he called POSTSCRIPT. The Apple Laser Writer was the first commercial product to use POSTSCRIPT. The definition of POSTSCRIPT is public. Adobe's product is their implementation of POSTSCRIPT, which they will port to a hardware RIP that either Adobe or Adobe's customer designs.
On the Interpress side, a subset of Research Interpress was chosen which became the '82 Xerox internal standard language that was called the "Interpress Electronic Publishing Standard". Printing instructions were added to Interpress '82 to become another Xerox internal version of Interpress, version 2.0. Xerox made version 2.1 public in April of 1984. In 1986, Xerox released Interpress version 3.0 which contained three sets. The Set" Set" "Commercial handles basic text and trivial graphics; the "Publication adds bit-map Set" fonts, vector graphics, and bit-map printing; the "Professional Graphics provides high functionality, like scaled and rotated outiine fonts and bit-map image processing. The Set" Publication is a medium functionality language similar to "imPress", a language developed Set" and sold by Imagen Corp. The "Professional Graphics is a high functionality page description language similar to POSTSCRIPT.
Much of this information was taken from reference #1. (Reference list may befound in section 6.)
Section 1.1 - Introduction &* 1976: While at Evans Sutherland, John Warnock Bob Sproull develops works on graphics algorithm PRESS at Xerox research for flight simulators
Late 70's- earlv 8Q's
Xerox PARC "Research Interpress" headed by Chuck Geschke
Graphics" PRESS implemented John Warnock develops "Cedar and used inside .Jtbe JaM graphics print graphics research Xerox ing language program
"printing" Add instructions to Guibas 1982 Leo conduct^ July January 1982 Research Interpress & research John Warnock Interpress Xerox Internal Standard Interpress '82 ' at Stanford F& Doug Wyatt Publish "Interpress '82 Electronic a "A Device Independent Standard" .Publishing Graphics Imaging ModelJ for Use with Raster
Devices"
John Warnock Internal to Xerox: and Interpress 2.0 Chuck Geschke
start Adobe Sys.
1985: jr April 1984 >w First POSTSCRIPT / Public: Interpress \ Product 1 Electronic Printing J Apple Laser Writer V Standard J \Vali/
Commercial -?Set 1986 ^N. 1986: / Interpress 3.0 \ Publication
r~ Apple Laser I released to "?"Set Writer Plus V public J
Announced Xerox ^^7++^ Prof. Graph. printers to support / "-?Set others include Interpress include J* QMS, Mergenthaler, 4045, 4050, 9700, & 8700 Data Products, ... History of Interpress and POSTSCRIPT figure 1.3
Section 1.3 - Introduction 1.4 A Comparison of OutHfif YS KiHnan Fonts
could use fonts. One of the Before POSTSCRIPT was introduced most printers only bitmap set Adobe Systems, Inc. ahead of the key capabilities of POSTSCRIPT that certainly in addition to the less used competition was the extensive use of outline fonts. This is bitmap bitmaps. Four of the more font functionality. Outline fonts have many advantages over important advantages are outlined below.
Independence 1. Resolution . output the same outline can Since a font outline is not tied to a specific resolution device, device. easily be used to drive any resolution output
required for printers with different For bitmap fonts, entirely different bitmaps are when printed on a 400 dpi resolutions. For example, a 300 dpi font will be 75 % size printer, or 150 % size on a 200 dpi printer.
2. Device Independence page. In some cases Different printers have different processes that lay black marks on a the output even if two printers of the same resolution print the exact same bitmap (font) data, printers a tight (laser or can appear significantly different. In the case of electrophotographic such that the LED) exposes an area of electrophotosensitive material. The process is set up black" pick in a exposed area either picks up toner, in a "write system, or does not up toner,
white" "write system If the same bitmap is printed on two printers with different polarity white" processes the print produced with "write tends to be lighter than the print produced with "write black". Inconsistencies across printers can be compensated for in the outline font rendering algorithm, so that the same basic outline can be used to print on different process printers.
In contrast, to make bitmap fonts look the same on printers with very different processes, different font bitmaps are needed.
3. Better selection of high quality rotated and scaled fonts A single font outline can be scaled to any size and rotated to any angle. In addition it can be "obliqued" or tilted or reflected in either or both axes. In short, any outline font can be transformed in a way that can be described by any linear transformation.
By comparison bitmap fonts are applicable for only one size and orientation (and resolution and process). A 12 point font contains an entirely different set of bitmaps than a 10 point font of the same font style. The next section (4) discusses what this means relative to font storage space. Another method of printing bitmaps is to use one or several bitmaps and scale from the nearest bitmap font available. Although this method saves storage space and communications download time the quality of the font is severely degraded.
4. More memory space efficient. An outline font is specified at one size, typically on a 1,000 by 1,000 unit grid for POSTSCRIPT. The outline description for each character of the font is specified relative to discrete points on this grid. These outlines are made up of straight line segments and bezier curve segments. Characters in this font are then scalable and rotatable for fully any size,' and orientation. An outline font takes resolution, approximately 30 KBytes of memory space. For example the size of the Adobe POSTSCRIPT Stone Serif downloadable font is 34,260 bytes (*) when stored on the host Mac U computer. Once the font is downloaded it packed the is inside Apple LaserWriter Plus in a slightly more compact manner and occupies 28 KBytes of RAM **.
* measured with the GetInfo utility of the Apple Macintosh Finder ** measured with the Printer FontDirectory function of the FontDownloader program
4
Section 1.4 - Introduction By contrast a bitmap font only describes a typeface rendered at a single size, resolution, and orientation. If a 10 point and a 12 point font are needed (say at a given resolution and orientation) then two different files must be created and stored for the best quality. One size can be scaled from the other (see #3 above), but this yields very poor results.
The size of a bitmap font varies as the size of the font and the resolution varies. For example take a 12 point font with 96 printable characters at a 300 dot per inch resolution. The largest possible bounding box of a 12 point font is 12 points wide by 12 point high. This can be calculated to be 50 dots:
* 12iz points 300 dots per inch = 50 dots 72 points per inch
So the 12 point by 12 point box when translated into dots is a 50 dot by 50 dot character bounding box. This represents 2500 dots, each of which can be represented by one bit, assuming the dot is bitonal (i.e. Black or White). 2500 bits can be stored as 313 bytes per character. On average the characters only occupy about one third of this space, so it takes approximately 104 bytes to store each character's bitmap alone. For 96 characters this rums out to be about 10 Kbytes to store the bitmaps of a full 96 character set Additional font information which can take several KBytes also needs to be included along with the character bitmaps. An example of this kind of information is the character metrics of a font (i.e. width, height, kerning info). If this information takes 4 KBytes, then the hypothetical font described above will need 14 KBytes to store a single size of one font. There are other factors which influence the size of bitmap fonts. Depending on the combination of the size and resolution of a bitmap font, the effect of scaling a font will have varied results. Three "regions" (size-resolution) are looked at in more detail below:
Low (Size-Resolution) "Region"
This region can be active under three conditions:
1. small to medium point sizes are selected (e.g. 10, 12, 14);
2. (screen) resolutions of approximately 75 dots per inch are used;
"Byte" "Word" 3. the method of storing the bitmaps uses or padding.
At these size-resolution combinations the average characters all fit within one byte (of width). The 12 point bounding box is approximately 12 dots by 12 dots at this resolution. If the width of the average character is one half of this, the character is 6
padding" dots wide. With "byte the bitmap of this character would be stored as a column of bytes with the rightmost two bits of each byte padded with zeroes. Using the same assumptions a 10 point font would have an average character width of approximately 5 dots; at 14 point, 7 dots. In this region, as fonts are scaled the size of storage needed scales linearly, not geometrically. This is because only the height of the font changes (more rows) but the width does not (most characters fit in the one byte).
Note that even though the bitmaps scale linearly in this region, the space required to store the constant metric information often outweighs the amount of storage space needed for the variable bitmap data.
No specific example is provided to demonstrate this effect
5
Section 1.4 - Introduction "Region" Medium (Size-Resolution)
the two conditions: This region can be active under either of following
runs into the next); 1. No byte padding (i.e. one character's bitmap
or
2. Byte padding is used with
- small to medium point sizes (e.g. 10, 12, 14);
- per inch. (printer) resolutions of approximately 300 dots
height change as the font In the first case, if no byte padding is used both the width and square). size changes. The size therefore scales quadratically (as the
enough so the overhead In the second case, if the size-resolution combination is large the font size scales incurred with byte padding becomes negligible then, once again, quadratically. As discussed earlier in this section the 12 point bounding box is 50 dots character about dots wide. With this by 50 dots at this resolution, so the average is 25 size-resolution combination a much smaller percentage of the information is byte two padding, so as the size of a font increases the space needed to store it increases in directions. The formula that better explains this phenomena is:
2 y = x + b
Note that the space required to store the constant metric information, specified as b above, is quite substantial.
Macintosh bitmap fonts are stored in memory with each character butting up to the next character all having a constant height Byte padding is not used. To show that the (variable) bitmap portion of the screen font scales geometrically with font size, the 12 point and 24 point Times Roman screen fonts were examined using ResEDIT (a Macintosh resource editor).
Point Size Total Size* Bitmap Font Size** Metrics, etc.**
12 7,570 bytes 1,752 bytes 5,818 bytes
24 12,730 bytes 6,912 bytes 5,818 bytes
* Measured with the Font/DA Mover utility program. ** Measured with ResEDIT.
Macintosh Times Roman Screen Font
Figure 1.4.1 b = 5,818
* x = point size 12 = ( / ) V 1,752 41.9/or the Times Roman screenfont
It is shown in the figure 1.4.1 that the clearly Bitmap Font Size scales quadratically with the point size. The size of the portion of the 24 bitmap point font is almost exactly four times that of the 12 point font (within 1.4% error due to rounding). See references 29 and 30 for more information on the Macintosh sreen font formats.
Section 1.4 - Introduction High (Size-Resolution) "Region"
As the * (size resolution) product gets much larger the basic effect on the bitmap storage needed continues to be rise exponentially with the size of the font. However, when the bitmaps get much larger, they are generally compressed. A typical compression scheme is one called "run-length encoding". The simple one dimensional version of this compression scheme simply stores the number of white and black pixel runs for each scan line of font bitmap data. More sophisticated schemes allow compression in two dimensions. The obvious advantage to using data compression is that is reduces the amount of data storage space needed. The disadvantage is that more time (and or hardware assist) is needed to process the data on both ends: compression and de-compression.
"Compressed characters consume much less space .. than full pixel arrays (by factors of up to 40), but require more computation to reconstitute when you need them. Reconstituting a compressed character is still substantially faster than re-executing the description." original character In the Apple LaserWriter IIntx bitmaps of fonts that are larger than 20 points in size are stored in compressed format (all Ref. 2)
7
Section 1.4 - Introduction 1.5 Text. Vector Graphics, and Bifman Images
The POSTSCRIPT page description language has instructions that allows the user to draw text, vector graphics, and (scanned) bitmap images on a page. This thesis concentrates on text and does not address the vector graphics and bitmap imaging areas in any detail. However, many real-life applications, like electronic publishing, regularly include these types of images. POSTSCRIPT is very rich in vector graphics and bit-map imaging functions. It would be misleading to not even mention them in a paper such as this one. Therefore, to present a more complete picture ofPOSTSCRIPT, all three will be discussed briefly here.
1.5.1 Text
"mark" Text is generally the simplest most efficient and most used that is put on the page. Once a font is defined with a string like /Times-Roman findfont 12 scalefont setfont most of the POSTSCRIPT program consists of the actual strings of characters. In simple line printers the only overhead is the carriage return - line feed characters delimiting lines of text. This can be two ACSII characters per each 100 character (or so) line oftext or 2 % overhead. With POSTSCRIPT the overhead can vary widely, due to POSTSCRIPT's diverse functionality. But, for a simple line printer emulation, the overhead of textual POSTSCRIPT can be made with a few simple assumptions:
1. a single positioning command, like 72 720 moveto, will be used per line of text;
2. the strings of text will be encapsulated in parentheses, and followed by the show command; ( this is a string oftext ) show
3. 100 characters per average line;
4. the number of tines are sufficiently large such that the overhead incurred by the instructions selecting the font can be ignored;
5. - additionally one carriage return line feed pair per line is used
With these assumptions there are 22 characters per 100 characters of output text or 22% overhead. A dense page of very text containing 4,000 characters, can be described by approximately 4,900 characters ofPOSTSCRIPT code.
Since POSTSCRIPT is a full programming language, a simple program that emulates the carnage return - line feed function can be in defined the beginning of the file and accessed that function with a by calling single character (i.e. the name of the function) after each string of text is specified. this Using method the overhead can approach 3 % ignoring imnalization overhead, and one assuming matching pair of parentheses one character (c, below) which calls the carriage return - line feed function: initialization includes: - specifying the font
- defining the c (carriage return - line feed) procedure* - positioning the first line of text
(first string ofcharacters )c( second string ofcharacters )c( third string ofchar ) Generally, as the complexity of the text increases, though, so does the overhead of describing that text Much more is said about te"xt throughout titis^thesis 8
Section 1.5 - Introduction 1.5.2 Bitmap Images
On the other end of the spectrum of efficiency and speed are bitmap images. If the entire page were defined by a bitmap image that matches the resolution of the Apple Laser Writer Plus print engine (300 dots per inch), it would take over 8 Mbits or 1 MByte of binary data. That's 90,000 bits per square inch! The overhead of POSTSCRIPT for images is much more severe than for text A single binary byte of image data is described by two ASCII characters that specify two hexadecimal numbers. So 1 MByte of binary data is described by 2 MBytes of ASCII-encoded hex in POSTSCRIPT, or 100% overhead. Fortunately one does not necessarily need to specify that much data to fill the entire page with a bitmap image. This is because POSTSCRIPT:
- is resolution independent The input image does not have to match the output 300 dpi resolution. The POSTSCRIPT image operator automatically adjusts the input to output mapping for printers with two different resolutions (say 300 dpi and 600 dpi). The input can be presented to the RIP in any resolution.
- allows scaling of all images (whether they are text, graphics, or bitmaps). An image scanned from a 1 inch by 1 inch image can be scaled to any size on the output. In fact any linear transformation can be specified which can:
scale in x and y by the same amount (1 inch by 1 inch scales to 7 inches by 7 inches);
- anamorphically scale in x and y (1 inch by 1 inch scales to 3 inches by 7 inches);
"tilt" - the image (rectangular image becomes an image fitting a parallelogram);
- rotate the image.
"contone" Images can also be scanned as images (i.e. more than 1 bit per pixel; typically 8 bits per pixel for monochrome). Since the output image cannot print grey dots matching the grey areas of input image, a mapping of grey values to black and white printable dots must be made. This mapping is called screening . Variables that can be set with POSTSCRIPT are:
* - frequency of the screen. This is the number of "halftone dots", or "super-pixels", are printed per inch on the printer. Each of these halftone dots represent a grey value (or set of grey values) from the input contone image.
* - angle of the screen. This specifies the number of degrees by which the halftone screen is to be rotated with respect to the device coordinate system.
* - spot function of the halftone dot. This specifies how the halftone dot is to be "grown" as the input grey area changes from white (no black pixels turned on) to black (all black pixels turned on). Specifically, a procedure is specified which describes the order in which pixels within a halftone cell are whitened to produce any desired shade of grey, (setscreen, reference 3)
- input to output transfer function. A procedure can be specified which maps the input which a fraction of all are grey values to the printer grey values, is pixels that to be whitened, (settransfer, reference 4)
Section 1.5 - Introduction The two greatest performance botdenecks when dealing with images with POSTSCRIPT are:
1. accessing the image. Images tend to be large. If a communications line is used, it simply takes a long time to download the image. POSTSCRIPT's method of encoding the image with ASCII-encoded hex, described on the previous page, slows down this process by a factor of two. For example a 256 KByte binary image, which when encoded this way becomes 512 KBytes, takes almost 9 minutes to download using a conventional RS-232 serial interface line running at 9600 baud. Even when the image is resident inside the RIP, say on a disk, once again due to the size of the image it still takes a relatively long time to retrieve the image from disk, and to use the disk as a backup scratch pad when processing the image.
This bottleneck can be diminished by using faster communications interfaces, faster disks, and more RAM. O course, along with these RIP enhancements usually comes a higher cost.
2. processing the image. The previous page summarizes the image processing functions that can be applied to bitmap images. As in all of POSTSCRIPT, the functions vary from very simple to very complex. Applying a particular image processing algorithm to an image takes an amount of time that is proportional to the "complexity" loosely of the image processing function selected and, you guessed it the size
of the image.*ev
This bottleneck can be reduce by: , - once again, more RAM and/or faster disc; - faster general purpose CPU; - computer architecture that better suits the image processing algorithms that are commonly used. This can include special purpose hardware.
1.5.3 Vector Graphics
Somewhere in between text and bitmap images lies vector graphics in speed and efficiency. A single straight that tine traverses the height and width of a page can be described in just a few POSTSCRIPT instructions:
mveto % set cursor to lower left comer ofpage 612J 792 Iineto % draw line to upper right comer, coordinates are "points" in stroke % or 1/72 inch
Now the Raster Image Processor needs to fill all of the pixels in page memory that correspond to the pixels that make the up black line. Other settings that effect the rendering of (connected) lines are:
- width of the line, setable with the setlinewidth operator;
JOin' WWCh Can bC mlter' OT IOUnd' bCVel; Settable *** Ae setlinejoin
" ^ ^^^^" Pn>jeCted Square; ***** *** **
10
Section 1.5 - Introduction Instead of the simple sequence of instructions shown above, a path consisting of many shorter lines segments, all connected together, which define the same resultant line could also be specified in POSTSCRIPT. Even though the same exact bits are turned one, this problem is significantly more difficult for at least two reasons:
1. more POSTSCRIPT code needs to be read and interpreted;
2. each small line segment needs not only to be drawn, but connected to the next line segment in such a manner to make it appear as one continuous line.
Other graphical shapes can be specified:
- circualar arc segments (arc, arcn, reference 5) ;
- Bezier cubic spline segments (curveto, reference 6) ;
in addition to stroking (drawing) a line or curved segment, an area that is described by a sequence of these segments can be filled with black or some halftone pattern corresponding to the selected grey value. (stroke, strokepath, reference 7 ; fill, ref. 8 ; eofill, ref. 9 ; setgray, ref. 10 )
In addition to drawing or filling the paths that are defined, these same paths can be used to specify a clipping boundary through which other text, vector graphics, or bitmap images are clipped before being rendered in page memory and subsequently on the printed page, (clip, reference 11)
Once again POSTSCRIPT gives the user almost limitless flexibillity for printing vector graphics. Both the amount of POSTSCRIPT code as well as the rendering compexity can vary widely. I have no doubt that similar papers to this one could be written with concentration on performance aspects of vector graphics or bitmap imaging instead of text Hopefully, this brief section has provided the reader with some appreciation for the number and magnitude of issues when dealing with POSTSCRIPT vector graphics and bitmap images.
11
Section 1.5 - Introduction 12
Section 1.5 - Introduction 2. Problem Description
There are many different ways of describing a page of text in POSTSCRIPT. How one describes a page can significantly influence the overall performance of the printing system. The variables to be investigated, along with the expected outcome of the experiments, are described in sections 2.1.1 through 2.1.8 . The expected results are based on assumptions of the RIP architectural model described in section 2.4. Sections 2.1.1 through 2.1.5 match with sections 3.1 through 3.5. The latter sections deal with the specific experimental procedures used, the results that are produced, analysis of these results, and proposals, if any, on what changes could be made to improve performance.
For each variable in question, a set of benchmark pages are generated to demonstrate the significance of the variable. Many of the benchmark pages are included in sections 3.1 through 3.5. Due to space constraints, benchmark pages that are similar to ones included, but different in some small way, are described, but not included as inserts.
Section 3.2 specifies the methods used in calculating and measuring times taken for the different phases of the RIPing process, namely communications and the combined compilation and rasterization time. The programs written to support the experiments performed for this thesis are explained in section 3.3 with backup information provided in Appendix 2.
Once again, section 3 records the experimentally measured times, analyzes these times, and suggests improvements to the RIP architecture and/or to the POSTSCRIPT language itself that might yield better performance.
Section 4 presents overall conclusions using all of the information in section 3 to comment on the general trends that were observed.
13
Section 2 - Problem Description 2.1 Variables that Affect Performance
printer can be instructed in how to print There are many different ways that a POSTSCRIPT performance are listed m the text on a page. Some variables which affect system following sections.
2. 1 . 1 . Font Formats : Outline vs. Bit-Maps
Problem Description
(BLT- Rasterizing a font outline takes much more time than copying Block Logical memory. There is a Transfer) a font already in bitmap form to the page buffer tendency and in to use only a small number of different fonts (at a certain size orientation) any style" given written work. In fact it is considered "good to limit the number of fonts and sizes to just a few within any document. Furthermore, when using any given font, most of the time the writer uses characters of the alphabet that have been used before. For "a" example if the letter is used 20 times on a single page in the same font it needs only "a" to be rendered once and is repeated 19 times. In this case the leter is repeated 95% of the time. Repeat use of fonts and of characters within a font are the two primary reasons why all POSTSCRIPT printers to date have a font cache which stores the scan converted fonts for later use in the faster bitmap form. "Printing a character that is already in the font cache is typically a thousand times faster than scan converting it from font" the character description in die (reference 12) . The time consuming process of outline font rasterization can be done at various times, influencing the printer's performance. This section looks at three of these particular times:
1. inside a POSTSCRIPT program, when a new non-cached character is specified to be printed;
"factory" 2. once at the where the bit-maps are permanently stored in non-volatile memory, typically some type of ROM;
3. during idle time. When the RIP is not busy generating pages it can perform the time corisuming font outline rasterization task.
These three are looked at in more detail in sections 2.1.1.1 through 2.1.1.3, respectively. The corresponding experimental procedures, results, and analysis can be found in sections 3.1.1 through 3.1.3.
Section 2.1.1.4 and its complement section 3.1.4 deal with the performance effects of and outline scaling rotating fonts. Since detailed performance measurements will be done in section the print 3.1.4, job for this experiment contains no repeat characters. This is the only way to isolate the scan conversion process from the bit BLTing (moving bit-maps) from bit-map cache. More on this in section 3. 1.4.
14
Section 2.1.1 - Problem Description 2. 1 . 1 . 1 Real Time Outline Font Rasterization and Caching
During the course of a typical POSTSCRIPT file, fonts resident in outline form are specified to be scaled, (possibly) rotated, and printed. When this occurs the first print using these fonts tends to be slow due to the time consuming task of in-line (or real time) scan conversion of the outline fonts into the faster bit-map form.
Expected Results The first page after a power up sequence printing a font that has not been stored in bit-map form is expected to be slow. Once this first page has been printed, all of the fonts on that page will have been stored in the RTP's bit-map font cache. Subsequent pages are expected to print at a much faster rate, assuming the printer is kept powered-up.
2. 1 . 1 .2 Pre-Cached Bit-Maps
If the time consuming process of outline font rasterization is done before the font is requested in the POSTSCRIPT program, substantial performance gains can be realized. This section deals with the case where the outline font rasterization is done factory" once "at the and the resultant bit-maps of a select few fonts are stored in non-volatile bit-map font memory, such as EPROM in the case of the Apple Laser-Writer Plus.
Expected Results Pages that print fonts that have been pre-scan converted and permanendy stored in ROM are expected to yield equivalent performance whether the page is the first one after power up or not. The time consuming outline scan conversion has been done once, at the factory. The REP need not be bogged down with this task.
15
Section 2.1.1.1 Problem Description Outline Rasterization 2. 1 . 1 .3 Background
the user is forced to wait While a page printer is in the powering-up state, typically first page can be printed. In laser or LED up to several minutes before the to the time it takes for the electrophotographic printers much of this delay is due a portion of fuser heating element to rise up to its required temperature. During this initialization and diagnostic phase. time the RIP usually goes through an checking Once this is done, the RIP must wait until the print engine is ready to accept a print of job from the RIP. This is one example of idle time . Another example idle time is the time in between jobs. If the time consuming process of outline font rasterization is done before the font is requested in the POSTSCRIPT program, say during this idle time, substantial performance gains can be realized.
Expected Results Plus Several fonts in the Apple LaserWriter are scan converted from there original outline form to bit-map form and stored in the REP's font cache memory during idle time. The POSTSCRIPT Language Reference Manual lists several fonts and sizes at a zero degree rotation (i.e. portrait orientation) that are automatically scan
converted during idle time (reference 13) . They include all of the alphanumerics and common punctuation of the 10 and 14 point Times-Roman and Helvetica fonts, and also the lower case letters of the 10, 12, and 14 point Times-Bold and Helvetica-Bold fonts. In addition, an extension to the POSTSCRIPT page Plus description language has been specified for the Apple LaserWriter to allow the POSTSCRIPT programmer to specify which fonts he or she would like to be scan converted during the printer's idle time. The setidlefonts operator allows the selection of one of thirteen fonts with a different x and y point size selectable in tenths of a point increments, and an angle selectable in increments of five degrees
(reference 26) .
Print times for pages that use the 10 point Helvetica and the 14 point Times-Roman fonts will be looked at The POSTSCRIPT files containing references to these fonts will be sent at varying times after the power-up sequence is begun. This will be done by simply tirrning the printer off and then back on. It is expected that if a job using an idle time scan converted font is sent immediately to the printer following a power up sequence, it will take longer than if some time is waited before this is done. The experiments are reported in section 3. 1.3.
16
Section 2.1.1.3 - Problem Description 2. 1 . 1 .4 Effect of Scaling and Rotation
Section 2.1.1.4 and its complement section 3.1.4 deal with the performance effects of scaling and rotating outline fonts. Page 91 of the POSTSCRIPT Language Reference Manual states the the "built-in POSTSCRIPT (outline) fonts are usually defined in terms of a 1000 unit character coordinate system, and their initial FontMatrix is [0.001 0 0 0.001 0 0]. When a font is modified by the scalefont or makefont operator, the new matrix is concatenated with the font." FontMatrix to yield a transformed In other words the FontMatrix maps a font in the 1000 unit space to a one unit space scaling the x and y font units by 1/1000 with the following matrix:
0.001 0 0
0 0.001 0
0 0 1
This matrix scales both x and y coordinates by 1/1000. See the definition of CTM in the Glossary (section 5) for more information on the variables of a given matrix.
Since the default unit in POSTSCRIPT is the point, this means that if any given font is not scaled by some means, it will print out at a 1 point size. Therefore all usable fonts that are scan converted from outline are initially scaled. The time consuming matrix multiplication step must always be done. The second part of the scan conversion process involves the rasterization, or rendering, of the transformed (scaled, etc.) font outline.
Note that, in addition to the concatination of the FontMatrix with the transform matrices generated by the scalefont and makefont operators, the fonts are also affected by the Current Transformation Matrix or the CTM. Other general POSTSCRIPT operators that modify the CTM are the translate, rotate, and scale operators. So, there are several ways to scale and rotate fonts. As already mentioned, executing the scalefont and makefont operators can scale fonts. In addition, the POSTSCRIPT scale operator, which affects the CTM, also applies to fonts. Fonts can be rotated in two ways: by specifying the correct matrix variables using the makefont operator; or by executing the rotate command. Note that the makefont operator provides the user with a much more powerful tool than just the scaling and rotating functions. Since the user specifies a matrix, any linear transformation can be specified. This is how fonts are obliqued (ie. tilted) for example.
"intelligence" There is one more funtion that should be mentioned: that is, applying to the outlines. It is commonly known that Adobe Systems, Inc., the implementors "hints" of POSTSCRIPT in the Apple LaserWriter Plus, applies proprietary to their font outlines when rendering them. This is done to yield better looking characters at the 300 dot per inch resolution of the Apple LaserWriter Plus. This procedure is certainly done at the 0 degree (portrait) orientation and is probably done at other quadrant orientations - 90 degrees (landscape), 180 degrees, and 270 degrees. The performance impact of this factor is not known.
This section compares the performance of scaling and rotating a printer resident POSTSCRIPT outline font versus the same font that has already been scan converted and stored in the RTP's bit-map font cache memory. The font that has been selected for these experiments is the Times-Roman font two point sizes will be 1 1 points and 22 points; three angles of rotation will be 0, 70 and 90 degrees. 17
Section 2.1.1.4 - Problem Description an outline font: A^Tcusstdabove, there are two steps in rendering needs rotation the current FontMatrix. This to be - to applying the scaling and angle. Some multiplies are easier, done for any scale factor or rotation faster. Of the three angles specified, 0 and 90 however, and should execute than 70 degrees. degrees should be faster _ outline. In from an 11 to a 22 point - scan converting the transformed going need to be four times the font twice the number of scan lines accessed; number of pixels need to be written to.
Scaling Outline Fonts:
outline font is the domimant factor, the 22 point If c?jt converting the transformed point font If however font should take two to four times longer than the 1 1 outline is the dominant then the applying the transformation to the font factor, of point size). Not performance should be closer to equal (i.e. independent expectation relative to font size variation is knowing which of these is dominant, the as follows:
As the, size of the font increases, the time needed to render that font is expected to increase at a rate in between one and the square of the size difference. In the of 1 1 and 22 point size fonts, the 1 1 point font is expected to perform from 1 to 4 times faster than the 22 point font Note that the effect of incorporating "intelligence" font into this was not considered.
Font Outline Scan Conversion vs. Pre-Cached Bit-Map Fonts:
Rendering an outline font is expected to take much longer than pulling the same font already in bit-map form, from die font cache. "Printing a character that is already in the font cache is typically a thousand times faster than scan converting it from the font" character description in die (reference 12) Based on this information it is expected that the measured performance of pre-cached fonts should be approximately 1000 times faster than the measured performance of outline fonts. The overhead of a base (i.e. blank) page must be considered in this analysis. See section 3.2.4 for more details on this experiment.
Rotating Outline Fonts:
As for the effect of angle on performance, it is expected that 0 degrees will yield the best performance because of two reasons: - it is assumed that the POSTSCRIPT interpretor is probably optimized for this highly used case; - at 0 degrees, the cos and sin values yield 1 and 0 respectively. Assuming this information is used to descrease the number of calculations, an increase in performance should be realized
The performance of the 90 degree rotated case should follow with the 70 degree rotation case yielding the poorest performance. On the other hand the 70 degree rotation case could instead, vied the fastest results if font intelligence step turned out to be a dominant (and slow) process.
18
Section 2.1.1.4 - Problem Descrip^on 2. 1 . 1 .5 Variations ofFont Style
On page 20 of the Fluent Laser Fonts User's Guide it states that "complex fonts
... will take longer to print because of the intricate curves and shapes". Three "complexity" printer-resident fonts with different levels of will be used:
1 . Helvetica was chosen for its simple style. There are no serifs and many of the characters, like H, A, and V use straight line segments exclusively. This information can be stored in a very compact outline form and is expected to scan convert faster than the two other, more complex fonts described in 2 and 3 below. The text of this paragraph is set in Helvetica at 12 point.
2. Times Roman was chosen for its medium complexity style. On the one hand Times Roman is a complex font since it has serifs on many of the characters, like "i", "m", and "T". On the other hand many outline segments of the characters of the Times Roman font are made up of straight line segments orthoganal to the device coordinate system. The page that uses the Times Roman font is expected to yield better performance than the same page using the simpler Helvetica font shown in (1) above, but worse performance than the more complex Zapf Chancery Medium Italic font show in (3) below. The text of this paragraph is set in Times Roman at 12 point
3. ZapfChancery was chosenfor its comple^style. 'Whereas thefonts shown in (1) and(2) above usedmany straight One segments, the ZapfChancery Medium Italic font uses many more curvedsegments, which are inherently more compe%. The performance ofaprintedpage using Msfont is expected to yieldthe worst performance when comparedto (1) and (2). The text ofthis paragraph is set in Zapf Chancery Medium Italic at 12 point.
"performance" Note that when is mentioned above, only the scan conversion process is intended to be used as a comparison. Once the font is in the bitmap font cache all three fonts are expected to perform equally well. If there is a small difference in speed when printing from the font cache, the font that is the smallest (i.e. Zapf Chancery) should be the fastest, with the font that is the largest (i.e. Helvetica) should be the slowest This is because the time to BitBLT a font character from the bitmap font cache is assumed to be directiy proportional to the size that character occupies in memory. Note that although each of the fonts shown in (1), (2) and (3) are set at 12 points, they each appear to be a different size.
Expected Results The following relative scan conversion rates are expected: - Helvetica: fastest due to the simple style;
- , Times Roman: intermediate;
- Zapf Chancery: slowest due to the complex font style.
Once the font has been scan converted and placed into the bitmap font cache, all fonts are expected to print equally fast.
19
Section 2.1.1.5 - Problem Description 2. 1 .2. Resident vs. Downloaded Fonts
Problem Description
Fonts can be either resident in the printer (i.e. RIP) or be downloaded from the host computer (host-resident). Furthermore, fonts can be in either bit-map or outline format This section concentrates on observation of the performance differences between downloadable vs. printer-resident fonts. To simplify the task and to get more meaningful results outlines are compared with outlines, and bit-maps with bit-maps.
Downloading fonts can significandy impact system performance. The key parameter that effects performance is communication time (i.e. time to download the font). For outline fonts this may be about 30 KBytes per typeface at any size. For bit-map fonts the amount of data varies with the size of the font (see section 1.4). A full bit-map representing each character at each size is needed
Fonts can be in one of the following formats: Bit-map fonts A. Downloadable bit-map fonts;
B. Printer-resident bit-map fonts.
Adobe Bezier outline fonts
C. Resident in the Apple Laser Writer Plus printer (RIP and print engine combination); D. Host-resident, downloadable fonts in Adobe encoded Bezier format
Third party oudine fonts
E. Downloadable in fonts Bezier format described with generic POSTSCRIPT instructions;
All five of these formats are used to print simple text and are compared on a *performance basis in this secnon.
Three comparisons are made:
A vs. B Resident vs. downloaded bit-map fonts.
See sections .2. 2. 1 1 and 3.2. 1 .
C vs. D Resident vs downloaded Adobe outline fonts See sections 2.1.2.2 and 3.2.2.
D vs. E Adobe vs. third party downloaded outline fonts See sections 2.1.2.3 and 3.2.3.
20
Section 2.1.2 - Problem Description 2.1.2.1 Downloaded Bitmaps vs. Printer Resident (Cached) Bitmaps
Two bitmap fonts are used for this experiment: A. Downloadable bit-map font A hand-coded POSTSCRIPT bitmap font similar to the one described in section 2.3.3 is downloaded to the Apple Laser Writer Plus. For this experiment only ten 12-point characters were defined at 300 dots per inch. These ten characters are then printed. The download time as well as the printing times are both measured
B. Printer-resident bitmap font The Apple Laser Writer Plus has several pre-scan converted printer-resident bit-map fonts (reference 14). The 12 point Helvetica font is selected for this experiment The time to print the same ten character string is measured and. compared to the time taken with the downloadable bitmap font of (A).
Expected Results
The total time to print the downloadable font includes not only printing the ten character string but, even more significantly, also includes the time to download the bitmap font itself. A 12 point font is assumed at a printer resolution of 300 dots per inch. If a full character set were specified complete with upper and lower case letters, then the average size of a single character bitmap would be approximately 170 bytes, which is 50% of the 50 pixel by 50 pixel character bounding box (see section 1.4). Since the ten characters chosen for this experiment are all lower case letters it is assumed that, on average, the size of these ten character bitmaps are 25% smaller than the average bitmap across the entire character set. This brings the 170 bytes average per all characters down to 127 bytes average per lower case character. Therefore, the size of the combined bitmaps of the ten characters is 1,270 bytes. Since POSTSCRIPT describes all bitmaps with ASCII encoded hex, the bitmap data "A7" is expanded by a factor of two (i.e. a hex value of is coded as two sequential "A" ASCII characters: and "7". When this is taken into account the ASCII encoded bitmaps for the ten lower case characters take up 2,540 bytes. Examining the POSTSCRIPT bitmap font shown in section 2.3.3, it appears that the font overhead excluding the font metrics is about 1 Kbyte. The metrics information overhead is about 40 bytes per character or 400 bytes per the ten character set The anticipated dowloaded font size is:
2,540 bytes: bitmaps for ten characters 400 bytes: metric information for ten characters + 1.000 bytes: additional font overhead 3,940 bytes: expected size of ten character bitmap font
If the RS-232 serial communications interface is used at 9600 baud, then the expected download time for the 3,940 byte bitmap font is 4. 10 seconds. For this experiment Appletalk is used instead of RS-232, so a faster download time is expected. Note that the raw data transmission speed of Appletalk is 220 Kbits/sec, although the actual throughput is a fraction of this mainly due to protocol overhead. See sections 2.1.2.4 and 3.2.4 for more information on this topic.
Once the bitmap font is downloaded it is expected that the downloaded font will perform as well as the printer-resident bitmap font. The overall time to print the downloadable font will be significandy longer due to the font download time.
21
Section 2.1.2.1 - Problem Description Resident Outlines 2. 1.2.2 Adobe Downloaded Outlines vs. Printer (Internal)
Description . . - , . Problem ,. , , outline fonts (see section 2.4 for The Apple LaserWriter Plus printer has 35 resident can purchase additional fonts for use a list of resident fonts). In addition, a user are supplied on Macintosh with Macintosh application programs. These fonts several four: regular, italic, compatible micro-floppy discs and include (usually family. One printer outline font and bold, and bold italic ) styles of a single font screen fonts is provided per each style. several (about five different sizes) bitmap programs to provide the desired The bitmap screen fonts are used by application downloaded to the printer WYSIWYG effect. The printer outline font needs to be program to the printer before the application program can send the POSTSCRIPT with a that references that particular font This can be done either explicitly, the application program which downloads the outline printer font or implicitly, by interrogates the printer to program needing the font In the latter case the application the print program is determine in the font is already loaded into the printer. If it is, downloaded right before the simply downloaded. If it is not loaded, then the font is print program.
Section 3.2.2 compares a particular printer resident font Times-Roman to another Adobe outline font, the downloadable Stone Serif font They are compared on the basis of scan conversion speed, BitBLT from cache to page buffer speed, and download time.
Expected Results Whether the font originates from the host or an from an internal RIP font data structure (i.e. in ROM), the task of generating a bit-map from outline is essentially the same in either case, especially if both fonts were supplied by the same font vendor who, in this case, is Adobe Systems, Inc. So, the task of scan converting the outlines and the subsequent task of moving the cached bitmaps to the page buffer in the two cases are expected to yield similar results.
The font styles of the downloaded Adobe font called Stone Serif, was chosen to be similar in complexity to Times-Roman, the internal font it is being compared to. This was done to minimize the effect that varying the complexity of a font style has on performance. Section 2.1.1.5 and its complement, section 3.1.5 deal with this subject in detail.
The one area where a large difference in system performance is expected is in the area of font download time. Resident fonts are held in ROM so there is no download time. Downloaded outline fonts are approximately 30 to 40 KBytes in size. If an RS-232 serial interface were used running at 9600 baud the download time would be about 35 seconds. Since Appletalk is used this time should be less, but still significant
22
Section 2.1.2.2 - Problem Description 2.1.2.3 Adobe Downloaded Outlines vs. Third Party Downloadable Outlines
Problem Description
As mentioned in the previous section a user can purchase downloadable fonts for use with Macintosh application programs. These fonts are supplied on Macintosh compatible micro-floppy discs and include several (usually four: regular, italic, bold, and bold italic ) styles of a single font family. One printer oudine font and several (about five different sizes) bitmap screen fonts is provided per each style. The bitmap screen fonts are used by application programs to provide the desired WYSIWYG effect. The printer outline font needs to be downloaded to the printer before the application program can send the POSTSCRIPT program to the printer that references that particular font This can be done either expticidy, with a program which downloads the outline printer font or implicidy, by the application program needing the font In the latter case the application program interrogates the printer to determine if the font is already loaded into the printer. If it is, the print program is simply downloaded If the font is not loaded then it is downloaded right before the print program.
Downloadable fonts can be purchased from Adobe, the creators of POSTSCRIPT and POSTSCRIPT fonts. They can also be purchased from other third party vendors. There are several differences:
1 . Adobe fonts are encrypted
Third party fonts direcdy follow the convention set in the POSTSCRIPT Language Reference Manual with no encryption (reference 15).
2. Adobe fonts have "intelligence". That is, there is a proprietary Adobe algorithm hints" which reads the encrypted oudine font with "intelligence and scan converts the oudine producing a high quality font at the 300 dpi printer resolution.
Third party font outlines are treated as generic graphic shapes when scaled They do not have any "intelligence". The quality produced on a 300 dpi device is noticeably poorer at typical sizes (i.e. 10 or 12 point). Compare figures 3.2.3.A. 1 & 2 (no intelligence) to figures 3.1.1.A.1 & 2 (with intelligence).
3. Adobe fonts generally originate from well known font houses like Linotype and ITC and are aimed at providing virtually all printing and publishing needs.
Third party fonts generally are new designs with an unconventional artistic flare. Note, however, that the third party font selected for this experiment, the CasadyWare Galileo Roman font was chosen for its similarity (in style and complexity) to the Adobe Stone Serif font
4. Adobe fonts are typically more expensive, costing in the $100 to $300. As an example the list price of the Adobe Stone Serif font used in this section was $275.
Third party fonts are typically less expensive, costing in the $50 range. As an Roman example the list price of the CasadyWare Galileo font used in this section was $45.
23
Section 2.1.2.3 - Problem Description the Adobe Stone Serif and the Section 3.2.3 compares a two downloaded fonts, Roman on the basis of scan CasadyWare Galileo font. They are compared time. cache to page buffer speed and download conversion speed, BitBLT from
Expected Results , "intelligent" , outline is more The task of scan converting the Adobe inherendy outline (i.e. characters tike difficult than scan converting a non-intelligent treating outlines into bitmaps but the Adobe graphic shapes). Both tasks need to convert the incorporates the intelligence. This conversion has one more step, the step that should scan convert implies that the Adobe downloaded font (with intelligence) intelligence). slower than the CasadyWare downloaded font (without
stored in the font cache the task Once the bitmap has been generated from outline and same in either case. the task of of printing the bitmaps is essentially the So, moving similar die cached bitmaps to the page buffer in the two cases are expected to yield results.
Roman Both the Stone Serif and Galileo fonts are downloadable POSTSCRIPT outline fonts. It is assumed that their sizes are similar and subsequentiy their download times should also be similar.
The font styles of the downloaded Adobe font called Stone Serif, was chosen to be Roman similar in complexity to CasadyWare Galileo font it is being compared to. This was done to rninimize the effect that varying the complexity of a font style has on performance. Section 2.1.1.5 and its complement, section 3.1.5 deal with this subject in detail.
Probably the largest factor is the one that is least predictable. That is the variability introduced when comparing two different font vendors. Even if the original outlines were exacdy the same, how these outlines are converted into a POSTSCRIPT program may have significant effects on how fast they scan convert
24
Section 2.1.2.3 - Problem Description 2. 1 .2.4 Appletalk vs. RS-232 Comparison
Both the Appletalk and RS-232 communications interfaces were used throughout this paper. RS-232 was used more extensively due to the greater control this interface allows:
- ability to capture the real-time conversations between the host computer and the printer with a protocol analyzer,
- the predictable overhead (i.e. one start bit and one stop bit);
- the point to point nature of the interface.
Appletalk, on the other hand was used primarily to allow the download of Adobe and third party (CasadyWare) downloadable fonts. Sections 2.1.2.1-3 and their complementary sections 3.2.1-3 used Appletalk. It is more difficult to separate out the protocol overhead and interference from other computer systems sharing the Appletalk network. Nevertheless, Appletalk is looked at in this section and section 3.2.4 and compared with RS-232. The printing times are examined as well as the communications download throughput
Expected Results The printing times are expected to be the same. The communications interface should not influence the time that a page prints once it is downloaded
The raw data rate of the RS-232 communications interface is 9600 bits / second. It is shown in section 2.2.1 that the communications overhead is two bits per eight bit character (i.e. the start and stop bits). Therefore it is expected that the efficiency of the RS-232 interface will be 80% of the rated bit rate of 9600, or 7,680 bits per second.
The raw data of Appletalk is 230.4 KBits per second. It is expected that the effective throughput speed will be much less than the raw data rate, but how much is not easily predictable. It is expected though, that larger files will transfer at a slower effective data rate than small files, due to the packet size limitations of Appletalk. Again how significant this factor is, is not predictable.
25
Section 2.1.2.4 - Problem Description 2.1.3. Methods ofPrinting Strings
page in a number of ways Each method Strings of characters can be placed on a given printed in section 3.3. All of the fonts used outlined in this section will be timed and will be in resident outline format
terms. The exact experimental The following methods are described in general procedure used is described in section 3.3.
A. Simple unjustified text (i.e. "ragged right")
at specified point x y moveto string starts (x,y)
character is ( string of characters ) show string proportionally spaced
B. Justified texi widi the front end application providing the extra incremental spacing to be applied between adjacent characters, using the ashow command.
x y moveto string starts at specified (x,y) point
xinc 0 ( string of characters ) ashow characters are spaced proportionally withxinc added to relative x increment to every character, note "0" that is the y increment
C. Justified text with the front end application providing the extra incremental spacing to be applied between adjacent words, using the widthshow command
x y moveto string starts at specified (x,y) point
xinc 0 32 ( string of characters ) widthshow characters are spaced proportionally with xinc added to relative x increment to every character with an ASCII value of "32" "0" (i.e. a space); note that is the y increment
D. Justified text with a downloaded POSTSCRIPT program that calculates the excess space and distributes it between all adjacent characters within the line. The routine to justify a string of text is repeatedly called once per line. This routine provides the following functions:
- calculates the width of line of text
- calculates the extra space needed to fill the line;
- calculates the incremental space that must be added to each character to achieve proper justification (note: number ofcharacters in line is passed to this procedure);
- prints the line of text the ashow using command equally distributing the extra space in between adjacent characters within the string.
26
Section 2.1.3 - Problem Description E. This method is the same as that used in (D) on the previous page except the dowloaded justification program has one additional feature: it calculates the number of characters in the string.
F. This method is the same as that used in (E) above except the dowloaded justification program also handles the carriage return - line feed functions.
Expected Results
Each case uses more capabilities of the POSTSCRIPT page description language. It is expected that as cases A through F are timed and printed, the times will progressively get larger (i.e. page printing times get slower), indicating that the simpler any program is, the faster it executes.
"Targeting" 2. 1 .4. Resolution vs. Total Resolution Independence
POSTSCRIPT is a resolution independent language. Its default coordinate system is the point which Adobe defines to be exactiy 1/72 of one inch. If one knows the actual resolution of the printer to be R dots per inch, then the Current Transformation Matrix (CTM) can be set up to scale all coordinate references by R / 72. Then if only integer references are made, these references will map direcdy to the engine pixels. In other words, the CTM which maps user coordinates (now in R units per inch) to device coordinates (in R pixels per inch) is the unity matrix. If the POSTSCRIPT software has the intelligence to recognize this situation, a possible performance increase can be right" achieved The "ragged (case A) page described in the previous section will be printed and compared to a similar page with all of the coordinates given in integers representing pixels. The following POSTSCRIPT commands will be issued:
72 300 div dup scale change CTM to unity matrix
xnl vnl (string of text) show xnl vn2 (string of text) show
xnl vnm (string of text) show
Note that only if the actual print engine resolution is 300 dpi, and if the POSTSCRIPT "smart" imaging software is enough to recognize this case, can the potential performance gain be realized If the print engine resolution were, say 400 dpi, the CTM would not be the unity matrix and the output would be generated looking the same. That is why "targeting" this is termed resolution rather than resolution "dependence".
Expected Results The case that uses an integer coordinate system that corresponds to the print engine resolution should execute faster, it is not known how much faster.
27
Section 2.1.4 - Problem Description on POSTSCRIPT Processing Time 2. 1 .5 Effect of Varied Page Complexity
Program sec 2. 1.5. 1 Effect on the Inter-Page Time Delay
program which takes as its input an The sec program, shown below, is a delay designed to execute in n integer and a token (i.e. variable). It has been empirically final def command loads the where n is the integer passed to it. The seconds, "passed" to to the sec routine. measured sec execution time into the variable
/sec % one second delay under no load track of time taken { usertime /T exch def % keep actually
1228 { % loop that executes in 1 second under a load" "no condition 373.737 737.373 mul pop % }repeat } repeat usertime T sub def }def
"W7" /W7 7 sec % is the variable which will contain % the measured execution time of sec "7" % is the target number of seconds
Expected Results It is reasonable to expect a program to execute in a constant amount of time independent of the operations that are executed outside this program. This would normally be the expected results. However, during the course ofrunning other experiments it was observed that the measured time to execute sec varied as the contents, complexity, and position of text on the printed page varied Unless this phenomenon were not blindly stumbled upon, there would be no reason to suspect this to occur. Section 3.5.1 looks into this strange behavior and attempts to explain why it happens.
28
Section 2.1.5.1 - Problem Description 2. 1 .5.2 Effect on the Compilation and Rasterization of Text Pages
The sec program, described in the previous section, is used to induce delays in between the printing of consecutive pages. In this experiment the target delays are 0, 1, 2, 3, 5, 8, 12, and 16 seconds in duration. The nine pages printed are all the same page that is individually interpreted (or compiled) and rasterized each time. Figure 2.1.5.2.1 shows how these delays are interleaved with the task of printing these nine pages.
1 second 2 second 3 second delay delay delay
/ Print \ / Print \ 1 Print \ y Page j V Page } ^ Page /
8 second 12 second second fr ^^i + delay ? 1 delay
I Print v Page >
V- 16 second delay
Sequencing of Printing Pages
Figure 2.1.5.2.1
Expected Results As written in the previous section, it is reasonable to expect a program to execute in a constant amount of time independent of the operations that are executed outside this program. The last section dealt with the delay program sec. This section deals with the program that times and prints a page of text. In either case, this would normally be the expected results. However, during the course of running other experiments it was observed that the measured time to execute the printing of the pages varied as the delay time between pages varied. Once again, unless this phenomenon were not blindly stumbled upon, there would be no reason to suspect this to occur. Section 3.5.2 looks into this strange behavior and attempts to explain why it happens.
29
Section 2.1.5.2 - Problem Description 2.2 Measurement Techniques
Batch Program outlined in ThP PostScript text fdes generated by the Text Processing format shown betow. Noto that SSSSS^SSSf1. generals a file with the POSTSCRIPT file that has been generated by the Text Batch Annendix 2 2 4 contains a sample show the.actual hoe. of code References to appendix 2.2.4 are made to Sn? and Trailer. generated file: Header, Body, that correspondto the Lhree parts of the
the current time in a local variable and Header Two lines of POSTSCRIPT code that saves to be a callable procedure enabling timing sets up the text file that follows measurements to be taken.
Sec Appendix 2.2.4, page 1, (the first two lines):
/Tsd usertime def /Page{
instructions which selects fonts, positions the cursor Body A sequence of POSTSCRIPT at new-line positions, and writes strings of text.
page 2 to and See Appendix 2.2.4, page 1 (starting with the third line) to (up including the last show command:
/Times-Roman findfont 9.0 scalefont setfont
(effectively transfers the copy image to the paper.) show
Trailer POSTSCRIPT code that calls the Body a number of times, with different delays between calls, and keeps track of the Body download time, the page rasterization times and delay times; a trailer page with all of the timing information is also printed.
See Appendix 2.2.4, page 2 (starting with the first usertime instruction) to the end ofpage 6:
usertime /TO exch def % record time before showpage
showpage
The POSTSCRIPT usertime instruction is used extensively in recording times. When the usertime instruction is executed an integer representing the current time, in milliseconds, is placed on top of the stack. This is actually the time from power-up to the current time. To measure the time it takes to download the Body ofPOSTSCRIPT code, or to execute the Body (generate the corresponding page bit-map), a second time is taken. The first time is subtracted from the second time to derive elapsed time. This procedure is repeated a number of times. These times are kept in variables until all of the pages are printed. Then a final trailer page is printed (example shown on the second page of Appendix 2.2.5) showing the times, in milliseconds, and graphing the page generation times relative to the programatically induced delay times between the pages. Many different times are extracted in this way and are discussed more fully in sections 2.2.1 and 2.2.2. Figures 2.2.1, 2.2.2.1, and 2.2.2.2 illustrate how the times are used and are based on the example text POSTSCRIPT page shown in Appendix 2.2.4. Key instructions are extracted from the example in Appendix 2.2.4 and highlighted in these figures to explain the method used to measure the various times.
30
Section 2.2 - Problem Description 2.2.1 Communications
Please refer to figure the 2.2.1.1, Download Time Measurement , for following explanation. An initial time is loaded into the variable Tsd, start download time. The Page procedure contains the sequence of commands that specify the printed text "sees" on the page. However, the first time the POSTSCRIPT interpreter this sequence of instructions, previously called the Body, it does not execute them. Later, in the Trailer portion of the POSTSCRIPT file, the Page procedure is called and subsequendy executed. The first time through the Body simply passes through "sees" the interpreter until it the } def sequence, which tells the interpreter that the procedure Body, named Page, is done. Immediately following download of the Page Body another time is loaded into the variable Ted. The download time, Tdl, is derived by subtracting the start download time, Tsd, from the end download time, Ted.
To verify the validity of this method the times generated in this manner were compared to times generated by two other methods. A protocol analyzer was used to take two measurements: the actual download time and the number of characters that were downloaded. A Hewlette Packard 4953A Protocol Analyzer was connected in a (passive) monitor mode in between the host computer, which emits the POSTSCRIPT program to the printer, and the Apple LaserWriter Plus printer itself. The HP4953A was programmed to measure the time to download the Page portion of four increasingly more difficult pages. The first page did not print anything at all, but merely ejected pages. The second page printed the A through C sections of text shown in Appendix 2.2.5 in one font style, size, and orientation. The third page included printing of sections A through F; the fourth page, A through I. In all cases the trailer page reporting the measured download time using the POSTSCRIPT usertime operator was also printed. The rninimum and maximum recorded times (from five runs) are reported in column A of the table shown in
figure*>^ 2.2.1.2.
To measure the download times with the HP5953A Protocol Analyzer the triggers were set such that one of the protocol analyzer's internal timers was started at the beginning of the downloaded character stream being measusred and was stopped at the end of this same character stream. Measurements were taken on all five runs. The minimum and maximum times recorded with the protocol analyzer are reported in column B of the table shown in figure 2.2.1.2. In all four cases the maximum error is less than one percent, ranging from a maximum error of 0.02 % to 0.90 %.
The HP4953A Protocol Analyzer captures the entire character string that is transmitted It is temporarily stored in the protocol analyzer's internal memory buffer and then displayed on the protocol analyzer's CRT screen. Once on the screen, the relavant downloaded character stream is easily counted. The number of downloaded characters for all fourjobs are shown in column C of figure 2.2.1.2.
Job 1 downloaded 213 characters, ... job 4 downloaded 4,749 characters. To calculate the download time several transmission parameters must be known: # bits/character, # bits / second, # start bits, and # stop bits. This information was gotten by reading and interpreting the switch settings on the serial interface board used to drive the printer.
31
Section 2.2.1 - Performance Measurement and Calculation "Tsd" HMimitlllMIIIIIMtltl is the start download time -HI /Tsd usertime def
/Page {
/Times-Roman findfont 9.0 scalefont setfont
72.00 709.20 moveto The first time the PostScript file is (A. IMAGE LOOP. The KODAK EKTAPRINT "Page" downloaded the routine is electrically)show ... of film that is capable of being not executed, so the primary factors that influences Tdl (download time) > "Page" are the size of the procedure 72.00 48.00 moveto and the speed of the communication (... transfers the image to the paper. )show copy link.
usertime /TO exch def
showpage } def
is the end download time def"11 usertime j /Ted exch
Page
usertime Ted sub /TIB exch def
TO Ted sub /T1A exch def
Download Time (Tdl) = Ted Tsd sub /Tdl exch def "End Download Time (Ted) - Start Download Time (Tsd)
Download Time Measurement
Figure 2.2.1.1
32
Section 2.2.1 Problem Description # # # tp I- Cfl o On * (N On T1 o sw d 4 d d
2 x i ^ i fe u ea w o tt <* CN On , 1 < - < P d d :'.:d
S" -o MM 2 x> c ea C3 -*- -. c < "a e S2 O CO CO i S r. S -s t C c^ u E o S E o 8 c3 o o 1 1P co a o oo
o : u to *3 1 HS U S3 a> ^J o g Q NO On r~- Q->. 5 CO oo co cs *"* r On ^ w o in \D L 1 '-W K !r A i A 2 3 g CM t t f1 1 1 O rN r- 22 ! -^ to ^ 3 " O CO * o 1-H cs -J 33 Section 2.2.1 Problem Description The MTT-850/1650B multiple terminal interface is a 16 port serial controller internal to the Sun Microsystem 3/280 computer. Port 7 of this controller was used to download the POSTSCRIPT jobs for all of the experiments run for this thesis. The communication port was set up as follows: - baud rate = 9600 bits/second - character length - 8 bits - 1 start bit - 1 stop bit - No parity Calculating the download time is now a simple arithmetic calculation. To demonstrate this, job 4 is used below: Total number of bits per transmitted character = 1 start bit + 8 information bits + 1 stop bit = 10 bits / transmitted character * Download time (job 4) = 4.747 char 10 bits/char = 4.947 seconds 9600 bits /sec The calculated times forjobs 1 through 4 are shown in column C of figure 2.2.1.2 just below the # character entries. Once again the results are excellent. In all four cases the maximum error is less than one percent, ranging from a maximum error of 34 Section 2.2.1 - Performance Measurement and Calculation 2.2.2 Interpretation (Compilation) and Rasterization Once the Body is downloaded, it is then called and subsequently executed There are two parts to this task. The first is interpreting the string of ASCII bytes to generate the POSTSCRIPT tokens. It is assumed that these tokens are then executed in an interpretive nature, immediately generating the raster page bit-map. list" However, in some RIPs an intermediate "display is generated which better fits the hardware capabilities of the RIP. The combined process of tokenizing the ASCII list" string and generating this "display is commonly called "compilation". This "C" "ForTran" process is much like the process that is done by a or language compiler. The second part, called "rasterization", is the process of generating the raster image from either die list of tokens, in a single interpretive manner, or from a pre-compiled display list Since there is no way to externally separate the interpretation or compilation step from the rasterization step, they are treated atomically throughout this paper. Figure shows how the of the 2.2.2.1, Timing ofFirst Printed Page , timing first page is done. After the Body has been downloaded, the current time is stored in the variable /Ted. This is the same variable that was used in measuring the Body download time (see section 2.2.1). The Page call causes the Page procedure to be executed. All of the commands in the Body are inside the Page procedure. They consist of selection of fonts, positioning of new lines, and printing of strings of text The last POSTSCRIPT instruction in the Page procedure is showpage, which causes the page to be printed and the page buffer to be erased in preparation for the next page. Two times are taken immediately before and after this showpage instruction. The time that is of primary interest is the one following complete execution of the Page procedure. Upon completion of this procedure, program control returns to the instruction following the Page call. This instruction gets the current time, using usertime, subtracts the time value that was recorded prior to the Page call, in /Ted, and stores the difference in a new variable /TIB. /TIB now contains the time taken to fully generate the first page as specified in the Page procedure. A second time, stored in /T1A, is the same time as in /TIB, less the time taken to execute the showpage operator. 35 Section 2.2.2 - Problem Description /Tsd usertime def /Page { /Times-Roman findfont 9.0 scalefont setfont 72.00 709.20 moveto (A. IMAGE LOOP. The KODAK EKTAPRINT of electrica!ly)show ... of film that is capable being 72.00 48.00 moveto (... transfers the copy image to the paper. )show is the end of first page time /TO exch def "ill! "showpage" marker before the operator is executed. showpage } def "Ted" End Download Time is used usertime /Ted exch def""! "as the start time to measure the first page execution time. Page Start Here Current time, immediatly following execution of the first page procedure, usertime Ted sub /TIB exch def is the end of first page time marker (including "showpage"). TIB" holds the time it takes to completely execute the first page. T1A" M| i" mm iMiiiiiiiiiHiiiiiiiiiiiiiiiiiii holds the TO Ted sub /T1A exch def time it takes to print the first page, excluding execution of "showpage" the operator. Ted Tsd sub /Tdl exch def Timing of First Printed Page Figure 2.2.2.1 36 Section 2.22 Problem Description Figure 2 shows the of the 2.2.2.2, Timing ofPages Through 9 , how timing following eight pages is done. First two supporting POSTSCRIPT procedures must be described: /sec This procedure is passed a literal (eg. /W2) and an integer (eg. 2). The integer acts as the outer loop variable. The inner loop, which multiplies two real numbers 1,228 times, executed under a no-load condition has been "no-load" measured to yield a one second delay. The condition was simply "Trailer" the sec procedure with calls to it along with the page reporting "Trailer" these times. No printing of text strings, other than the page itself, was executed for this measurement. Also, delay times corresponding to the sec" integers passed to it produced the expected linear result That is "2 sec" yielded a two second delay, "3 yielded a three second delay, ... The literal preceding the sec call (eg. /W2) is loaded with the actual measured time of the induced delay. /Pr This procedure is also passed a literal (eg. IT4) that is loaded with the time taken to execute the Page procedure. Inside the Pr procedure times are taken before and after Page is called. The difference of these times are loaded into the literal. Using the sec and Pr procedures a total of nine pages are printed in the following manner: Print page 1 method shown in figure 2.2.2.1 no delay Print page 2 using Pr shown in figure 2.2.2.2 1 second delay using sec shown in figure 2.2.2.2 Print page 3 2 second delay : Print page 4 : 3 second delay Print page 5 5 second delay Print page 6 8 second delay Print page 7 12 second delay Print page 8 16 second delay Print page 9 All delays and measured page times are reported on the trailer page (see page two of Appendix 3.2.5). Additionally, the (delay before a page, page generation) time pairs are graphed showing the effect delays between page has on page rendering times. 37 Section 22.2 - Problem Description /Page { } def print first page Page Calling to "/sec { usertime /T exch def { 1228 This section of PostScript has been 1 second 373.737 737.373 mul popop / previously measured to take Jrepeat to execute with no other code running. repeat . } "W2" The variable is loaded with usertime T sub def I"'"!!! the actual measured time taken in > def L this procedure. This is the current "T" time minus the time recorded '/Pr when entering "sec". { , Call to print another page exch usertime /T def ."" lllllllllllllll IIIIMIIIIIIIHIIIIIII Da CTp l||[| "T4" iiimiiiiiiiiiMiiMiiimiHHiiHiiThe varialble is loaded with j usertime T sub def |il|||| } the actuale measured time taken to print this page. This is the current |||l fiiiiiiiiiiiiiiiiiiiiiiiiiiiiil""... time minus the time "T recorded "Pr" /T2 Pr "'"., when entering "' "No delay between pages 1 and 2 AVI 1 sec /T3 Pr "2" "sec" "The number is passed to the JW2 sec procedure to cause a 2 second delay. r _/T4Pr < Code that calls the procedures to cause a delay and print a page /W16 16 sec /T9 Pr Timing of Pages 2 Through 9 Figure 2.2.2.2 38 Section 2.22 Problem Description To test the repeatability of measurements the methodjust described was modified slightly. Instead of changing the delay times from page to page, all delays were set to be equal. Each job was executed eight times with the delay set to 0 for the 1st run, 1 second for the 2nd run, 2 seconds for the 3rd run, ..., and 16 seconds for the 8th run. During each of the eight runs perjob, nine pages plus the trailer page were printed. Print page 1 N second delay Print page 2 N second delay Print page 3 N second delay Print page 4 N second delay Print page 5 N second delay Print page 6 N second delay Print page 7 N second delay Print page 8 N second delay Print page 9 Print trailer with timing information N = 0 (no delay instructions are executed), 1, 2, 3, 5, 8, 12, and 16. The minimum and maximum times ofpages 2 through 9 are shown in figure 2.2.2.5. Minimum and maximum times of all eight delays per run are also recorded there. Three jobs were run: Job 1 prints a blank page. Job 2 prints a simple text page and shown in figure 2.2.2.3. The page had been printed before this experiment was done so that all of the fonts were already in bit-map form (see sections 2.1.2 and 3.2 for more on this). Job 3 prints a vector graphics page and is shown in figure 2.2.2.4. 39 Section 2.2.2 - Problem Description LOOP is a continuous of film that A. IMAGE LOOP. The KODAK EKTAPRINT IMAGE loop and is sensitive to direct light. The IMAGE LOOP is is capable of being electrically charged, continuous motion for as as exposures driven around the IMAGE LOOP CORE in a long copy are being made (see Figure 1). CHARGER is to place a negative B PRIMARY CHARGER. The function of the PRIMARY LOOP for exposure and development. charge on the IMAGE LOOP. This prepares the IMAGE LOGIC AND CONTROL. LOGIC AND The IMAGE LOOP starts moving on command from CONTROL then turns on the PRIMARY CHARGER. CORE to the EXPOSURE C. EXPOSURE. The charged IMAGE LOOP continues around the focused on the IMAGE LOOP at area, where it is exposed to a reflected light copy image that is CONTROL. The original document is precisely the right time, as determined by LOGIC AND illuminated by high intensity flash lamps for a short duration, which prevents blurring of the on IMAGE LOOP is image as it is exposed on the moving IMAGE LOOP. The charge the removed from the areas that are exposed to light The charge remains in the areas that are not characteristics of the IMAGE LOOP exposed. The exposure is said to discretely alter the charge IMAGE LOOP image so that the focused copy image is recorded on the IMAGE LOOP. This is known as an electrostatic image. D. AUXILIARY ERASE. Just before each first, and just after each last, exposure area is an improperly charged segment. These segments are produced when the PRIMARY CHARGER is turned on at the time of initial IMAGE LOOP movement and turned off during final IMAGE LOOP movement. As the unwanted areas pass under the AUXILIARY ERASE LAMP, it floods the moving IMAGE LOOP base with light that desensitizes the IMAGE LOOP to prevent unwanted development. E. DEVELOPER STATION ASSEMBLY. The properly charged and exposed IMAGE LOOP area now enters the DEVELOPER STATION ASSEMBLY where positively charged KODAK EKTAPRINT K Toner particles are attracted to the IMAGE LOOP. Development occurs as the result of attraction of the toner particles to the electrostatic image on the IMAGE LOOP. The toner particles are carried away on the IMAGE LOOP surface for later transfer to a copy paper. F. SCAVENGER ROLLER. Any developer carrier granules (iron) left on the IMAGE LOOP are salvaged at this point by the SCAVENGER ROLLER and returned to the DEVELOPER STATION ASSEMBLY. G. POST-DEVELOPMENT ERASE LAMP. To reduce the electrostatic stress on the IMAGE LOOP and thereby increases its life, the POST DEVELOPMENT ERASE LAMP is used to lower the high level charge that was required for proper image development This POST-DEVELOPMENT ERASE process also helps to prevent residual image retention. H. REGISTRATION. While the developed electrostatic image moves around the CORE, a sheet of copy paper is advanced to the REGISTRATION ASSEMBLY (not shown in Figure 1). At the right the paper precisely time, copy is directed into contact with the IMAGE LOOP and its developed image. This aligns the copy paper and the image on the IMAGE LOOP. I. TRANSFER CHARGER. The IMAGE LOOP and copy paper now pass under the TRANSFER which CHARGER, produces a negative charge on the paper surface to attract the positive charged developer toner. This effectively transfers the copy image to the paper. Note : The printed areas on this page excluding the region bounded by this rectangle is the printed test page output Simple Text Page page 40 Figure 2.2.2.3 Note : The printed areas on this page excluding the region bounded by this rectangle is the printed test page output Vector Graphics Page Figure 2.2.2.4 page 41 Repeatability Experiment Results: All of the repeatability results are shown in figure 2.2.2.5. The measured delay times were within 2 milliseconds per run. If one assumes the accuracy of the of the usertime command to be 1 millisecond, as the POSTSCRIPT Language Reference Manual indicates, the best results that can be (i.e.+/- expected is exactly 2 milliseconds 1 millisecond). However, as figure 2.2.2.5 as well as figure 2.2.1.2 shows, all differences are even numbers (in milliseconds). This suggests the accuracy may actually be limited to 2 milliseconds. In any event, this experiment shows exellent repeatabillity results for the delay time measurements. There is still one more interesting (puzzling?) point to note; that is, how the delay times change depending on the complexity of the job. This is not the expected result since one would normally expect die same instructions executed on the sftme processor to take the same amount of time. This point is further explored in sections 2.1.5 and 3.5. The measured page times were all within 0.46 % per run, and most were much better. The worst case is job 2 with a delay time of 16 seconds: a 28 millisecond variation was recorded which translates to a 0.46% error. The vector graphics job (#3) seems to yield more stable results than the textjob (#2) or even the blank page job (#1). Even though this experiment shows a small amount of variation from run to run, the results of less than 1/2 of 1 percent indicates that this method of measurement is adequate for timing of the experiments run for this thesis. 42 Section 2.2.2 - Problem Description Job 1 Job 2 Job 3 , 1 Input Blankpage Fullpage - simple text vector graphic Delay Time * min max %diff* * % difT min max min max % diff A V Mpficnrpft T\V1 " w 0 1 1006 1008 1714 1716 1712 1714 2 -<-2006-*- 3536 3538 -#-3536-^ 3 3004 3006 5156 5158 4904 4906 5 5004 5006 7154 7156 6904 6906 8 8002 8004 -4-40154 -? - .*_9904-#* 12 -4-12000 -? -4-14152 -? -#-13900 -? 16 -#-15998 -*? - 18148 18150 - * 17900 - . &!: Measured PAGE TIM! W 0 7362 7368 .08% 7364 7366 -#-10124 -#? ^_ 1 6354 6358 .06% 5646 5650 .07% 9410-*- 2 5356 5360 .07% 5088 5096 .16% 8588 8592 .05% - 3 4356 4358 4470 4476 .13% 8218 8220 ;- - 5 3512 3526 .40% 4466 4482 .36% 8218 8220 j -4- - 3518 -#- -*? 8 ? 6008 6014 .10% 8218 .20% 6062 .20% 12 5050 5060 6074 8214 8218 .05% 5104 5114 .20% 6054 .46% 16 6082 8214 8218 .05% Results of Repeatability Experiment Figure 2.2.2.5 fote: iftime difference is 2 msec. diff" rr less, "% is not shown 43 Section 2.2.2 Problem Description 2.2.3 Print Engine Paper Ejection Once the RIP has completed generating the bit-map page, the print engine main drive LBP-CX motor is turned on to start the actual page printing process. The Canon 8.5" 11" print engine page rate is 8 pages per minute. The x page is printed lengthwise. 8.5" That is the RIP writes each scan line in the direction. The Canon LBP-CX print engine employs a real-time serial interface to facilitate the transfer of the full page 8.5" " from the RIP to the print engine. To transfer an x 1 1 page at a 300 dot bit-map "video" per inch resolution at a rate of 8 pages per minute, the data interface must sustain a bit rate of approximately 1. 1 MBits/sec. This number is calculated as follows: * * * Bits /page ~= (8.5 inches 300 dots / inch) (1 1 inches 300 dots / inch) = 8,415,000 bits /page * Ave. data rate ~= (8,415,000 bits/page) (8 pages/minute) / (60 seconds/minute) = 1.122 MBits/sec. These calculated numbers are only estimates and will differ from the actual specified data rate for following reasons: 1 . The writeable scan width is not exacdy 8.5 inches, nor is the page length exactly 8.3" 1 linches (note that European A4 paper size is supported which is x 1 1.7"). 2. Most RIPs do not print on the outer 0. 1 inch border reducing the amount of page bit-map storage required. 3. There are inefficiencies in the transfer of data between scan lines and between pages. It is assumed that the RIP has hardware to serialize a 16 bit word and transmit this serial stream to the print engine. It is also assumed that no DMA (Direct Memory Access) hardware exists in the RIP. This means the RIP CPU must transfer a word from bit-map page memory to the parallel-to-serial converter word buffer approximately every 14 microseconds. This number is calculated as follows: Ave. data rate ~= l.lMbits/sec (from above) Time per word ~= (16 bits/word) / (l.lMbits/sec) ~= 14 microseconds/word At a 10 MHz CPU clock rate this out turns to be 140 clock cycles or every 14 microseconds. It is assumed the transfer takes ~ 14 clock cycles or 1.4 microseconds (estimate). A memory to memory word move takes 12 clock cycles if the source (page address is kept in an address register bit-map) that is post-incremented (An)+, and if the destination (memory-mapped address buffer) is kept in a second address register (An) (reference 27). Two additional clock cycles are added assvoming read and write memory that requires a nominal one wait-state, which brings the total to 14 clock cycles. This means that 10% of the approximately CPU is dedicated to performing the bit-map to print engine writing function. It is not the intent of this thesis to further evaluate the print engine specific performance, but the RIP performance. Exact numbers to drive the print engine can only be calculated or measured the exact by examining implementation. This is impossible due to the fundamental rule followed throughout all ofthe thesis* experiments run for this only external examination of the Apple Laser Writer Plus is allowed (i.e. no reverse-eneineering). 44 Section 2.2.3 - Problem Description It was observed that the page ejection time for a single page was approximately 15 seconds for the simplest POSTSCRIPT page. Once the printer main drive motor was in motion, however, subsequent pages could eject at a continuous 8 page per minute rate. Since only 10% of the CPU time is taken up by the data transfer to the print engine, 90% is free for communications and generation of the next page. Timing the interaction of the RIP with the print engine is further investigated in sections 3.5.1 and 3.5.2. 2.3 Programming Tasks A set of POSTSCRIPT programs are generated to test the performance of one implementation of POSTSCRIPT, namely that of the Apple Laser Writer Plus, while printing text in a variety of ways. Several support programs and packages that aid in the generation of these test pages are described below: 2.3.1 Extraction of Font Widths from Apple Laser Writer Plus The POSTSCRIPT program shown in appendix 2.1.1 interrogates the Apple Laser Writer printer to extract three sets of font widths at a font size of 10 points. The numbers extracted are real numbers, in points, representing the font width of each "stl" printable character specified in strings and "st2". These widths are needed by the Batch Composition Program, described in section 2.3.2 below, which implements a simple line break algorithm. Figure 2.3.1 shows how the POSTSCRIPT Font-Width Interrogation Program fits into the task of automatically generating POSTSCRIPT text pages. The program shown in appendix 2.1.1 requests the Times Roman, Times Italic, and Times Bold fonts. Similar programs were written to get the other four fonts required of the Batch Composition Program. Appendixt 2.1.2 shows the page of font widths printed on the Apple Laser Writer Plus when sent the program shown in appendix 2.1.1. In order to put the font width information into a file that the Batch Composition Program could use, a Unix file was "vi" hand created using the editor on a Sun workstation. The format of this file, consisting of (character,width) pairs, is shown in appendix 2.1.3. 45 Section 2.3.1 - Problem Description Apple Laser Writer PostScript Plus Printer Printed Font see POSTSCRIPTS Width appendix see Font * Width Tables 2.1.2 Interrogation appendix 'rogram 2.1.1 j Hand Editing Structural Session to see Markup Files Create UNIX appendix Font-Width File 2.1.3 see appendix 2.2.3 H Fetch Font PostScript Widths,, Header Program Text Batch Processing Program PostScript Trailer 2fi see appendix 2J2.1 see Program appendix 2.2.2 Generate PDL File "SGML-Like" Pre-Justified Justified Text Files PostScript^ (paragraphs Files are delimited) Hand Code v Add in -^Graphics Key to Programming Languages: POSTSCRIPT by Hand POSTSCRIPT To Printer Logical Row to Generate Benchmark PostScript Pages Figure 2.3.1 46 Section 2.3.1 Problem Description 2.3.2 Batch Composition Program A batch composition program, written in C, generates a POSTSCRIPT file using two SGML-like files for input. Appendix 2.2.2 shows one type of an input file that contains the printable text with beginning and end ofparagraph markers, and
Font typeface (number corresponding to a name) and font size in points;
Leading multiplier (1.0 indicates that the vertical spacing is equal to the font size);
Width of the printed justified line, in inches;
Justification method (one of 6 possible types, corresponding to section 3.3);
(x,y) Cursor position, in points, at which the first character is printed.
In the example shown in appendix 2.2.3, structure commands for nine paragraphs are specified. There are nine tines of commands contained within the < and > symbols, corresponding to exacdy nine paragraphs in appendix 2.2.2, which are delimited by the pair
and
. The structure commands of the first paragraph are:F 1 9.0 Font number 1 (Times Roman); 9 point
L 1.2 leading Multiplier of 1.2 meaning the vertical spacing from line to line is 1.2 times the size of the font (9 point). For the first paragraph the distance from the baseline of one line of text to the baseline of the line of * text directly below it is 10.8 points (1.2 9).
W 6.5 Width of the lines of text are limited to 6.5 inches. In other words, the batch composition program inserts a line break after 6.5 inches of text read in.
J 1 Justification method number 1 : simple ragged right utilizing the simple POSTSCRIPT show command. See section 5.1.3 for the mapping of the other methods that are experimented with.
C 72.0 720.0 Starting (cursor) position at (x=72 points, y=720 points) Since 72 points equals one inch, the point at which the printing starts is one inch from the left edge of the page and 10 inches from the bottom edge of the page (or one inch from the top).
47
Section 2.3.2 - Problem Description commands are issued. All of the other (non-font For paragraphs 2 through 9 only font still in effect until changed. Note that when the related) commands shown above are with the size of the font even font size changes, the vertical line spacing changes along command for: though the leading multiplier L stays constant at 1.2. The
paragraph 2 is F 1 11.0 = Font 1 (Times Roman); 1 1 point
paragraph 3 is F 1 13.0 = Font 1 (Times Roman); 13 point
paragraph 4 is F 2 9.0 = Font 2 (Times Italic); 9 point
paragraph 5 is F 2 11.0 = Font 2 (Times Italic); 1 1 point
paragraph 6 is F 2 13.0 = Font 2 (Times Italic); 13 point
paragraph 7 is F 3 9.0 = Font 3 (Times Bold); 9 point
paragraph 8 is F 3 9.0 = Font 3 (Times Bold); 11 point
paragraph 9 is F 3 9.0 = Font 3 (Times Bold); 13 point
Appendix 2.2.1 is the pseudocode for the C program that generates the POSTSCRIPT file from these two SGML-like input files. This Batch Composition program calculates how many words, along with their associated interword spaces, fit within the line width specified in the "Markup File". In POSTSCRIPT fonts and their widths are linearly scaled. So the Batch Composition program uses the font widths shown in Appendix 2.1.3 and scales these widths appropriately (i.e. linearly). The POSTSCRIPT file generated from the input files of appendices 2.2.2 and 2.2.3 is shown in Appendix 2.2.4, with the actual Apple Laser Writer Plus printer output shown in Appendix 2.2.5.
48
Section 2.3.2 - Problem Description 2.3.3 Downloadable POSTSCRIPT Bitmap Font Program
The program shown in figure 2.3.3.1 is a part of one that is listed in the POSTSCRIPT Language Tutorial and Cookbook (Reference 17). Two small changes were made to make this example and the experiment of section 3.1.1 simpler. First, the number of characters defined was limited to ten: only ten of the defined" twenty-five characters (plus a special "not blank character) were specified in the encoding vector, and similarly bitmaps for the same ten characters were defined when building the CharData dictionary. Second, the string to be printed consisted of only one occurrence of each of the ten characters instead of five lines (one sentence) of text In other words, all ten characters were printed exactiy once.
A user-defined font must contain the following entries:
FontMatrix transforms the character coordinate system into the user coordinate system. In the program shown in figure 2.3.3.1 it is the unity matrix.
"3" FontType must be the integer for user defined fonts.
FontBBox specifies the (x,y) coordinates for the lower left and upper right corners of an imaginary box that represents the smallest rectangle in which all the characters of the font being defined would simultaneously fit, assuming all of their origins were coincident. In the program shown in figure 2.3.3.1 the lower left comer has the coordinate (-0.16, -0.24), and the upper right corner has the coordinate (1.28, 1.2). Note that later in the
program the imagemaskmatrix , an input to the imagemask operator, is set up to map a 25 pixel character (baseline to baseline) to the character coordinate system which is one unit wide and high. Taking this into account the coordinates shown above map into the following pixel coordinates: lower left comer is (-4, -6); upper right comer is (32, 30). Figure 2.3.3.2 shows "g" this mapping graphically for the character of the user defined font of figure 2.3.3.1.
Encoding is a 256 element array which maps the array indices to character names. In the case of printer resident fonts these names, in turn, serve as keys in the CharStrings dictionary to reference the (proprietary) executable character drawing programs. In the case of a user defined font, a procedure provided by the user, which must be named BuildChar, uses the Encoding vector to find the character name which serves as a key into the CharData dictionary. Information in this dictionary is used by the BuildChar procedure to render the character. More information on the BuildChar procedure is given on the following page.
In the program shown in figure 2.3.3.1 the Encoding vector maps ASCII character codes to the letters, "a", "b", "c", "d", "e", "f, "g", "h", "i", and ' "m". All other character codes have been set up to reference the ".notdef character which does nothing.
49
Section 2.3.3 - Problem Description BuildChar is a procedure provided by the user to render the desired character. The specific BuildChar routine shown in figure 2.3.3.1 is described below in detail.
name the character The current font dictionary, whose is Bitfont , and code is passed to BuildChar.
/BuildChar { 0 begin current diet, is temporarily stored on stack
/char exch def character code and /fontdict exch def font dictionary are stored locally
/charname fontdict /Encoding get put the Encoding vector on top of the stack char get access the character name "charname" def and store it in
/charinfo fontdict /CharData get put the CharData diet on top ofthe stack "charname" charname get access info associated with "charinfo" def and store it in
"charinfo" /wx charinfo 0 get def 1st element of array is char width
/charbbox charinfo 1 4 next four elements are lower left (x,y) and getinterval def upper right (x,y) coordinates of the individual character bounding box
wx 0 charbbox need to call setcachedevice with x and y aload pop cursor advancement values, and the setcachedevice character bounding box llx, lly, urx, and ury
charinfo 5 get width and height of bitmap image for the charinfo 6 get imagemask command
true invert the image (imagemask input)
fontdict /imagemaskmatrix get dup 4 get x translate "charinfo" from the array and charinfo 7 get put add it to the imagemaskmatrix dup 5 get "charinfo" y translate from the array and charinfo 8 get put add it to the imagemaskmatrix matrix is used as imagemask input
charinfo 9 1 getinterval get the character bitmap cvx "proc" make it executable and use as the imagemask for the imagemask command
end make previous dictionary the current one }def end of BuildChar procedure
50
Section 2.3.3 - Problem Description 9 diet dup begin /FontType 3 def /FontMatrix [10 0 10 def 0] /FontBBox {1.28 1.2 -0.16 -0.24] def /Encoding 256 array def 0 1 255 {Encoding exch /.notdef put) for
of ASCn v2!"es to dup 97 /a put dup 98 /b put dup 99 /c put dup 100 16 put dup 101 /e put dup 102 n put\MaPpin8 character names. These dup 1 03 /g put dup 1 04 ,'h put dup 1 05 /i put 1 09 /m put /
_f names then act as keys into "CharStrings" /BuildChar the dictionary {0 begin referencing the character /char exch def descriptions themselves /fontdict exch def /charname fontdict get char get def /Encoding "BuildChar" /charinfo fontdict /ChaiData get charname get def is passed the current font /wx charinfo 0 get def dictionary and the character code of the /charbbox charinfo 1 4 getinterval def > character to be printed. It then constructs wx 0 charbbox aload pop setcachedevice the character from the information shown charinfo 5 get charinfo 6 get true below. fontdict /imagemaskmatrix get dup 4 charinfo 7 get put dup 5 charinfc 8 get pu! charinfo 9 1 getinterval cvx imagemask end Jdef
/BuildChar load 0 6 diet put /imagemaskmatrix [25 0 0 -25 0 0] def /CharData 11 diet def
CharData begin
/a[.64 .04 0 .56 .56 13 14 -1.5 13.5
/b[.64.04 .76 -1.5 0.56 13 19 18.5 ten 6-point
/d[.64 .04 0 .56 .76 13 19 -1.5 18.5 <001 8001 8001 800 1 8001 80F983FD870786038C01 8C01 8C01 8C01 8C01 8C01 8603870783FD80F98>]def
/e[.64.04 0.56 .56 13 14 -1.5 13.5
<0E1E383030FEFE303030303030303030303030>]def
/g[.64 .04 -0.16 .56 .56 13 18 -1.5 13.5 <0F983FD870786038C01 8C01 8C01 8C01 8C01 8C01 8C03870783FD80F98601 870303FF00FC0>]def
/h[.6 .04 0 .52 .76 12 19 -1.5 18.5
/i[.2.04 0.12 .76 2 19 -1.5 18.5
/m[.92.04 0.84 .56 20 14 -1.5 13.5
/.notdef [.24 0 0 0 010 0 o]def
/Squeid 2 def PostScript Downloadable end Font /Bitfont exch definefont pop Bitmap /Bitfont findfont 40 scalefont setfont 100 100 moveto (abedefghim) show Figure 2.3.3.1 showpage
51
Section 2.3.3 : Problem Description Figure 2.3.3.2 shows one line of the CharData dictionary which was put into the "g" charinfo variable in the BuildChar procedure. The charinfo data for is as follows:
.64 x direction cursor advancement (16 pixels)
(.04, -.16) lower left comer coordinate of the character bounding box (1,-4) pixels
upper comer of (.56, .56) right coordinate the character bounding box (14, 14) pixels
1 3 width of character in pixels
1 8 height of character in pixels
(-1.5, 13.5) x and y translation components in pixels
52
Section 2.3.3 - Problem Description Bounding Box
in pixels = 13 Lower Left Comer Upper Right Comer of Character Box of Character Bounding Box Bounding x - direction cursor is , is ( [.04*25] , [-.16*25] ) ( [.56*25] [.56*25] ) advancement = = d,-4) (14,14) * = .64 25 16
height of character in pixels f
.56 -1.5 /g [ .64 .04 -.16 .56 13 18 13.5 < bit-map data > ] def (x,y) translation components
Character Definition of a PostScript Bitmap Font
Figure 2.3.3.2
53
Section 2.3.3 : Problem Description 2.3.4 Installing Downloadable POSTSCRIPT Outline Fonts
Stone Provided with the Adobe Serif font disk is a program, called FontDownloader, that establishes a connection with the Apple LaserWriter Plus via the Appletalk network Stone and downloads the Serif outline fonts. This type of manual downloading causes the downloaded font to remain in the printer until it is turned off or restarted. Once the font has been downloaded it can be referenced by its assigned name, StoneSerif for the Stone Serif font with the following POSTSCRIPT instructions:
/StoneSerif findfont 12 scalefont setfont
In addition to the manual method ofdownloading fonts there is another one, which is called automatic. To use the automatic method, first the screen font must be installed with the FontlDA Mover program so that the application program can access it for display on the screen. Font metric information is also included in the screen font file and is needed to calculate line and character positioning. Second, the downloadable printer fonts must be placed in the System directory. When Print is activiated through the application program, the printer driver immediately interrogates the printer to get a list ofprinter resident fonts. If the font selected with the application program is not resident inside the printer, then the printer driver looks for the downloadable font in the System directory. If it is found, the font is automatically downloaded. If not, a scaled version of the corresponding screen bitmap font is downloaded instead. This causes a very significant degradation offont image quality. After the POSTSCRIPT file has finished printing, the downloaded font is deleted from the printer. For this reason the font is said to be temporary.
Only the manual download method was used for this paper. The results are reported in sections 3.2.2 and 3.2.3.
54
Section 2.3.4 - Problem Description 2.4 Assumed RTP Architectural MorlPl
The hardware and software models of the Apple Laser Writer Plus is presented below. The information was extracted from the references specified (see section 6). Full bibliography entries can be found in section 7.
RIP Hardware MC68000 microprocessor + 7.455 MHz (Reference 28)
- 1.0 MByte of ROM (Read Only Memory) (Reference 17) + printer control routines + Adobe Systems POSTSCRIPT page description language interpreter (version 42.2) + printer diagnostic routines + printer emulator routines + Appletalk routines + error-reporting routines + outline fonts (35 fonts) + bit-map fonts ( see Pre-cached Bit-maps reference below)
- 2.0 MBvtes of RAM (Random Access Memory) (Reference 28) + Appletalk data buffer (Ref 28) + frame buffer for constructing the bitmapped page image (Ref. 28) + font cache buffer for caching character bitmaps (Ref. 28) + display list buffer for storing compiled POSTSCRIPT (Ref. 28) + virtual memory - 175KBytes (Ref. 23) + downloadable fonts (Ref. 28)
Fonts (Reference 18) All fonts are printed in 14 point. Resident fonts on the Apple LaserWriter and LaserWriter Plus include:
Annie Laser Writer (original 13 faces)
Times Roman Bold Italic Bold Italic
Helvetica Regular Bold Oblique Bold Oblique
Courier Regular Bold Oblique Bold Oblique
Symbol
55
Section 2.4 - Problem Description Anp'f T -mr WH*pr Pl"s Additional 22 faces)
New Century Schoolbook Roman Bold Italic Boldltalic
ITC Bookman Light Light Italic Demi Demi Italic
ITC Avant Garde Book Book Oblique Demi Demi Oblique
Helvetica Narrow Regular Bold Oblique Bold Oblique
Palatino Roman Bold Italic BoldItalic
ITC ZapfChancery Medium Italic
ITC Zapf Dingbats
56
Section 2.4 - Problem Description Internal resident outline fonts (Reference 19) The Apple LaserWriter Plus stores fonts in an outline format, and rasterizes individual characters at the desired font, style, size, and orientation when it is specified in the POSTSCRIPT program
Font bit-map cache (References 20, 21) In a POSTSCRIPT printer, the first time a character appears in a particular font, style,
cache" point size and rotation angle, its dot image is stored in a "font (a reserved portion of the printer's memory), so that the next time it appears it doesn't need to be re-imaged. 160 KBytes of the total 1.5 MBytes of RAM is used for font caching.
Full page bit-map memory (References 22, 23) The Apple Laser Writer Plus bit-map memory is normally limited to an area of 8 inches by 10.75 inches. This uses up 967,500 bytes, which is 61.5 % of the available 1.5 MBytes of RAM:
RAM required to image an 8 inch by 10.75 inch area (8 inches * 300 dots/inch) * (10.75 * 300 dots/inch) = 7,740,000 bits = 967,500 bytes
Percent of the total RAM available 967,500 / 1,572,864 = 61.5 %
It is possible to image a full letter-size page on the LaserWriter Plus, but the memory "borrowed" must be from other functions, such as space for downloadable fonts. To image die entire 8.5 inch by 11 inch area, 1,051,875 bytes of RAM is required, which is 66.9 % of the total 1.5 MBytes. This is an additional 84,375 bytes, or an additional 5.4 % of the total RAM in the system, over the smaller, and generally acceptable, 8 inch by 10.75 inch area.
RAM required to image an 8.5 inch by 11 inch area (8.5 inches * 300 dots/inch) * (11 * 300 dots/inch) = 8,415,000 bits = 1,051,875 bytes
Percent of the total RAM available 1,051,875 / 1,572,864 = 66.9 %
Difference of RAM used for the two imaging areas = 1,051,875 - 967,500 = 84,375 bytes 5.4%
Pre-cached Bit-maps for selected fonts and sizes (Reference 24) Times-Roman- Helvetica-12 and Courier-10 are the most 12 (point) , (point) , (point) frequendy used fonts in business communications. By having these fonts already bit-mapped in ROM, the page can be assembled much faster than if the fonts had to be reconstructed for each printing job.
Print Engine Specifications Canon LBP-CX Laser Beam Printer - laser-scanning - xerographic (electrophotographic) printer
- 8 page per minute maximum page rate
- 300 dots per inch resolution
57
Section 2.4 - Problem Description 58
Section 2.4 - Problem Description 3. Analysis of Experimental Results
3.1 Font Formats; Outline vs. Bit-Maps
3. 1 . 1 Real Time Outline Font Rasterization and Caching
3. 1 . 1 . A. Experimental Results
Two experiments were run according to the procedure described in section 2.2. For each of the experiments two runs of nine pages were printed: the first run immediately followed the printer power-up sequence; the second run followed the first run. The programmed wait times in between pages ranged from 0 seconds (no delay) to 16 seconds. Only the times of the first page of each run is reported in figure 3.I.I.A.3. The program which measures the time to generate the first page is described in section 2.2 and shown in figure 2.2.2.1
Two test programs were used which resulted in the printed pages shown in figures 3.1.1.A.1 and 3.I.I.A.2. The first program prints 96 characters of the 1 1 point Times Roman font in two lines. The page this first program prints is shown in figure 3. 1.1.A. 1. The Body of code contains the following sequence of POSTSCRIPT instructions:
Times-Roman findfont 1 1 scalefont setfont 72 720 moveto (!"$%&' ... MNOP) show 72 720 moveto
(QRST ... yz{|}~) show
The second program, which prints the page shown in figure 3.1.1.A.2, prints the same two lines as above, but in addition prints an additional 41 lines that contain a total of an additional 2,243 characters.
The timing measurements are shown in figure 3.1.1.A.3 in a bold typeface. The first column of figure 3.1.1.A.3, with the heading of 96 char., is split with two different shades of gray. The entry in the first row, labeled 1st after region page power-up , appearing in the light gray is the measured time to print the page shown in figure 3. 1.1.A. 1 the first time after a power-down / power-up sequence. This measured time of 34.860 seconds includes the time to scan convert all of the 96 character outlines, since powering down and powering up the printer clears the bitmap font cache. The entry in the pre-cached the region second row, labeled 1stpage , appearing in dark gray is the measured time to print this same page for the first time of the second run. During the first run all of the characters were scan converted and placed into the font cache, so this second measured time of 5.154 seconds includes only the time to move (BitBLT) all of the 96 character bitmaps from the bitmap font cache to the page buffer.
59
Section 3.1.1 : Analysis of Experimental Results The second column of figure 3.1.1.A.3, with the heading 2,339 (96 + characters split into a white and a region. The in the 2243) , is gray entry in the white region is the first row, labeled 1stpage afterpower-up , measured time to print the page shown in figure 3.1.1.A.2 after a power-down / power up sequence. This measured time of 35.746 seconds includes the time to scan convert the initial 96 characters, printed in the first two lines of the page, as well as the time to move (BitBLT) the remaining 2,243 characters from font cache containing the newly entered character 1stpage pre-cached bitmaps. The entry in the second row, labeled , appearing in the gray region is the measured time to print this same page for the first time of the second run. This second measured time of 5.946 seconds includes only the time to move all 2,339 characters from the bitmap font cache to the page buffer.
Note that it is impossible to completely isolate the scan convesion time or the BitBLTing time from the overall time ofprinting a POSTSCRIPT page. In an attempt to extract a major portion of the printing overhead a very simple page was printed and timed. The job consists of a single character being positioned and printed on the page. The character being printed was pre-cached by running one of the programs disussed earlier. A time of 5.124 seconds was measured to print this almost blank page. The remaining values shown in figure 3.1.1.A.3 are calculated in the analysis section which follows.
3.I.I.B. Analysis
Four methods were used to calculate the speed, in characters per second, that Plus the Apple Laser Writer can print from the font cache:
1. Methods one and two are similar. Focus on the first row of figure 3.1.1.A.3 entided 1stpage afterpower-up. The entry in the first column, 34.860 seconds, is the total time taken, including overhead, to scan convert and print 96 characters. The entry just to the right of this, in the second 35.746 column, seconds, is the total time taken to do exacdy the same task as before, plus move an additional 2,243 characters from font cache to the page buffer. So, the time that can be attributed specifically to moving, or Bit BLTing, the additional 2,243 characters can be calculated the by taking difference of these two values. This yields the value 0.886 seconds and can be found in the third column labeled BitBLT 2243 char.
- from cache . calculated Dividing the number ofcharacters that are moved from cache (2,243 characters) by the time needed to move them (0.886 yields seconds) the rate at which the printer can render characters from font cache (2.532 characters per seconrtt
2. Now focus on the second row of figure 3.1.1.A.3 entitled 1st page pre-cached . The in entry the first column, 5.154 seconds, is the total time taken, including overhead, to BitBLT the 96 printable ASCII characters from font cache. Similar to the case described in (1) above the in the second entry column, 5.946 seconds, is the time to do the same task plus BitBLT an additional 2,243 characters. Once again the difference of these numbers representing the time to BitBLT 2,243 characters is calculated and placed in column three. The time to BitBLT teFS iS ?o902o^onds- 2'243 -792 yields a SSm t v f DividinS by ' BitBLT character rate of 2.832 characters per semnH
60
Section 3.1.1 : Analysis ofExperimental Results "L" 3. Methods three and four are similar. Focus on the dark gray shaped band in that highlights the 96 char, column and the BitBLT 95 charfrom cache column. The time to print 95 pre-cached characters is 5.154 seconds. The overhead to print one pre-cached character is 5.124 seconds. Subtracting out this overhead yields 0.030 seconds to BitBLT 95 characters (i.e. 96-1). Dividing these numbers produce a character BitBLT rate of 2.843 characters per second.
"L" 4. Now focus on the light gray shaped band in that highlights the 2,339 (96 + 2^43) characters column and the BitBLT 238 charfrom cache column. The time to print 2,339 pre-cached characters is 5.946 seconds. Subtracting out this overhead yields 0.822 seconds to BitBLT 2,338 characters (i.e. 2,339 - 1). Dividing these numbers produce a character BitBLT rate of 3.167 characters per second.
The calculated character BitBLT rates range from 2,532 to 3,167 characters per second. The accuracy of method four is suspect due to the small time value to BitBLT 95 charactersfrom cache, 0.030 seconds. In section 2.2 it was shown that the methods used for the experiments throughout this paper can routinely be off, from run to run, by 0.010 second or more (see figure 2.2.2.3). With such a combined change in either the 96-character page print
time or the 1 -character page print time, the character per second rate would change from 2,375 (+ 0.010 change) to 4,750 (- 0.01. change). Therefore the results produced with method four will not be used. Methods one, two and three produce results within 11% of each other. Since methods two and three produce very similar results (less than 0.4%) and since method two produced a result between the results from methods one and three, the value produced by method two (2,832) will be used for further evaluation.
"L" Now focus on the outermost shaped gray band that highlights the 96 char, column and the Scan Convert 96 characters row. It takes 34.860 seconds to print a 96-character page the first time after a power-down / power-up sequence. This time includes scan converting the 96 characters. When the overhead associated with printing an almost blank page, 5.124 seconds, is subtracted from 34.860 seconds, the difference generated, 29.736 can be specifically attributed to the scan conversion of the 96 character outlines to bitmaps. Dividing 96 characters by the time to scan convert 96 characters yields the character per second scan conversion rate of 3.228 characters per second.
In this case, printing from the font cache was 877 times faster than scan converting the original outline. The POSTSCRIPT Language Reference Manual states that "printing a character that is already in the font cache is a thousand times faster than scan converting it from the character typically font" description in the (reference 12) 877 is rather close to the expected value of 1,000.
Improvements 3. 1 . 1 .C. Proposed
Add hardware speedup for the scan conversion.
61
Section 3.1.1 : Analysis of Experimental Results r#$%&'0*+,--/0123456789:;<=>?@ABCDEFGHIJKLMNOP
- l~abcdefghijklmnopqrstuvwxyz I QRSTUVWXYZNAJ { j
Note : The printed areas on this page excluding the region bounded by this rectangle is the printed test page output
96 characters of 11 point Times-Roman
page 62 Figure 3.1.1.A.1 !"#$%&'0*+,-y0123456789:;<=>?@ABCDEFGHIJKLMNOP QRSTUVWXYZMAj|~abcdefghJjklmnopqrstuvwxyz{l}~
A. IMAGE LOOP. The KODAK EKTAPRINT IMAGE LOOP is a continuous of film that is capable of loop being electrically charged, and is sensitive to direct light. The IMAGE LOOP is driven around the IMAGE LOOP CORE in a continuous motion for as long as copy exposures are being made (see Figure 1).
PRIMARY B. CHARGER. The function of the PRIMARY CHARGER is to place a negative charge on the IMAGE LOOP. This prepares the IMAGE LOOP for exposure and development. The IMAGE LOOP starts moving on command from LOGIC AND CONTROL. LOGIC AND CONTROL then turns on the PRIMARY CHARGER.
C. EXPOSURE. The charged IMAGE LOOP continues around the CORE to the EXPOSURE area, where it is exposed to a reflected light copy image that is focused on the IMAGE LOOP at precisely the right time, as determined by LOGIC AND CONTROL. The original document is illuminated by high fh?h intensity lamps for a short duration, which prevents blurring of the image as it is exposed on the moving IMAGE LOOP. The charge on the IMAGE LOOP is removed from the areas that are exposed to light. The charge remains in the areas that are not exposed. The exposure is said to discretely alter the charge characteristics of the IMAGE LOOP so that the focused copy image is recorded on the IMAGE LOOP. This IMAGE LOOP image is known as an electrostatic image.
D. AUXILIARY ERASE. Just before each first, and just after each last, exposure area is an improperly charged segment. These segments are produced when the PRIMARY CHARGER is turned on at the time of initial IMAGE LOOP movement and turned off during final IMAGE LOOP movement. As the unwanted areas pass under the AUXILIARY ERASE LAMP, it floods the moving IMAGE LOOP base with light that desensitizes the IMAGE LOOP to prevent unwanted development
E. DEVELOPER STATION ASSEMBLY. The properly charged and exposed IMAGE LOOP area now enters the DEVELOPER STATION ASSEMBLY where positively charged KODAK EKTAPRINT K Toner particles are attracted to the IMAGE LOOP. Development occurs as the result of attraction of the toner particles to the electrostatic image on the IMAGE LOOP. The toner particles are carried away on the IMAGE LOOP surface for later transfer to a copy paper.
F. SCAVENGER ROLLER. Any developer carrier granules (iron) left on the IMAGE LOOP are salvaged at this point by the SCAVENGER ROLLER and returned to the DEVELOPER STATION ASSEMBLY.
G. POST-DEVELOPMENT ERASE LAMP. To reduce the electrostatic stress on the IMAGE LOOP and thereby increases its life, the POST DEVELOPMENT ERASE LAMP is used to lower the high level charge that was required for proper image development This POST-DEVELOPMENT ERASE process also helps to prevent residual image retention.
Note : The printed areas on this page excluding the region bounded by this rectangle is the printed test page output
Page of 1 1 point Times-Roman text; all 96 printable ASCII characters are printed at least once; 43 lines of text; 2,339 non-space characters; 427 inter-word spaces.
Figure 3.1.1.A.2 page 63 BitBLT Times-1^oman 2,243 char. char /sec from cache 2,339 96 char. (96 + 2,243) calculated calculated characters
1st page 34.860 35.746 0.886 2,532 after power up
1st page 5,154 5.946 0.792 2,832 pre-
cached
simple
-^ ':;:ei;.i -\ a 1 char pie-cached
BitBLT 2,338 char. 0.822 2,843 from cache
BitBLT 95 char. 0.030 3 167 from cache
Scan Convert 29.736 3.228 96 characters
All times are given in seconds. Printing from cache memory is 877 times faster than scan converion: Measured times are printed in BOLD. Calculated times are printed in normal text (2,832/3.228)
RS-232 communications was used.
Times-Roman Printing Timing Figure 3.1.1.A.3
64
Section 3.1.1: Analysis ofExperimental Results 3.1.2 Pre-Cached Bit-Maps
3. 1 .2.A. Experimental Results
For run each of this experiment a single page, along with its associated timing page, was printed. The POSTSCRIPT file specifying these two pages were downloaded to the printer after a printer power-up sequence. Figure 3. 1.2.A. 1 shows the results of the three runs, each of which prints a full page of a single font For the first run an 1 1 point Helvetica font is used; for the second run a 12 point Helvetica font is used; and for the third "set" run a 13 point Helvetica font is used. All three pages were at 12 point That is the leading, or vertical spacing between lines were all the same. This insured that the three POSTSCRIPT files were identical except for the variable preceding the scalefont operator.
All three runs were printed twice: once immediately following a printer power-down / power-up sequence, and a second time immediately following the first, keeping the printer powered up. The page used for this experiment is identical to the text page shown in appendix 3.2.5 except that one (font & size & orientation) is used instead of the nine used in the appendix.
Right After Second Run Power-Up Time
1 (11 point) 20.858 seconds 6.082 seconds
2 (12 point) 6. 194 seconds 6.078 seconds
3 (13 point) 21.330 seconds 6.084 seconds
Figure 3.1.2.A.1
3.I.2.B. Analysis
The 12 point Helvetica font is one of the designated fonts that is pre-scan converted and permanendy resident in the RTP in bit-map form (Ref. 13). The experimental results show this to be due. The page of 12 point Helvetica text printed in 6.194 seconds immediately following a power-up sequence, only 0.1 10 seconds slower than that recorded for a second run. By comparison, the 1 1 point and 13 point Helvetica text pages took much longer to print the first page after power up vs. the second time (about 15 seconds). Clearly this is due to the additional time needed to scan convert these fonts during the POSTSCRIPT page itself.
Improvements 3. 1 .2.C. Proposed
Expand the size of the bit-map font storage ROM;
Strongly advise the user to keep the printer powered up;
Expand the non-volatile memory - possibly disk.
65
Section 3.1.2 : Analysis ofExperimental Results LOOP a of film that is A. IMAGE LOOP. The KODAK EKTAPRINT IMAGE loop; to directis+ light. The IMAGE LOOP is capable of being electrically charged, and is sensitive motion for as as exposures driven around the IMAGE LOOP CORE in a continuous long copy are being made (see Figure 1).
to place a negative B. PRIMARY CHARGER. The function of the PRIMARY CHARGER is LOOP for exposure and development. charge on the IMAGE LOOP. This prepares the "MAGE AND CONTROL. LOGIC AND The IMAGE LOOP starts moving on command from LOGIC CONTROL then turns on the PRIMARY CHARGER.
EXPOSURE C. EXPOSURE. The charged IMAGE LOOP continues around the CORE to the focused on the IMAGE LOOP at area, where it is exposed to a reflected light copy image that is CONTROL. The original document is precisely Ibe right time, as determined by LOGIC AND illuminated bv hioh intensity flash lamps for a short duration, which prevents blurring of the IMAGE LOOP is image as it is exposed on the moving IMAGE LOOP. The charge on the removed from the areas that are exposed to light. The charge remains in the areas that are not of the IMAGE exposed. The exposure is said to discretely alter the charge characteristics IMAGE LOOP LOOP so that trie focused copy image is recorded on the IMAGE LOOP. This image is known as an electrostatic image.
D. AUXILIARY ERASE, Just before each first, and just after each last, exposure area is an improperly charged segment. These segments are produced when the PRIMARY CHARGER is turned or. at the time of initial IMAGE LOOP movement and turned off during final IMAGE LOOP movement. As the unwanted areas pass under the AUXILIARY ERASE LAMP, it floods the moving IMAGE LOOP base with light that desensitizes the IMAGE LOOP to prevent unwanted development.
E. DEVELOPER STATION ASSEMBLY. The properly charged and exposed IMAGE LOOP area now enters the DEVELOPER STATION ASSEMBLY where positively charged KODAK EKTAPRiMT K Toner particles are attracted to the IMAGE LOOP. Development occurs as the result of attraction of the toner particles to the electrostatic image on the IMAGE LOOP. The toner particles are carried away on the IMAGE LOOP surface for later transfer to a copy paper.
F. SCAVENGER ROLLER. Any developer carrier granules (iron) left on the IMAGE LOOP are salvaged at this point by the SCAVENGER ROLLER and returned to the DEVELOPER STATION ASSEMBLY.
G. POST-DEVELOPMENT ERASE LAMP. To reduce the electrostatic stress on the IMAGE LOOP and thereby increases its life, the POST DEVELOPMENT ERASE LAMP is used to lower the high level charge that was required for proper image development. This POST-DEVELOPMENT ERASE process also helps to prevent residual image retention.
H. REGISTRATION. While the developed electrostatic image moves around the CORE, a sheet of copy paper is advanced to the REGISTRATION ASSEMBLY (not shown in Figure 1). At precisely the right time, the copy paper is directed into contact with the IMAGE LOOP and its developed image. This aligns the copy paper and the image on the IMAGE LOOP.
I. TRANSFER CHARGER. The IMAGE LOOP and copy paper now pass under the TRANSFER CHARGER, which produces a negative charge on the paper surface to attract the positive charged developer toner. This effectively transfers the copy image to the paper.
Note : The printed areas on this page excluding the region bounded by this rectangle is the printed test page output
Full page of 1 1 point Helvetica.
page 66 Figure 3.1.2.A.2 3. 1 .3 Background Outline Rasterization
3. 1 .3.A. Experimental Results
For each run of this experiment a single page, along with its associated timing page, was printed. The POSTSCRIPT file specifying these two pages were downloaded to the printer after a printer power-up sequence. Figure 3. 1.3.A shows the results for the case when a full page of exclusively 10 point Helvetica was printed. The shaded columns show the time waited from the completion of the power up sequence (ie. the header sheet was fully ejected) until the the POSTSCRIPT file started to download. The white columns show the measured printing time of the first page using the method described in section 2.2.2. The page used for this experiment is identical to the text page shown in figure 3.I.2.A.2. In addition to the 1 1 point case, 9 and 10 point Helvetica were also used. The data shown in figure 3. 1.3.A refers to the 10 point Helvetica case.
10 Point Helvetica Case As shown in figure 3.2.3.A the page that was downloaded immediately following the header page ejection (Time After l'st paper eject = 0 seconds) took the longest to print, 15.888 seconds. As more time was allowed to expire after the power-up sequence was complete the printing times decrease until, at 14 seconds, the printing time appears to reach the lower limit at about 6.65 seconds. The printing time stays at this limit for all of the recorded wait times above 14 seconds up to 30 seconds. Another page was printed without powering down the printer. The second print time, for which all characters have already been cached, took 6.052 seconds, about one half second faster than the limit that was reached.
Two additional small experiments were ran. The font specified in the POSTSCRIPT file was changed from 10 point Helvetica to 9 point Helvetica for the first experiment and 1 1 point Helvetica for the second "set" experiment. As in 3.2.1 both pages were at the same point size, 10 point in this case, to insure that all the three POSTSCRIPT files were identical except for the variable preceding the scalefont operator.The non-cached printing times were as follows:
9 point printing time 20. 1 10 seconds. 1 1 point printing time 20.842 seconds.
14 Point Times-Roman Case The experimental results for the 14 point Times-Roman did not vary as the time delay after the first paper eject varied. Times delays ranged from 0 seconds to over one hour with exactly the same results: a print time of 26.374 seconds. As in the previous case, a second page was also printed without powering down the printer. The second print time took 6.062 seconds.
67
Section 3.1.3 : Analysis ofExperimental Results 16 m
| 12
= 8
4 Time for 2'nti print 1= 6.0521 sec (pre-cached fbnts) 0 -//- 4 6 8 10 12 14 16 20 30
Time after first paper eject (after power-up)
Time After Print Time Time After Print Time 1'st paper eject (Seconds) l'st paper eject (Seconds)
0 15.888 11 7.516
1 14.554 12 7.526
2 13.886 13 7.220
4 12.144 14 6.646
7 9.762 15 6.660
9 7.634 20 6.658
10 7.516 30 6.658
Results of Background Outline Rasterization Experiment
Full Page of 10 Point Helvetica Text Figure 3. 1.3.A
68
Section 3.1.3 : Analysis ofExperimental Results 3.I.3.B. Analysis
10 Point Helvetica Case
The 10 point Helvetica font is one of the designated fonts that is scan converted during idle time (Reference 13). The experimental results show the idle time span from 0 to 14 seconds to be the time during which all (or most) of the 10 point Helvetica outline fonts are scan converted. The scan conversion was most likely already in process by the time the first page was downloaded to the printer (ie. the Time = 0 sec. case). It is assumed that, to scan convert a 10 point Helvetica page of text, it takes somewhere between the times to scan convert a 9 point page ofHelvetica text and an 1 1 point page ofHelvetica text A simple approximation is to average the two, which yields 20.476 seconds. This implies that the scan conversion process began approximately 4.6 seconds before the header sheet was completely ejected:
Ave of 9 & 1 1 point scan conversion times 20.476 seconds - 10 point scan conversion from T=0 15.888 seconds scan conversin time before T=0 4.588 seconds
This is still a rough estimate for the following reasons:
- times to print the 9 and 1 1 point font pages did require the scan conversion of all of the alphanumerics and common punctuation;
- also, these times include the POSTSCRIPT interpretation and rendering tasks.
The measured times decrease as the wait time increases. This is exactly the expected results.
Note that between 10 and 12 seconds there was virtually no change in printing time. A possible reason for this is that the remaining characters that still needed scan conversion were scan converted after the 12 second mark In between 10 and 12 seconds the idle time scan converter worked on characters not needed by the currentjob.
14 Point Times-Roman Case The experimental results indicate that no idle time scan conversion of the 14 point Times-Roman font is done. It is possible that the information given Book" Writer in the "Red once applied for the Apple Laser but not for the Apple Laser Writer Plus.
69
Section 3.1.3 : Analysis ofExperimental Results 3. 1 .3.C. Proposed Improvements
Currently a font is scan converted during the RTP's idle time if:
1. it is one of the default fonts, specified by the printer manufacturer (Apple in this case) or
2. it is explicitly specified via the setidlefonts operator by the user.
One possible addition to this scheme would be to automatically scan convert the remainder of the character set of a font previously selected by the POSTSCRIPT findfont, scalefont, and setfont (and possibly a few other) commands. If some significant number of characters have already been used, then the remaining few characters of the same font could be idle time scan converted This assumes that more characters of the same font will probably be used in subsequent printing jobs. If, however, only one or a few characters were used, this mechanism should not be activated.
70
Section 3.1.3 : Analysis ofExperimental Results 3. 1 .4 Effect of Scaling and Rotation
3. 1 .4.A. Experimental Results
The 96 printable ASCII characters were all printed exactly one time using the following POSTSCRIPT code (or variations of it):
/Times-Roman findfont 11 scalefont setfont
350 300 translate 70 rotate
0 75 moveto (l"#$%&,()*+,-./01 23456789:;) show 0 50 moveto (<=>?@ABCDEFGHIJKLMNOP) show 0 25 moveto (QRSTUVWXYZ[\\]AJ|~abcdefg) show 0 0 moveto (hijklmnopqrstuvwxyz{|}~) show
Two main variables are modified:
1. The number specifying the font point size is set to either: 1 1 (point), as shown above; or 22 (point);
2. The number specifying the angle ofrotation is set to either 0 (degrees), for which case the line of code is completely removed; 70 (degrees) as shown above; or 90 (degrees). The x and y coordinate variables that are input to the translate command also need to be modified as the angle changes to assure that all of the text maps inside the page boundaries (8.5 inches by 1 1 inches). These variables are shown above as 350 and 300 (points).
Six different POSTSCRIPT programs (two point sizes at three orientations) were run two times (with and without pre-cached fonts). The choices are:
- font is Times-Roman; - two font sizes are 11 and 22 point; - three orientations are 0, 70, and 90.
71
Section 3.1.4: Analysis of Experimental Results ^ # / i
# # # # / /
Note : The printed areas on this page excluding the region bounded by this rectangle is the printed test page output
96 characters of 11 point Times-Roman rotated 70 degrees
page 72 Figure 3. 1.4.A. 1 Two tables containing six entries each are shown in figures 3.1.4.A.2 and 3. 1 .4.A.3. Both tables show the measured time to print the first page of the standard nine page sequence. Note that the page 2 through 9 times were not relevant for this experiment since these pages automatically use pre-cached fonts and also do not have the same startup overhead associated with them. Figure 3.1.4.A.2 gives the measured times immediately after a power-down/ power-up sequence. This insures that none of the fonts being printed were in the font cache and therefore all six of these times include the font outline scan conversion times (i.e outline font rasterization). Figure 3.1.4.A.3 gives the measured times for a second run, immediately following the previously described run. This insures that all of the fonts being printed were already resident in the bit-map font cache.
Character ^ - A ngle of Rotation ? Size 0 Degrees 70 Degrees 90 Degrees
11 point 35.350 seconds 31.356 seconds 36.264 seconds
22 point 40.730 seconds 37.098 seconds 41.442 seconds
First Time After Power-Up (ie. Without Pre-caching) Figure 3.1.4.A.2
Character ngle of Rotatic>n ? Size 0 Degrees 70 Degrees 90 Degrees
11 point 5.162 seconds 5.172 seconds 5.178 seconds
22 point 5.160 seconds 5.178 seconds 5.180 seconds
First Page Time After Previously Printed Job (ie. With Pre-caching) Figure 3.1.4.A.3
A blank page was printed and timed. The measured time to print a single blank page was 5. 110 seconds. This blank page time is treated as an overhead time that is inherently imbedded in the times of figures 3.1.4.A.2 and3.1.4.A.3.
Since the measurements for the 1 1 point - 0 degree case were substantially different than the measurements from a very similar page printed in section 3.1.1 an additional experiment was run. Both the translate and rotate commands were removed. Four lines were still printed. The results are as follows:
First time after power-up: 34.878 seconds
Pre-cached time: 5.160 seconds
73
Section 3.1.4: Analysis of Experimental Results 3.I.4.B. Analysis
the outline font rasterization The purpose of this section is to compare pre-cached to the font printing performance (i.e. without fonts) bit-map pre-cached as the character size and printing performance (i.e. with fonts) experiments performed m section orientation changes. This expands on the the 3.1.1 in that two additional variables are introduced into experiment, namely font size and orientation.
Page" considered baseline The "Blank time, of 5.1 10 seconds, is to be This is close to the "almost overhead that any POSTSCRIPT job has in it. blank" printed one page time of section 3.1.1 (5.124 seconds) which Page" seconds pre-cached character. The overhead "Blank time of 5. 1 10 is subtracted from all of the measured times in figures 3. 1.4.A.2 and 3, and these results (differences) are recorded in figures 3.1.4.A.5 and 6, respectively. What is left in figures 3.1.4.A.4 and 5 are the times that are more attributable to the scan-conversion and accessing from font cache tasks. This is not entirely true, since the POSTSCRIPT interpreting also occurs, but this is the lowest level that can be investigated from the outside of the Apple Laser Writer Plus printer.
Character llgic ui ""lam Size 0 Degrees 70 Degrees 90 Degrees
11 point 30.240 seconds 26.246 seconds 31.154 seconds
22 point 35.62 seconds 31.988 seconds 36.332 seconds
First Time After Power-Up (ie. Without Pre-caching) Less Blank Page Overhead Figure 3.1.4.A.4
Character ngle of Rotation ? Size 0 Degrees 70 Degrees 90 Degrees
11 point 0.052 seconds 0.062 seconds ;; 0.068 seconds
22 point 0.050 seconds 0.068 seconds 0.070 seconds
First Page Time After Previously Printed Job (ie. With Pre-caching) Less Blank Page Overhead Figure 3.1.4.A.5
74
Section 3.1.4: Analysis of Experimental Results Scaling Outline Fonts Figure 3.1.4.A.4 shows that it takes approximately 20 % longer to scan convert the 22 point font when compared to the 1 1 point font:
- at 0, 5.380 seconds more or 17.7 %
- at 70, 5.742 seconds more or 21.9 %
- at 90, 5.178 seconds more or 16.6 %
It also appears that the performance of scaling a rotated font not on a quadrant boundary is slightly more affected by size variation than for one that is on a 70 quadrant boundary (i.e. about 4% for the case over the other "intelligence" two cases). This difference may be due to the font that is used 0 90 for the and cases (see Outline Fonts below). The "intelligence" Rotating algorithm may be less size dependent and therefore did not 70 slow down as much as the case, for which font intelligence is not used.
It was expected to take 1 to 4 times longer to scan convert the 22 point font vs. the 11 point font. The experimental data shows it taking 1.2 times longer. This implies that the task of applying the transform to the outline is dominant over the rendering task.
Once the font is in the bit-map cache it seems that the time to pull the bit-map characters out of cache and onto the page is not dependent on font size. The numbers may be too small to see a definitive trend. See the following page for a discussion on the accuracy of the numbers in figure 3.1.4.A.6
Font Outline Scan Conversion vs. Pre-Cached Bit-Map Fonts Figures 3.1.4.A.4 and 5 contain the measured times to scan convert and print from cache, respectively, less the overhead of printing a blank page. Figure 3.1.4.A.6 shows the ratios of the entries in figure 3.1.4.A.4 as compared to figure 3.I.4.A.5. That is, figure 3.1.4.A.6 shows how much faster printing from font cache is vs. printing from outlines that have yet to be scan converted.
A Character Ilglc VI IVUldlll ? Size 0 Degrees 70 Degrees 90 Degrees
11 point 582 423 458
22 point 712 470 519
Ratio of Scan Converted Font Timing to Bit-mapped Font Timing Figure 3.1.4.A.6
The ratios range from 423 to 712. with the average being 527. This is ahont one half of the expected 1000 and substantially different than the results of
section 3.1. 1 . which yielded a ratio of 877. The accuracy of these numbers should not be taken as absolutes, but merely as a general approximation for the following reasons:
75
Section 3.1.4: Analysis of Experimental Results and therefore are 1 The times recorded in figure 3.1.4.A.5 are differences, error of two measured that of subject to the potential cumulative values, and that of the blank page. the printing text from outline or cache, printing
small. Since these 2. The numbers shown in figure 3.1.4.A.5 are very in these values can numbers are are so small, small fluctuations (errors) 3.I.4.A.6. For cause large deviations in the ratios found in figure 0 millisecond difference in example, for the (22 point, angle) case a 10 value range from the 50 millisecond recorded value will make the 712 594 to 891.
attibutable to the 3. As previously mentioned, these numbers are not purely processes. The scan conversion or printing from font cache POSTSCRIPT interpretation was included in printing both types ofjobs. The larger this number is, the smaller the ratios in figure 3.1.4.A6 tend to be.
Comparison to Results in Section 3.1.1
The experiment that was run in section 3.1.1 is very similar to the 1 1 point, 0 degree case of this section. Both print 96 characters of an 1 1 point Times-Roman font in the portrait orientation (i.e. 0 degrees). There are two small differences:
1. the translate command was used in this section but not in section 3.1.1;
2. four lines were printed in this section instead of two tines in section 3.3.1 (i.e. two additional moveto commands).
In an attempt to isolate the variable that caused the difference of BitBLT to scan conversion ratios (877 vs. 582) the POSTSCRIPT translate command was taken out of the program. The four discrete moveto coordinate pairs were changed to position the text in the middle of the page. Also, there was no rotate command. Figure 3.1.4.A.7, below shows the results.
First page time Pre-cached fonts
"translate" with 35.350 seconds 5.162 seconds command
"translate" w/o 34.878 seconds 5.160 seconds command section 3.1.1 results 34.860 seconds 5.154 (w/o "translate") seconds
with "translate" Page Printing Times and without POSTSCRIPT command for the 1 1 point, 0 degree case
Figure 3.1.4.A.7
76
Section 3.1.4: Analysis of Experimental Results It seems that only the first page time is effected by the presence of the translate command. When die translate command is eliminated from the experiment run in this section the results are very close to the results of section 3.1.1: 34.878 seconds vs. 34.860 seconds, respectively. The additional 0.018 second difference may be due to the additional two moveto commands.
One possible explanation for the larger 0.490 second discrepency (i.e. 35.250 seconds vs. 34.860 seconds) is that the scan conversion software may be sensitive to any modification of the current transformation matrix (CTM). The CTM is changed by the scale, rotate, and translate commands. Once the font is in bitmap form in the font cache, however, the effect seems to disappear.
An even more significant factor that influenced the 877 vs. 582 discrepency in BitBLT vs. scan conversion time ratios is the times that were used for the "base" page. There was a 0.014 second difference in these numbers which becomes a 28% difference to the 0.050 second value. These values should only be used as general guidelines for RIP performance. Any small change in measured values reflect large ratio differences.
Rotating Outline Fonts 70 The rotated case yielded the best results:
0 13.2 % faster than 1 1 point at orientation; 90 15.7 % faster than 1 1 point at orientation; 0 10.2 % faster than 22 point at orientation; 90 12.0 % faster than 22 point at orientation.
"intelligence" This indicates that the font overhead is more dominant than the overhead incurred when rotating a font outline. The 0 and 90 degree cases are both slower due to the font intelligence algorithm used. As expected, the 0 90 case is slighdy faster than the case, although by only about 3 %. The font outline scan conversion algorithm evidently takes advantage of 90 knowledge of the rotation for the performance to take such a small hit
3 . 1 .4.C. Proposed Improvements
A faster processor and/or math accelerator hardware could help in generating the font bitmaps from the master font outlines. Once the font is in bitmap form in the font cache the time to move these bitmaps onto the page is limited by memory speeds. Using faster memory could help. Also, for larger fonts data compression / decompression could help the potential memory speed bottleneck.
77
Section 3.1.4: Analysis of Experimental Results 3. 1 .5 Variations of Font Style
3. 1 .5.A. Experimental Results
same The experiment of 3.1.1 used the Times-Roman font The other Helvetica and experiment was run in this section using two fonts: Zapf Chancery Medium Italic. The Times-Roman printed pages are shown in figures 3.1.1.A.1 and 3.1.1A.2, along with the detailed measured of and calculated times in figure 3.1.1A.3. One of the two pages ZapfChancery text is shown in figure 3.1.5.A1. The Helvetica pages are not shown.
All three fonts are resident in the Apple Laser Writer Plus. Scan convert times and BitBLT times were measured and calculated in the same manner described in section 3.1.1. The results are shown below:
Characters per second Ratio BitBLT from Scan Convert cache BitBlt/Scan
Helvetica 3.976 2,797 703
Times-Roman 3.228 2,832 877
Zapf Chancery 2.875 2,868 998 Medium Italic
3.I.5.B. Analysis
"Complex fonts ... will take longer to print because of the intricate curves and shapes", (reference 25) It can be seen from the data shown above that
complex" as the font gets "more the character per second scan conversion rate decreases. The simple Helvetica style is 38% faster to scan convert than the more complex Zapf Chancery font However, once the font has been cached there is only a minimal effect on speed of moving the cached bitmaps to page memory for printing. Consequently, the significant effect that font complexity has on the cache vs. scan converting the font outlines.
Once the font has been placed in the bitmap font cache all three fonts are yielded performance that were vey close to each other. There was a slight difference in speed that seems to corrolate with the apparent size of the fonts:
- the font that appears to be the smallest (i.e. Zapf Chancery) was the fastest, printing 2,868 characters per second;
- the font that appears to be the second smallest (i.e. Times Roman) was "in between", printing 2,832 characters per second;
- the font that appears to be the largest (i.e. Helvetica) was the slowest, printing 2,797 characters per second;
78
Section 3.1.5: Analysis of Experimental Results t'#$%&W+r./0123456789:;<=>r^BCTfcTQM3JqMWpT Q&mi'lW^\JAJ\~a6cdcfliyl^
A. IMAGE LOOT. The WV^EW%TW9&IMAGE LOOP is a continuous phn. that is capable loop of ofbeing electrically charged) andis sensitive to direct light. The IMAGE LOOT is driven aroundthe IMAGE WOT CORE in a continuous motionfor as long as copy exposures are being made (see figure 1).
C EXPOSURE. The charged IMAGE LOOT continues around the CO%E to the "EXBOSIVRE area., where it is exposed to a reflectedlight copy image that is focusedon the IMAGE LOOT at precisely the right time., as determinedby LOGIC A?@> COT&RpL. The original document is illuminatedBy high flash Campsfor a short intensity duration, which prevents blurring ofthe image as it is exposedon the moving IMAGE LOOT. The charge on the IMAGE LOOT is removedfrom the areas that are exposed to light. The charge remains in the areas that are not exposed. The exposure is saidto discretely alter the charge characteristics ofthe IMAGE LOOTso that thefocusedcopy image is recorded on the IMAQE LOOT. This IMAGE LOOT image is known as an electrostatic image. E. EVELOTE!XJTATIO%CASSEM2L% The properly chargedandexposed IMAGE LOOT area now enters the 'DE'VELOTE^^IATIOH.ASSEMBLy where positively charged !KP 7. SCAVE'XgE'RJRS)LLE% Any developer carriergranules (iron) left on the IMAGE LOOT are salvagedat this point by thcSaMETfgE^RPLLEXjmd returned to the VEVELC)TE!RjTATI09ASSEM'BLy. Q. T0ST-E'lSELOTME9{TE%ASE LAMP. To reduce the electrostatic stress on the IMAGE LOOT and thereby increases its life, die T0STT/EVEL0TME7& E%ASE LAMT is used to lower the high levelcharge that was requiredfor proper image development. This T0ST-E'VEL0TME9&E,!XASE process also helps to prevent residualimage retention. Note : The printed areas on this page excluding the region bounded by this rectangle is the printed test page output Italic all 96 printable ASCII characters are Page of 1 1 point Zapf Chancery Medium text; 427 inter-word spaces. printed at least once; 43 lines of text; 2,339 non-space characters; Figure 3.1.5.A.1 page 79 3. 1.5.C Proposed Improvements Same as section 3.1.1.G 80 Section 3.1.5: Analysis of Experimental Results 3.2 Resident vs. Downloaded Fonts In section 2.2 the measurement techniques are explained using several experiments to demonstrate the validity of the techniques used. All experiments that were run in section 2.2, as well as in almost all other sections in chaper 3, use the RS-232 communications interface (see section 2.2.1 for more details). Sections 3.2.1 through 3.2.3 are the exception to this rule. In these next three sections Appletalk is used exclusively, instead The reason Appletalk is used instead of RS-232 is because two (of the three) downloadable fonts were purchased and come Downloader" in a form that is set up for use with Appletalk. The "Font software, provided by Adobe, uses Appletalk. Once these fonts have been downloaded into the Apple Laser Writer Plus printer via Appletalk it is impossible to change the communications mode of the printer without powering it down. Since the downloaded fonts are stored in volatile memory (RAM), all downloaded fonts are effectively erased when the printer is powered down. Therefore all experiments that use a font that has been downloaded with Appletalk must also be run with Appletalk. Downloader" In addition to downloading fonts the "Font tool also allows a POSTSCRIPT file to be downloaded via Appletalk. All of the techniques described in section 2.2 are still valid when using Appletalk, including the measurement of download times of POSTSCRIPT fonts and programs. The one drawback to using Appletalk is that experiments involving measurement of download times cannot easily be translated back to the equivalent times with "shared" RS-232. This is because of the uncertailty of the Appletalk protocol overhead and the nature of the Appletalk network. To address the latter point to some extent the printer is connected point-to-point with the Mac-II providing the POSTSCRIPT file with no other computers or printers physically connected. Downloader" For more information on the "Font tool and how it is used to download POSTSCRIPT fonts as well as POSTSCRIPT programs refer to section 2.3.4. 3.2. 1 Downloaded Bitmaps vs Printer Resident (Permanently-Cached) Bitmaps 3.2. 1 A. Experimental Procedure and Results A very simple page of text is printed and timed. The page consists of a single string often characters each of which were printed exacdy one time. The string is postioned once. The POSTSCRIPT commands that were used are: 200 400 moveto (abcdefghim) show Two bitmap fonts are used: A. A hand-coded downloadable POSTSCRIPT bit-map font. The program shown in section 2.3.3 is a downloadable POSTSCRIPT font that was largely taken from a section in the POSTSCRIPT Language Tutorial and Cookbook (see reference 16). Ten characters of a simple six point font are defined in that program. Unfortunately no six point font was available in permanent bit-map form on the Apple Laser Writer Plus for this comparison, but a 12 point font was available - a factor of two larger than the six point downloadable bit-map font For this experiment the bit-map definitions ofthe ten characters were doubled in size in both the x and the y directions. This was done by replication was used. hand editing the file. Simple pixel 81 Section 3.2.1: Analysis of Experimental Results four other entries needed to be In addition to modifying the bit-maps modified: 1. the imagemaskmatrix was changed from [25 0 0 -25 0 0] to [50 0 0 -50 0 0] ; 2. the width of each character, in pixels, was doubled; 3. the height of each character, in pixels, was doubled; was doubled . 4. the y translation component (+0.5) Once the new 12 point font, named Bitfont is defined, it is callable by the command: /Bitfont findfont 12 scalefont setfont B. The printer resident Helvetica 12 point font. The 12 point Helvetica font is pre-scanned and permanendy resident in ROM, in bitmap form (reference 13). Section 3.1.2 of this thesis also discusses the topic ofprinter resident bit-map fonts. To select the 12 point bit-map font the following simple sequence of POSTSCRTT code is used: /Helvetica findfont 12 scalefont setfont The bit-map version of this font is automatically referenced. This command precedes the pair of commads shown earlier which positions and specifies the string to be printed (i.e. the moveto and show commands). The size of the bitmap font is: 2,712 bytes: character bitmaps and metric information 959 bytes: additional overhead 3,671 bytes total The measured time to download the bitmap font was 1.044 seconds. Nine pages were output with varied delays between page printing. The following times were measured: Bitfont downloaded Helvetica resident 1st page 5.580 seconds 5.110 seconds Min. Time 3.498 seconds 3.510 seconds 82 Section 32.1: Analysis of Experimental Results abcdefghim Note : The printed areas on this page excluding the region bounded by this rectangle is the printed test page output 10 characters of the 12 point downloaded bitmap font Figure 3.2. 1.A. 1 page 83 abcdefghim Note : The printed areas on this page excluding the region bounded by this rectangle is the printed test page output 10 characters of the 12 point printer resident bitmap font (Helvetica) page 84 Figure 3.2.1.A.2 3.2. l.B. Analysis The actual size of the bitmap font was slightly smaller than anticipated: 3,671 bytes actual vs. 3,940 bytes expected. The combination of the character bitmaps and the character metrics information was larger 2,712 bytes actual vs. 2,940 bytes expected (2,540 bytes of bitmaps + 400 bytes of metrics). Given the difficulty of predicting exact sizes of ten specific characters, these results look very good. The measured download time of 1.044 seconds, on Appletalk, is about four times faster than the 4.10 second time predicted for slower RS-232 communications interface. This indicates that, for this particular case (file size, Appletalk loading, etc.) the Appletalk network provided a throughput of approximately 40 KBits / sec. This is about 20 % of its maximum speed. Two times are recorded above: First Time: The time taken to print the first page. It took 0.470 seconds more to print the first page using the downloaded bitmap font vs. printing the printer resident Helvetica bitmap font. This does not include font download time, but instead is a measure of the time to move the bitmap font (i.e. a POSTSCRIPT program defining a font) to the font cache. Minimum Time: Of the nine pages that were printed, this time shows how fast the page can be printed under as close to ideal conditions as possible. All other pages are effected by external influences (see sections 2.1.6 and 3.6). The measured time to print the page with the ten bitmap characters, 3.498 seconds, was only 0.34 % less than the measured time to print the page with the ten printer-resident bitmap characters, 3.510 seconds. This is exactly what was expected. Once a font is in cache memory, whether it originated in the printer or was downloaded, the time to access this font is the same. 3.2.l.C. Proposed Improvements Use a faster communication interface; Use a communications interface that handles binary information; Use data compression. 85 Section 3.2.1: Analysis of Experimental Results Outlines 3.2.2 Adobe Downloaded Outlines vs. Printer Resident (Internal) 3.2.2.A. Experimental Results The two POSTSCRIPT test pages that were printed in section 3.1.1 are set identical to one set of test pages printed in this section. This consists of characters of the 1 1 point two programs. The first program prints 96 Times Roman font in two lines as described in section 3. 1. 1. The page this first program prints is shown in figure 3.1.1.A.L The second program, which prints the page shown in figure 3.1.1A.2, prints the same two lines as total of above, but also prints an additional 41 lines that contain a 2,243 experiment in section 3.1.1 characters. The only difference in mnning the and this section is the communications interface used: in section 3.1.1, the serial RS-232 interface is used; in this section, the Appletalk local area network is used. In addition to the pages described above that use the Times-Roman font, two more pages were printed for comparison that were exacdy the same except for the font used. The two new pages use the Adobe downloaded Stone Serif font They are shown on the following two pages in figures 3.2.2.A.land3.2.2.A2. The data in figure 3.2.2A.3 shows the experimental results when the four pages were printed. Following the convention set forth in section 3.1.1 all of the measured times are printed in a bold face and all of the the calculated values are printed in a normal weight face. Furthermore, the values that correspond to the pages that use the Stone Serif font are printed on top in the Roman style (Roman and Roman Bold); the values that correspond to the pages that use the Times-Roman font are printed on the bottom in the Italic style (Italic and Italic Bold ). Since Appletalk and the font / program downloader programs were provided, very little control was available to accurately time the font download time. A stop watch was used to measure the time from the program selection (i.e. begin execution) to the return from the program. It took 4 seconds for the Font Downloader program, provided with the Adobe Stone Serif font, to establish a connection with the Apple LaserWriter Plus with an additional 26 seconds needed to download the font The size of the outline font was measured to be 34,260 bytes with the Get Info utility program on the Macintosh Finder. The space this font occupies in the Apple Laser Writer Plus is 28 KBytes, as measured by the Printer FontDirectory function of the FontDownloader program. 3.2.2.B. Analysis The same analysis procedure that was used in section 3.1.1 is used here. For a detailed explanation of this procedure, refer back to section 3.1.1. It will not be repeated here. As expected the printing perfomance of the resident and the downloaded fonts were very close: - scan conversion rate 3.23 characters per second for Stone Serif 3.19 characters per second for Times-Roman 86 Section 322: Analysis of Experimental Results pruning bitmaps from cache 2,776 (2,375 to 2,776) characters per second for Stone Serif 2,825 (2,37 1 to 2,969) characters per second for Times-Roman The download time of 26 seconds includes all of the Appletalk overhead combined with the Font Downloader application program overhead. Assuming the entire 34,260 byte Stone Serif font is actually downloaded in this time, the overall throughput is only 10.5 KBits/sec. As predicted, font download time is quite significant The time to download the font via this means is almost as long as the time taken to scan convert a full 96 character set of the font itself. 3.2.2.C. Proposed Improvements Optimize the program path that downloads the font. Appletalk has a burst rate of 230.4 KBits/sec. The effective data rate of only 10.5 KBits/sec can probably be improved by optimization. Use a faster communications interface. Spool downloadable fonts on a disc to reduce future needs for download. 87 Section 3.2.2: Analysis of Experimental Results !"#$%&'0*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOP QRSTUVWXYZ[\]A_'l~abcdefghijklmnopqrstuvwxyz{l}~ Note : The printed areas on this page excluding the region bounded by this rectangle is the printed test page output 96 characters of 1 1 point Stone Serif page 88 Figure 3.2.2.A.1 r#$%&'0*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOP QRSTU\^XYZ[\]VI~abcdefgWjWmnopqrsmv^{|}- A. IMAGE LOOP. The KODAK EKTAPRINT IMAGE LOOP is a continuous ^.JP^&vt0^!1? f.bein8 electrically charged, and is sensitive to direct light. The IMAGE LOOP is driven around the IMAGE LOOP CORE in a continuous motion for as long as copy exposures are being made (see Figure 1). B. PRIMARY CHARGER. The function of the PRIMARY CHARGER is to place a negative charge on the IMAGE LOOP. This prepares the IMAGE LOOP for exposure and development. The IMAGE LOOP starts moving on command from LOGIC AND CONTROL. LOGIC AND CONTROL then turns on the C. EXPOSURE. The charged IMAGE LOOP continues around the CORE to the EXPOSURE area, where it is exposed to a reflected light copy image that is focused on the IMAGE LOOP at precisely the right time, as determined by LOGIC AND CONTROL. The original document is illuminated by high intensity flash lamps for a short duration, which prevents blurring ofthe image as it is exposed on the moving IMAGE LOOP. The charge on the IMAGE LOOP is removed from the areas that are exposed to light. The charge remains in the areas that are not exposed. The exposure is said to discretely alter the charge characteristics of the IMAGE LOOP so that the focused copy image is recorded on the IMAGE LOOP. This IMAGE LOOP image is known as an electrostatic image. D. AUXILIARY ERASE. Just before each first, and just after each last, exposure area is an improperly charged segment. These segments are produced when the PRIMARY CHARGER is turned on at the time of initial IMAGE LOOP movement and turned off during final IMAGE LOOP movement. As the unwanted areas pass under the AUXILIARY ERASE LAMP, it floods the moving IMAGE LOOP base with light that desensitizes the IMAGE LOOP to prevent unwanted development. E. DEVELOPER STATION ASSEMBLY. The properly charged and exposed IMAGE LOOP area now enters the DEVELOPER STATION ASSEMBLY where positively charged KODAK EKTAPRINT K Toner particles are attracted to the IMAGE LOOP. Development occurs as the result of attraction of the toner particles to the electrostatic image on the IMAGE LOOP. The toner particles are carried away on the IMAGE LOOP surface for later transfer to a copy paper. F. SCAVENGER ROLLER. Any developer carrier granules (iron) left on the IMAGE LOOP are salvaged at this point by the SCAVENGER ROLLER and returned to the DEVELOPER STATION ASSEMBLY. G. POST-DEVELOPMENT ERASE LAMP. To reduce the electrostatic stress on the IMAGE LOOP and thereby increases its life, the POST DEVELOPMENT ERASE LAMP is used to lower the high level charge that was required for proper image development. This POST-DEVELOPMENT ERASE process also helps to prevent residual image retention. Note : The printed areas on this page excluding the region bounded by this rectangle is the printed test page output printable ASCII characters are printed Page of 1 1 point Stone-Serif text; all 96 427 inter-word spaces. at least once; 43 lines of text; 2,339 non-space characters; Figure 3.2.2.A.2 page 89 BitBLT 2,243 char. char /sec from cache 2,339 char. 96 (96 + 2,243) calculated calculated characters 2,614 1st page 36.330 37.188 0.858 2,371 after 35.260 36.206 0.946 power up 2,776 1st page 5.158 5.966 0.808 pre- 5.262 5.956 0.794 2,825 cached k- * ^ 1 simple 1 ft 1 char 5.130 pre-cached BitBLT 0.848 2,756 2,338 char. 0.826 2,831 from cache BitBLT 0 040 2,375 95 char. 0.032 2,969 from cache 31.212 3.23 Scan Convert 30.130 3.19 96 characters Stone Serif times are printed in: All times are given in seconds. Roman print for calculated values; Bold print for measured values. Appletalk was used. Times-Roman times are printed in: Italicprintfor calculated values; Bold Italic for measured values. Adobe Stone Serif (Downloaded Outlines) vs. Adobe Times-Roman (Printer Resident) Figure 3.2.2.A.3 90 Section 32.2: Analysis of Experimental Results 3.2.3 Adobe Downloaded Outlines vs. 3rd party 3.2.3.A. Experimental Results As in sections 3.1.1 and 3.2.2 two sets of two pages each were printed. Two of the four POSTSCRIPT test pages that were printed in section 3.2.2 are used in this section with no changes. They are the two pages that use the Adobe downloaded Stone Serif font. The first program prints 96 characters of the 1 1 point Stone Serif font in two lines as described in section 3.1.1 (see figure 3.1.1.A.1). The second program prints the same two lines as above, but also prints an additional 41 lines that contain a total of 2,243 characters. The two pages that correspond to the programs described above are shown in figures 3.2.2.A.1 and 3.2.2.A.2. In addition to the pages described above that use the Stone Serif font two more pages were printed for comparison that were exactly the same except for the font used. The two new pages use the CasadyWare downloaded Roman Galileo font. They are shown on the following two pages in figures 3.2.3.A.1 and 3.2.3.A.2. The data in figure 3.2.3.A.3 shows the experimental results when the four pages described above were printed. Following the convention set forth in section 3. 1 . 1 all of the measured times are printed in a bold face and all of the the calculated values are printed in a normal weight face. Furthermore, the values that correspond to the pages that use the Stone Serif font are printed on top in the Roman style (Roman and Roman Bold); the values Roman that correspond to the pages that use the Galileo font are printed on the bottom in the Italic style (Italic and Italic Bold ). Since Appletalk and the font / program downloader programs were provided, very little control was available to accurately time the font download time. A stop watch was used to measure the time from the program selection (i.e. begin execution) to the return from the program. It took 4 seconds for the Font Downloader program, provided with the Adobe Stone Serif font, to establish a connection with the Apple LaserWriter Plus with an additional 26 seconds needed to download the font The size of the Stone Serif outline font was measured to be 34,260 bytes with the Get Info utility program on the Macintosh Finder. The space this font occupies in the Apple Laser Writer Plus is 28 KBytes, as measured by the Printer FontDirectory function of the FontDownloader program. The Adobe Font Downloader program was not able to download the CasadyWare Galileo Roman font. The reverse procedure also did not work. That is, the Altsys Laser Writer Downloader program (version 1.3), Roman provided with the CasadyWare Galileo font, was not able to download the Adobe Stone Serif font. When using the Altsys program to Roman download the Galileo font it took a total of about 10 seconds to connect with the printer and download the font This is three times faster than downloading the Stone Serif font with the Adobe Font Downloader Roman program, above. The size of the Galileo outline font was measured to be 44,341 bytes with the Get Info utility program on the Macintosh Finder. The space this font occupies in the Apple Laser Writer Plus is 28 KBytes, as measured by the Printer FontDirectory function of the Adobe FontDownloader program. 91 Section 3.2.3: Analysis of Experimental Results !"#$%&'()*+,-70123456789:;<=>?@ABCDEFGHIIKLMNOP QRSTUVWXYZ|\]\>abcdefgrnjldninopqrstuvwxyz{l}- Note : The printed areas on this page excluding the region bounded by this rectangle is the printed test page output 96 characters of 1 1 point Galileo Roman page 92 Figure 3.2.3.A.1 !"#$%&*()*^-70123456789::<>?ABQEFGHIJKLMNOP QKTUWXYZN^akdefgHjTdmaopqrstuvwxyzfl}- A. IMAGE LOOP The KODAK EKTAPRINT IMAGE LOOP is a continuous *** chai*ed' * "Sn. to direct light.SSS The IMAGE LOOP is driven around^^ the IMAGE LOOP CORE in a continuous mobon for as as long copy exposures are being made (see Figure 1). B PRIMARY CHARGER. The function of the PRIMARY CHARGER is to place a negative charge on the IMAGE LOOP. This prepares the IMAGE LOOP for exposure and deve bpment f j The^^^K^ta"^IMAGE LOOP *JL m?, from SGIC AND CONTROL. LMK " on tne PRIMARY CHARGER. CEXPOSIRE. The charged IMAGE LOOP continues around the CORE to the EXPOSURE ^a-^re is exposed to a J reflected light copy image that is * **&* the ** S- ^ determined LOGICSAmAND?SCONTROL. *%? by Tbe original document is illuminated by high intensity flash lamps for a short which duration, prevents blurringof the image as it is exposed on the moving IMAGE LOOP. The charge on the IMAGE LOOP is removed from the areas that are exposed to light. The charge remains in the areas that are not exposed The exposure is said to discretely alter the charge characteristics of the IMAGE so LOOP that the focused copy image is recorded on the IMAGE LOOP. This MAGE LOOP image is known afanXrosUfc image. D. AUXILIARY ERASE. Just before each first, and just after each last, exposure charged ,!?v JSPESESty seS^ent These segments are produced when the PRIMARY CHARGER is turned on at the time of initial IMAGE LOOP movement and turned off during final MAGE LOOP movement. As the unwanted areas pass under the AUXILIARY ERASE LAMP, it floods the moving MAGE LOOP base with light that desensitizes the MAGE LOOP to prevent unwanted development. E. DEVELOPER STATION ASSEMBLY. The properly charged and exposed MAGE LOOP area now enters the DEVELOPER STATION ASSEMBLY where positively charged KODAK EKTAPRINT K Toner particles are attracted to the IMAGE LOOP. Development occurs as the result of attraction of the toner particles to the electrostatic image on the MAGE LOOP. The toner particles are carried away on the MAGE LOOP surface for later transfer to a copy paper. F. SCAVENGER ROLLER. Any developer carrier granules (iron) left on the MAGE LOOP are salvaged at thispoint by the SCAVENGER ROLLER and returned to the DEVELOPER STATION ASSEMBLY. G. POST-DEVELOPMENT ERASE LAMP. To reduce the electrostatic stress on the IMAGE LOOP and thereby increases its life, the POST DEVELOPMENT ERASE LAMP is used to lower the high level charge that was required for proper image development. This POST-DEVELOPMENT ERASE process also helps to prevent residual image retention. Note : The printed areas on this page excluding the region bounded by this rectangle is the printed test page output Roman Page of 1 1 point Galileo text; all 96 printable ASCII characters are printed at least once; 43 lines of text; 2,339 non-space characters; 427 inter-word spaces. Figure 3.2.3.A.2 page 93 BitBLT 2,243 char. char sec from cache / 2,339 96 char. + (96 2,243) calculated calculated characters 1st page 36.330 37.188 0.858 2,614 after 40.528 41.346 0.818 2,742 power up 1st page 5.158 5.966 0.808 2,776 pre- 5.168 5.972 0.804 2,790 cached simple 1 char 5.130 pre-cached BitBLT 0.848 2,756 2,338 char. from cache 0.842 2,776 BitBLT 0.040 -2,375 95 char. from cache 0.038 2,500 31.212 3.23 Scan Convert 96 characters 35.398 2.71 Stone Serif times are printed in: All times are given in seconds. Roman print for calculated values; Bold print for measured values. Appletalk was used. Roman Galileo times are printed in: Italicprintfor calculated values; Bold Italic for measured values. Adobe Stone Serif (Adobe Downloaded Outlines) vs. CasadyWare Galileo Roman (3rd Party Downloaded Outlines) Figure 3.2.3.A.3 94 Section 3.2.3: Analysis of Experimental Results 3.2.3.B. Analysis The same analysis procedure that was used in section 3.1.1 is used here. For a detailed explanation of this procedure, refer back to section 3.1.1. It will not be repeated here. It was expected that scan converting the Adobe Stone Serif font would be slower than scan converting the CasadyWare Galileo Roman font because "inteUigence" the Adobe algorithm incorporates whereas the CasadyWare algorithm does not The results were exacdy the opposite. Scan conversion times are: 3.23 characters per second for Stone Serif; 2.71 characters per second for Galileo Roman. The two possible reasons why this discrepency exists are font style complexity and font vendor encoding differences. Although every attempt was made to select a font with a similar complexity to the Stone Serif font, this judgement is very subjective. Some the performance difference may be due to this. Secondly, the font vendor encoding difference, which is the largest unknown in this case, is probably the biggest cause of the performance difference. Whether Adobe downloadable fonts will consistendy outperform third party fonts cannot be predicted from this single experiment Once the fonts have been downloaded and scan converted (i.e. put into the font cache) the printing bitmaps from cache performance of the two are very close, as expected: 2,776 (2,375 to 2,776) characters per second for Stone Serif; 2,790 (2,500 to 2,790) characters per second for Galileo Roman. The file size of the two downloadable fonts were expected to be close. They were not: 34,260 bytes for the Stone Serif font; 44,341 bytes for the Galileo Roman font. (This may indicate higher complexity which supports the earlier reason" "possible for the scan conversion performance discrepancy.) Yet the space these fonts occupy in the Apple Laser Writer font memory is the same: 28 KBytes. Compaction may occur at the printer. Or it is Roman possible that not all of the Galileo printer font is downloaded. It was expected that the download times of the two downloadable fonts surprise. Even would be very close to the same. This was the biggest though the Adobe font was smaller by more than 10,000 bytes (34,260 vs. 44,341 bytes) it took three times as long to connect with the printer and download the font (30 vs. 10 seconds). Assuming the etire files were sent to the printer, the overall system throughput was approximately 9,000 bits/sec to download the Stone Serif font with the Adobe FontDownloader program download the Galileo Roman font vs. approximately 35,000 bits/sec to program. From this comparison with the Altsys Laser Writer Downloader it program utlizes the Appletalk network seems that the Altsys font download much more efficiendy than Adobe's. quite significant In either case, the font download time is 95 Section 3.2.3: Analysis of Experimental Results 3.2.3.C. Proposed Improvements It seems that using the Altsys program to download the POSTSCRIPT font is a substantial improvement over using Adobe's download program. Still to be resolved is why it does not work with Adobe fonts. Use a faster communications interface. Spool downloadable fonts on a disc to reduce future needs for download. 96 Section 3.2.3: Analysis ofExperimental Results 3.2.4 Appletalk vs. RS-232 Comparison 3.2.4.A. Experimental Results The two POSTSCRIPT test pages that were printed in section 3.1.1 are identical to one set of test pages printed in section 3.2.2. The first program prints 96 characters of the 1 1 point Times Roman font in two lines as described in section 3.1.1. The page this first program prints is shown in figure 3. 1.1.A. 1. The second program, which prints the page shown in figure 3.1.1.A.2, prints the same two lines as above, but also prints an additional 41 lines that contain a total of 2,243 characters. The only difference in running the experiment in section 3.1. 1 and 3.2.2 is the communications interface used: in section 3.1.1, the serial RS-232 interface running at 9600 baud is used; in section 3.2.2, the Appletalk local area network running at a burst rate of 230.4 Kbits/second is used. The data in figure 3.2.4.A.1, on the following page, is a reiteration of the experimental results reported in figures 3.1.1.A.3 (for the RS-232 data) and 3.2.2.A.3 (for the Appletalk data). The printer resident Times Roman font is used for both cases. Following the convention set forth in section 3.1.1 all of the measured times are printed in a bold face and all of the the calculated values are printed in a normal weight face. Furthermore, the values that correspond to the RS-232 case are printed on top in the Roman style (Roman and Roman Bold); the values that correspond to the Appletalk case are printed on the bottom in the Italic style (Italic and Italic Bold ). "bodies" Figure 3.2.4.A.2 shows the size of the of the two downloaded pages, along with the measured download times of each for both RS-232 and Appletalk communication interfaces. Again, die measured values are reported in bold with die calculated values in normal weight The methods used to download these jobs are described below: RS-232 On the Sun workstation shown in Appendix 1 the UNIX command cat file_to_be_sent > /dev/tty07 was typed which sends the fftefiletobesent to the printer via port 7 of the 16-port multiple terminal interface. Appletalk On the Macintosh II personal computer shown in Appendix 1 the program FontDownloader was selected (executed). The file to be downloaded to the printer was then selected and downloaded. This procedure is described in more detail in section 2.3.4. 3.2.4.B. Analysis The measured times to print the first page after a power-down / power-up in the measurements sequence is the only noticeable difference printing time shown in figure 3.2.4A.1. It takes 0.400 seconds more in the 96 character page case and 0.460 seconds more in the full page case for the to print using Plus Appletalk than RS-232. It appears that the Apple Laser Writer Appletalk functions processor is using some of its time performing during even the point at the execution time of the POSTSCRIPT page though, page which these measurements were made, the POSTSCRIPT had already been fully downloaded. rates are close for both the The calculated character per second printing very the scan conversion case. printing from cache case and Section 3.2.4: Analysis of Experimental Results BitBLT Times-Iloman 2,243 char. char /sec from cache 2,339 char. 96 (96 + 2,243) calculated calculated characters 2,532 1 st page 34.860 35.746 0.886 2,371 after 35,260 36.206 0.946 power up 1st page 5.154 5.946 0.792 2,832 pre- 5.162 5.956 0.794 2,825 cached ^ CI 1 A fc- simple 1 char 5A 30 pre-cached BitBLT 0.822 2,843 2,338 char. 0.526" 2,831 from cache BitBLT 0.030 3,167 95 char. 0.032 2$69 from cache 29.736 3,23 Scan Convert 30.130 3.19 96 characters RS-232 times are printed in: All times are given in seconds. Roman print for calculated values; Bold print for measured values. Appletalk times are printed in: Italicprintfor calculatedvalues; Bold Italic for measured values. Appletalk vs. RS-232 Comparison Figure 3.2.4.A. 1 98 Section 32.4: Analysis of Experimental Results As shown in figure 3.2.4.A.2 the maximum raw data rate of Appletalk, at 230.4 KBits / second, far exceeds that of RS-232, at 9600 Bits / second. Using these base numbers Appletalk has a raw communications speed that is 24 times faster than the raw data rate of the RS-232 communications interface used. However, the point to point nature of the RS-232 interface and the low protocol overhead (i.e. 2 bits per 8 bit character), make this interface rather efficient (80%). On the other hand, Appletalk is set up to be a local area network and has with it several inherent overheads: 1. several layers of protocol overhead including: "to" - the address "from" - the address; - the type of frame (i.e. information, acknowledgement, etc.); - flow control information; - error detection via a CRC check 2. retransmission if an error occurred; 3. contention with other computers and printers sharing the Appletalk network; 4. the requirement to break up large files into packets no larger than 512 bytes. Due to these factors Appletalk tends to be less efficient The calculated efficiency values, based on the measured times to download two files of different size, are 20% and 30% for the larger and smaller files respectively. Instead of being 24 times faster than RS-232, Appletalk is only 9 times faster for the 96 character case and 6 times faster for the larger full page of text case. The reason Appletalk gets less efficient as the file size increases is up" listed as factor #4 above. The 4,322 byte file needs to be "chopped into 9 smaller sub-file and sent to the printer through 9 separate packets. The smaller 363 byte file can easily fit in one packet and is subsequendy faster. It is not known how badly the throughput of Appletalk degrades as files sizes get much larger. Size of the downloaded file is a very important factor especially when considering downloadable fonts. Font sizes of the downloaded fonts used in this section 3.2 are as follows: Stone Serif 34,260 bytes Galileo Roman 44,341 bytes Also note that for this experiment no other computers were active on the Appletalk network So the factor listed in #3 above did not even come into play. efficient" Still it should be noted that although Appletalk is "less than RS-232, it still is shown delivering between 6 and 9 times the throughput of the RS-232 interface for the experiments run in this section. 99 Section 3.2.4: Analysis of Experimental Results 2,339 96 characters (96 + 2,243) characters RS-232 Appletalk RS-232 Appletalk Characters Download 363 Characters R,322 Page 2,904 Bits 34,567 Bits Size 'V *-|_ h Measured 4.502 sec. 765 msec. Download 378 msec 42 msec. Time Maximum 9600 230,400 9600 230,400 Bit Rate Bits / Sec. Bits / Sec Bits / Sec Bits / Sec (Bits/Sec) Calculated 45,186 Bit Rate 7,683 69,143 7,678 /Sec Bits Sec (Bits/Sec) Bits / Sec Bits / Sec Bits / % Comm 80% 30% 80% 20% Protocol Efficiency Efficiency Efficiency Efficiency Efficiency % Comm. 20% 70% 20% 80% Protocol Overhead Overhead Overhead Overhead Overhead Measured values are printed in Bold print. Calculated values are printed in Roman print Appletalk vs. RS-232 Download Times Figure 3.2.4.A.2 100 Section 3.2.4: Analysis of Experimental Results 3.2.4.C. Proposed Improvements Faster local area networks, like Ethernet at 10 MBits/seconds could improve the communications bottleneck present with large files (fonts, images, etc.). The cost of Ethernet may still be a drawback to this improvement. Faster dedicated point-to-point communications interfaces, like a faster RS-232 running at 19.2 K or higher, or a Centronics parallel interface running at more than 100 KBits / second. An architecture that supports spooling input files as fast as the communcations interface allows with faster rates available from the internal disc (i.e. SCSI interface). 101 Section 3.2.4: Analysis of Experimental Results 3.3 Methods nf Printing Strings 3.3.A. Experimental Results Strings of characters can be placed on a given page in a number ofways. Each method outlined in this section will be used to print the pages shown in figures 3.3.A. 1 through 3.3.A.3. For the following examples please note that words in bold are POSTSCRIPT tokens; all other variables, numbers, and words are parameters that influence the effect of the command. Note that all pages use a the Times-Roman font set at 10 point All times given assume the font has already been scan converted A. Simple unjustified text (i.e. "ragged right") 72.00 710.00 moveto (A. IMAGE LOOP. The KODAK EKTAPRINT IMAGE LOOP is a ....)show 72,00 700.00 moveto (electrically charged, and is sensitive to direct light The IMAGE LOOP...)show 72.00 280.00 moveto (effectively transfers the copy image to the paper. )show Note: The printedpage produced with this method is shown infigure 3.3A.1. B . Justified text with the front end application providing the extra incremental spacing to be applied between adjacent characters. 72.00 710.00 moveto 0.054 0(A. IMAGE LOOP. The KODAK EKTAPRINT IMAGE LOOP...) ashow for the above line, the characters are spaced proportionally with 0.054 points added to relative x increment "0" to every character, note that is the y increment 72.00 700.00 moveto 0.044 0(electrically charged, and is sensitive to direct light The TMAGE...)ashow 72.00 290.00 moveto 0.356 0(which produces a negative charge on the paper surface to attract..)ashow 72.00 280.00 moveto (effectively transfers the copy image to the paper. )show Note: Theprintedpage produced with this method is shown infigure 3.3A2. 102 Section 3.3 : Analysis ofExperimental Results A. IMAGE LOOP. The KODAK EKTAPRINT IMAGE LOOP is a continuous loop of film that is capable of being electrically charged, and is sensitive to direct light. The IMAGE LOOP is driven around the IMAGE LOOP CORE in a continuous motion for as long as copy exposures are being made (see Figure 1). B. PRIMARY CHARGER. The function of the PRIMARY CHARGER is to place a negative charge on the IMAGE LOOP. This prepares the IMAGE LOOP for exposure and development The IMAGE LOOP starts moving on command from LOGIC AND CONTROL. LOGIC AND CONTROL then turns on the PRIMARY CHARGER. C. EXPOSURE. The charged IMAGE LOOP continues around the CORE to the EXPOSURE area, where it is exposed to a reflected light copy image that is focused on the IMAGE LOOP at precisely the right time, as determined by LOGIC AND CONTROL. The original document is illuminated by high intensity flash lamps for a short duration, which prevents blurring of the image as it is exposed on the moving IMAGE LOOP. The charge on the IMAGE LOOP is removed from the areas that are exposed to light. The charge remains in the areas that are not exposed. The exposure is said to discretely alter the charge characteristics of the IMAGE LOOP so that the focused copy image is recorded on the IMAGE LOOP. This IMAGE LOOP image is known as an electrostatic image. D. AUXILIARY ERASE. Just before each first and just after each last, exposure area is an improperly charged segment. These segments are produced when the PRIMARY CHARGER is turned on at the time of initial IMAGE LOOP movement and turned off during final IMAGE LOOP movement. As the unwanted areas pass under the AUXILIARY ERASE LAMP, it floods the moving IMAGE LOOP base with light that desensitizes the IMAGE LOOP to prevent unwanted development. E. DEVELOPER STATION ASSEMBLY. The properly charged and exposed IMAGE LOOP area now enters the DEVELOPER STATION ASSEMBLY where positively charged KODAK EKTAPRINT K Toner particles are attracted to the IMAGE LOOP. Development occurs as the result of attraction of the toner particles to the electrostatic image on the IMAGE LOOP. The toner particles are carried away on the IMAGE LOOP surface for later transfer to a copy paper. F. SCAVENGER ROLLER. Any developer carrier granules (iron) left on the IMAGE LOOP are salvaged at this point by the SCAVENGER ROLLER and returned to the DEVELOPER STATION ASSEMBLY. G. POST-DEVELOPMENT ERASE LAMP. To reduce the electrostatic stress on the IMAGE LOOP and thereby increases its life, the POST DEVELOPMENT ERASE LAMP is used to lower the high level charge that was required for proper image development. This POST-DEVELOPMENT ERASE process also helps to prevent residual image retention. H. REGISTRATION. While the developed electrostatic image moves around the CORE, a sheet of copy paper is advanced to the REGISTRATION ASSEMBLY (not shown in Figure 1). At precisely the right time, the copy paper is directed into contact with the IMAGE LOOP and its developed image. This aligns the copy paper and the image on the IMAGE LOOP. I. TRANSFER CHARGER. The IMAGE LOOP and copy paper now pass under the TRANSFER CHARGER, which produces a negative charge on the paper surface to attract the positive charged developer toner. This effectively transfers the copy image to the paper. Note : The printed areas on this page excluding the region bounded by this rectangle is the printed test page output Simple Unjustified Text (i.e. "ragged right") Figure 3.3.A.1 page 103 A. IMAGE LOOP. The KODAK EKTAPRINT IMAGE LOOP is a continuous loop of film that is capaWe of being LOOP is driven around the IMAGE LOOP CORE electrically charged, and is sensitive to direct light The IMAGE (see Figure 1). in a continuous motion for as long as copy exposures are being made on the B. PRIMARY CHARGER. The function of the PRIMARY CHARGER is to place a negative charge IMAGE LOOP starts on LOOP. This prepares the IMAGE LOOP for exposure and development. The IMAGE moving on PRIMARY CHARGER. command from LOGIC AND CONTROL. LOGIC AND CONTROL then turns the C. EXPOSURE. The charged IMAGE LOOP continues around the CORE to the EXPOSURE area, where it is LOOP at the right as exposed to a reflected light copy image that is focused on the IMAGE precisely time, determined by LOGIC AND CONTROL. The original document is illuminated by high intensity flash lamps for a The charge on short duration, which prevents blurring of the image as it is exposed on the moving IMAGE LOOP. the IMAGE LOOP is removed from the areas that are exposed to light The charge remains in the areas that are not exposed. The exposure is said to discretely alter the charge characteristics of the IMAGE LOOP so that the focused an electrostatic image. copy image is recorded on the IMAGE LOOP. This IMAGE LOOP image is known as D. AUXILIARY ERASE. Just before each first and just after each last exposure area is an improperly charged segment. These segments are produced when the PRIMARY CHARGER is turned on at the time of initial IMAGE LOOP movement and turned off during final IMAGE LOOP movement. As the unwanted areas pass under the AUXILIARY ERASE LAMP, it floods the moving IMAGE LOOP base with light that desensitizes the IMAGE LOOP to prevent unwanted development. E. DEVELOPER STATION ASSEMBLY. The properly charged and exposed IMAGE LOOP area now enters the DEVELOPER STATION ASSEMBLY where positively charged KODAK EKTAPRINT K Toner particles are attracted to the IMAGE LOOP. Development occurs as the result of attraction of the toner particles to the electrostatic image on the IMAGE LOOP. The toner particles are carried away on the IMAGE LOOP surface for later transfer to a copy paper. F. SCAVENGER ROLLER. Any developer carrier granules (iron) left on the IMAGE LOOP are salvaged at this point by the SCAVENGER ROLLER and returned to the DEVELOPER STATION ASSEMBLY. G. POST-DEVELOPMENT ERASE LAMP. To reduce the electrostatic stress on the IMAGE LOOP and thereby increases its life, the POST DEVELOPMENT ERASE LAMP is used to lower the high level charge that was required for proper image development. This POST-DEVELOPMENT ERASE process also helps to prevent residual image retention. H. REGISTRATION. While the developed electrostatic image moves around the CORE, a sheet of copy paper is advanced to the REGISTRATION ASSEMBLY (not shown in Figure 1). At precisely the right time, the copy paper is directed into contact with the IMAGE LOOP and its developed image. This aligns the copy paper and the image on the IMAGE LOOP. I. TRANSFER CHARGER. The IMAGE LOOP and copy paper now pass under the TRANSFER CHARGER, which produces a negative charge on the paper surface to attract the positive charged developer toner. This effectively transfers the copy image to the paper. Note : The printed areas on this page excluding the region bounded by this rectangle is the printed test page output Justified text with the front end application providing the extra incremental spacing to be applied between adjacent characters. page 104 Figure 3.3.A.2 C. Justified text with the front end application providing the extra incremental spacing to be applied between adjacent words. 72.00 710.00 moveto 0.293 0 32 (A. IMAGE LOOP. The KODAK EKTAPRINT IMA...)widthshow for the line above, the characters are spaced proportionally with 0.293 points added to relative x increment to every character with an ASCII "32" value of (i.e. a space); note that "0" is the y increment 72.00 700.00 moveto 0.263 0 32 (electrically charged, and is sensitive to direct light. Th...)widthshow 72.00 290.00 moveto 2.242 0 32 (which produces a negative charge on the paper surface...)widthshow 72.00 280.00 moveto (effectively transfers the copy image to the paper. )show Note: The printedpage produced with this method is shown infigure 3.3A.3. 105 Experimental Results Section 3.3 : Analysis of A. IMAGE LOOP. The KODAK EKTAPRINT IMAGE LOOP is a continuous loop of film that is capable of being driven around the IMAGE LOOP electrically charged, and is sensitive to direct light. The IMAGE LOOP is CORE in a continuous motion for as long as copy exposures are being made (see Figure 1). B. PRIMARY CHARGER. The function of the PRIMARY CHARGER is to place a negative charge on the IMAGE LOOP. This prepares the IMAGE LOOP for exposure and development The IMAGE LOOP starts moving on command from LOGIC AND CONTROL. LOGIC AND CONTROL then turns on the PRIMARY CHARGER. C. EXPOSURE. The charged IMAGE LOOP continues around the CORE to the EXPOSURE area, where it is exposed to a reflected light copy image that is focused on the IMAGE LOOP at precisely the right time, as determined by LOGIC AND CONTROL. The original document is illuminated by high intensity flash lamps for a short duration, which prevents blurring of the image as it is exposed on the moving IMAGE LOOP. The charge on the IMAGE LOOP is removed from the areas that are exposed to light The charge remains in the areas that are not exposed. The exposure is said to discretely alter the charge characteristics of the IMAGE LOOP so that the focused copy image is recorded on the IMAGE LOOP. This IMAGE LOOP image is known as an electrostatic image. D. AUXILIARY ERASE. Just before each first, and just after each last, exposure area is an improperly charged segment. These segments are produced when the PRIMARY CHARGER is turned on at the time of initial IMAGE LOOP movement and turned off during final IMAGE LOOP movement. As the unwanted areas pass under the AUXILIARY ERASE LAMP, it floods the moving IMAGE LOOP base with light that desensitizes the IMAGE LOOP to prevent unwanted development. E. DEVELOPER STATION ASSEMBLY. The properly charged and exposed IMAGE LOOP area now enters the DEVELOPER STATION ASSEMBLY where positively charged KODAK EKTAPRINT K Toner particles are attracted to the IMAGE LOOP. Development occurs as the result of attraction of the toner particles to the electrostatic image on the IMAGE LOOP. The toner particles are carried away on the IMAGE LOOP surface for later transfer to a copy paper. F. SCAVENGER ROLLER. Any developer carrier granules (iron) left on the IMAGE LOOP are salvaged at this point by the SCAVENGER ROLLER and returned to the DEVELOPER STATION ASSEMBLY. G. POST-DEVELOPMENT ERASE LAMP. To reduce the electrostatic stress on the IMAGE LOOP and thereby increases its life, the POST DEVELOPMENT ERASE LAMP is used to lower the high level charge that was required for proper image development This POST-DEVELOPMENT ERASE process also helps to prevent residual image retention. H. REGISTRATION. While the developed electrostatic image moves around the CORE, a sheet of copy paper is advanced to the REGISTRATION ASSEMBLY (not shown in Figure 1). At precisely the right time, the copy paper is directed into contact with the IMAGE LOOP and its developed image. This aligns the copy ^paper and the image5 on the IMAGE LOOP. I. TRANSFER CHARGER. The IMAGE LOOP and copy paper now pass under the TRANSFER CHARGER, which produces a negative charge on the paper surface to attract the positive charged developer toner. This effectively transfers the copy image to the paper. Note : The printed areas on this page excluding the region bounded by this rectangle is the printed test page output Justified text with the front end application providing the extra incremental spacing to be applied between adjacent words. Page 106 Figure 3.3.A.3 D. Justified text with the downloaded POSTSCRIPT program calculating excess space and it distributing between all adjacent characters. The number of characters in each "js" line is passed to the routine. /xlen 468 def width of line set at 468 points or 6.5 inches "js" /js{ - justify string procedure name: assumes a string to be printed is on top of the stack /si exch "si" def is a variable that is assigned the length of the string on the stack in an integer number of characters, including spaces "sw" dup stringwidth pop /sw exch def is a variable that is assigned the width of the string on the stack in current units; if no scale command was issued, then the current unit is "point" the /s exch def "s" is the name of the string on top of the stack xlen sw sub the excess space is calculated si 1 sub div and distributed between adjacent characters "0" 0 s ashow indicates that the incremental character positioning is only in the x "s" direction; the string is printed }def 72.00 710.00 moveto (A. IMAGE LOOP. The KODAK EKTAPRINT IMAGE LOOP is a contin...) 99 js characters are automatically spaced proportionally with the extra space evenly distributed between adjacent characters 72.00 700.00 moveto (electrically charged, and is sensitive to direct light The IMAGE...) 108 js 72.00 290.00 moveto (which produces a negative charge on the paper surface to attract..) 108 js 72.00 280.00 moveto (effectively transfers the copy image to the paper. )show Note: The pageproduced is the same as the one shown infigure 3.3A2. 107 Section 3.3 : Analysis of Experimental Results the excess E. Justified text with the downloaded POSTSCRIPT program calculating the space between space and the number of characters in the string, and distributing not passed to the all adjacent characters. The number of characters in each line is "js" "js" within itself. routine, as in (D), but instead is calculated /xlen 468 def width of line set at 468 points or 6.5 inches "js" /js{ - justify string procedure name: assumes a string to be printed is on top of the stack "sw" dup stringwidth pop /sw exch def is a variable that is assigned the width of the string on the stack in current units; if no scale command was issued, then the current unit is "point" the "si" dup length /si exch def is a variable that is assigned the length of the string on the stack in an integer number of characters, including spaces "s" /s exch def is the name of the string on top of the stack xlen sw sub the excess space is calculated si 1 sub div and distributed between adjacent characters "0" 0 s ashow indicates that the incremental character positioning is only in the x "s" direction; the string is printed }def 72.00 710.00 moveto (A. IMAGE LOOP. The KODAK EKTAPRINT IMAGE LOOP is a continuo )js 72.00 700.00 moveto (electrically charged, and is sensitive to direct light. The IMAGE )js 72.00 290.00 moveto (which produces a negative charge on the paper surface to attract )js 72.00 280.00 moveto (effectively transfers the copy image to the paper. )show Note: The page produced is the same as the one shown infigure 3.3A2. 108 Section 3.3 : Analysis ofExperimental Results F. In addition to "js" "js" the functions performed by the routine in (E), the routine for this section also handles the carriage return - line feed functions. /x 72 def 730 def /y starting (x,y) coordinates /xlen 468 def width of line = 6.5 inches /D 1 {x y yneg sub dup /y exch def moveto} def single line feed /D2 {x " " y yneg 2 mul sub dup /y exch def moveto} def double carriage return - line feed /js{dup stringwidth pop /sw exch def dup length /si exch def /s exch def xlen sw sub si 1 sub div 0 s ashow Dl}def same as "js routine in (E) plus line feed - carriage return /yneg 10 def leading Dl (A. IMAGE LOOP. The KODAK EKTAPRINT IMAGE LOOP is a continu....)js (electrically charged, and is sensitive to direct light The IMAGE LOOP....)js (which produces a negative charge on the paper surface to attract the....)js (effectively transfers the copy image to the paper. )show The fastest measured print time (of the nine pages per run) is used for comparison: Case Print Time A 4.460 seconds B 4.514 seconds C 4.538 seconds D 4.872 seconds E 4.870 seconds F 4.926 seconds 3.3.B. Analysis As the experiments progress from case A through case F the POSTSCRIPT RIP is progressively handling more of the job: supplied the POSTSCRIPT characters A. All positioning information is by program; are positioned according to their normal proportional spacing rules; no adjustment is made for justification. The show command is used. 109 Section 3.3 : Analysis ofExperimental Results B. Positioning information is still supplied by the POSTSCRIPT program, as in (A), but now the position ofevery character of each printed string is adjusted by an amount that is also specified by the POSTSCRIPT program. This is to achieve full justification of the text. The ashow command is used. C. Once again, the positioning information is supplied by the POSTSCRIPT program, as in both (A) and (B). Now, instead of adjusting the position of every character, as in (B), only the position of characters that have the ASCII code represented by the "32" "space" decimal number (i.e. the character) will be adjusted. The amount of adjustment is provided by the POSTSCRIPT program, same as in (B). This case is more difficult than (B) in that the RIP needs to check each character and only adjust the positioning of one particular character, namely the space character in this case. D. The positioning information is still supplied by the POSTSCRIPT program. A separate routine, called js, calculates the length of the string passed to it, subtracts the calculated width from the preassigned width of the line held in xlen, divides this number by the number of characters in the string (less one) which is also supplied to the js program, and uses this result as a parameter for tha ashow command. Many more calculations are executed here than in cases (A), (B), or (C). E. This case is similar to (D) except the number of characters in the string is also calculated in the js routine using the length operator, instead of this number being provided to js, as in (D). Note tlie time to print cases (D) and (E) are nearly the same. This indicates that the overhead to get the length ofthe sting to beprinted using length is similar to the overhead incurred bypassing the length ofthe string itself. feed" F. This case is similar to (E) except the "carriage return / line function is automated with programs Dl and D2. It can be seen that as the complexity of the program to print text increases, the time to print them also increases. The only apparent contradiction to this rule is explained in the italicized print for case (E). 3.3.C. Proposed Improvements Encourage the printer driver developers to write simple POSTSCRIPT code. 110 Section 3.3 : Analysis ofExperimental Results "Targeting" 3,4 Resolution vs. Total Evolution TnrippPnrW> 3.4.A. Experimental Results Strings of characters can be placed on a given page in a number of ways. Each method oudined in this section will be used to print the pages shown in figures 3.3.A.1 through For the following examples please note that words in bold are POSTSCRIPT tokens; all other variables, numbers, and words are parameters that influence the effect of the command. Note that all pages use a the Times-Roman font set at 10 point All times given assume the font has already been scan converted Simple unjustified text (i.e. "ragged right") with the CTM set to device resolution, 300 units to the inch. 72 300 div dup scale /Times-Roman findfont 3000 72 div scalefont setfont 300 3000 moveto (A. IMAGE LOOP. The KODAK EKTAPRINT IMAGE LOOP is a cont....)show 300 2958 moveto (electrically charged, and is sensitive to direct light. The IMAGE LOOP...)show 300 1250 moveto (which produces a negative charge on the paper surface to attract the....)show 300 1208 moveto (effectively transfers the copy image to the paper. )show Note: The printedpage produced with this method is shown infigure 3.4A.1. The fastest measured print time (of the nine pages per run) is used for comparison: Case Print Time A 4.460 seconds the point is used as the positioning unit "target" 4.458 seconds the 300 dpi pixel is used as the positioning unit 3.4.B. Analysis user coordinates to print engine pixels did not seem Setting up the CTM to direcdy map to have an effect on speed nor appearance (compage figure 3.3.A. 1 to 3.4.A.1). 3.4.C. Proposed Improvements None. Ill Section 3.4 : Analysis ofExperimental Results continuous of film that is capable of A. IMAGE LOOP The KODAK EKTAPRINT IMAGE LOOP is a loop being tight. The IMAGE LOOP is driven around the IMAGE LOOP CORE electrically charged, and is sensitive to direct made (see Figure 1). in a continuous motion for as long as copy exposures are being charge on the IMAGE B PRIMARY CHARGER. The function of the PRIMARY CHARGER is to place a negative IMAGE LOOP starts on LOOP This prepares the IMAGE LOOP for exposure and development The moving then turns on the PRIMARY CHARGER. command from LOGIC AND CONTROL. LOGIC AND CONTROL EXPOSURE where it is C EXPOSURE. The charged IMAGE LOOP continues around the CORE to the area, IMAGE LOOP at the right as exposed to a reflected light copy image that is focused on the precisely time, flash for a determined by LOGIC AND CONTROL. The original document is illuminated by high intensity lamps IMAGE LOOP. The charge on short duration, which prevents blurring of the image as it is exposed on the moving the areas that are not the IMAGE LOOP is removed from the areas that are exposed to light The charge remains in IMAGE LOOP so that the focused exposed. The exposure is said to discretely alter the charge characteristics of the LOOP image is known as an electrostatic image. copy image is recorded on the IMAGE LOOP. This IMAGE D. AUXILIARY ERASE. Just before each first and just after each last exposure area is an improperly charged segment. These segments are produced when the PRIMARY CHARGER is turned on at the time of initial IMAGE LOOP movement and turned off during final IMAGE LOOP movement As the unwanted areas pass under the AUXILIARY ERASE LAMP, it floods the moving IMAGE LOOP base with light that desensitizes the IMAGE LOOP to prevent unwanted development E. DEVELOPER STATION ASSEMBLY. The properly charged and exposed IMAGE LOOP area now enters the DEVELOPER STATION ASSEMBLY where positively charged KODAK EKTAPRINT K Toner particles are attracted to the IMAGE LOOP. Development occurs as the result of attraction of the toner particles to the electrostatic image on the IMAGE LOOP. The toner particles are carried away on the IMAGE LOOP surface for later transfer to a copy paper. F. SCAVENGER ROLLER. Any developer carrier granules (iron) left on the IMAGE LOOP are salvaged at this point by the SCAVENGER ROLLER and returned to the DEVELOPER STATION ASSEMBLY. G. POST-DEVELOPMENT ERASE LAMP. To reduce the electrostatic stress on the IMAGE LOOP and thereby increases its life, the POST DEVELOPMENT ERASE LAMP is used to lower the high level charge that was required for proper image development. This POST-DEVELOPMENT ERASE process also helps to prevent residual image retention. H. REGISTRATION. While the developed electrostatic image moves around the CORE, a sheet of copy paper is advanced to the REGISTRATION ASSEMBLY (not shown in Figure 1). At precisely the right time, the copy paper is directed into contact with the IMAGE LOOP and its developed image. This aligns the copy paper and the image on the IMAGE LOOP. I. TRANSFER CHARGER. The IMAGE LOOP and copy paper now pass under the TRANSFER CHARGER, which produces a negative charge on the paper surface to attract the positive charged developer toner. This effectively transfers the copy image to the paper. Note : The printed areas on this page excluding the region bounded by this rectangle is the printed test page output Simple Unjustified Text (i.e. "ragged right") with all positioning coordinates given in device units (300 dpi). page 112 Figure 3.4.A.1 3,5 Effect of Varied Page Complexity on PostScript Processing Time 3.5. 1 Effect on the Inter-Page Time Delay Program sec 3.5.1.A. Experimental Results The sec program, shown below, is measured and analyzed in this section. /sec % one second delay under no load { usertime /T exch def % keep track of time actually taken 1228 { 373.737 737.373 mul pop }repeat } repeat usertime T sub def }def In each of the five cases the sec program is called seven times. Each time the parameter selecting the intended time delay, in seconds, changes until all seven are completed in the seqeunce 1, 2, 3, 5, 8, 12, and 16. These are the target delay times shown in the figure below. As the cases progress from one though five, the amount of work that the RIP does outside the sec delay program increases. In case one, nothing is done other than calling the sec program and reporting the measured times in the printed trailer page. In case two, a trivial page routine which prints a blank page is called in between calls to the sec routine. In cases three and four, the page routine includes the printing of a few lines of text at the top and the bottom of the page, respectively. And in case five a full page of text is printed. Detailed descriptions of the five cases follow. Case 1 Experiment: The sec program is called seven separate times. Each time it is called one of the seven target delay times, shown above, is passed to it. The page procedure is not part of this particular POSTSCRIPT job and is therefore never called. Only the trailer page with the seven measured delay times is printed. No other showpage instruction is executed. Note that the loop count of 1228 was heuristically generated to produce results as close as possible to the target delay load" times under this "no condition. /sec { sec delay program is shown above }def AVI 1 sec AV2 2 sec AV16 16 sec print trailerpage 113 Results Section 3.5.1 : Analysis ofExperimental Case 2 Experiment: This case is similar to case one with one exception: the showpage operator is executed inside the page procedure and timed between each pair of sequential causes pages to be printed followed calls to the sec delay program. This blank by the trailer page containing the seven measured delay times. /page { showpage } def /sec { sec delayprogram is shown on previous page }def /Pr { calls and times the secprocedure; shown infigure 2.22.2 and page 3 ofappendix 22.4 }def /T2Pr /Wl 1 sec /T3Pr /YV2 2 sec /T4Pr /W16 16 sec AT9Pr print trailerpage Case 3 Experiment: This case is similar to case two except for the operations executed in the page procedure. Thirteen lines of left justified text plus 2 additional line spaces (to "printed" separate 3 paragreaphs) are in page using the POSTSCRIPT show operator. The text is positioned at the top of the page occupying almost two inches of the page (in the y direction). It starts at 10 inches from the bottom of the page (or 1 inch from the top) and progressing downward to 8.1 inches from the bottom of the page. /page { 72 700 moveto ( string 1 ) show 72 691 moveto ( string 2 ) show 72 574 moveto ( string 13 )show showpage }def The sec and Prprocedures, the calling sequence to these procedures, and theprinting ofthe trailerpage are the same as shown in case two above. 114 Section 3.5.1 : Analysis ofExperimental Results Case 4 Experiment: This case is identical to case three with the exception of the position of the thirteen lines of left justified text printed in page. Here the text is positioned at the bottom of the page instead of the top of the page as in case three. It starts at 2.8 from inches the bottom of the page and progressing downward to 0.9 inches from the bottom of the page. /page { 72 190 moveto ( string 1 ) show 72 181 moveto ( string 2 ) show 72 64 moveto ( string 13 ) show showpage }def The sec and Prprocedures, the calling sequence to these procedures, and the printing ofthe trailerpage are the same as shown in case two. Case 5 Experiment: This case is identical to case three with the exception of the number of lines printed: 29 (with 8 additional line spaces) instead of 13 (with 2 additional line spaces). It starts at 10 inches from the bottom of the page and progressing downward to 5.2 inches from the bottom of the page. /page { 72 700 moveto ( string 1 ) show 72 691 moveto ( string 2 )show 72 376 moveto ( string 29 )show showpage }def The sec andPrprocedures, the calling sequence to these procedures, and the printing ofthe trailerpage are the same as shown in case two. Target Delav Time Casel Case 2 Case 3 Case 4 Case 5 1 1.074 1.006 1.686 1.716 1.716 2 2.020 2.006 2.686 3.540 3.446 3 3.000 3.008 3.684 5.362 4.446 5 4.998 5.004 5.684 7.440 6.444 8 7.998 8.004 8.684 10.438 9.442 12 11.994 12.002 12.682 14.436 13.440 16 15.992 15.998 16.678 18.434 17.438 all times given in seconds 115 Experimental Section 3.5.1 : Analysis of Results 18 . Half^Page- of Text (case 5) ||rr-*11Top-Load- (case 3) -a c o U n > j C No Load : iand : J2 j "showpage'! Q | (cases 1 and 2) CD W) cd Oh I \- o CD seconds^ j "2"""T"""6 "8 i'6 12 14 16 i.8 20 "sec" Inter-Page Time Delay Under No Load Conditions Figure 3.5.1.A. 1 116 Section 3.5.1 : Analysis of Experimental Results 3.5. l.B. Analysis Note the correlation between distance from bottom of page that characters are placed and delay time discrepancy. 1 ~ (8. .7 Top inches) sec for all target delays of 1 sec and up case 3 ~ Middle (5.2 1 .4 inches) sec for all target delays of 2 sec and up case 5 Bottom (.9 inch) -2.4 sec for all target delays of 3 sec and up case 4 The time taken to execute sec seems only to be influenced by the position of the mark on the page that is closest to the bottom of the page. Furthermore, this relationship is linear: Assume x is the distance of the bottom-most mark on the page and y is the time discrepency in seconds. Using the top and bottom points of (8.1,0.7) and (0.9,2.4) the slope (m) and y intercept (b) can be calculated to be: m = - 0.236 b = 2.613 Calculating the third point, y, with the x value equal to 5.2 yields: y = mx + b = (-0.236) 5.2 + 2.613 = 1.385 ~= 1.4 Page complexity does not seem to have any effect: case 5 prints the more than twice as much text as either cases 3 or 4, yet the sec delay program time discrepency lies in between these two cases. One possible explanation for this strange behavior is that immediately following the showpage command, the POSTSCRIPT interpreter needs to clear the page buffer memory before the next page is allowed to use the page. The algorithm seems to start from the top of the page and work its way down until it is determined that no more page memory was used. In case 3 this occurs close to the top of the page so this overhead is minimal, but in case 4 this occurs almost at the very bottom of the page, so the overhead in great. 3.5.1.G Proposed Improvements If a dual page buffer were used with additional hardware to do the necessary should disappear. memory housecleaning this phenomena 117 Section 3.5.1 : Analysis ofExperimental Results 3.5.2 Effect on the Compilation and Rasterization of Text Pages 3.5.2.A. Experimental Results Experimental cases 3 and 4, described in the previous section, are used here. Sample output for case 3 is shown in figure 3.5.2.A.1, along with its observations will be corresponding timing page in figure 3.5.2.A.2. Two made: 1. The time to execute (i.e. print) the text page from case 3 will be examined as the induced delay between subsequent pages changes. 2. How the data from (1) above changes as the position of the text changes will also be examined. This is done by comparing the measured times of case 4, which prints several lines to text close to the bottom of the page, to the measured times of case 3, which prints the save text close to the top of the page (see figure 3.5.2.A.3). 3.5.2.B. Analysis As shown in figure 3.5.2.A.2 the time to print the very simple page of text (with pre-cached fonts) is 5.542 seconds for the first page. With no induced delay the second page prints in 7.322 seconds. As the induced delay times increase in between pages the time needed to print the next three test pages steadily decreases. With a 3.734 second delay (target delay of 3 seconds) the measured print time is 3.898 seconds. As the delay time increases to to 5.736 seconds the measured print time stays constant This is the point at which the printer motor turns off (as observed by hearing). As the delay times increase from 8 to 16 seconds the print time is again constant at a much higher print time, -5.45 seconds. Possible explanations for this behavior is broken into three sections: 1. Print time decreases as interpage delay time increases. During this region way" printing the previous page "gets in the of printing the current page. As more time is allowed between pages, the previous page gets in the way less and therefore the current page waits less time to access the page buffer and therefore takes less time to render the page. 2. Constant minimum time: increasing delay time does not effect print time. Once the point has been reached where enough time between pages is waited the previous page no longer interferes with the printing of the current page, the page prints at its maximum possible speed. As long as nothing else changes, (i.e. status of print engine, etc.) changing the interpage delay times has no effect on the printing times. 3. Second constant time region (after motor shuts off): no effect of increasing delay time. Once the print engine motor shuts off, additional time is required to turn it back on. 118 Section 3.5.2 : Analysis ofExperimental Results A. IMAGE LOOP. The KODAK EKTAPRINT IMAGE LOOP is a continuous loop of film that is capable of being electrically charged, and is sensitive to direct light. The IMAGE LOOP is driven around the IMAGE LOOP CORE in a continuous motion for as long as copy exposures are being made (see Figure 1). B. PRIMARY CHARGER. The function of the PRIMARY CHARGER is to place a negative charge on the IMAGE LOOP. This prepares the IMAGE LOOP for exposure and development The IMAGE LOOP starts moving on command from LOGIC AND CONTROL. LOGIC AND CONTROL then turns on the PRIMARY CHARGER. C. EXPOSURE. The charged IMAGE LOOP continues around the CORE to the EXPOSURE area, where it is exposed to a reflected light copy image that is focused on the IMAGE LOOP at precisely the right time, as determined by LOGIC AND CONTROL. The original document is illuminated by high intensity flash lamps for a short duration, which prevents blurring of the image as it is exposed on the moving IMAGE LOOP. The charge on the IMAGE LOOP is removed from the areas that are exposed to light. The charge remains in the areas that are not exposed. The exposure Is said to discretely alter the charge characteristics of the IMAGE LOOP so that the focused an electrostatic image. copy image is recorded on the IMAGE LOOP. This IMAGE LOOP image is known as the region Note The printed areas on this page excluding test page output bounded by this rectangle is the printed of Page Case 3 Output: Printing on Top PaSe 119 Figure 3.5.2.A.1 20t 15- 1/3 C o o u 10+ c o c o o ID to 5 - 0 + -fc 5 10 15 20 Wait Time After Previous Page [in seconds] Download Time = 2350 Page Time 1 (A) = 434 Page Time 1 (B) = 5532 = Wait Time 0 sec =0 Page Time 2 7320 Wait Time 1 sec = 1716 Page Time 3 = 5644 Wait Time 2 sec = 2738 Page Time 4 = 4626 Wait Time 3 sec = 3736 Page Time 5 = 3894 Wait Time 5 sec = 5736 Page Time 6 = 3894 Wait Time 8 sec = 8734 Page Time 7 = 5430 Wait Time 12 sec = 12732 Page Time 8 = 5440 Wait Time 16 sec = 16728 Page Time 9 = 5484 Ave Pg Time 2-9 = 5216.5 Note: All times are specified in milliseconds. page 120 Figure 3.5.2.A.2 Test Page The second part of this analysis deals with comparing printing times when the positions of the text that is placed on the page changes. Data that has been extracted from figure 3.5.2.A.2 for case 3 and a similar timing page for case 4 (not shown) was compiled and put in graph form. The data, shown in figure 3.5.2.A.3, indicates that only variations in the delay time effect the printing times. Region 1 ranges from 1.7 seconds to about 3.7 seconds; region 2 from 3.7 seconds to 7.4 seconds, and region 3 above 7.4 seconds 3.5.2.C. Proposed Improvements Once again, a dual page buffer system with hardware assist would help eliminate the extra time in region 1. Secondly, entrance into region 3 could be ready" delayed or eliminated if the printer were left in a "more state (i.e. without stopping the motor) when the RIP is still processing a print job. On the negative side, more power would be taken up when the print engine itself would be in the idle state. 121 Experimental Results Section 3.5.2 : Analysis of Oi ? : CO j -; I \ * & S3 a o 4 ? *'' j B3 CO !> ;- ' ?? j ; j j ^ s> &> cu IT) >* ^ \ \ I ] M \ " ; | E ] | M 8 C5 i j ^>w . . . . . : co 1/3 ; ; N51 | bfl r^ i | 8 CD i | i\\ \ I Lf) PQ : : i \ W CO ; i sA CM I j * \ VO CO I seconds Page Rasterization Performance Under Varied Wait Times Figure 3.5.2.A.3 122 Section 3.5.2 : Analysis ofExperimental Results 4. Conclusions 4.1 Scan Converting Outline Fonts vs. Caching Rjtman Fonts fonts that are in the Printing bitmap bitmap font cache are about 500 times faster than scan the outline converting corresponding font (see section 3.1.4). The character scan conversion or rastenzation rate is 3 approximately characters per second (see sections 3.1.1 and 3 1 5) Note that this time includes the POSTSCRIPT interpretation overhead. Because this is such a dominant factor, several methods are used to increase the probability of a font being in bitmap form when it is specified in a POSTSCRIPT program: 1. a small set of fonts are stored in ROM in bitmap form (see section 3.1.3). These fonts are specified by the manufacturer of the LaserWriter Plus Printer, Apple Computer Inc. 2. an area of RAM in the memory RIP is reserved to serve as a bitmap font cache (see section 2.4). When a character of an outline font is specified in a POSTSCRIPT program, the time consuming scan conversion program is executed only one time (see section 3.1.1). The rendered bitmap font is stored in bitmap font cache. When the same character is subsequendy specified, it is accessed from this font cache. 3 a small set of which are fonts, stored in outline form, are scan converted during the printer's idle time (see section 3.1.3). The newly generated font bitmaps are stored in the bitmap font cache. This process generates certain default fonts at pre-selected sizes and orientations that are specified, once again, by the manufacturer of the printer which, in this case is Apple Computer Inc. much Since of the time of the printer is idle, this seems to be a very good way to build up a library of bit-map fonts in cache. 4. a process similar to that specified in #3 above allows the user to select which outline fonts are to be scan converted during the printer's idle time (see section 3.1.3). 5. a bitmap font can be downloaded to the printer and stored in the bitmap font cache, eliminating the scan conversion overhead. Unfortunately, the communications overhead can similary slow performance (see section 3.2.1). There are several potential ways to increase the performance of the POSTSCRIPT printer: "encourage" 1. the customer (e.g. person running the application program) to make extensive use of the pre-cached bitmap fonts described in #1 above or the idle time scan converted fonts described in #3 above. "encourage" 2. the customer to use a small number of fonts so that once they are scan converted by one of the means specified above they will be kept in the bitmap font cache for future use at the higher speed. "encourage" 3. the printer driver developers to make extensive use of the user-selectable idle time scan conversion function described in #4 above. Note that #1 through #3 are ways to increase performance that are accessable externally to the printer. 4. use a faster processor and/or math accelerator hardware. In the event that the selected font than has not been scan converted, the added hardware should scan convert faster the 3 character per second rate that was observed. helps if the printer 5. increase the ROM size to store more bitmap fonts. This only "guesses" will use. manufacturer correcdy which fonts the customer 123 Section 4 - Conclusions placed 6. increase the amount of font cache RAM. This will delay the time at which previously bitmap fonts must be cleared out of the bitmap font cache. with disk memory. a font from disk is still 7. extend the bitmap font cache Accessing bitmap faster than scan converting an outline font. section 1 .4). 8. make use of data compression for larger fonts (see communications interface to download the (or 9. use a faster and/or more efficient bitmap and 3.2.4). outline) fonts (see sections 2.2.1 require internal changes to the Note that #4 through #9 are ways to increase performance that RIP that drives the print engine. Hints" 4.2 Scan Converting Font Outlines with "Quality Applied hints" applied to the outline fonts At a printer resolution of 300 dots per inch, "quality are and At typical sizes during the scan conversion process (see sections 2.1.1.4 3.1.4). ranging uniform look from 6 to 14 point, the scan conversion algorithm uses these hints to insure that a character are to of the fonts are provided. For example, stems and curves of a given forced be the same dot patterns (e.g. "m"). Also similar characters are forced to have similar dot patterns "c" "m" (e.g. and "o", or and "n"). The experiments reported in section 3.1.4 reveal that these intelligent hints: 1. are only applied if the orientation of the font lies on a quadrant angle (i.e. 0, 90, 180, or 0 90 70 360). Only the and cases were tested. A font that was rotated did not have the "hints" applied 0 90 2. take additional time to apply. Figure 3. 1 . A.4 shows both the and cases taking 12 % 70 to 16 % longer to scan convert as compared to the case. This indicates that the overhead of applying the hints was greater than the overhead of rotating the font set to a non-quadrant angle. As the industry progresses to higher resolutions in the future, the issue of needing these font quality hints will probably fade away. 4.3 Font Style Complexity The performance of scan converting a font outline varies with the complexity of the font (see section 3.1.5). The simple Helvetica font style was measured to scan convert 38 % faster than the more complex Zapf Chancery font style. Performance of scan converting the Times Roman font was in between the simple Helvetica and the complex Zapf Chancery font styles, as could be expected. Fastest Helvetica scan converted at a rate of 3.976 characters per second. Medium Times Roman scan converted at a rate of 3.228 characters per second. Slowest ZapfChanceryscan convertedat a rate of2.875characters persecond. V2A Section 4 - Conclusion': 4.4 Downloading Fonts The paramter that key influences the performance of downloaded fonts is the download process itself. The time to download a font is influenced by: 1 . the size of the font; 2. the speed of the communications interface used; 3. the efficiency of the communications interface used; 4. the efficiency of the application program and communications interface driver software. One surprising result that was found in section 3.2.3 shows point #4 above to be a very significant factor. When the Adobe Stone Serif font was downloaded using Adobe's Font Downloader program, it took about 30 seconds to download the 34 KByte font. When the CasadyWare Galileo Roman font was downloaded using the Altsys Laser Writer Downloader program, it took about 10 seconds to download the 44 KByte font. This is three times faster to download about 30% more data. Both used the Appletalk communications interface. It was disappointing to find that the Adobe font would not download using the Altsys program, nor CasadyWare would the font download using the Adobe program. Without any more data available, it seems that point #4 above, the efficiency of the Altsys download program vs the Adobe download program, was the key difference. Once the font has been downloaded, the performance of downloaded fonts were similar to the performance of internal fonts. The performance of two different downloaded fonts were also rather close. When the scan conversion time of the Adobe internal Times Roman font was compared to the Adobe downloaded Stone Serif font the times were very close: 3.19 vs. 3.23 characters per second respectively. The third party downloaded CasadyWare Galileo Roman font scan converted at a slightly slower speed, 2.71 characters per second. This speed difference could be attributable to many different factors, like less efficient coding of the fonts themselves or the effect of the font style complexity variation. 4.5 Methods of Printing Strings Since POSTSCRIPT is a full functionality programming language it is possible to printjustified and unjustified strings of text in a variety of different ways. Section 3.3 shows six of them. "showing" One trend was shown. As more POSTSCRIPT instructions had to execute per each line of text, the time to execute these instructions increased causing the page performance to decrease. the start positions of each line of text The way to achieve the best performance is by calculating each within the in the front end composition computer and send this information down for line widthshow operators can be POSTSCRIPT page. For justification the ashow or used, intercharacter or interword spacing). depending on the effect that is desired (i.e. adjusting the better performance than the page In the experiments, the page using ashow yielded slighdy using widthshow. 125 Section 4 - Conclusions 4,6 ... Resolution Targeting ,. Manual it states that it: On page 76 of the POSTSCRIPT Language Reference that uses one bit per sample, and 1 . a sampled image is a binary image transformation matrix is such that one 2. the combination of the image matrix and the current unit in image space corresponds to one unit in device space, then pixel level and executes a great deal The produced results are precisely predicatable down to the faster than general imaging. not fonts. Section 3.4 tested to see if The above statement applies to scanned bitmap images, to of each line were specified in print a similar speedup could be observed if the starting positions active for a special engine coordinates. No effect could be seen. This speedup seems to be only case of bitmap images. 4.7 Printer Indiiced Delays Execution of POSTSCRIPT programs on the Apple LaserWriter Plus are influenced by several factors: "y" mark on the page. On the Apple 1 . the location of the lowest (smallest value) LaserWriter Plus, the page writes from top to bottom. All lines below the line which prints the lowest mark on the page is all white. It seems that the Apple LaserWriter Plus RIP keeps track of this information (sometimes called a "highwater mark"). When this point is reached the RIP can start to used the page buffer to generate the next page, while at "white" the same time providing a signal to the print engine to finish printing the current page. This phenomena is shown in section 3.5.1. 2. similar to #1 above, the printing of the current page holds up the generation of the next "ping-pong" page, since a page buffer is required to operate in. A dual page buffer can alleviate this problem at an added cost. 3. print engine control and communications interface control. Since the Apple LaserWriter Plus printer RIP has a single processor generating the page it must be shared to perform non-POSTSCRTPT functions, thereby slowing down the page generation task. Dedicated microcontrollers could be used to handle these ancilary tasks and help improve the overall performance. See section 3.5.2 for more on this topic. 126 Section 4 - Conclusions 5. Glossary batch composition - A program that executes on a front end system that accepts, as its input, a text file with markup commands (line width, type ofjustification, etc.), and outputs a page description file ready to be output on a printer. cache (also - memory bitmap font cache) memory (RAM) on the Apple LaserWriter Plus RIP that temporarily stores bitmap fonts. Outline fonts are scan converted and placed in cache memory. When a reference is made to print a character of a certain font that has been placed in previously the font cache the bitmap is quickly BitBLTed from the font cache to the page buffer. This process is much faster than scan converting the outline character. composition The process of integrating text, vector graphics, and bit-map images on pages in a form tiiat enhances the information being conveyed by the written prose. Typical features of a composed page are justified text using multiple fonts, charts that graphically show a trend, and screened photographs of items being described in the written portion of the page. CTM (Current Transformation Matrix) - A 3x3 matrix that describes how user coordinate space maps into device space. Changing variables in the CTM changes rotation, scaling, and translation. The matrix is shown below: Sx cos 3 Sx sin 9 0 - sin 9 Sy Sy cos d 0 Tx Ty 1 d is angle of rotation in a positive direction (counterclockwise) Sx is the scale factor in the x direction. Sy is the scale factor in the y direction. Tx is the translate number in the x direction. Ty is the translate number in the y direction device coordinate system - The cartesian coordinate system that describes the printable dots of a particular print engine (i.e. "device"). The units of the device coordinate system have a one to one correlation to die dots of the printer. For the Apple LaserWriter Plus printer the device resolution is 300 dots per inch. The Current Transformation Matrix, or CTM, maps the user space into device space. dot - see printable dot EPROM (Electrically Programmable Read Only Memory) - A type of ROM that is programmable using a computer controlled tool that provides sequenced electrical pulses to the EPROM. EPROMs are typically erasable by irradiating the EPROM chip with ultraviolet light for several minutes. Because they are erasable and (re)programmable, EPROMS are commonly reused during product development and for product code updates. font - A complete assortment of a given size of type, including capitals, small capitals, and lowercase, together with figures, punctruation marks, ligatures, and the commonly used signs and accents. The italic of a given face is considered a part of the equipment of a font of type but is spoken of as a separate font. 127 Section 5: Glossary .character*|in ^font^For and sizes of the font - A all the styules family group including characters m the limes contains all sizes of aU example Times is the font family that Bold Italic fonts. Roman, Times Italic, Times Bold, and Times wkhin atine intercharacter and/or mterword spacing, full justification - modification of the pomts. This is done to till in a of the hue at certain to position both the left and right ends complete rectangular space with solid text via other computers ^orkinterface, - typically front end A workstation with interfaces to and an interface to and scanned image input, a user interface to allow text, graphical, printers. strings of text into - of H & (Hyphenation aM Justification) The process breaking up J complex set width a specified font A substrings that fit well within a specified line using should occur between adjacent words used to determine whether a line break SSfSc two words. If a word is broken into or the line break should occur between up hyphen place place on consecutive lines with a sub-words, then the two sub-words are after the first sub-word. system that as its - on a front end accepts, interactive composition A program that executes the text and style that the user wants input, keystrokes and possibly mouse clicks defining image on the computer CRT screen and the page to look like, and displays a softcopy description file to be output on a printer. ultimately outputs a page ready Xerox Corporation. - invented Interpress A family of page description languages, by three language sets: Interpress has ..,..* v m 1. Commercial Set includes the specification of basic text files, similar functionality printers. to many line ... similar in 2. Publication Set specifies multiple bit-map font capability and graphics, functionality to imPress. 3. Professional Graphics Set is the high functionality PDL allowing arbitrarily similar in to rotated and scaled font, among other high end features. It is functionality PostScript. left justification - Placement of consecutive lines so that the left edge of each line starts at right" the the same x coordinate. This type ofjustification is also called "ragged since right edges do not line up, but appear to be "ragged". justification - The process of positioning strings of text to get a more legible effect. See left justification andfulljustification for more information. kerning - The process of altering the spacing between two adjacent characters such that one character engulfs (ie. gets closer to) the other. Kerning is an advanced method of ""VA" generating very high quality text Common kerning pairs are and "Ti". landscape - A page orientation where the horizontal dimension is greater than the vertical 8.5" 11" direction. On a typical x page the horizontal dimension is 1 1 inches with the "portrait" vertical dimension being 8.5 inches. See for comparison. "fit" ligature - A character combination that is made up of two or three characters that well with each other. These characters are graphically combined and are typographically "fi" "fl" considered a single character. Common ligatures are the and the character combinations. outline font rasterization - see scan conversion 128 Section 5: Glossary PDL POSTSCRIPT - A high functionality page description language, defined by Adobe Systems, Inc. that boasts full functionality. The language itself is stack oriented and "forth"-like, and has the ability to define callable procedures and looping constructs. It is used in the Apple Laser Writer Plus printer, the printer used throughout this thesis. It is similar in functionality to the Interpress Professional Graphics Set. print engine - A device that put black or color marks onto paper at a typical resolution of 300 to 400 dots per inch. Note that at 300 dots per inch, over 1 MByte of data is needed to "paint" a full 8.5 x 1 1 inch page at 1 bit/dot printable dot The smallest mark on a page that a print engine can render. Size of the printable dots, or pixels ("picture elements") are the unit measures of the "device coordinate system". printer - The combination of a RIP and a print engine. process (electrophotographic) - The process used in most copiers and many page printers in which the following steps take place to produce copied or printed pages: 1. an area ofelectrophotographic material is charged with a uniform static electrical charge; 2. light, provided by a flashed image, laser or LED, exposes the page area on this charged material; 3. charge dissipates in the areas that were exposed, creating the latent image; 4. toner particles are charged such that either they will be attracted to the area that was exposed or not exposed, depending on the polarity of the process. A mirrored image on toner is layed onto the page area. 5. paper is charged such that the toner image is attracted to it; 6. the toner transfers to the paper; 7 the toner is fused to the paper using heat and/or pressure. process color - The ability to produce a large number of different colors (thousands to millions) on a printed page to closely resemble a continuous tone color picture. See spot color for comparison. 129 Section 5: Glossary shade of - render an intermediate screen A method, called "halftone screening", is used to be either white or black. The gray, using a grouping of dots that can, individually, parameters that define a screen in POSTSCRIPT are: per inch in device 1. frequency, which specifies the number of halftone cells space; haltone screen is to be rotated 2. angle, which specifies the number of degrees that the with respect to the device coordinate system; order in which pixels 3. a procedure defining the spot function, which determines the within a halftone cell are whitened to produce the desired shade of gray. spot color - The ability to produce several (typically 2 to 4) different color to accentuate key words or graphics for effect. Seeprocess color for comparison. "rasterizing" converting" rasterization (alternatively, or "scan a font) - see scan conversion RIP (Raster Image Erocessor) - A computer that inputs a page description language file and generates a bit-map image to transfer to the print engine, usually in a raster form. ROM (Read Only Memory) - Computer memory that is written into only once, at the factor}', and read many times. The data that is stored in ROM is permanent and non-volatile. It is typically used to store program code and other static data structures (like resident fonts). scan conversion - The process of converting a geometric description of a shape and generating the bitmap that corresponds to that shape. Outline fonts and graphical objects are scan converted in RTPs that accept POSTSCRIPT. user coordinate system - A cartesian coordinate system, specifiable through POSTSCRIPT, defined by the units (per inch), the origin, and x and y incrementing directions. The default user coordinate system of POSTSCRIPT defines the units to be 1/72 of an inch (close to a "point"), the x incrementing direction to be "right", the y incrementing direction to be "up", and the origin to be the lower left hand comer of the page. - device coordinate system The units of the device coordinate system have a one to one correlation to the dots of the printer. For the Apple LaserWriter Plus printer the device resolution is 300 dots per inch. The Current Transformation Matrix, or CTM, maps the user space into device space. WYSIWYG (W.hat-Y.ou-ee-Is-W.hat-Y.ou-fiet) - The concept, in interactive composition systems, where the image that is viewed on the CRT screen is the same image that will be printed out on the printer. 130 Section 5: Glossary References (see section 7 for full bibliography entries) Interpress 1 . A Comparison of and POSTSCRIPT 2. page 109 Apple LaserWriter Reference for LaserWriter, LaserWriter Plus, LaserWriter IInt, and LaserWriter Untx 3. page 221 POSTSCRIPT Language Reference Manual 4. page 222 POSTSCRIPT Language Reference Manual 5. pp. 1 17, 1 1 8 POSTSCRIPT Language Reference Manual 6. page 140 POSTSCRIPT Language Reference Manual 7. page 229 POSTSCRIPT Language Reference Manual 8. page 156 POSTSCRIPT Language Reference Manual 9. page 150 POSTSCRIPT Language Reference Manual 10. page 216 POSTSCRIPT Language Reference Manual 1 1 . page 128 POSTSCRIPT Language Reference Manual 12. page 97 POSTSCRIPT Language Reference Manual 13. page 287 POSTSCRIPT Language Reference Manual 14. page 288 POSTSCRIPT Language Reference Manual 15. pp. 85 - 102 POSTSCRIPT Language Reference Manual 16. pp. 222-225 POSTSCRIPT Language Tutorial and Cookbook 17. page 41 Printers Buyers Guide and Handbook Test Reports 18. page 6 Apple LaserWriter Reference for LaserWriter, LaserWriter Plus, LaserWriter IInt, and LaserWriter Entx for LaserWriter 19. pp. 3, 17 Apple LaserWriter Reference LaserWriter, Plus, LaserWriter IInt, and LaserWriter Untx LaserWriter 20. page 17 Apple LaserWriter Reference for LaserWriter, Plus, LaserWriter UNT, and LaserWriter Untx 21. page 90 Laser Wars Reference for LaserWriter 22. page 1 8 Apple LaserWriter LaserWriter, Plus, LaserWriter IInt, and LaserWriter IIntx 23. pp. 87,92 Laser Wars of a Job 24. page 76 The Laser's Edge: Anatomy Printing Fonts User's Guide 25. page 20 Fluent Laser 131 Section 6: References 26. pp 287, 301 POSTSCRIPT Language Tutorial and Cookbook 27. page 7-5 MC68000- 16-/32-Bit Microprocessor 28. page 122 Apple LaserWriter Reference for LaserWriter, LaserWriter Plus, LaserWriter UNT, and LaserWriter Untx - Macintosh 29. pp. 1 230 235 Inside Volumes I, H, and DT 30. pp. IV 33 - 48 Inside Macintosh Volume IV 132 Section 6: References 7. Bibliography Adobe Type Library User's Manual for the Macintosh Version 2.0 - October, 1987 Copyright 1987 Adobe Systems Incorporated Apple LaserWriter Reference Apple Programmer's and Developer's Association (APDA) APDA #: KNBLRM 290 SW 43rd Street Renton, WA. 98055 Tel. No. (206)251-6548 Apple LaserWriter Reference for LaserWriter, LaserWriter Plus, LaserWriter IInt, and LaserWriter Untx Apple Computer, Inc. Addison-Wesley Publishing Company, Inc. Copyright 1988 by Apple Computer, Inc. The Chicago Manual of Style Thirteenth Edition, Revised and Expanded The University of Chicago Press Copyright 1982 Interpress A Comparison of and POSTSCRIPT Jerry Mendelson April, 1985 Xerox Corporation Font and Function - The Adobe Type Catalog Spring / 1988 Adobe Systems Incorporated 1988 Fluent Laser Fonts User's Guide Robin Casady and Richard Ware CasadyWare Inc. Copyright 1987 Information Processing - Text and Office Systems Standard Generalized Markup Language ISO /DIS8879 Inside Macintosh Volumes I, n, and m Addison-Wesley Publishing Company, Inc. Copyright 1985 by Apple Computer, Inc. Sixth Printing, September 1987 Inside Macintosh Volume IV Inc. Addison-Wesley Publishing Company, Inc. Copyright 1986 by Apple Computer, Third Printing, April 1987 Job The Laser's Edge: Anatomy of a Printing Goodman Danny Macintosh MACWORLD The Magazine February, 1985 - Article: The Laser's Edge - pp. 70 79 Anatomy of a Printing Job - pp.76 133 Section 7: Bibliography Laser Wars Henry Bortman Macintosh MacUser - The Resource (magazine) October, 1987 Article: Laser Wars - pp. 84 - 94 MC68000- 16-/32-Bit Microprocessor Advance Information March, 1985 Motorola Publication Number ADI814R5 Page Description Languages Robert A. Morris Interleaf, Inc. and the University of Massachessetts at Boston Copyright 1985, Boole Press, Dublin Proceedings of the ProText n Conference, Boole Press, 1985 Pocket Pal - a graphics arts production handbook International Paper Company Thirteenth Edition Copyright May 1983 POSTSCRIPT Language Program Design (aka - the Green Book) Adobe Systems Incorporated Addison-Wesley Publishing Company, Inc. Glenn C. Reid Copyright 1988 POSTSCRIPT Language Tutorial and Cookbook (aka - the Blue Book) Adobe Systems Incorporated Addison-Wesley Publishing Company, Inc. Copyright 1985 POSTSCRIPT Language Reference Manual (aka - the Red Book) Adobe Systems Incorporated Addison-Wesley Publishing Company, Inc. Copyright 1985 Postscript: Master of the Raster Ted Nace PC World August, 1985 pages 256-262 Printers Buyers Guide and Handbook Test Reports Printers Buyers Guide and Handbook Guide #7 Copyright 1987 Article: Apple Laser-Writer Plus - page 41 Supporting Downloadable POSTSCRIPT Fonts Glenn Reid Adobe Systems Incorporated August 14, 1987 134 Section 7: Bibliography aaoHni __ JBSS8SB8g IWiTfflnrVWffl Basaaa Sun Microsystem Macintosh Display Terminal Apple Personal Computer (Mac transfer H) RS-232 Sun Video Microsystems 3/280 Appletalk RS-232 ^4888888888888^ Apple HP 4953A Protocol Analyzer X LaserWriter Plus PostScript Evaluation Equipment Configuration Appendix 1 Appendix 1 : PostScript Evaluation Equipment Configuration 2.1 POSTSCRIPT Font Widths 2.1.1 POSTSCRIPT source code for the extraction of printer- resident font widths from the Apple Laser Writer Plus 2.1.2 Printed output on an Apple Laser Writer Plus printer when sent the font extraction program of 2.1.1 above. 2.1.3 Hand created (and edited) file containing a portion of the information shown on 2.1.2 (specifically, the font widths for a 10 point Time-Roman typeface). This is one of seven font width files used by the justification program described in 2.2.1. POSTSCRIPT 2.2 Generation of Text pages 2.2. 1 Pseudo-code for the C-language program that performs line-breaking, justification, and generation ofjustified line of text using POSTSCRIPT in a variety of different ways. 2.2.2 Sample input to justification program of 2.2. 1 above. Input contains paragraphs of information meant to be printed, but no formatting information is included here. Format is "Content" similar to a file of SGML. 2.2.3 Sample input to justification program of 2.2.1 above. Input contains the formatting information that applies to the printable data of 2.2.2. Format is similar (in concept) to a "Style" file of SGML. 2.2.4 Sample output POSTSCRIPT file generated by the justification program of 2.2.1 using the input files shown in 2.2.2 and 2.2.3. 2.2.5 (One) page printed on the Laser Writer Plus printer using the POSTSCRIPT file of 2.2.4. Also, included is the timing page that is ejected after a series of pages is printed. Note: The pages that are shown in 2.2.2 through 2.2.5 are used to generate timing data recorded in section 33 using justification method # 1 . Appendix 2: Support Programs Appendix 2: Support Programs % Written for the Masters Thesis at RIT; Thomas L. Kowalczyk % Performance Analysis of Text Oriented Printing Using PostScript % % This procedure interrogates the Apple Laser Writer Plus for the font widths % of three of its printer resident fonts. The font widths of the normal ASCII % printable characters are extracted, and font width tables for three font % faces are printed. A 10 point font was assumed for all three fonts. % Default units of POSTSCRIPT is the point, which is 1/72 of an inch. The "inch" % procedure allows the program to specify coordinates in inches instead. /inch {72 mul} def % The top of the font width columns is this distance from the bottom of the % page. Note that in POSTSCRIPT the origin is at the lower left corner of the % page with x in increasing value to the right and y increasing in value up, % like a normal Cartesian coordinate system. o t; /ytop 9.25 inch def % Set two up strings of characters corresponding to the two columns of font % width tables. % /stl ( !"#$%&'(>*+,-./012345 6789:; <=>?@ABCDEFGHIJKLMNOP ) def (QRSTUVWXYZ[\\]A_* /st2 |~abcdefghijklmnopqrstuvwxyz{ | }~ ) def % Set variables and up position cursor before each column is printed % /reset__to_top { /n 0 def % character index into string ytop def % set /y y cursor value to top of column position x moveto y % position POSTSCRIPT cursor on page } def % Put title on the top of the page % /page_header { /Times-Roman findfont 24 scalefont setfont 2 . 5 inch ytop . 5 inch add moveto (Font Extraction Program) show } def Appendix 2.1.1 Font Extraction Program pagel of 3 Appendix 2.1.1: Support Programs % each individual character Selecting from the string passed to this procedure, % request its character width. Then, starting at the existing (x,y) cursor % place each position, (character, width) pair at locations successively below % one another (i.e. print a column) . /print_col { /st exch def % pass string of characters to procedure 1 1 49 % loop from the first number to the last % number in increments of the second number { st n 1 getinterval % get the n'th character of the string "s" dup /s exch def % save it in the variable show % print it at the current (x,y) position x .2 inch add y % position cursor to print width to the right moveto % of the character s string-width % get the width of the individual character pop % x width and y height are returned, so get % rid of the height, since it is of no interest 100 mul round % round the font width to the nearest 1/100 of "round" cvr 100 div % a point; note that the operator yields "cvr" % an integer and converts it back to real ( ) cvs % convert the number which represent the % character width to a printable string of % characters show % and print it . /y y 12 sub def % set up y to go down to the next line x y moveto % position the cursor for next pair /n n 1 add def % increment index to reference next character ) for } def % Print two columns of font width tables , /print_2_col { position cursor reset_to_top % set up variables and column of stl print_col % generate and print first % (char, width) pairs % set second columm to be to the right of /x x . 8 inch add def up % the first one just printed % set variables and position cursor reset_to_top up and print second column of st2 print_col % generate % (char, width) pairs } def Appendix 2.1.1 Font Extraction Program page2 of 3 Appendix 2.1.1: Support Programs % Code starts to execute here. All of the above are procedures are referenced % by the calls below. % Print title on the page. page_header % Select fonts, position the x cursor position, print a column title, and print % the (char, width) pairs for three font faces. o /Times -Roman findfont 10 scalefont setfont % select the font /x 1 inch def % set up x position for first set of columns x ytop 15 add moveto % position (10 point Times Roman) show % and print title print_2_col % extract and print table /Times-Italic findfont 10 scalefont setfont % select the font /x 3.25 inch def % set up x position for second set of columns x ytop 15 add moveto % position (10 point Times Italic) show % and print title print_2_col % extract and print table /Times-Bold findfont 10 scalefont setfont % select the font /x 5.5 inch def % set up x position for last set of columns x ytop 15 add moveto % position (10 point Times Bold) show % and print title print_2_col % extract and print table showpage % print and eject the page Appendix 2.1.1 Font Extraction Program page3 of 3 Appendix 2.1.1: Support Programs Following Page is the Aeteal 0Btpnrt from the Apple Laser Writer PMs Printer Appendix 2.1.2 Printed Font Width Tables from Laser Writer Plus single printed page to follow Appendix 2.1.2 : Support Programs Font Extraction Program point Times Italic 10 point Times Bold 10 point Times Roman 10 2.5 7.78 2 5 Q 7 22 25 Q 7.22 Q 333 R 7.22 i 333 R 667 333 R 6.11 ! " " 5.55 S 5.56 "4 08 S 5.56 42 S 5.0 5.0 T 6.67 #50 T 611 #5.0 T 556 # U 7.22 $ 50 U 7.22 $ 5.0 U 722 $ 5.0 V 7.22 % 8 33 V 7.22 % 833 V 6.11 % 10.0 10.0 & 7.78 W 9.44 & 7.78 W 833 & 8.33 W ' ' ' 7.22 3.33 X 7.22 333 X 6.11 3.33 X Y 7.22 ( 3.33 Y 7.22 ( 333 Y 556 ( 3.33 6.67 ) 3 33 Z 6.11 J 333 Z 556 ) 3.33 Z * * 5.0 [ 3.33 * 5.0 [ 3.89 5.0 [ 3.33 + 5.64 \ 2.78 + 6.75 \ 2.78 + 5.7 \ 2.78 333 , 25 3.89 , 23 ] , 2.5 ] 3.33 ] A A - A - - 3.33 4.69 333 422 3.33 5.81 . 5.0 . 5.0 2.5 . 5.0 25 _ 2.5 _ _ ' ' ' / 2.78 3.33 / 2.78 333 I 2.78 333 0 5.0 I 2.0 0 5.0 j 2.75 0 5.0 | 2.2 ~ 1 5.0 - 5.41 1 5.0 ~ 5.41 1 5.0 5.2 2 5.0 a 4.44 2 5.0 a 5.0 2 5.0 a 5.0 3 5.0 b 5.0 3 5.0 b 5.0 3 5.0 b 5.56 4 5.0 c 4.44 4 5.0 c 4.44 4 5.0 c 4.44 5 5.0 d 5.0 5 5.0 d 5.0 5 5.0 d 536 6 5.0 e 4.44 6 5.0 e 4.44 6 5.0 e 4.44 7 5.0 f 3.33 7 5.0 f 2.78 7 5.0 f 333 8 5.0 g 5.0 8 5.0 g 5.0 8 5.0 g 5.0 9 5.0 h 5.0 9 5.0 h 5.0 9 5.0 h 536 : 2.78 i 2.78 ; 333 i 2.78 : 333 i 2.78 ; 2.78 j 2.78 ; 333 j 2.78 ; 333 j 333 < 5.64 k 5.0 < 6.75 k 4.44 < 5.7 k 536 = 5.64 1 2.78 = 6.75 I 2.78 - 5.7 1 2.78 > 5.64 m 7.78 > 6.75 m 722 > 5.7 m 833 ? 4.44 n 5.0 ? 5.0 n 5.0 ? 5.0 n 536 @ 9.21 o 5.0 @ 92 o 5.0 @ 93 o 5.0 A 7.22 p 5.0 A 6.11 p 5.0 A 7.22 p 536 B 6.67 q 5.0 B 6.11 q 5.0 B 6.67 q 536 C 6.67 r 3.33 C 6.67 r 3.89 C 7.22 r 4.44 D 7.22 s 3.89 D 722 s 3.89 D 722 s 3.89 E 6.11 t 2.78 E 6.11 t 2.78 E 6.67 t 333 F 5.56 u 5.0 F 6.11 u 5.0 F 6.11 u 536 G 7.22 v 5.0 G 722 v 4.44 G 7.78 v 5.0 H 7.22 w 7.22 H 722 w 6.67 H 7.78 w 722 I 3.33 x 5.0 / 333 x 4.44 I 3.89 x 5.0 J 3.89 y 5.0 / 4.44 y 4.44 J 5.0 y 5.0 K 7.22 z 4.44 K 6.67 z 3.89 K 7.78 z 4.44 L 6.11 { 4.8 L 556 { 4.0 L 6.67 { 3.94 M 8.89 I 2.0 M 8.33 / 2.75 M 9.44 | 22 N 7.22 } 4.8 N 6.67 } 4.0 N 722 } 3.94 O 7.22 -5.41 O 722 ~ 5.41 O 7.78 - S2 P 5.56 2.5 P 6.11 25 P 6.11 23 s 2 .5 j 3 .33 II 4 .08 # 5 .0 $ 5 .0 % 8 .33 7 .78 1 3 .33 ( 3 .33 ) 3 .33 * 5 .0 + 5 .64 r 2 .5 - 3 .33 , 2 .5 / 2 .78 0 5 .0 1 5 .0 2 5 .0 3 5 .0 4 5 .0 5 5 .0 6 5 .0 7 5 .0 8 5 .0 9 5 .0 : 2 .78 r 2 .78 < 5 .64 = 5 .64 > 5 .64 7 4 .44 e 9 .21 A 7 .22 B 6 .67 C 6 .67 D 7. 22 E 6.,11 F 5. 56 G 7. 22 H 7. 22 I 3. 33 J 3. 89 K 7. 22 L 6. 11 M 8. 89 N 7. 22 0 7. 22 P 5. 56 Q 7. 22 R 6. 67 S 5. 56 Appendix 2.1.3 Times-Roman Font Width Table pagel of 2 Appendix 2.1.3: Support Programs T 6. 11 U 7. 22 V 7. 22 W 9. 44 X 7. 22 y 7. 22 z 6. 11 [ 3. 33 \ 2. 78 ] 3. 33 A 4. 69 5. 0 - 3. 33 a 4. 44 b 5. 0 c 4. 44 d 5..0 e 4..44 f 3. 33 g 5 ,0 h 5..0 i 2 .78 j 2 .78 k 5 .0 1 2 .78 m 7 .78 n 5 .0 o 5 .0 P 5 .0 q 5 .0 r 3 .33 s 3 .89 t 2 .78 u 5 .0 V 5 .0 w 7 .22 X 5 .0 y 5 .0 z 4 .44 { 4 .8 t 2 .0 > 4 .8 - 5 .41 Appendix 2.1.3 Times-Roman Font Width Table page2 of 2 Appendix 2.1.3: Support Programs Batch_composition mam program Leading = 1 factor times font size for vertical spacing Initialize default global static composition state Statlc_llne_wldth = 7 Inches variables; these variables are also set as specified in Justification_method = ragged right thefilename.structure file Font = Times Roman Font_size = 10 point X_cursor = 1 1nch Y_cursor = 10 Inches { Input filename from command line filename.postscript postscript header file for fonts 1 through 7 load font widths from font width files Initialize dynamic composition state variables Word_char_cnt = 0 current # ofcharacters in word Llne_char_cnt = 0 current # of characters in line (including spaces) Old_line_width = 0 before current word width is added Newjlne_wldth = 0 after space width and current word width is added Space_cnt = 0 # spaces before current word lnside_word_flag = FALSE Loop to get next character until done { Get next character "normal" if Character Is i.e. not a "<", space, or carriage return then { for next time through lnside_word_flag = TRUE set flag loop Current_word = Current_word + Character } "normal" character is not delimiter has been detected else a If lnslde_word_flag = FALSE then { If Character Is a space or carriage return then space or carriage return increment Space_cnt more than one "<" it's a else look at structure file if Call Get_command interpret command; necessary } Pseudo-code Appendix 2.2.1 Batch Composition pagel of 3 Appendix 2.2.1 : Support Programs was inside a word else first delimiter after a word { lnside_word_flag = FALSE + New_llne_width - Old_line_wldth Old_space_cnt * width of space + the Line + Word fit on the line? width of Current_word Does add word to line If New_llne_wldth < Statlc_l!ne_wldth it fits, so then { Line = Line + Spaces + Current_word Llne_char_cnt = Llne_char_cnt + Space_cnt + Word_char_cnt Total_space_cnt = Total_space_cnt + Space_cnt word Word_char_cnt = 0 get ready for next Old_iine_wldth = New_line_wldth Space_cnt = 1 "<" If Character = end ofparagraph marker then { Print (Line) Print unjustified line Reset ail dynamic comp variables paragraph" Cali Get_command get rid of 7p>", and "beginning of marker "structure" if it exists along with info, for new par. } else Space_cnt = 1 space and CR both count as a space fits" } end of "it else { it doesn't fit, Justified_print (Line) so printjustified line "<" if Character = end ofparagraph marker then { Print (Word) Print unjustified line consisting of one word Reset all dynamic comp variables paragraph" Call Get_Command get rid of 7p>", and "beginning of marker "structure" } if it exists along with info, for new par. else { Line = Word Start building new line with the word that didn't fit Space_cnt = 0 Reset all dynamic comp variables } fit" end of "it doesn't line" } end of "first delimiter after character" } end of loop "get next PrinMrailer "cat" the trailer postscript file that sets up timing ) tests to the filename.postscript file Appendix 2.2.1 Batch Composition Pseudo-code page2 of 3 Appendix 2.2.1 : Support Programs Get_COmmand procedure to detect beginning and end ofparagraphs and setting of the global static composition variables from the "structure" file I Get next character from filename.data if Character = V then read next three characters from fllname.data get rid of the "p", ">", and carriage return of the end-of-paragraph command to get the input file to the position for reading more data else *p' If Character = get rid of the ">", and carriage return of the { beginning-of-paragraph command to get the input file read next two characters from fllename.data to the position for reading more data Get next character from filename.structure Loop until Character = V reset the global static composition parameters when a beginning-of-paragraph marker is detected { Get command Character from filename.structure "structure" all sttructure cmnds are read from the file 'J' if Character = Justification_method = Integer from fllename.structure Iff Leading = real number from fllename.structure If'F' { Font = Integer from 1 to 7 from fllename.structure Font_size = real number from fllename.structure filename.postscript postscript font setup Instructions } we { X_cursor = real number (in points) from fllename.structure Y_cursor = real number (In points) from fllename.structure filename.postscript postscript cursor positioning instructions } WW filename.structure Static_line_wldth = real number (In Inches) from done" end of "loop until 'p' " \ end of "character is a end of Get_commmand routine Appendix 2.2.1 Batch Composition Pseudo-code page3 of 3 Appendix 2.2.1 : Support Programs , n EKTAPRINT IMAGE LOOP is a continuous loop A IMAGE LOOP. The KODAK and is of electrically charged, of film that is capable being The IMAGE LOOP is driven around the sensitive to direct light. exposures motion for as as copy IMAGE LOOP CORE in a continuous long Figure . are being made (see 1) of the PRIMARY CHARGER is to place B. PRIMARY CHARGER. The function IMAGE LOOP- This prepares the IMAGE LOOP a negative charge on the IMAGE LOOP starts moving on for exposure and development. The AND CONTROL then turns on command from LOGIC AND CONTROL. LOGIC the PRIMARY CHARGER. around the CORE to C. EXPOSURE. The charged IMAGE LOOP continues reflected light the EXPOSURE area, where it is exposed to a copy image that is focused on the IMAGE LOOP at precisely the right time, The original document is as determined by LOGIC AND CONTROL. illuminated by high intensity flash lamps for a short duration, exposed on the which prevents blurring of the image as it is moving IMAGE LOOP removed from the areas IMAGE LOOP . The charge on the is are that are exposed to light. The charge remains in the areas that charge not exposed. The exposure is said to discretely alter the characteristics of the IMAGE LOOP so that the focused copy image is known as an recorded en the IMAGE LOOP . This IMAGE LOOP image is electrostatic image. D. AUXILIARY ERASE. Just before each first, and just after each last, exposure area is an improperly charged segment. These segments are produced when the PRIMARY CHARGER is turned on at the time of initial IMAGE LOOP movement and turned off during final IMAGE LOOP movement. As the unwanted areas pass under the AUXILIARY ERASE LAMP, it floods the moving IMAGE LOOP base with light that desensitizes the IMAGE LOOP to prevent unwanted development . E. DEVELOPER STATION ASSEMBLY. The properly charged and exposed IMAGE LOOP area now enters the DEVELOPER STATION ASSEMBLY where positively charged KODAK EKTAPRINT K Toner particles are attracted to the IMAGE LOOP. Development occurs as the result of attraction of the toner particles to the electrostatic image on the IMAGE LOOP . The toner particles are carried away on the IMAGE LOOP surface for later transfer to a copy paper. F. SCAVENGER ROLLER. Any developer carrier granules (iron) left on the IMAGE LOOP are salvaged at this point by the SCAVENGER ROLLER and returned to the DEVELOPER STATION ASSEMBLY.
"Content" Appendix 2.2.2 Input Data File (All paragraphs) pagel of 2
Appendix 2.2.2 : Support Programs
G. POST-DEVELOPMENT ERASE LAMP. To reduce the electrostatic stress on the IMAGE LOOP and thereby increases its life, the POST DEVELOPMENT ERASE LAMP is used to lower the high level charge that was required for proper image development. This POST-DEVELOPMENT
ERASE process also helps to prevent residual image retention.
H. REGISTRATION. While the developed electrostatic image moves
around the CORE, a sheet of copy paper is advanced to the
REGISTRATION ASSEMBLY (not shown in Figure 1) . At precisely the right time, the copy paper is directed into contact with the IMAGE LOOP and its developed image. This aligns the copy paper and the
image on the IMAGE LOOP .
I. TRANSFER CHARGER. The IMAGE LOOP and copy paper now pass under the TRANSFER CHARGER, which produces a negative charge on the paper
surface to attract the positive charged developer toner. This
effectively transfers the copy image to the paper.
"Content" File (All paragraphs) Appendix 2.2.2 Input Data page2 of 2
Programs Appendix 2.2.2: Support 0>
Appendix 2.2.3 Input Markup "Structure" File pagel of 1
Appendix 2.2.3 : Support Programs /Tsd usertime def /Page { /Times-Roman findfont 9.0 scalefont setfont 72.00 709.20 moveto (A. IMAGE LOOP. The KODAK EKTAPRINT IMAGE LOOP is a continuous loop of film that is capable of being electrically)show 72.00 698.40 moveto
(charged, and is sensitive to direct light. The IMAGE LOOP is driven around the IMAGE LOOP CORE in a continuous motion)show 72.00 687.60 moveto (for as long as copy exposures are being made \(see Rgure 1\). )show
/Times-Roman findfont 1 1 .0 scalefont setfont 72.00 663.60 moveto
(B. PRIMARY CHARGER. The function of the PRIMARY CHARGER is to place a negative charge on)show 72.00 650.40 moveto (the IMAGE LOOP. This prepares the IMAGE LOOP for exposure and development. The IMAGE)show 72.00 637.20 moveto (LOOP starts moving on command from LOGIC AND CONTROL. LOGIC AND CONTROL then turns)show 72.00 624.00 moveto (on the PRIMARY CHARGER. )show /Times-Roman findfont 13.0 scalefont setfont 72.00 595.20 moveto (0 EXPOSURE. The charged IMAGE LOOP continues around the CORE to the)show 72.00 579.60 moveto (EXPOSURE area, where it is exposed to a reflected light copy image that is focused on)show 72.00 564.00 moveto (the IMAGE LOOP at precisely the right time, as determined by LOGIC AND)show 72.00 548.40 mcveto (CONTROL The original document is illuminated by high intensity flash lamps for a)show 72.00 532.80 moveto (short duration, which prevents blurring of the image as it is exposed on the moving)show 72.00 517.20 moveto (IMAGE LOOP. The charge on the IMAGE LOOP is removed from the areas that are)show 72.00 501.60 moveto (exposed to light. The charge remains in the areas that are not exposed. The exposure is)show 72.00 4S6.00 moveto (said to discretely alter the charge characteristics of the IMAGE LOOP so that the focused)show 72.00 470.40 moveto (copy image is recorded on the IMAGE LOOP This IMAGE LOOP image is known as)show 72.00 454.80 moveto (an electrostatic image. )show /Times-Italic findfont 9.0 scalefont setfont 72.00 428.40 moveto (D. AUXILIARY ERASE. Just before each first, and just after each last, exposure area is an improperly charged segment. These)show 72.00 417.60 moveto movement and (segments are produced when the PRIMARY CHARGER is turned on at the time of initial IMAGE LOOP turned off)show 72.00 406.80 moveto AUXILIARY ERASE it floods the (during final IMAGE LOOP movement. As the unwanted areas pass under the LAMP, moving)show 72.00 396.00 moveto , development._, , )show (IMAGE LOOP base with light that desensitizes the IMAGE LOOP to prevent unwanted setfont /Times-Italic findfont 1 1 .0 scalefont 72.00 372.00 moveto _.....,-, IMAGE LOOP area now)show (E. DEVELOPER STATION ASSEMBLY. The properly charged and exposed
KODAK EKTAPRINT K Toner)show (enters the DEVELOPER STATION ASSEMBLY where positively charged moveto 72.00 345.60 , , _ . , 4U . u as the result of attraction of the toner)show (particles are attracted to the IMAGE LOOP. Development occurs
72.00 332.40 moveto
Appendix 2.2.4 Text POSTSCRIPT File page 1 of 6
Appendix 2.2.4 : Support Programs are carried on the)show (particles to the electrostatic image on the IMAGE LOOP. The toner particles away 72.00 319.20 moveto (IMAGE LOOP surface for later transfer to a copy paper. )show /Times-Italic findfont 13.0 scalefont setfont 72.00 290.40 moveto IMAGE)show (F. SCAVENGER ROLLER. Any developer carrier granules \(iron\) left on the 72.00 274.80 moveto (LOOP are salvaged at this point by the SCAVENGER ROLLER and returned to the) show 72.00 259.20 moveto (DEVELOPER STATION ASSEMBLY. )Show /Times-Bold findfont 9.0 scalefont setfont
.. 232.80 moveto __ _ . 72.00 , LOOP andjshow (G. POST-DEVELOPMENT ERASE LAMP. To reduce the electrostatic stress on the IMAGE 72.00 222.00 moveto level charge)show (thereby increases its life, the POST DEVELOPMENT ERASE LAMP is used to lower the high 72.00 21 1.20 moveto process also helps to)show (that was required for proper image development This POST-DEVELOPMENT ERASE 72.00 200.40 moveto (prevent residua! image retention. )show
/Times-Bold findfont 1 1 .0 scalefont setfont 72.00 176.40 moveto (H. REGISTRATION. While the developed electrostatic image moves around the CORE, a)show 72.00 163.20 moveto (sheet of copy paper is advanced to the REGISTRATION ASSEMBLY \(not shown in)show 72.00 150.0u'moveto (Figure 1\). At precisely the right time, the copy paper is directed into contact with the)show 72.00 136.80 moveto (IMAGE LOOP and its developed image. This aligns the copy paper and the image on)show 72.00 123.60 moveto (the IMAGE LOOP. )show /Times-Bold findfont 13.0 scalefont setfont 72.00 94.80 moveto (I. TRANSFER CHARGER. The IMAGE LOOP and copy paper now pass)show 72.00 79.20 moveto (under the TRANSFER CHARGER, which produces a negative charge on)show 72.00 63.60 moveto (the paper surface to attract the positive charged developer toner. This)show 72.00 48.00 moveto (effectively transfers the copy image to the paper. )show
usertime /TO exch def % record time before showpage showpage % operator is executed }def
usertime /Ted exch def % record time at end of file download Ted Tsd sub /Tdl exch def % calculate download time
% * % Procedures to time the printing of pages and generate and time the delay between pages. * % ,
/sec % one second delay under no load { % keep track of time actually taken usertime /T exch def { 1228 {373.737 737.373 mul pop) repeat } repeat usertime T sub def) def
Appendix 2.2.4 Text POSTSCRIPT File
page 2 of 6
Appendix 2.2.4 : Support Programs % Print one page and keep time { usertime IT exch def Page usertime T sub def }def
% Calling sequences for the print (and time) pages % and the delay (again with timing) % .
/Print_Pages { /T1 usertime def Page
usertime T1 sub /T1 B exch def % calculate time that the first page % took to execute
TO T1 sub /T1 A exch def % calculate time that the first page "showpage" % took to execute, less the
/T2Pr % T2 gets time to print second page
W1 1 sec % W1 gets actual delay time (1 second under no load)
/T3Pr % T3 gets time to print third page
/W2 2sec % W2 gets actual delay time (2 seconds under no load)
/T4Pr % T4 gets time to print fourth page
/W3 3 sec % W3 gets actual delay time (3 seconds under no load)
/T5Pr % T5 gets time to print fifth page
/W5 5sec % W5 gets actual delay time (5 seconds under no load)
/T6Pr % T6 gets time to print sixth page
/W8 8sec % W8 gets actual delay time (8 seconds under no load)
/T7Pr % T7 gets time to print seventh page
/W1212sec % W12 gets actual delay time (1 2 seconds under no load)
/T8Pr % T8 gets time to print eighth page
/W16 16 sec % W16 gets actual delay time (16 seconds under no load)
/T9Pr % T9 gets time to print ninth page
Jdef
Appendix 2.2.4 Text POSTSCRIPT File page 3 of 6
Appendix 2.2.4 : Support Programs % Routines to draw a simple graph relating delay time between pages % on the x axis) to the time to print the page (on the y axis) %- /Draw_Graph { /Times-Roman findfont 12 scalefont setfont /x 160 def /y 280 def
/GraphXlnit125def /GraphYlnit 350 def /GraphUnit 0.02 def % 20 points per second
GraphXInit GraphYlnit 400 add moveto % draw the graph axes 0 400 neg rlineto 400 0 rlineto stroke
/GX GraphXInit 16 sub def /GY GraphYlnit 4 sub def
GX GY moveto (0) show % put numbers in GX GY 1 00 add moveto (5) show % on y axis -20 0 rmoveto gsave 90 rotate (Page Generation Time [in seconds]) show grestore GX GY 200 add moveto (1 0) show GX GY 300 add moveto (15) show GX GY 400 add moveto (20) show
/GX GraphXInit 7 sub def /GY GraphYlnit 12 sub def
GXGY 10 sub moveto GX 1 00 add GY moveto (5) show % on x axis 0-15 rmoveto (Wait Time After Previous Page [in seconds]) show GX 200 add GY moveto (1 0) show GX 300 add GY moveto (15) show GX 400 add GY moveto (20) show
GraphXInit GraphYlnit moveto % put tick marks in
100 -3.5 rmoveto 0 7 rlineto % x axis, 5 100 0 rmoveto 0 -7 rlineto %x axis, 10 100 0 rmoveto 0 7 rlineto % x axis, 1 5 100 0 rmoveto 0 -7 rlineto stroke % x axis, 20
GraphXInit GraphYlnit moveto % put tick marks in
-3.5 100 rmoveto 7 0 rlineto % y axis, 5 0 100 rmoveto -7 0 rlineto %y axis, 10 0100 rmoveto 7 0 rlineto %y axis, 15 0 100 rmoveto -70 rlineto stroke % y axis, 20 } def
Appendix 2.2.4 Text POSTSCRIPT File
page 4 of 6
Appendix 2.2.4 : Support Programs % procedure to draw a point on the graph { /yy exch def 3 add yy moveto -3 3 rlineto
-3 -3 rlineto
3 -3 rlineto 3 3 rlineto stroke )def
/ShowPageTime % procedure to display time to generate page { x 200 add y moveto (Page Time ) show show x 290 add y moveto (= )show dup /Ty exch def ( ) cvs show }def
/ShowWaitTime % procedure to display actual delay time { d (Wait Time ) show show ( sec) show x 90 add y moveto (= )show dup /Wx exch def ( ) cvs show }def
/Graphlt % procedure to graph a (Delay.Page) time pt. { Wx GraphUnit mul GraphXInit add Ty GraphUnit mul GraphYlnit add Diamond }def
Appendix 2.2.4 Text POSTSCRIPT File page 5 of 6
Appendix 2.2.4 : Support Programs * % % Calls to the above routines to print the timing data.
7o /ReportJTimes { Draw_Graph xy moveto (Download Time) show x 100 add y moveto (= )show Tdl ( ) cvs show
/d {x y 1 5 sub dup /y exch def moveto) def
dTlA(1\(A\))ShowPageTime
dT1B(l\(B\))ShowPageTime
0 (0) ShowWaitTime T2 (2) ShowPageTime Graphlt
W1 (1) ShowWaitTime T3 (3) ShowPageTime Graphlt
W2 (2) ShowWaitTime T4 (4) ShowPageTime Graphlt
W3 (3) ShowWaitTime T5 (5) ShowPageTime Graphlt
W5 (5) ShowWaitTime T6 (6) ShowPageTime Graphlt
W8 (8) ShowWaitTime T7 (7) ShowPageTime Graphlt
W12 (12) ShowWaitTime T8 (8) ShowPageTime Graphlt
W16 (16) ShowWaitTime T9 (9) ShowPageTime Graphlt
d x 200 add y moveto (Ave Pg Time 2-9) show x 290 add y moveto (= )show T2 T3 add T4 add T5 add T6 add T7 add T8 add T9 add 8 div ( ) cvs show
/Times-Italic findfont 12 scalefont setfont d d (Note: All times are specified in milliseconds.) show
} def
Print_Pages
Report_Times
showpage
Appendix 2.2.4 Text POSTSCRIPT File
page 6 of 6
Appendix 2.2.4 : Support Programs Following Pages
are the
Aetoal 0etpBt
from the
Apple Laser Writer Pins
Printer
Appendix 2.2.5: Printed Text & Timing Pages from Laser Writer Plus two printed pages to follow
Appendix 2.2.5 : Support Programs : Generation ofPostScript Text Pages Printed Text and Timing Pages from the Apple Laser Writer Plus capable of A. IMAGE LOOP. The KODAK EKTAPRINT IMAGE LOOP is a continuous loop of film that is being electrically IMAGE LOOP CORE in a continuous motion charged, and is sensitive to direct light The IMAGE LOOP is driven around the for as long as copy exposures are being made (see Figure 1).
charge on B. PRIMARY CHARGER. The function ofthe PRIMARY CHARGER is to place a negative IMAGE the IMAGE LOOP. This prepares the IMAGE LOOP for exposure and development The AND CONTROL then turns LOOP starts moving on command from LOGIC AND CONTROL. LOGIC on the PRIMARY CHARGER.
C. EXPOSURE. The charged IMAGE LOOP continues around the CORE to the EXPOSURE area, where it is exposed to a reflected light copy image that is focused on AND the IMAGE LOOP at precisely the right time, as determined by LOGIC CONTROL. The original document is illuminated by high intensity flash lamps for a short duration, which prevents blurring of the image as it is exposed on the moving IMAGE LOOP. The charge on the IMAGE LOOP is removed from the areas that are exposed to light. The charge remains in the areas that are not exposed. The exposure is said to discretely alter the charge characteristics of the IMAGE LOOP so that the focused copy image is recorded on the IMAGE LOOP. This IMAGE LOOP image is known as an electrostatic image.
D. AUXILIARY ERASE. Just before eachfirst, andjust after each last, exposure area is an improperly charged segment. These segments are produced when the PRIMARY CHARGER is turned on at the time ofinitial IMAGE LOOP movement and turned off duringfinal IMAGELOOP movement. As the unwanted areaspass under the AUXILIARY ERASE LAMP, itfloods the moving IMAGE LOOP base with light that desensitizes the IMAGE LOOP toprevent unwanted development.
E. DEVELOPER STATION ASSEMBLY. The properly charged and exposed IMAGE LOOP area now enters the DEVELOPER STATIONASSEMBLY where positively charged KODAK EKTAPRINT K Toner particles are attracted to the IMAGE LOOP. Development occurs as the result ofattraction ofthe toner particles to the electrostatic image on the IMAGE LOOP. The tonerparticles are carried away on the IMAGE LOOP surfacefor later transfer to a copy paper.
F. SCAVENGER ROLLER. Any developer carrier granules (iron) left on the IMAGE LOOP are salvaged at this point by the SCAVENGER ROLLER and returned to the DEVELOPER STATIONASSEMBLY.
G. POST-DEVELOPMENT ERASE LAMP. To reduce the electrostatic stress on the IMAGE LOOP and thereby Increases its life, the POST DEVELOPMENT ERASE LAMP is used to lower the high level charge that was required for proper image development This POST-DEVELOPMENT ERASE process also helps to prevent residual image retention.
H. REGISTRATION. While the developed electrostatic image moves around the CORE, a sheet ofcopy paper is advanced to the REGISTRATION ASSEMBLY (not shown in Figure 1). At precisely the right time, the copy paper is directed into contact with the IMAGE LOOP and its developed image. This aligns the copy paper and the image on the IMAGE LOOP.
I. TRANSFER CHARGER. The IMAGE LOOP and copy paper now pass under the TRANSFER CHARGER, which produces a negative charge on the paper surface to attract the positive charged developer toner. This effectively transfers the copy image to the paper. 2UT
15--
c o 8
8 io
cs o
c O
M 0- 5
0 + 5 10 15 20 Wait Time After Previous Page [in seconds]
Download Time = 5396 Page Time 1 (A) = 127394 Page Time 1 (B) = 132492 Wait Time 0 sec = 0 Page Time 2 = 7364
Wait Time 1 sec = 1714 Page Time 3 = 5648
Wait Time 2 sec = 3538 Page Time 4 = 5552
Wait Time 3 sec = 5360 Page Time 5 = 4762
Wait Time 5 sec = 7500 Page Time 6 = 6158
Wait Time 8 sec = 10500 Page Time 7 = 6160
Wait Time 12 sec = 14498 Page Time 8 = 6218
Wait Time 16 sec = 18496 Page Time 9 = 6212 Ave Pg Time 2-9 = 6009.25
Note: All times are specified in milliseconds.