Personal Distributed Computing: The Alto and Ethernet Software

5.4.Integration

An integrated system has a consistent user interface, consistent data representations, and co-resident applications. What does this mean?

A consistent user interface is one in which, for example, there is a single “delete” command that deletes the selected object, whether the object is a text string, a curve, a file, or a logic element. Every kind of object has a visual representation, and operations common to sev­eral objects are specified in the same way and have the same results on all the objects. Most computer systems are constructed by amalga­mating several applications and lack any consistency between the ap­plications.

A consistent data representation is one that allows two applica­tions handling the same kind of data to accept each other’s output. Thus a document editor can handle the drawing produced by an illus­trator or a graph plotting program, and a compiler can read the output of a structured document editor, ignoring the structuring information that isn’t relevant to the syntax of the programming language.

Two applications are co-resident if control can pass from one to the other quickly and smoothly, without loss of the program state or the display state. If a text document editor allows pictures in the docu­ment, can pass control to the picture editor, and the picture can be edited while it appears on the screen along with the text, then the text and picture editors are co-resident. In the same way a spreadsheet, a database query system, or a filing system might be co-resident with editors or with each other.

Integration is difficult for several reasons. Designing consistent in­terfaces is difficult, both technically and organizationally. Consistent data representations require compromises between the different needs of different applications; most Alto programmers were (rightly) uninterested in compromise. Co-residency requires common screen-handling facilities that meet the needs of both applications, and enough machine re­sources to keep the code and data for more than one program readily available.

In spite of these problems, integration was always a goal of many Alto system applications, but success was limited. Gypsy has excellent integration of text editing and filing. The window system of Smalltalk provides some integration, the later Star and Cedar systems continue this, and all three have some consistency in user interfaces. All three also have a common data representation for simple text, and make it easy to copy text from one application to another as pipes do in Unix. Star goes furthest in consistency of interfaces and representations, and also has co-residency of all its applications. A great deal of effort was devoted to the user interface design [43] to achieve these results. Un­fortunately, it pays a considerable penalty in complexity and perform­ance. In Cedar some applications, notably the Tioga structured document editor, can be easily called as subroutines from other appli­cations.

5.5.Making images

The Alto user interface depends heavily on displaying images to the user. These are of two main kinds: text and pictures. The application programs that allow users to make different kinds of images are de­scribed in the next section. They all, however, use a few basic imaging facilities that are discussed here.

The basic primitive for making images is BitBlt, designed by Dan Ingalls [18,37]. It operates on rectangular sub-regions of two bitmaps or two-dimensional arrays of pixels, setting each pixel of the target rectan­gle to some function of its old value and the value of the corresponding source pixel. Useful functions are

• 
  constant black or white, which sets the target black or white;
  
• 
  source, which copies the source to the target;
  
• 
  merge, which adds black ink from the source to the target; and
  
• 
  xor, which reverses the target color where the source is black.
  

There is also provision for a texture source that is an infinite repeti­tion of a 4 x 4 array of pixels; this provides various shades of gray, striping, and the like. The Alto has a microcoded implementation of BitBlt that is quite fast.

BitBlt is used for rearranging windows and for scrolling images in a window. In addition, a single BitBlt can draw an arbitrary rectangle, and in particular a horizontal or vertical line, or it can copy or merge the image of a character from a source image called a font that contains all the characters of a typeface. Arbitrary lines and curves are drawn by procedures that manipulate the target image directly, since the rec­tangles involved are too small for BitBlt to be useful. In many cases, however, the resulting images are saved away as templates, and BitBlt copies them to the screen image.

In the Alto system applications make images by using BitBlt di­rectly, or by using procedures to paint a character string in a given font or to draw a line or spline curve. Curves, once computed, are stored in a ‘chain’ encoding that uses four bits to specify the direction of the curve at each pixel. There is also a package that handles arrays of inten­sity samples, built by Bob Sproull, Patrick Baudelaire and Jay Israel; it is used to process scanned images. Cedar has a complete graphics package that handles transformations, clipping, and halftoned repre­sentations of sampled images within a uniform framework [59].

6. Applications

Most people who look at the Alto system see the applications that allow users to do many of the major tasks that people do with paper: preparing and reading documents with text and pictures, filing infor­mation, and handling electronic mail. This section describes the major Alto system applications that are not programming systems: editors, illustrators, and filing and mail systems.

6.1.Editors

The Bravo editor was probably the most widely used Alto application [25]. It was designed by Butler Lampson and Charles Simonyi, and implemented by Simonyi, Tom Malloy, and a number of others. Bra­vo’s salient features are rapid screen updating, editing speed indepen­dent of the size of the document, what-you-see-is-what-you-get formatting (with italics, Greek letters, and justified text displayed on the screen), and semi-automatic error recovery. Figure 2 shows a Bravo screen, illustrating the appearance of formatted documents. Later ver­sions also have style sheets, which introduce a level of indirection be­tween the document and its layout, so that the layout can be changed systematically by editing the style sheet; the document specifies “em­phasis” and the style sheet maps it to “italic” or to “underlined” as desired.

Bravo is a rather large program, since it includes a software-imple­mented virtual memory for text and fonts; layout of lines and para­graphs in a variety of fonts with adjustable margins, tab stops, and leading; mapping from a point in the displayed text back to the docu­ment; incremental screen update; a screen display identical to the final printed copy; hard-copy generation for ears and Press printers as well as daisy-wheel devices; and page layout. Later versions have a document directory, style sheets, screen display of laid-out pages, hyphenation, a remote terminal service, an abbreviation dictionary, mail merge, and assorted other features.

Good performance in a small machine comes from the representa­tion of edits to the text and of formatting information, and from the method for updating the screen. The text is stored as a table of pieces, each of which is a descriptor for a substring of an immutable string stored in a file. Initially the entire document is a single piece, pointing to the entire file from which it was read. After a word is replaced, there are three pieces: one for the text before the word; one for the new characters, which are written on a scratch file as they are typed; and one for the text after the word. Since binary search is used to access the piece array, the speed is logarithmic in the number of edits. This scheme was independently invented by Jay Moore [35].

Formatting information is represented as a property record of 32 bits for each character (font, bold, italic, offset, etc.); since consecutive characters usually have the same properties, they are stored in run-coded form in a table much like the piece table. Changes in formatting are represented by a sequence of formatting operators attached to each piece. Thus to find the font for a character it is necessary first to find its entry in the run-coded table, and then to apply all the formatting operators in its piece. But it takes only a few instructions per piece to make a 60,000 character document italic. When an editing session is complete, the document is written to a file in a clean form, so that the piece table doesn’t keep growing.

To make screen updating fast, the screen image is maintained as a table of lines, each containing its bitmap and pointers to the charac­ters used to compute it. This table is treated as a cache: When an edit is done, any entries that depend on characters changed by the edit are invalidated. Then the entire screen is recomputed, but the cache is first checked for each line, so that recomputation is done only if the line is actually different.

Bravo has a clumsy user interface. The Gypsy editor, built by Larry Tesler and Tim Mott, uses much of the Bravo implementation but re­fines the user interface greatly. Gypsy introduced a modeless user in­terface, editable screen display of bold and italics, and an integrated file directory that is modified by the same commands used for editing. All these ideas were later used in many parts of the Alto system. The parallel development of Bravo and Gypsy is an illustration of the many elements required in a good application. Both the refined implementa­tion methods of Bravo and the refined user interface of Gypsy are im­portant; each required several years of work by talented people.

The Star editor evolved from Bravo and Gypsy, with further re­finement of the user interface [43] and the integration of graphics (see the next section). The Star interface design in turn had considerable influence on later versions of Bravo, from which Microsoft Word was then derived. It also influenced the Cedar document editor, Tioga, which is distinguished by its support of tree-structured documents (de­rived from Engelbart’s system [13]), and by a fully programmable style-sheet facility that can do arbitrary computations to determine the format of a piece of text.

There are also simple text editors embedded in the Smalltalk and Mesa programming environments. These allow plain text files to be created, read, and modified. They are used for editing programs and for viewing typescripts, the output of programs that produce a sequence of unformatted lines.