Chapter3.Tioga
Last edited by Rick Beach, May 3, 1985 9:28:17 pm PDT
3
Graphical Style
3 GRAPHICAL STYLE
====================
3.1 Producing High Quality Illustrations
This chapter addresses the problems of producing high quality illustrations in documents. In particular, the issues of ensuring stylistic consistency among a group of related illustrations and of reusing illustrations in different media or for different purposes are presented. The concept of graphical style is introduced to deal with both of these problems. The illustrations considered here are two-dimensional images formed with lines, curves, areas, scanned raster images, and text. Three-dimensional images must currently be reduced to two-dimensional representations for displaying on screens or printing in documents. The concept of graphical style however extends gracefully to structured image rendering systems of any dimension.
The research into graphical style for illustrations was conducted at Xerox PARC in 1982. That work resulted in a paper coauthored with Maureen Stone and presented at the 1983 ACM SIGGRAPH conference [Beach&Stone, Graphical Style]. The paper reports on a prototype implementation, TiogaArtwork, in the Cedar programming environment [Teitelman, Cedar] using the Tioga document structure and the CedarGraphics imaging software [Warnock&Wyatt, CedarGraphics]. This chapter provides additional background to the problem and summarizes the main features of the graphical style prototype.
Few of the document composition systems outlined in Chapter 2 can integrate illustrations within the electronic manuscript file. Those that can impose severe restrictions on the achievable quality: pic and ideal produce line drawings with only a single line weight, and the Xerox Star does not output to typeset-quality devices. Illustrations for many typeset documents are prepared by skilled draftsmen and then manually pasted onto the final typeset pages. In the past, computer-generated illustrations have been easy to identify by their poor quality, especially in author-prepared manuscripts that feature diagrams prepared on pen-plotters with irregular character shapes.
This is not a new problem brought on by computer technology, but one which has always existed. All too often the illustrations in a book, especially in a technical book, do not receive the same production treatment as the text. Some publishers require the author to prepare the illustrations while others provide minimal resources for creating illustration artwork.
``When the author's contract stipulates that he is to supply illustration copy, he may choose to draw it himself or get it drawn by somebody else whose main qualification for the task is that he will make no charge for it, or next to none. The resulting material may be clear enough to explain its meaning but incapable of adequate reproduction or too irregular in drawing to appear in a well-produced book.'' [Williamson, Book Design, p 258]
The incentive for this research was to develop tools for use by an author who chooses to draw illustrations himself yet wishes to achieve a graphic arts standard of quality.
3.1.1 Text Book Illustrations
Two college text books [Dyck, PASCAL] [George&Liu, Sparse Matrices] formatted and typeset by the author of this thesis are representative of the difficulties one encounters in producing publishable quality illustrations. Both books are heavily illustrated: the first book contains over 150 line drawings and the second about 80. Both books contain hundreds of computer program fragments and many mathematical equations, typographic requirements that are often difficult and expensive when preparing text books without electronic composition tools. The computer program fragments could be treated as text and simply typeset with an appropriate font to resemble the fixed-width characters on a computer line printer. The mathematical equations were formatted with a system similar to eqn. However there were no support tools for preparing the illustrations which were ultimately drawn by hand and pasted onto the final pages.
The numerous illustrations in the two text book projects could be grouped into a few categories: mathematical graphs of curves complete with axes, tick marks, and labels; syntax charts for a programming language; data structure diagrams consisting of shaded boxes for variables and curved arrows for pointers; sparse matrix layouts depicting an arrangement of nonzero elements; and schematic diagrams to illustrate examples or exercises at the end of the chapters. Ensuring that the draftsman prepared all of the illustrations from a particular category in a consistent manner proved difficult. Several factors varied: choice of line weight, reduction percentage for illustrations drawn larger than finished size, positioning and style of tick marks on graphs, treatment of points along a curve, treatment of arrows and arrowheads, and the typography of text labels on graphs. Figure 3-1 is an example of one of the mathematical graphs from the Computing text book.
====================
///Beach/Thesis/Figure3-1-TrapezoidTypeset.Artwork
Figure 3-1. TRAPEZOIDAL RULE FIGURE from Computing [Dyck, Computing] redrawn with the Griffin illustrator using a style faithful to the hand-drawn original. This illustration will be used in several examples in this chapter. (Used with permission from Reston Publishing Co.)
====================
To control this variation, guidelines were drawn up to establish the desired choices. An axis line was always to be drawn with a thin line; the data curve would be drawn with a heavier line; points along the curve would be dots of a certain radius; tick marks would be a specified length; arrows would bend a preferred way and have a certain kind of arrowhead. Text captions and labels proved to be the most troublesome to handle. The book designers had taken great advantage of the flexible electronic document composition system to use several fonts in a disciplined way. To ensure that the illustration labels conformed to the typography of the book, the labels had to be typeset separately and supplied to the draftsman, who either cut and pasted the labels onto the artwork, or else rubbed on customized transfer lettering developed from the typeset labels.
The goal of those efforts was to ensure a consistent appearance among all the illustrations in each category. Books on graphic design urge this discipline and consistency:
``Every item in the book gains in appeal to the reader's eye from its relationship with all the other items. Something of a family resemblance, an appearance of being a set of pictures rather than a collection from disparate sets, may confer this advantage on the illustrations of any edition.'' [Williamson, Book Design, p 256]
The first problem is to ensure consistency among a set of illustrations. In developing the illustration style guidelines, several iterations between designer and draftsman were needed to specify the correct rules completely. It became obvious that this iterative design process was essentially the same process as specifying the book design guidelines between a graphic designer and the programmer of a document formatting package. The consistency problem for illustrations would be solved if one could capture and share style guidelines for rendering computer-generated illustrations in precisely the same way that style guidelines are developed for text preparation.
The second problem is to extend the lifetime of illustrations beyond a simple use. Both of the text books were used in college courses. Lecturers in those courses wanted to present overhead transparencies of the illustrations. Text book publishers often supply instructors' manuals free of charge with transparency masters for creating overhead slides. All too frequently to save time and money, the preparation of these transparency masters is done near the end of the book production cycle (or afterward) from inexpensive typewritten illustrations. It would be preferable to have the same illustrations from the text book available as transparency masters for overhead slides.
In the published forms of the two text books, the graphs and diagrams used fine lines and shaded textures appropriate for the typeset material surrounding them. Those same fine lines and shades do not reproduce well onto transparencies. For overhead or 35 mm slides projected to a large audience, the lines must be much darker, the text much bolder, and the shaded textures much coarser or (better still) displayed in color. The problem of reusing illustrations across different media would be greatly reduced if one could automatically render the illustrations with different graphical attributes suitable for different media.
If it were easier to reuse illustrations, then perhaps people would take more time and care to create really good ones.
3.2 Previous Work
Most earlier computer-based illustration systems have been primarily concerned with functionality. The thrust has been in developing algorithms for synthetic graphics and in implementing software to render illustrations. Many of these systems permit graphical attributes to be assigned to elements of the images [Crow, Image Environment], but they have no mechanism to collect attributes for easy change.
The PICTURE language [Beatty, Picture] and Picc [White, Picc], a later implementation for the C language, define picture description languages for publication quality illustrations. The style of the illustration is described by graphical parameters supplied to the rendering operations, such as line width and dash pattern required by the line drawing routine These parameters provide explicit control over some aspects of graphical style. The TELE-A-GRAF business graphics package by ISSCO [—, TELE-A-GRAF] provides templates for generating idiomatic graphics with a convenient style of presentation built into the template. Two other interesting illustrators, JUNO [Nelson, Juno] and GOB [Zabula-Salelles, GOB], use constraints to create pictures that preserve certain relationships after changes in portions of the picture, but there is no style capability to make a set of illustrations consistent.
Interactive illustrators, such as those developed at Xerox PARC, also suffer from a lack of style facilities. Bitmap illustrators like MARKUP [Newman, Markup] draw lines of different widths or shade areas with different textures to create a black and white bitmapped illustration. However, the illustration has a fixed resolution and one cannot easily change the line widths or shading textures after the illustration is created. An object illustrator like DRAW [Baudelaire, Draw] makes it easier to manipulate graphical objects, but does not provide attributes for all the rendering options nor a means of grouping graphical attributes for objects that look similar. The Griffin illustrator [Baudelaire&Stone, Griffin] does have an explicit notion of style attributes and provides menus for selecting line weight, filled and/or outlined areas, colors, text fonts, sizes, and orientations. Still, there is no grouping of style attributes nor any naming or indirection to allow sharing of attributes among several objects with the same style.
The troff preprocessors for illustrations, pic [Kernighan, pic] and ideal [van Wyk, ideal], can produce simple line drawings. There are few attributes for the graphical objects and no style mechanism. The line drawing capabilities are device specific, provide only a single default line weight, and are implemented on some typesetters by overlaying a prodigious number of dots to form connected curves.
The Xerox Star provides a comprehensive integration of graphics within office documents [Lipkie, Star Graphics]. The editing and formatting environment of the Xerox Star permits similar user interaction techniques to be used across both graphical and textual material. In particular, formatting attributes for both textual and graphical objects are assigned through the same property sheet mechanism. However, there is no grouping or indirection of these properties.
Consider an example of the frustration that occurs when there are graphical attributes but no style mechanism which occurred at Xerox PARC. A Griffin illustration of three roses was selected for use in a trade show demonstration of a new graphics printer. The original illustration had red flower petals with green leaves and stems. Unfortunately, the new printer could produce only three shades of grey and no color. The printing software substituted the same grey pattern for both red and green colors. The result was a rather flat picture. To change the colors of the red petals, green stems, and green leaves to three distinct greys required tediously applying style attribute changes to each petal, leaf and stem of the three roses by selecting each one individually. It would have been much easier if the petals, leaves, and stems each referred to a named set of graphical attributes that could be changed once to affect all references.
Grouping and sharing graphical attributes into styles is not a new idea. An early proposal by Thomas in 1976 for specifying display parameters in graphics programming languages [Thomas, Graphics Parameters] contains the essence of the graphical style idea. The Graphical Kernel System [ANSI, GKS] also provides a mechanism for grouping graphical attributes into `bundles' that are assigned to graphical objects to be rendered by a display workstation. However, these ideas have never been integrated into document composition systems or document style mechanisms.
3.3 The TiogaArtwork Prototype
The TiogaArtwork prototype illustration system was an experimental implementation of graphical style. An extended document structure that incorporates illustrations and an extended style machinery for graphical style attributes were embedded into the existing Tioga document composition system in the Cedar programming environment [Teitelman, Cedar]. The Cedar graphics package [Warnock&Wyatt, CedarGraphics] provided the necessary graphics rendering algorithms, including drawing straight lines and curves with different thicknesses, shading areas with various colors or textures, typesetting text with graphic arts fonts in various sizes, and rendering continuous tone images from either scanned or synthetically computed sources.
The TiogaArtwork illustration system is integrated with the Tioga document formatter in two ways: the document structure was extended to include both text and illustration objects, and the style machinery was extended to incorporate graphical formatting attributes. The resulting document structure for text and illustration objects provides a recursive nesting of text within illustrations and illustrations within other illustrations. Such an integrated document structure provides the basis for integrating illustrations into the editor, since many of the user interaction techniques can be made similar for text and graphics, in the fashion of the Xerox Star user interface. The style machinery extensions define additional graphical style attributes needed by the illustration rendering algorithms.
These extensions to the document structure and style machinery provide the basis for separately specifying the form (or rendering) of an illustration from the content (or geometry) of an illustration.
3.3.1 Tioga Document Model
The document model in Tioga is a tree structured hierarchy of nodes, much like NLS [Engelbart, NLS]. Textual documents are typically organized as paragraphs within sections within chapters. Each document node has textual content and an associated property list. The properties of a node affect the formatting algorithms by supplying parameters or hints.
====================
///Beach/Thesis/Figure3-2-TiogaStructure.Artwork
Figure 3-2. THE TIOGA DOCUMENT STRUCTURE is a hierarchical structure of text nodes. Each node is shown as a text phrase enclosed in a box. The hierarchical structure is shown by lines connecting boxes: lines down indicate sibling relationships (several section headings within a chapter); lines to the right indicate children (chapters contain section headings that in turn contain paragraphs). Each node has a property list shown in parentheses on top of the node box. The root of the structure has a property, (Style, WaterlooThesis), that defines the style dictionary appropriate for formatting PhD dissertations. Formatting style rule properties on each text node identify a group of formatting attributes.
====================
Two standard properties for Tioga nodes are Style and Format. (Property names and values are distinguished by a special typeface in this chapter). The Style property identifies a dictionary that binds style rule names to formatting attributes. There may be any number of style dictionaries, corresponding to kinds of formatted documents such as Cedar for program source code files, or BlueAndWhite for Xerox PARC Technical Reports (which happen to have blue and white covers). The Format property identifies a style rule in the current style dictionary. The style rule name for a particular node is usually chosen to relate to some semantic notion in the document, such as paragraph, head, or item.
Formatting attributes in the Tioga style machinery are defined by formatting algorithms which register an attribute name and a default value. Style rules are sets of interpreted instructions that assign values to the formatting attributes. For instance, the paragraph style rule sets the type size for normal text, the head rule increases the type size and sets the font bold, and the item rule increases the left indent.
The hierarchical path from the root to the node forms a search path for locating attribute-value bindings similar to programming language scoping. A Style property establishes the identified dictionary as a current scope for all nodes in the subtree spanned by that node. Attributes are assigned their values by walking the search path and executing each style rule in turn. A formatting style rule is found by searching for the style rule in the set of nested scopes. An extensive caching mechanism in the Tioga style machinery makes this traversal efficient. The existing Tioga style mechanism deals with about 50 text formatting attributes.
These format properties are analogous to declarative tags in Janus or Etude, and the formatting attributes they describe are similar to properties in the Xerox Star. However, unlike NLS and Tioga, those other document composition systems lack an explicit structured document model.
3.3.2 Artwork Class Nodes
To extend the Tioga document model to incorporate illustrations, a new node property, ArtworkClass, was defined to distinguish the illustration node content from plain text. The ArtworkClass property is interpreted by the document formatter which treats the node content as the specification of an illustration.
During development of the prototype, the Tioga editor was not modified and thus did not recognize the new ArtworkClass property. The content of these artwork nodes was a textual representation of illustrations. Therefore, the Tioga editor displayed them as text and could not present the images in a WYSIWYG fashion. Future implementation outlined in Chapter 6 will involve modifying the editor to provide a general mechanism for WYSIWYG editing classes of nontextual nodes, including illustrations.
We next define the representation within an ArtworkClass illustration. Illustrations have a natural hierarchy for positioning subpictures relative to other pictures as recognized in the earliest computer graphics systems [Sutherland, Sketchpad]. This hierarchy is mapped directly onto the Tioga document model, one subtree for each subpicture. The positioning in the hierarchy is accomplished by providing a stack of transformations and activating a new positioning transformation at each branch in the tree. These are the standard graphical transformations of translation, scaling, and rotation. The illustration content is formed from the set of graphical primitives: lines, curves, areas, scanned raster images, and text. Each of these is defined as a distinct class, described below.
The class mechanism permits recursive inclusion of content. Thus a text document may contain an illustration, and that illustration may in turn contain a text label. Furthermore, illustrations may contain any future class of object, such as mathematical equations or tables.
The artwork class of nodes is formatted using an object-oriented design. Each artwork node is represented by an object with two associated procedures, one for layout and one for rendering. The layout procedure is given the document subtree rooted at the current document node and returns the bounding box dimensions of the formatted artwork object. The dimensions of the box may be specified as glue [Knuth, The TEXbook], with appropriate stretch and shrink, so that the object can be included in the existing page layout algorithms just as a normal box, but with a special rendering procedure. The rendering procedure is given the subtree and the dimensions determined by the layout procedure. It produces an instance of the object at that size on the formatted output stream, normally a printable document file.
The TiogaArtwork prototype implementation defines several artwork classes. A registry mechanism permits extensions to be added by supplying the necessary layout and rendering procedures for each additional class. Objects of the first artwork class, ArtworkNode, serve as the roots of subpicture trees in the document structure and normally contain the transformations for positioning the
====================
///Beach/Thesis/Figure3-3-ArtworkStructure.Artwork
Figure 3-3. HIERARCHICAL ILLUSTRATION STRUCTURE of Figure 3-1. The ArtworkClass property identifies a graphical object and a description is shown as the content. Note the inclusion of text nodes, without an ArtworkClass property, for the caption labels.
====================
subpicture. An ArtworkPath class node contains the geometric definition of a path for a line or curve object, described in detail below. An ArtworkImage class node defines a continuous-tone scanned image. In the prototype implementation of the image class the node content is the filename of the scanned image, although a future extension would be to include the scanned image data directly in the node. An ArtworkFileName class node contains the name of another TiogaArtwork illustration file and thus serves as an inclusion mechanism for large or shared illustrations. The prototype provided no additional naming capability for sharing subpictures, although such a facility could be added.
3.3.3 Geometric Representation of Illustrations
The internal geometric representation of illustrations in the TiogaArtwork prototype is based on a text description in an interpretive graphics language in Cedar [—, JaM]. The language is stack-oriented with postfix operators for arithmetic, logical, and graphical operations. Geometrical objects are defined by a path that determines the trajectory followed by a line or a curve, or the boundary of an area filled with color or texture. All of the rendering parameters for the geometric objects in an illustration are defined by the style rules described in the next section. Figure 3-4 contains the plain geometry of the trapezoidal rule illustration. The textual representation of this illustration is shown later in Figure 3-5.
Transformations in an illustration can be composed of translation, scaling and rotation elements appropriate for standard graphics packages. The hierarchical structure for the illustration is traversed using a standard tree-walk. At each branch in the tree, the current transformation is stacked and the new transformation concatenated. These operators are used to specify the positioning transformations:
x y .translate — translate the origin to <x,y>
sx sy .scale — scale by the factors sx in x and sy in y
r .rotate — rotate clockwise by r degrees
The paths that define stroke trajectories or areas are composed of straight lines and B ezier parametric cubic curves. The graphics package provides the notion of a current point that is set at the beginning of the path and updated as line segments and curves are added to the path. As a trajectory, the path specifies the centerline of strokes. As a filled area, the path specifies the boundary of the area. Note that no rendering specifications are necessary in the
====================
///Beach/Thesis/Figure3-4-TrapezoidSketch.Artwork
Figure 3-4. SKETCH OF THE ILLUSTRATION for Figure 3-1 represents the basic geometry of the picture. The same TiogaArtwork representation was used for this illustration as for Figure 3-1, however all of the rendering attributes have been reduced to drawing only thin lines and using a typewriter-like typeface.
====================
geometrical specification, because they are available through the style machinery. These operators are used to define geometrical paths for each synthetic graphical object:
x y .moveto — establish the current path position <cx,cy> as <x,y> with respect to the current transformation
x y .lineto — extend the path with a straight line from the current path position <cx,cy> to <x,y>, and update the current path position <cx,cy> to be <x,y>
x1 y1 x2 y2 x3 y3 .curveto — extend the path with a curve which has the four B ezier control points <cx,cy>, <x1,y1>, <x2,y2>, and <x3,y3>, and update the current path position <cx,cy> to be <x3,y3>
====================
% TiogaArtwork figure for Trapezoid Rule
% Cluster 1
0 0 .translate 1 1 .scale 0 .rotate
% y-axis
11 31 .translate 1 1 .scale 0 .rotate
1 1 .moveto 1 185 .lineto
% x-axis
3 39 .translate 1 1 .scale 0 .rotate
1 1 .moveto 249 1 .lineto
% curve
27 87 .translate 1 1 .scale 0 .rotate
1 1 .moveto
8 17 15 33 25 49 .curveto
43 78 71 106 105 113 .curveto
131 118 161 110 185 97 .curveto
194 92 201 87 209 81 .curveto
% area from a to (a+b)/2
51 39 .translate 1 1 .scale 0 .rotate
1 1 .moveto 1 97 .lineto
81 161 .lineto 81 1 .lineto
1 1.lineto
% area from (a+b)/2 to
...
% y-axis label
8 216 .translate 1 1 .scale 0 .rotate
y
% x-axis label
247 36 .translate 1 1 .scale 0 .rotate
x
...
Figure 3-5. GEOMETRIC REPRESENTATION of Figure 3-1 in a textual form consists of transformations and path definitions. The Trapezoidal Rule illustration was first drawn with the Griffin illustrator and then automatically converted into a TiogaArtwork representation. The node structure corresponds to Griffin clusters and the node properties correspond to groups of Griffin style attributes. Here, the indentation indicates the node structure. The style properties are not shown. Comments, which begin with percent signs, were added for exposition purposes only by manually editing the text.
====================
3.3.4 Graphical Style Attributes
Extending the style machinery for the TiogaArtwork prototype required defining additional style attributes to provide parameters for the various graphical rendering algorithms. Some of these attributes specify straightforward parameters, such as line thickness or area color. Other attributes specify how the geometry of the illustration should be treated, for instance, whether the path defines an outline or an area or both. Secondary attributes are necessary to describe how outlines are to be drawn. For instance, a pen metaphor, similar to the one in METAFONT [Knuth, METAFONT], is used to draw lines that provides different shapes of pens specified by various parameters. The following attributes are provided in the TiogaArtwork prototype for simple line drawings. Some values are keywords and others are numeric. Later in this chapter, Figure 3-7 contains several examples of graphical style rules.
pathType — the choice of path treatment as an area or outline or both: filled, outlined, filled+outlined
lineWeight — the line thickness (a measurement)
penType — the choice of pen shape: round, square, rectangular, elliptical, italic
penHeight — the pen height as a proportion [0..1] of lineWeight
penWidth — the pen width as a proportion [0..1] of lineWeight
penAngle — the rotation of the pen, in degrees clockwise from horizontal
areaColor — the color of filled areas as hue, saturation, brightness values in the range [0..1]
outlineColor — the color of outlines as hue, saturation, brightness values in the range [0..1]
Additional attributes define how textual captions and labels should be handled within illustrations. Several attributes come directly from the existing Tioga style attributes, while others were added to distinguish among the variety of caption alignments:
family — the name of a type family, such as "Helvetica" or "Times Roman"
size — the type size (a measurement)
face — the choice of type style: regular, italic, bold, and bold+italic
captionFormat — the choice of text justification format: flushLeft, flushRight, centered, or justified
captionAlign — the choice of the text alignment point: flushTop, centered, baseline, or flushBottom
lineLength — the length of caption lines (from Tioga)
leftIndent — the left indent for captions (from Tioga)
rightIndent — the right indent for captions (from Tioga)
leading — the spacing between lines of text (from Tioga)
textRotation — the rotation of the text line, in degrees clockwise from horizontal
textColor — the color of caption text: hue, saturation, brightness values in the range [0..1]
3.3.5 TiogaArtwork Rendering Algorithms
Recall that artwork class objects have two procedures, one for layout and one for rendering the illustration. The layout procedure returns the bounding box for the illustration, and the rendering procedure creates an image either on a display screen or in a printable file.
In fact, both these object procedures depend on the rendering algorithm. The bounding box information for layout is collected by rendering the illustration through a special imaging device that computes the bounding box of all the graphical objects it sees. The document formatting algorithm accepts the illustration as a box with those dimensions and positions the illustration box within a page. With the position determined, the formatter invokes the object rendering procedure to create the viewable illustration.
The rendering technique is to walk the illustration subtree in prefix tree-order, and for each child of the subtree root representing a subpicture, stack the current transformation, render the subpicture and pop the transformation stack. The subpicture node class determines the layout and rendering procedures to use for an object of that class.
Algorithm A (Render Artwork)
A1 [Traverse the illustration subtree] Given the root of the illustration subtree, walk the tree. For each child node of the root:
A1.1 [Stack Current Transformation] Request the graphics package to remember the current transformation on its stack.
A1.2 [Invoke Node Render Procedure] Select the object rendering procedure depending on the class of object found. Common classes are listed here for convenience.
A1.2.1 [ArtworkNode] Concatenate the transformation and invoke Algorithm A on this node as the root of a subpicture.
A1.2.2 [ArtworkPath] Render the path according to the graphical style attributes using the geometry defined by this node as needed.
A1.2.3 [ArtworkImage] Render the raster image stored in the file named in the node contents.
A1.2.4 [Text] Format the text caption using the text class layout procedure and graphical style attributes to position the caption.
A1.3 [Pop Transformation] Pop the transformation stack in the graphics package to return to the transformation of the parent node.
The path rendering algorithm uses the graphical style attributes to determine how to use the geometrical path information. Given the separate specification of geometry from style in a TiogaArtwork illustration, one can make multiple uses of the geometry to create special effects. Multiple use has already been discussed for areas that are both outlined and filled where the path serves once as the boundary of the filled area and a second time as the centerline of the outline. Other special effects, such as shadows, arrow designs, and border patterns, were considered for the prototype. Only shadows were implemented in TiogaArtwork, although techniques for rendering arrow and border designs along path geometries were discussed in the Graphical Style paper [Beach&Stone, Graphical Style].
Two types of shadows were implemented to simulate apparent depth: a drop shadow, where the object is drawn with a slanted shadow, and an offset shadow, where the object is drawn repositioned slightly from the original and in a different color. A similar scheme was used for highlighting text in an interactive paint program previously developed by the author of this thesis [Beach, Paint]. The shadow style attributes defined were the following:
shadowType — the choice of shadow effect: drop or offset
shadowAngle — the angle of the shadow from the object, in degrees clockwise from the horizontal
shadowDirection — the direction of the shadow from the object: upLeft, upRight, downLeft, downRight
shadowPathType — the choice of offset shadow treatment: filled, outlined, filled+outlined
shadowOffsetAmount — the distance that the offset shadow is placed at shadowAngle
shadowWeight — the thickness of the drop shadow or the outline of the offset shadow
shadowAreaColor — the color of the drop shadow or offset shadow area
shadowOutlineColor — the color of the offset shadow outline
3.4 Results
To experiment with the graphical style prototype, line drawing illustrations were created with the Griffin illustrator and converted into the TiogaArtwork document structure. The conversion program understands the Griffin file format and extracts the geometric definition of objects from the files. Griffin illustrations can be built with clusters of graphical objects and the clusters are preserved as a subpicture tree in the hierarchical TiogaArtwork document structure. The coordinate origin for each cluster is set to the lower left corner of its bounding box and an appropriate transformation is inserted into the root of the subpicture tree. Griffin style attributes for each object are collected into TiogaArtwork style rules and a style dictionary is built automatically for each illustration. Generic names for the style rules and style dictionary are synthesized by the conversion program. These names can be edited by hand to reflect more meaningful names, and the styles for several illustrations collected into a single style dictionary. This process simulates the operation of an interactive WYSIWYG-style user interface for an illustrator program (one that was not built as part of the prototype experiment). The trapezoidal rule figures in this chapter, Figure 3-1, Figure 3-4, and Figure 3-6 were all created this way.
Existing scanned images, new images scanned using services on the network, or raster images computed by image synthesis algorithms may also be included as illustrations. TiogaArtwork nodes referencing image files or illustration files were inserted into test documents `by hand' for the prototype using the Tioga editor.
The class mechanism for artwork illustrations proved to be a very successful extension strategy for Tioga documents. Several additional ArtworkClass properties have been implemented through this mechanism, including tables discussed in Chapter 5.
The TiogaArtwork scheme was successful in creating pictures more complex than previous interactive illustrators at PARC. In particular, the concept of transformations and named subpicture elements stored in a hierarchical fashion was not available in the Griffin illustrator. The inclusion of simple text is supported by Griffin, but the general formatting capabilities of Tioga are only accessible through the TiogaArtwork scheme. The combination of synthetic line drawings with images and formatted text within a document was not available, except through a `paste-up' program for combining printer format files.
The TiogaArtwork prototype was successful in separating the graphical attributes from the illustration rendering algorithms. The graphical style concept thus provided the enforcement mechanism to ensure that a set of illustrations in a document have a consistent appearance. Reusing the same illustration for different media was also made possible by changing the graphical attributes in alternate versions of the style rules. Figure 3-6 contains the same trapezoidal rule illustration as Figure 3-1, but with a style suitable for a 35 mm color slide presentation. Figure 3-7 contains the two sets of style rules for the typeset illustration, Figure 3-1, and the 35 mm slide illustration, Figure 3-6.
Unfortunately, the style concept is not sufficient to capture all the notions of changing illustrations across media. Unless the illustration and its style attributes are carefully designed, such as carefully choosing the text alignment and anchor points, unfortunate results may occur when changing the style without changing the content. When an illustration is prepared as a projected slide there is less room for detail. Suppressing detail is a change supported by some graphic systems, such as in Crow's scene assembler [Crow, Image Environment] , which the prototype graphical style system does not accommodate. Text size is a style
====================
% this a composite illustration: first a background, then the artwork
% establish a background for the 35 mm slide form
0 0 .moveto 275 0 .lineto 275 235 .lineto 0 235 .lineto 0 0 .lineto
10 10 .translate
///Beach/Thesis/Figure3-6-TrapezoidSlide.Artwork
Figure 3-6. TRAPEZOIDAL RULE SLIDE uses the same picture file as Figure 3-1, but with a style appropriate for a projected 35 mm color slide. The image has the `preferred' format with light detail on a dark background, thicker lines in white, a larger, bolder and simpler typeface. (Used with permission from Reston Publishing Co.)
====================
parameter, but transformation scaling of the graphical objects is not. For instance, the graphical box surrounding a text phrase would not change size when the text was made larger. Constraints would be an asset in changing the graphical objects with respect to surrounding material. Incorporating the constraint aspects of Nelson's JUNO illustrator [Nelson, Juno] into the illustration artwork rendering system might alleviate these problems. This is discussed in Chapter 6.
Manipulating styles in the TiogaArtwork prototype stresses the tools available in Tioga. More interactive tools, such as property sheets from the Xerox Star, would be a boon to selecting attributes and naming format rules. New style tools should list the set of style dictionaries available, list the formatting style rules in a selected dictionary, and list the values of formatting attributes defined in a selected style rule. Style rules could then be defined to be the `same as but different' from other style rules by naming one style rule and setting specific attribute values to be different. Layout parameters might be more easily specified through an interactive design tool for styles.
The goal of the graphical style research was to provide a new tool for the graphic artist to be more effective when mixing illustrations within electronic
====================
% TrapezoidBook.Style % TrapezoidSlide.Style

BeginStyle BeginStyle

(BasicGraphics) AttachStyle (BasicGraphics) AttachStyle

(BasicText) AttachStyle (BasicText) AttachStyle

(axis) "x,y axes" { (axis) "x,y axes" {
black outlineColor white outlineColor
outlined pathType outlined pathType
1 pt lineWeight 2 pt lineWeight
} StyleRule } StyleRule

(darkArea) "dark areas" { (darkArea) "dark areas" {
grey areaColor orange areaColor
filled pathType filled pathType
} StyleRule } StyleRule

(lightArea) "light areas" { (lightArea) "light areas" {
lightGrey areaColor lightYellow areaColor
filled pathType filled pathType
} StyleRule } StyleRule

(curve) "function line" { (curve) "function line" {
black outlineColor white outlineColor
outlined pathType outlined pathType
2 pt lineWeight 4 pt lineWeight
} StyleRule } StyleRule

(caption) "text caption" { (caption) "text caption" {
"TimesRoman" family "Helvetica" family
8 bp size 12 bp size
italic face bold face
flushLeft captionFormat flushLeft captionFormat
flushTop captionAlign flushTop captionAlign
0 leftIndent 0 leftIndent
black textColor white textColor
} StyleRule } StyleRule

(xAxisLabel) "text label" { (xAxisLabel) "text label" {
caption caption
center captionFormat center captionFormat
} StyleRule white textColor

(yAxisLabel) "text label" { (yAxisLabel) "text label" {
caption caption
flushRight captionFormat flushRight captionFormat
} StyleRule white textColor

EndStyle EndStyle
Figure 3-7. GRAPHICAL STYLE SHEETS for the two Trapezoidal Rule illustrations in Figure 3-1 and Figure 3-6 demonstrate the style language and the graphical style attributes. The style on the left produces a typeset book quality illustration and the style on the right produces a colored 35 mm slide form. Note that the styles differ in the choice of line weights, color selections, and typography parameters, and that the caption rules depend on a common definition with different alignment. The style rules are named for the obvious parts of a mathematical graph.
====================
documents. Just as careful document design permits a manuscript to be published in several different forms, the careful design of illustrations and their styles leads to the ability to reuse illustrations for several purposes and to control the production of high-quality illustrations more efficiently.