Computer Science Laboratory
May 11, 1978

FromDan Swinehart, Joe Maleson, Patrick Baudelaire, and Edward Fiala

Printing at Palo Alto

Filed As[Maxc]<Gr-Docs>Printing.Press
This document has the twofold aim of describing the printing facilities that are currently available, and of announcing two major impending changes.
Key Points
We are currently in transition from one major printing format (EARS) to another (Press), with a corresponding introduction of new printing hardware (Dover, Pimlico, Sequoia). Some aspects of this transition will affect users quite a bit, some very little. All will of course affect those who produce formatted files.
One upcoming change that will have substantial effect on the entire community will be the distribution, on June 15, of a new Fonts.Widths file, correcting the width specifications for our major document fonts. Previously produced Press files should continue to print reasonably accurately, although they may not do so forever. Subsystems that create Press files will be required to supply the current date (machine readable format) in a new field within each new Press file.
Another major impact will be felt as the Ears system is decommissioned on the same date (June 15, 1978). It will be possible to convert most EARS format files to Press format, and thus to print them. This includes all new EARS files that are produced by the Pub system, and most if not all previously created ones.
A modification of printing resolution (from 350 to 384 dots/inch) for Dover and Sequoia printers will limit printing to the lower 10.6" of each page; information in the top .4" will be lost. This is expected to affect very few documents.
The sections that follow survey the current state of Printing Formats and Transmission Protocols, Fonts, Printing and Formatting Programs, Printer Types, and Impending Changes. Appendices supply a variety of useful information, including a comprehensive glossary of terms associated with page imaging. There is also a bibliography of related documents and manuals. Feel free to skim or skip those sections that do not appear to be of interest.
Printing Formats
EARS Format
EARS format [Rider1] was developed as the input format for the Ears printer (see below). It is a character oriented format, specifying for each page the names and positions of each character to be printed. An EARS format file must also contain a font directory before it can be printed. This directory, describing the shape of each character to be printed, can be a permanent part of the file, or may be inserted just before the file is shipped to the printer, based on a list of requests (the Doculist) that is embedded in the document. Exception: a default set of 16 commonly used fonts is available at the printer site, and need not be transmitted with the file.
In addition to characters, line drawings and passable low-resolution bit maps may be specified using EARS format, by creating suitable "type faces" containing the required patterns. Ears can handle most Alto screen resolution bit maps in this way.
In Palo Alto, there is only one Ears system (named Palo).
Press Format
Press format [Newman/Sproull] is ’an attempt to define a "universal" format for describing documents’ for printing and editing. Its major goal is the complete description of document appearance in a device-independent fashion. A Press file should look the same, within device limitations, on any printer.
Press format allows the specification of:
Text characters.
Solid rectangles parallel to the paper edges.
Objects whose outlines are defined by a series of graphic commands including spline curves. Character shapes may be defined in this way. (see fonts section below).
Images specified as a matrix of intensity values at arbitrary resolutions. Bit map patterns are an instance of such images, where intensity values are constrained to one bit.
Any of these entities may be placed at any location on the page, and may be assigned brightness (obtained with half-tone shading methods) and color characteristics. Characters to be printed are specified by name. Custom shapes may be included by sending their splines and the names to be assigned to them, but one usually depends on the server to locate the necessary shapes based on the names alone, using established conventions (see the Fonts section below).
A printer that accepts Press format is not required to implement all its provisions. The descriptions below indicate for each program and printer what subset of the Press facilities it implements.
Text Files
Programs exist on both Maxc and Altos (see below) for converting standard Ascii text files to EARS or Press format, with optional headings and page numbers. These programs often combine translation with transportation to the appropriate printer. For the results to be pleasing, the text files must contain explicit line breaks.
Pspool Format
Pspool format [Fiala1] is a simple augmentation of Ascii text files. Escape sequences describe margin settings, column settings, landcape/portrait selection, font selection, underlining, etc. A document heading may override default selections for user identification, file identification, etc.
At present, only the printing subsystem on Maxc1 or Maxc2 (see Formatting Programs, below) will honor Pspool format, and then only for files to be sent to Ears. A Press version should be complete by June 15.
Transmission Protocols
A printer is classified as a "server" if it can operate unattended, accepting files sent to it over the internetwork using a Pup-based protocol. Otherwise it is a "stand-alone" printer, requiring each user to attend its operation.
The user of a stand-alone printer may choose any available transmission program to transfer files to the printer’s local disk. The Ftp program [Boggs/Taft], using the FTP protocol [Shoch1], is preferred because of its speed, utility, and availability -- it is the only protocol currently used by the IFS systems.
All server systems currently use a simpler protocol, EFTP protocol [Shoch2], which is more easily incorporated into sending programs like Bravo that are tight for space. The EFTP protocol provides only for the transmission of file data. Thus the only identification information available to the server is information contained in the file itself. This, combined with some limitations in Press format, has caused some difficulty in properly identifying the sender of documents to Press printers.
A final protocol, known as EARS protocol [Taft2], is honored by all servers. It provides a means whereby user programs can determine a server’s current status.
See the Formatting Programs section for more information about protocol usage.
High resolution raster representations of fonts comprise many bits, and are device dependent; for these reasons font rasters are not included in Press files. Instead, fonts are specified by family name, a numberic code specifying type face (bold, italic, regular, etc.), point size, and rotation. An extensive description of font issues can be found in [Sproull4]. Two representations exist for fonts: outlines (described by graphic commands including spline curves) and rasters (or "bit maps"). Along with the description of character shape according to one of these representations, positional information is needed. A variety of file formats are presently used for storing this font information. Sometimes several fonts are included in a single file, called a dictionary. PrePress [Sproull2] is a program which converts among the various formats, and performs some bookkeeping operations for font dictionaries. Press format allows up to 16 different fonts per entity (a page subgrouping). When more than 16 fonts appear in a page, they must be grouped into font sets (of up to 16 fonts) in such a way that each page contains fonts from only one set. A document may contain up to 64 font sets.
Font Naming Conventions
A standard file naming convention allows identification of what font is contained in a file. The convention is:
Examples: TimesRomanB.SD, TimesRoman10B.AC
The optional B|L stands for Bold or Light;I for Italic;C|E for Condensed or Expanded. Device independent fonts (outlines) omit {point-size}. The extension indicates the format (see below) of the font representation. For device-dependent (e.g., bit map) representations, the standard conventions contain no clue to the orientation, resolution, etc., of the font.
An alternate font naming convention is used to expand the code describing the type face, in Press files and in some of the formats below. This convention uses a three letter code, selecting from the orthogonal attributes
(bold/medium/regular, italic/regular, condensed/regular/ expanded). In the TimesRoman10B example, this face code is thus BRR. See [Sproull4] for the precise mapping between this code and the actual numeric specifications used in
Press and in font dictionaries.
The format of a file is indicated by its extension. Standard formats include:
.SFOutline representations edited with FRED (device-independent).
.SDCompact outline representations, produced by PrePress from .SF files (device-independent).
.ACRaster representations edited or created with PrePress from SD format (device-dependent).
The remaining formats can be be converted to AC format, and can be produced from AC format:
.CU"Carnegie-Mellon" format raster representations.
.ALRaster representations in Alto (CONVERT) format.
.STRIKERaster representations in Alto (BITBLT) format.
.EPEARS-format portrait font (run-coded raster).
.ELEARS-format landscape font (run-coded raster).

Example: Helvetica12I.EP is a 12-point Helvetica font for EARS (face code MIR).
While raster representations can be automatically converted from outline descriptions, this process is not performed efficiently with present hardware. In addition, some hand tuning of a scan converted font often improves its appearance. Therefore, each Press printer is expected to have local raster copies of all necessary fonts, converted to whatever resolution is appropriate. Although Press format allows users to include personal fonts in outline form, Spruce software does not implement this feature. The Orbit printers (Dover, Sequoia, Pimlico -- see [Ornstein] and discussion below) generally run at 384 dots per inch. Dovers currently running 350 dots will soon be converted to 384 (see issues and plans, below). The Orbit hardware supports a maximum of 4096 dots per scan line, and so limits printing length to 10.6" at 384 dots.
There is one problem with keeping fonts external to Press files: the width of a character is not specified locally, and formatting programs need to know character widths for things like text justification. This information is kept in a file named Fonts.Widths. Any changes to the width information (for purposes of standardization or aesthetic appeal) will alter the appearance of Press files which were produced using different widths. This is currently a major problem, as we attempt to reach compatibility with the printing world. Additional incompatabilities are the printing world’s two kinds of spaces (numeric and regular), different characters for hyphen and minus, and the use of ligatures (multiple character combinations like "ae" or "ff") and kerning (sometimes called "optical spacing" -- altering inter-character spacing for specific pairs of characters).
A list of the standard fonts to be available on printers in PARC beginning June 15 is contained in an appendix. More may be added, to all or some, as time goes on.
Printing Programs
The Sears program [Rider1] operates the Ears printers as a server, spooling and printing EARS format files (using the EFTP protocol).
There are two programs that accept Press format files: Press [Sproull1] and Spruce [Swinehart1].
This program, the older of the two, will accept and render nearly all Press specifications, including color (results depend on the printer). Press is a stand-alone program, whose intended application is the production of high-quality, high-resolution graphical images. Press is available on most of the printers described in the following section, except for the very fast ones (see Printers, below). Press does not operate as a "spooling" network service program, and is therefore not the printing program of choice for high-volume text printing.
Spruce is intended as a printing service system, primarily for printing office documents. It accepts a subset of Press files including text characters, rectangles, and most Alto screen resolution bit maps. It does not handle splines or arbitrary bit patterns, nor does it honor brightness and color requests (but see the note below). Enterprising users could obtain limited line-drawing capability by creating and using appropriate "spline fonts". Spruce operates only on printers controlled by Alto II/Orbit hardware (see Printers, below).
Continuous tone images which have been digitized are stored as an Array of Intensity Samples. AIS format is used to store such images. Included in an AIS file are various data about the image which are important for accurate reproduction. Software is available which prints AIS files using a variety of halftoning techniques. Halftoning simulates various gray tones using only one ink color by varying the amount of ink in an area proportional to the original intensity. By halftoning several different color separations, a wide range of hues can be achieved.
Color Note
Press format allows specification of hue (color) as well as intensity. The Press program implements this feature directly on the Pimlico printers (see below). An interim measure has been used, in Spruce for Pimlico and in Press for the Colorado system (see below), to produce color images. In these systems, three or four Press pages, one per color (sometimes including black) are required for each printed page. A full conversion to direct color specification support is expected for Spruce.
Formatting Programs
Maxc Programs
The Pspool program [Fiala1] runs as a background job on the Maxc systems, formatting and transmitting documents to printers as they appear on the <PRINTER> directory. Files are placed there either explicitly or in response the attempts of programs to write to the LPT: device. Files already in EARS or Press format may be sent to an appropriate printing server. Press format files may, alternatively, be converted to EARS format and sent to the Ears server. Pspool format may be converted into either EARS or Press format and sent (see the information on Docgen, below). Pspool will add necessary .EP or .EL files (EARS font descriptions) to a file on its way to Ears, if that information is not already in the file. It will use the Doculist section of the EARS file to decide what to send.
The EPress program is invoked by Pspool to translate Press format files into EARS format for printing on Ears. This conversion is automatic. The user has the option to save the resulting EARS file.
The standard way to direct text or pre-formatted files to printing servers is to run the Ears, Press, List, or Copy commands. These programs do intelligent things about selecting files with the proper extensions, embedding appropriate header information in EARS files, etc. Headings, page numbers, margin trnasformations and size reduction are also available through the Ears command.
The Printer Status command will indicate the names of files spooled on the <PRINTER> directory and of recently printed files, and the state of the most recently active printing server. Respool may be used to retransmit a file that was send for printing but did not get printed correctly for some reason.
The Pub [Tesler] formatting program is a batch processing system that is useful in formatting large documents, especially if they need indices or cross-reference, or if they are going to be updated frequently. Pub will produce plain text output (for on-line perusal) or EARS format output, including a Doculist that Pspool can use to include the necessary fonts. Once the Ears system is gone, production of Pub-formatted documents will of necessity be a two-stage process, producing first the EARS format file on Maxc, then a Press format file on an Alto using PressEdit (below).
Pspool often needs additional information about a user’s printing preferences before it can perform its tasks. When sending Press files, for instance, Pspool must know what server to send them to. Although it is always possible to specify these options directly, it is useful to be able to default them. The system provides global defaults for each option. The user may specify different ones by creating a Maxc file called Docgen.Prt. The system defaults and the format of Docgen.Prt may be found in [Fiala2].
Alto Programs
The Gears program [Rider1] will produce an EARS format file from a text file, transmitting the result to Ears. It will optionally supply a heading and page numbers on each page, expand tabs properly, and obey a small number of font change and formatting specifications. In addition, it uses the Ears protocol to report on the status of the printer.
NGPR is part of the design automation package. It produces EARS format versions of Sil format files, either leaving them on the local disk or sending them to Ears.
The Empress [Boggs/Maleson/Tiberi] and NPPR programs are analogous to Gears and NGPR, except they produce Press files. Empress does not provide all the formatting options that Gears does, but it does include some useful Press file processing functions. It is in addition willing to ship files that are already in Press format to a Press printer. NPPR uses Empress, via a command file, to print its output.
The OfficeTalk-Zero (OZ) system [Newman/Mott] is also capable of producing and directly sending Press files to suitable printers.
The Bravo editor will produce hardcopy in either EARS or Press format. It can either produce a local file or transmit the result directly to a printer. In the latter case, Bravo uses the file Swatee as a scratch file. Recent versions of Bravo and Draw (see below) will accept color information and produce the appropriate "color separated" Press file.
The [HARDCOPY] section of the User.Cm file on one’s Alto disk serves to personalize default printing options (e.g., preferred printing format, preferred printer, etc.) It is analogous to Docgen.Prt on Maxc. The following example contains a sample of each kind of entry that I am aware of:
Press or Ears
EARS: PaloName or legal network address of Alto providing Ears printing service
PRESS: MenloSimilarly for preferred Press printer
Preferred color printer (Press only)
See explanation below
See explanation below
The FONT entry, used up to this point only by Empress, specifies that TimesRoman10i (italic) should be used as a default font instead of Gacha8 (Empress’s default choice). The second, point size argument, and the third, face specification argument are optional. The face argument contains three letters specifying weight (M, B, or L), slope (R or I), and expansion (C, R, or E), respectively.
The PRINTEDBY field, if present, specifies the name to be used in the Name field on the break page. The current disk login name will replace the character $. Empress and Bravo both chose "$" as a default in the absence of a specification.
As far as we know only Bravo honors the PREFERREDFORMAT entry.
Of course, he [BRAVO] section of User.Cm also contains font selection specifications.
Related Programs
Markup [Newman1], Draw [Baudelaire1], and Sil [Thacker/Sproull] are interactive programs that produce Press file output for hardcopy. Markup and Draw are illustration programs with different strengths and emphases. Sil is a part of the hardware design automation package, but is also useful for producing charts and other simple line drawings.
PressEdit [Newman2] is used to edit and merge Press files (at the page level), and to convert EARS format files to Press format.
Fred [Baudelaire2] is an interactive spline curve editor specialized for font design. PrePress [Sproull2] is a utility program for converting spline character shapes to bit maps in various formats and resolutions, as described in the Fonts section. Both are of use mainly to implementors of printing or display software.
Printer Types
All the printers described below are Raster Output Scanner (ROS) printers. The complete printing facility includes a ROS and an Electronic Image Processor (EIP), consisting of an Alto and either a little or a lot of specialized imaging and interface hardware. Newer systems interface EIP to ROS using the "9-Wire standard" [Rider2, Rider3] -- a standard hardware interface and communications protocol.
Ears. [Rider1] A modified 7000 duplicator engine with Slot (Scanned Laser Output Terminal) imaging optics. Ears is controlled by a very powerful special purpose EIP, the Research Character Generator (RCG). The RCG is in turn controlled and supplied with data by an Alto. The Ears printer was designed and built at PARC.
Slot/3100. modified 3100 copier with Slot imaging optics. Image processing is done entirely in Alto microcode, and the machine is controlled through a very simple interface. This simple structure is made possible by the relatively slow operating speed of the 3100 engine. Because it runs slowly enough, and because the 3100 engine provides excellent solid-area development, high-quality, high-resolution graphic objects may be rendered on this machine. The Slot/3100 systems were built by XEOS.
Dover. [Ellenby, Sproull3] A modified 7000 duplicator with an improved Slot head totally contained within the original engine. Dovers are engineered to be produced in reasonable quantities. They contain ROS Adapter (video and control electronics) modules that may be used in several other printers (see below). The adapters communicate with their controlling Alto IIs using the 9-Wire Standard. A Dover Alto contains relatively inexpensive EIP hardware, called Orbit [Ornstein, Sproull3]. This device can, with some preprocessing assistance from its Alto, generate text pages and ruled forms at full Dover speed.
Dover’s capabilities are largely determined by the bandwidth of the associated EIP and storage medium. The Orbit hardware reduces the bandwidth required to do text and solid rectangles, but Alto main memory and T80 disk bandwidth limitations restrict Alto/Orbit/Dover systems to relatively low-resolution graphical output. The Alto/Orbit hardware can produce high-resolution, high-quality graphical output when used with slower engines (e.g., Sequoia, Pimlico).
Dover and Orbit were developed by team from PARC and EOD/SPG.
Sequoia. A modified 3100 copier equipped with a Slot head. Sequoia uses the Dover ROS adapter, obeys the 9-wire standard, and is controlled by an Alto II-Orbit. Sequoia was developed and manufactured at XEOS. Its operating speed and good solid-area development allow Sequoia to render high-quality graphics.
Pimlico [Swager, Baudelaire/Swinehart] A modified 6500 color copier. The original optics have not been removed; therefore hybrid composition techniques involving both platen and raster-scanned inputs are possible. Pimlico uses the Dover ROS adapter, obeys the 9-wire standard, and is controlled by an Alto II-Orbit. The entire electronics control package has been replaced by a microprocessor-based system, using an M6800, that can communicate with the controlling Alto II via standard adapter commands. This vastly improves the engine control protocols and capabilities. Pimlico was developed by a team from PARC and EOD/SPG. Its development was expedited with special funding provided by C. Peter McColough as part of the Xerox World Conference effort.
Alto/Orbit/Pimlico is capable of high quality renditions of graphical objects.
Colorado. A modified 6500 color copier that has been in service at XEOS in Pasadena for several years. Colorado has been developed by Dale Green (OSL) and his group, and has been used in a variety of pioneering color copying and printing experiments. This system is a high resolution, very high quality RIS-ROS system, with color correction, tone reporduction (TRC), and halftoning implemented in hardware. The ROS may also be used, at lower resolutions, as a color printer for the Alto. The interface to the Alto is the same as is used for the Slot/3100. Colorado uses Press and AIS printing software to print "color separated" files (see the note on color rendition above). Its 6500 engine has been augmented with a fourth developer (black) to print four-color pictures.
TC-200. A modified TC-200 telecopier, interfaced to an Alto in a manner similar to the Slot/3100. This system also contains RIS (raster input scanning) capabilities. It was developed at ADL. A TC-200 system will soon be available at PARC.
Versatec Plotter. A modified Versatec electrostatic plotter, interfaced to an Alto in a manner similar to the Slot/3100. This system is capable of printing on extremely large pieces of paper, but at a slower speed than the xerographic printers.
Performance and capability specifications for these printers appear in an appendix.
Impending Changes
Orbit Printer Resolution
We are currently operating all the Orbit printers (Dovers, Pimlicos, Sequoias) in Palo Alto at 350 dots/inch. For a variety of technical reasons, we plan to switch to a 384 dots/inch resolution as part of the June 15 cataclysm. With one important exception, users will not notice the change.
The exception is that, again for technical reasons, Orbit printers at 384 dots/inch are limited to a 10.6" high page. Dovers and Sequoias will thus enforce a .4" top margin, which may cause some information to be "clipped" from the page. Pimlico output will be unaffected.
The Demise of Ears
The Palo/Ears system, because of its advancing age, is becoming quite difficult to maintain. For this reason, a second floor tribunal has decided that Palo will be removed from service on June 15, 1978. The remainder of this section discusses various issues that this decision raises.
Spruce printers are now functionally competitive with the Ears system, although the number of available, useful fonts is somewhat diminished, particularly landscape fonts (see the appendix). Pending enabling technology, we are delaying plans to fetch additional font specifications from less restrictive storage on Juniper or Ivy systems. Some performance improvements are also planned in anticipation of the increased load.
It was also necessary to decide the fate of EARS format files: those currently in existence, and those that will continue to be produced by Pub. Most EARS files, including all new Pub products, contain the directory entries (Doculists) that allow the PressEdit program to produce equivalent Press files from them. We hope it will be possible to convert EARS files that do not contain this directory information to those that do. If not, then a relatively small number of old EARS files, produced by older verions of Pub, will no longer be printable.
One additional impending change, the modification of some of our character widths, add to the difficulties of retiring Ears. This is further discussed in the following section.
Character Widths
Press format files do not in general specify the height and widths of their text characters. Instead, it is assumed that the producer of a Press file (e.g., a formatting program), and its consumer (usually a printing server) have a common notion of these values. Each Alto based formatting program uses the file Fonts.Widths, which describes the heights and widths of all available type fonts in device-independent units. This width file is carefully maintained by each installation. It is augmented as new fonts are added.
The printing programs maintain corresponding width information, usually device-dependent, that agrees with the information in Fonts.Widths. In this way, the accuracy of Press renditions is guaranteed.
Unfortunately, we have learned that the widths originally assigned to the characters in the font families TimesRoman and Helvetica were incorrect -- for the most part, the current widths produce excessive inter-character spacing. For this reason, it will be necessary to institute a new width standard, using the following scheme:
On June 15, 1978, a new Fonts.Widths file will be promulgated. At the same time, an improved set of fonts, geared to the new widths, will be installed on all Palo Alto Spruce and Press systems (many sites already use these new fonts and widths). Users who obtain the new widths file should notice no changes. Problems might, however, be expected in printing previously created Press files (using the old width specifications). The following steps will be taken to reduce the inconvenience:
Old Press Files: The Press file document directory includes some spare fields. We have chosen one two-word field to represent a date and time, in Alto Standard format [Taft2]. The assumption is that old Press files contain values in this field that can be rejected as valid dates (typically 0 or -1). Subsequent to June 15, 1978, any Press file whose date appears invalid, or whose date precedes June 15 will be printed using the old widths. Files with dates of June 15 or later will use the new widths. It is not clear how long these old widths will remain available. The scheme to be used is quite general, and can support additional future width modifications, but such changes are painful, and are expected to be quite rare. Press file implementors: consult the information in [Swinehart2] or in the newly-updated version of [Newman/Sproull] for details required to update your output modules.
Old EARS Files: As indicated above, it should be possible to add Doculist directories to directory-less files. (These files contain the EARS fonts directly; PressEdit does not find them useful.) The old Fonts.Widths will be available, so that PressEdit may be used to create "old" Press files, complete with invalid or pre-June dates.
New EARS Files (Pub output): The .EP format files that Pub uses instead of Fonts.Widths to perform its formatting will be modified to reflect the new widths (note that only the width information in each font file will remain relevant, since Palo will have been retired.) Thus, PressEdit will have the proper information, using the new Fonts.Widths, to produce "new" Press files. These mechanisms are clumsy enough that we expect them to hasten the transition to newer formatting systems.
Longer-Term Issues
Many other modifications and additions have been contemplated for improving printing service. Most will require extensions to either the printing protocols or to the Press format.
Potential printing protocol extensions would permit the specification of the sending user (distinct from the creator of the Press file). It would also permit the transmission of non-resident, machine-dependent fonts (Press format supports the transmission of character shapes as outlines, but not as bit maps). In addition, one could request priority treatment, or could request that printing be delayed until the user is present, for security reasons. Other extensions might allow references to fonts and Press files on other file systems (e.g., Ivy) to be spooled, instead of the files themselves.
These issues are mentioned as possible areas of continued development; implementation should be considered distant.
This section has described some impending changes in terms of some problems and their solutions. The solutions are summarized in the Key Points section on page 1.