BEACH AND STONE GRAPHICAL STYLE SIGGRAPH '87 TUTORIAL COURSE NOTES DOCUMENTATION GRAPHICS === length: 1 in Graphical Style Towards High Quality Illustrations Graphical Style Towards High Quality Illustrations Richard Beach and Maureen Stone University of Waterloo and Xerox PARC ABSTRACT: If there is to be widespread acceptance of computer generated images in areas traditionally served by graphic artists, these images must meet a high standard of quality. Document preparation systems are an application area that is gaining maturity in providing high-quality computer typeset documents. These systems exhibit a trend towards specifying the formatting information for a document separately from the body of the text. The goal is to have the document format designed by someone with expert knowledge of typography. Writers can then apply a format to their own work simply by indicating the semantic content of their text, such as the headings, paragraphs, or footnotes. The result is that a writer can produce properly typeset documents without learning the esthetics of typography. This paper extends this idea to encompass the illustrations in the text. We have developed a prototype system that uses a set of graphical style rules to define the design guidelines for the illustrations. The rules, called a graphical style sheet, can be used to control a uniform "look" over a set of illustra-tions, or to change the appearance of a particular illustration to reflect different publishing styles or different media. The prototype coordinates with an existing document preparation system and the combined systems were used to produce this paper. We conclude that this is a viable method for controlling image style for at least one class of illustrations. This approach contributes to image quality by providing a method for capturing knowledge of graphic arts standards, and for ensuring a consistent appearance of related illustrations within technical documentation. Categories and Subject Descriptors: I.3.3 [Computer Graphics]: Picture/Image GenerationDisplay algorithms; I.3.4 [Computer Graphics]: Graphics UtilitiesPicture description languages; I.3.6 [Computer Graphics]: Methodology and TechniquesDevice independence; I.7.2 [Text Processing]: Document PreparationFormat and notation; languages; photocomposition; J.5 [Computer Applications] Arts and HumanitiesArts, fine and performing; Additional key words phrases: Graphic arts, graphic design, graphical style sheet, illustration, integrated text and graphics Introduction If there is to be widespread acceptance of computer generated images in areas traditionally served by graphic artists, these images must meet a high standard of quality. Increasingly, we see examples such as chart-making systems or spectacular special effects where the quality is defined by the traditional graphic arts standards for print, video or film media. This paper describes the development of tools to improve the quality of technical illustrations. The inclusion of graphic images into computer-typeset documents is an area of current research and development, for example, PIC [7], IDEAL [18], JANUS [5], Etude [12], and the Xerox Star [10,17]. Typical illustrations which we wish to include are line art and shaded images. Frequently the composition systems which create them are text formatters extended to handle the higher quality output and flexibility available with typesetters and laser printers. Computer graphics has evolved along two fronts towards quality images: the introduction of new output devices and the development of new rendering algorithms. New devices have higher resolution and more color capability making it possible to render images more precisely. New algorithms that generate smooth curves and more realistic shaded surfaces provide a way to produce high-quality images. Now, artists and designers can expect to find opportunities for creative expression within such systems. The style of a document is a phrase that conveys several meanings, all related to quality. The word style in a thesaurus refers to the ideas of fashion, method, beauty, class, and expression. To a graphic designer, the phrase house style refers to the customary way that a particular publishing house handles typesetting or illustrations. Traditionally to a graphic designer, a style sheet communicates to the compositor how to render a document or image [16]. A style sheet, such as the one in Figure 1, provides typographic parameters for typesetting text and guidelines for achieving certain visual effects. The purpose of a style sheet is to ensure consistency and design discipline within a project, and to provide a rapid and effective means for specifying that discipline. Computer typesetting systems have provided style mechanisms for text composition through formatting macros or style sheet databases. The `-ms' macro package supplied with TROFF is an example of formatting macros that implement document style [11]. SCRIBE uses document types to establish the formatting details for a variety of document styles [15]. The Xerox Star uses property sheets to select parameters to control the appearance of selected items of text and graphics in documents [10]. In each of these systems, some mechanism is provided to manipulate the content of a document separately from the appearance of the document. Thus consistency and design discipline can be achieved. This is accomplished without forcing the author to become a graphic designer while the graphic designer can supply specialized knowledge to create the document style. === Figure 1. TRADITIONAL STYLE SHEET for specifying typographic parameters. The rows indicate the parts of the document to be treated specially. The columns indicate the typographic parameters which the compositor uses when typesetting this job. Entries in the matrix are either checkmarks or numeric values. === Extending these formatting style techniques to include graphic images is a natural evolution. In the following sections we describe our concept of graphical style for illustrations and also the artwork-rendering prototype that we integrated with an existing text composition system. The illustrations we consider will be line drawings, although a provision for continuous tone images will also be described. Examples of Graphical Style To motivate our concept of graphical style, we present two examples taken from traditional graphic arts productions. The first example presents observations on some stylistic aspects of Scientific American illustrations. The second example describes how a consistent style was achieved in producing a book having many line drawings. === Figure 2. SCIENTIFIC AMERICAN STYLE for illustrations is evident in this one from David Waltz' article `Artificial Intelligence' [19] in the October 1982 issue, page 122. Several stylistic aspects can be noted: the thin line weights, the open arrowhead design, the use of color and shading, and the caption typography. (Used with permission of W.H. Freeman & Co.) === Scientific American Illustration Style Scientific American has established a reputation for the clarity and effectiveness of its illustrations. In Figure 2 taken from the recent article, `Artificial Intelligence,' in the October 1982 issue of Scientific American [19], we can observe several aspects of the Scientific American style. Lines are generally thin, although with different weights to convey detail, arrowheads are always the same open design, lettering is always 8-point Helvetica capitals, shades of grey and colors are used only when needed and then only to convey essential meaning, and the design is clean and carefully crafted. While the author supplies the concept sketch and the illustrator renders the image with great skill, it is the art department that ensures that the traditional style of Scientific American illustrations is maintained [4]. Traditional Illustrated Book Production A recent textbook for introductory computer science co-authored and typeset by the first author of this paper [6] required a large number of illustrations. Many of the illustrations were listings of computer programs and their output. With a suitable typeface and the text files containing the original programs and computer output, these figures were easily composed directly into the main body of the book. In contrast, there were over 150 line drawings that were hand-drawn by a draftsman. The production of these illustrations presented a considerably different problem. Illustration guidelines were written to establish the desired style. The authors and the book designer described how various details were to be handled by the draftsman for each type of illustration: mathematical graphs, Pascal syntax diagrams, data structure diagrams, and simple line drawings. For instance, the guidelines specified the different line weights for the axes and curves in graphs, the typography for labels on graphs and syntax diagrams, the shading technique for areas in graphs and simple line drawings, and the treatment of arrows in syntax and data-structure diagrams. These guidelines were organized by illustration categories, and then by illustration components. Thus the guidelines for graphs specified the treatment of axes, curves, areas, intersection points, axis tick marks, axis labels, and curve functions; and the guidelines for syntax diagrams specified the treatment of terminal symbols, nonterminal symbols, and grammar rules. Unfortunately, there was no computer support available for drawing the illustrations that could produce sufficiently high quality output or that could implement the various guidelines. The book's illustrations were also used to produce overhead transparencies for lectures. The computer programs and output could easily be reformatted with a larger type size suitable for projection by specifying a different text formatting style. The hand-drawn artwork had to be enlarged photographically. When an illustration was scaled to transparency size, much of the detail in the illustration was often too small to be read in a large lecture hall. A style substitution facility for graphical images, similar to the one available for text, with the ability to change the proportions of line weights, to use different shading, and to request larger, bolder, text captions would have been invaluable. Graphical Style Sheets A graphical style sheet is a way of describing the design guidelines for an illustration. A set of figures produced with the same style sheet should "look" related. It should also be possible to dramatically change the appearance of a figure by specifying different styles, as shown by the book style and transparency style for the Trapezoidal Rule illustration in Figure 3. This implies that there is some separation between the style sheet and the specifics of a particular illustration. The style sheet should contain rendering information specified in some semantic way. For example, there might be a rule that specifies how all axes for graphs should be rendered. We need to determine, therefore, how to separate an illustration into content versus format, and how to specify the format in terms of rendering attributes. Content versus Format in Illustrations To apply the content versus format discipline found in text composition systems to illustrations, it is necessary to define the content of an illustration separately from its format. The illustration's content is analogous to the author's rough sketch given to a draftsman, such as Figure 4, and its format is analogous to the appearance of the finished artwork rendered by the skill and craftsmanship of the artist, for example, Figure 3. The sketch is described by geometrical objects and their positioning, while the artwork rendering is described by design guidelines and drawing techniques. === Figure 3. TRAPEZOIDAL RULE FIGURES demonstrate the use of graphical style to produce two very different visual effects. The top illustration is adapted from Computing [6] by redrawing it with the Griffin illustrator. The style is faithful to the hand-drawn original. The bottom illustration uses the same picture file but with a style appropriate for a 35 mm. color slide. The slide has the preferred format with light detail on a dark background, thicker lines in white, a larger, bolder and simpler typeface, and the caption is formatted to the slide width. (Used with permission from Reston Publishing Co.) === In a manner analogous to the style mechanisms of text formatters, there must be an additional means of including semantic notions in an illustration. Just as not all three-space indentations are paragraph indents, not all thin lines are axes on a graph. Therefore, graphical style must include mechanisms for capturing the intent of the author/illustrator. One way to do this is to provide a level of indirection which names the semantic parts of the illustration. The rendering attributes and guidelines associated with these names are defined separately in a graphical style sheet. If this level of indirection is available, then it is possible to render the same illustration in quite different ways by changing only the graphical style definitions. For example, Figure 3 shows two graphical styles with thin, clean lines for a typeset book and with wider, bolder lines and colors for a color transparency. === Figure 4. SKETCH OF THE ILLUSTRATION for Figure 3 represents the basic geomety of the picture. All the rendering information for the figure has been reduced to drawing thin lines and using a typewriter-like typeface. The three examples of the Trapezoidal Rule have all been produced by using the same TiogaArtwork file but with appropriate differences in the style rules. === Rendering Attributes A graphical style sheet must express how an illustration is to be rendered. Basic drawing attributes supported in most graphics packages are obvious candidates for specifying how an artwork rendering program should produce an illustration. Examples of such attributes appear in the Griffin illustrator [3], the GKS standard workstation attribute model [2] and in the Xerox Star basic graphics feature [10]. These examples suggest that at least line weight, line patterns, color specification, and caption typography parameters be included in any graphical style sheet. Graphic designers frequently rely on mechanical aids and transfer sheets to obtain consistent or special effects, suggesting other sources of rendering attributes. A standard reference for transfer sheet designs is the Letraset Catalog [1]. Additional rendering algorithms can be created to produce some of those effects. For instance, a line in an illustration sketch might be rendered by specifying an arrow design in the graphical style sheet to be drawn along that line. Similarly, borders or texture patterns might be rendered from details provided in graphical style sheets. The Prototype System Overview To experiment with these ideas of graphical style we developed a prototype suitable for a class of technical illustrations The system, named TiogaArtwork, was designed to coordinate with the Tioga document preparation system and an interactive illustration program called Griffin [3]. The procedure for generating a figure is to make a draft using Griffin and then convert the figure to a special kind of Tioga document. Once the figure is in document form it is possible to adjust both the style and the content using a combination of Tioga and TiogaArtwork. All of the figures in this paper, except the published example in Figure 2, have been produced using this technique. The TiogaArtwork system was developed in the Cedar programming environment [14], which is a research project at Xerox PARC. Cedar is both a language, derived from Mesa [13], and a computing environment. The hardware for this environment is a Dorado processor [9] with a 1024 by 808 pixel bi-level display and, optionally, a 640 by 480 pixel color display. A range of medium- to high-resolution printers is available. The highest-quality printers produce digitally half-toned images at phototypesetter-compatible resolutions either in black and white or as color separations. The design of the prototype is based on features of the Tioga document preparation system, so it is necessary to briefly describe Tioga before going into the details of TiogaArtwork. The current implementation of Tioga consists of an interactive text editor and a batch-oriented typesetter. Documents in this system consist of two files: a file of text nodes and a file of formatting style rules. The text nodes in Tioga have a hierarchial structure similar to that of the NLS editor [12]. A document is a tree-structured hierarchy of nodes containing text, for example, in section, subsection, paragraph order. A normal tree-traversal results in the familiar form of the document. Each node in the document can possess certain node properties. The principal use of these properties is to associate the formatting style rules with the nodes. Figure 5 represents the Tioga document structure of some surrounding nodes of the document for this paper. The style concept in the Tioga formatter is similar to that in SCRIBE [15]. In Tioga, formatting styles are defined by a collection of rules contained in a separate file. The style rules specify formatting parameters such as type family, style, and size, indentation, interline leading, text justification mode, and composition layout parameters. The formatting rules are written in an interpreted language, so it is possible to compute parameters during the formatting process. We have designed a way to include nodes containing graphics in a Tioga document. These nodes contain a textual representation of geometric attributes such as line coordinates, curve control points, positions, and transformations. The style rules associated with these nodes specify graphical parameters and rendering attributes. Tioga's node properties are implemented as named property lists, so we defined a new property, which we called ArtworkClass, for the illustration nodes. The style machinery for Tioga is extensible, so the current set of tools allows us to build on the existing mechanisms for manipulating styles and for adding graphical style attributes. It also means that our system can use Tioga facilities for text formatting. A document in our system, therefore, is a tree of nodes arranged in a hierarchical structure. Some of the branches of the tree represent paragraphs of text and some represent illustrations. An illustration is a subtree in the document tree-structure with its root node possessing an ArtworkClass property. Nodes within the subtree structure may be either graphics or text. Nodes representing subpictures will have the ArtworkClass property, while text captions within an illustration will have only the standard Tioga properties. This recursive relationship is important; it means that our system can use all the text formatting features of Tioga for text inside of illustrations. Figure 6 represents the Tioga document node structure for portions of the Trapezoidal Rule illustrations in Figures 3 and 4. === Figure 5. DOCUMENT STRUCTURE provides a hierarchy for organizing a text document. This illustration represents the Tioga document structure for the nearby sections and subsections of this paper. The boxes represent text nodes and the labels above each box represent the node properties. The StyleRule property indicates the formatting attributes for first-level headings, second-level headings, paragraphs, and items within a list. === === Figure 6. ILLUSTRATIONS in TiogaArtwork also use the Tioga document structure. The boxes represent the artwork nodes which contain the geometrical representation, and the labels above the boxes represent the node properties. Note that StyleRule properties exist on both text and artwork nodes. This structure can be extended to encompass pictures composed of many subpictures and text captions in a natural hierarchy. === TiogaArtwork is the part of the system that interprets the graphical nodes and style rules. The pictures can be previewed on a display screen using the Cedar graphics package [21] or converted for printing. The combination of using the Tioga document structure and representing the graphics as text allows TiogaArtwork to interact easily with the Tioga editor and the Tioga typesetter. This is advantageous in a number of ways. One advantage is the ease of creating and editing figures. The Tioga editor does not react to the ArtworkClass property, so the text and style properties for a graphics node can be edited in the normal manner. This means that for the prototype experiment we did not have to write a special editor to manipulate the graphics, although we did write a conversion routine which translated from Griffin format to Tioga node structure and automatically generated style rule properties from the Griffin style attributes. Another advantage of using the Tioga document structure for illustrations is that it permits us to typeset any text in the illustration. This is accomplished by setting up a call-back mechanism between the typesetter program and TiogaArtwork. As the document tree is traversed, the typesetter formats text nodes in the normal fashion. Whenever a node with the ArtworkClass property is encountered, that entire subtree is passed to TiogaArtwork. If TiogaArtwork subsequently encounters a text node while rendering the illustration, it passes the text branch back to the typesetter. This recursion is guaranteed to terminate at the end of the tree-path traversal. The call-back mechanism is also used to pass dimensional information between the two programs. The typesetter provides the dimensional parameters for the formatted text with which TiogaArtwork can layout the caption within the illustration according to the style rule. TiogaArtwork generates the dimensions of the formatted graphics so the typesetter can layout the figures with the paragraphs on the page. This document structure and system design gives us a great deal of flexibility for experimenting with the best way to represent illustrations in a document. The current structure puts only geometric information in the document body and puts all rendering parameters in the style rules. We found that this representation gives a good semantic description of the picture. The next sections will describe our current implementation in more detail. Geometric description A Tioga document is a tree of nodes. Some of the branches of the tree represent paragraphs of text, and some represent illustrations. For text, the levels of the tree represent the section-subsection-paragraph hierarchy of the document. For illustrations, the hierarchy represents a relative set of transformations for subpictures. Each subpicture in the illustration is drawn relative to the coordinate system established by its ancestors. An ArtworkClass node, therefore, may contain a set of coordinate transformations which establish the coordinate system for this node and all of its descendant subpictures: x y .translate -- to translate the origin to sx sy .scale -- to scale by x,y scaling factors r .rotate -- to rotate by r degrees A geometrical shape can be composed of straight lines and curves, and a sequence of these lines and curves is called a path [21]. A path can represent a line, an area or a clipping region. The path definition is provided by commands to draw lines and curves: x y .moveto -- establish the current path position as x y .lineto -- draw a line from the current position to , and reset to x1 y1 x2 y2 x3 y3 .curveto -- extend the path with a curve which has the four Bezier control points , , , and , and reset to For the kind of pictures we are working with, the paths and transformations are all that is specified in the nodes of an illustration document. The rest of the rendering information will be supplied by the style rules. Figure 7 is an extract from the geometric description used for the three instances of the trapezoid rule diagrams in Figures 3 and 4. For reasons which become apparent during the discussion of rendering algorithms, it is necessary to distinguish between transformations and path definitions in the contents of an ArtworkClass node. It is also convenient to create artwork nodes which specify the file name of a TiogaArtwork illustration. Continuous-tone images stored as files are another category of illustration that can be accommodated by the ArtworkClass property. The values of the ArtworkClass property are the following: ArtworkNode -- node contains the textual representation of an illustration which is not a path, such as transformations ArtworkPath -- node contains the geometric definition of a path === % 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 7. GEOMETRIC REPRESENTATION of an illustration in a textual form consists of comments, transformations, and path definitions. The Trapezoidal Rule illustration was first drawn with the Griffin illustrator [3]. It was then automatically converted into a TiogaArtwork document generating the node structure and node properties from the Griffin illustration file. The indentation indicates the node structure. The comments, which begin with percent signs, were added manually by editing the document text. === ArtworkImage -- node contains the name of a continuous-tone image file stored as an array of intensity samples ArtworkFileName -- node contains the name of another TiogaArtwork file Basic style parameters Style rules are described in an interpreted language with each format rule expressed as a procedure definition. A typical rule describes a list of parameter-value pairs which will be stored in a global association list. The general format for this in the Tioga editor is: (name-of-style-rule) "commentary describing the style" { value parameterName value parameterName ... value parameterName } StyleRule The name-of-style-rule refers to some semantic aspect of the illustration such as axis, curve, or nonterminal. Values are either numbers or keywords and may be expressions. Values which are distances may be expressed in most convenient units. For instance, 2-point line weight can be expressed as 2 pt, colors can be expressed by keyword color names such as red, darkBrown, or lightBlue, and relative colors can be evaluated as some percentage (such as 75 percent) of the brightness or saturation of a named color. The following basic set of drawing attributes were defined as graphical style parameters: lineWeight the line thickness pathType the path area/outline type: filled, outlined, filled+outlined penType the pen shape: round, rectangular, elliptical, italic penHeight the pen height as a proportion of lineWeight penWidth the pen width as a proportion of lineWeight penAngle the rotation of the pen, in degrees from horizontal areaColor the color of filled areas: hue, saturation, brightness outlineColor the color of outlines: hue, saturation, brightness The following set of style attributes are supplied by the existing formatter but are interpreted by the artwork-rendering software for illustration captions and labels: family the type family, such as Helvetica or TimesRoman size the type size face the type style: regular, italic, bold, and bold+italic captionFormat the text justification mode: flushLeft, flushRight, centered, or justified captionAlign the vertical text justification mode: flushTop, centered, baseline, or flushBottom lineLength the length of caption lines leftIndent the left indent for captions rightIndent the right indent for captions leading the spacing between lines textRotation the rotation of the text line, in degrees from horizontal textColor the color of caption text: hue, saturation, brightness To demonstrate both the style language and the graphical style attributes, Figure 8 shows the two style definitions necessary for Figure 3. Rendering the illustration TiogaArtwork translates our representation of an illustration into a set of calls on the Cedar graphics package [21] . The graphics package implements a full set of transformation and clipping operations. Shapes are described as a set of analytical outlines that are filled either with a flat color or an image. The geometry in our documents consists of paths and transformations. The transformations translate one-for-one into calls on the graphics package. The path definitions are compatible with the outline description required by the graphics package. Thus, if a node contains a path with the pathType=filled, then the path represents a closed area to be colored with areaColor and can be easily rendered. If the pathType is outlined, then it represents the center-line of a line or pen stroke. A thick line is drawn along this path as defined by the lineWeight and pen parameters. Predefined pen shapes are round, square, rectangular, elliptical, and italic. Other style parameters control the aspect ratio and rotation of the pen shapes. The graphics package does not currently support a pen semantic, so TiogaArtwork reduces this description to an outline. This definition of a thick line is similar to that of a stroke in Metafont [8]. === % 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 (area1) "dark areas" { (area1) "dark areas" { grey areaColor orange areaColor filled pathType filled pathType } StyleRule } StyleRule (area2) "light areas" { (area2) "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 (leftCaption) "..." { (leftCaption) "..." { "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 } StyleRule white textColor } StyleRule (centeredCaption) "..." { (centeredCaption) "..." { ... ... (rightCaption) "..." { (rightCaption) "..." { ... ... EndStyle EndStyle Figure 8. GRAPHICAL STYLE SHEETS for the two Trapezoidal Rule illustrations in Figure 3 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 line weights, color selections, and typography parameters. === Extended style semantics This basic graphical style machinery can be extended to express more complicated style semantics. The following examples of shadows, arrows, and borders are based on common graphic arts practice. Shadow Styles Two-dimensional shadow effects can be created to emphasize an object. Two simple examples of shadow effects are drop shadows and offset shadows, shown in Figure 9. A drop shadow appears to give an object depth by extending a slanted shadow line away from the object. An offset shadow gives emphasis by showing an underlying copy of the object a short distance away. The style parameters for shadow effects are the following: shadowType the shadow effect: drop or offset shadowPathType the offset shadow path type: filled, outlined, filled+outlined shadowAngle the angle of the shadow from the object, in degrees shadowOffsetAmount the distance that the offset shadow is placed at shadowAngle shadowDirection the direction of the shadow from the object: upLeft, upRight, downLeft, downRight shadowWeight the weight of the drop shadow or outline of the offset shadow shadowAreaColor the color of the drop shadow or offset shadow area shadowOutlineColor the color of the offset shadow outline === Figure 9. SHADOW EFFECTS can be rendered by a simple algorithm that reuses the geometric path definition several times. The arrow on the left has a drop shadow and the arrow on the right has an offset shadow. Several style parameters are available to control the weight, angle, color, and type of shadow. === Both shadowing techniques can be rendered by first drawing the shadow of the object and then drawing the intended object. Slightly darker shadow colors can be computed in a style rule, for instance, shadowAreaColor might be computed as 50 percent of the brightness of the areaColor. Arrow Styles Arrows in drawings can be described as paths having a particular arrow style. The style must describe the shape of the arrowhead and tail. One approach is to define a prototype shape on a simple rectangular grid. This model resembles a transfer sheet system such as the one provided by Letraset [1]. To avoid cataloging a large variety of curved arrows, a mapping is used to stretch the prototype shape along any given path. The x-axis of the grid is mapped onto the path directly, and y-values are mapped into distances normal to the path [20]. This scheme permits considerable scope for creative designs by using a simple and easy-to-draw prototype, and then computing the hard-to-draw finished design as in Figure 10. Border Patterns Arbitrary patterns are a logical extension of the style for arrow heads. These border patterns are slightly more complicated to render because the prototype pattern must be repeated along the path like a wallpaper design. As only an integral number of repetitions is desired, the mapping algorithm must adjust scale factors to ensure an exact number of cycles. Again, the same simple prototype grid is mapped along the path, as shown in Figure 11. === Figure 10. ARROW STYLES can be created by mapping a prototype design, developed on a rectangular grid, along a curved path. The mapping algorithm can be controlled to preserve the arrow head and feather shapes and only stretch the shaft of the arrow. The path can be any combination of lines or curves. The style of the mapped arrow can be filled or outlined in a similar way to other TiogaArtwork objects. === === Figure 11. BORDER PATTERNS can also be mapped along paths using the same technique as for the arrows, but using an integral number of repetitions. This Greek Key design consists of a white rectangular area and a blue spiral. The design was created to fit together end to end. The path is a cubic curve. === Conclusions We conclude that a representation that explicitly specifies the stylistic properties of an illustration provides a powerful way to control document quality. Graphical style sheets can provide design discipline. Using a common style when designing a set of illustrations for a paper, for example, can guarantee a uniform specification of such parameters as color, line styles, and arrowhead shapes. Another benefit is that the additional semantic structure introduced by the style sheet makes it possible to produce those figures over a range of circumstances. Different style sheets can be designed to accommodate not only different publishing styles but also the restrictions inherent in different media, such as the difference between paper and 35 mm slide media. If it is easier to reuse figures, then perhaps more time will be spent producing good ones. We have successfully implemented a prototype system for manipulating graphical styles which was built to coordinate with the Tioga document preparation system. We have used the combination of Tioga and TiogaArtwork to produce this paper. We conclude from working with this system that it is possible to control some of the stylistic aspects of illustrations using a set of style rules, and that this approach is a useful one for specifying pictures in documents. The particular representation we used was a convenient one for our environment. The important aspect is the separation of the geometry and the style properties, especially the level of indirection introduced by using named style rules. The flexibility inherent in the textual representation and the style language was important in an experimental system. We suspect that a style language is the correct level of abstraction for graphical styles even in fully developed systems. Representing illustrations as styles plus geometry introduces some interesting issues with respect to rendering algorithms. For example, one natural specification for line style is to specify a uniform width. The specification should also describe the behavior of the line at joints and endpoints; for example, whether the corners are mitered or rounded off. An algorithm that produces an analytical description for the shape of an outline specified in this manner is nontrivial, especially if the path contains parametric cubic splines. This kind of example forces us as graphics system designers to pay attention to useful rendering algorithms, not just convenient ones. Future Work It is clear that for many applications one should use an interactive graphics system to design an illustration. For example, we used the Griffin system to generate the illustrations for our paper rather than manually calculate path descriptions. There are many interesting questions about how graphical style should be specified in such a system. Griffin assigns attributes to shapes, but there is little semantic content to the assignment; all objects with the same set of properties have the same style. In general, we need to learn more about organizing style rules. Our current implementation has a different rule for each node that looks at all different. Often, however, the styles vary in only a few parameters. In fact, the actual semantics may really be: these nodes are the same except for these parameters. In the current TiogaArtwork system, it is possible to define generic style rules, that can be referenced in specific style rules to specify the common set of attributes. Tools are needed to provide an effective interface to this style machinery. Illustrations are often produced by executing other graphics programs. Frequently these programs have little facility for providing graphical style. Many times the illustrations produced must be redrawn or the programs fine-tuned to generate publication-quality results. Some mechanism for capturing the images produced and for supplying graphical style semantics would be most helpful in incorporating such illustrations in documents. Another interesting topic is style guidelines which apply to the layout and design of illustrations rather than to simple rendering parameters. It can be convenient, for example, to express box dimensions as a function of the size of the text in the box. The size of the text depends on its font style, so there needs to be some way of specifying this relationship between the style and the geometry. In another example, the actual endpoint of an arrow changes when it is pointing to something which is rendered with a thick line than a thin one. Style rules might also include document layout parameters. For example, the style of an illustration could control the layout so that the figure might have a horizontal orientation when the document is typeset with wide columns, a vertical one when narrow columns are used, or a fixed aspect ratio to suit videotape or slides. A dynamic reconfiguration capability would be helpful in making the illustrations look better in the chosen layout. Acknowledgments The sensitivity to graphic arts quality and design issues in this project is due in part to George Roth, a graphic designer who collaborated on a variety of typesetting projects, including the Computing text book [6]. With enthusiasm and insight, he often asked "Why can't you program it to do this?" while offering suggestions as to the appearance of the final result. Both the design and implementation of Tioga document preparation system are critical to our work. Bill Paxton, Michael Plass and Scott McGregor are responsible for Tioga, and we would like to publicly thank them for their contributions to the graphical style project. We also thank John Warnock and Doug Wyatt for the Cedar graphics package and other graphical tools used in our prototype. One of the principal features of Cedar is that it is an integrated environment. In other words, it is very easy to use pieces of the existing system in a new application. Our work uses this feature extensively, so we were able to build our prototype system in rather short time. Therefore, we will simply thank all of the Cedar implementors for their contributions. References [1] anon., Letraset Catalog, Letraset USA. (1980). [2] anon., Graphic Kernel System (GKS) Functional Description, ISO TC97/SC5/WG2 N117 (1982). [3] Baudelaire, Patrick and Stone, Maureen, Techniques for Interactive Raster Graphics, Computer Graphics 14, 3, (1980). [4] Bell, Edward, Personal communication regarding the production of illustrations within Scientific American (1982). [5] Chamberlin, D., King, J., Slutz, D., Todd, S. and Wade, B., JANUS: An interactive System for Document Composition. IBM Systems Journal 21, 3 (1982). [6] Dyck, V.A., Lawson, J.D., Smith, J.A. and Beach, R.J., Computing -- An Introduction to Structured Problem Solving Using PASCAL, Reston (1982). [7] Kernighan, Brian W., PIC - A Language for Typesetting Graphics, Software Practice & Experience 12, 1 (Jan. 1982). [8] Knuth, Donald E., TEX and METAFONT, New Directions in Typesetting, Digital Press (1979). [9] Lampson, Butler W., Pier, Kenneth A., McDaniel, Gene A., Ornstein, Severo M. and Clark, Douglas W., The Dorado: A High-Performance Personal Computer, Three Papers, CSL-81-1, Xerox PARC (January 1981). [10] Lipke, Daniel, Evans, Steven R., Newlin, John K., Weissman, Robert L., Star Graphics: An Object-Oriented Implementation, Computer Graphics 16, 3 (1982). [11] Lesk, Mike E., Typesetting Documents on UNIX and GCOS: Using the -ms Macros with Troff and Nroff, Unix Programmer's Manual 2A, 7th ed., Bell Laboratories (1979). [12] Meyerowitz, Norman and van Dam, Andries, Interactive Editing Systems, Parts I and II, ACM Computing Surveys, 14, 3 (1982). [13] Mitchell, James G., Maybury, William and Sweet, Richard, Mesa Language Manual, CSL-79-3, Xerox PARC (April 1979). [14] Paxton, Bill, The State of Cedar, Xerox PARC videotape, V-163 (1982). [15] Reid, Brian K., A High-Level Approach to Computer Document Formatting, ACM Symposium on Principles of Programming Languages (Jan. 1980). [16] Ruegg, Ruedi and Frohlich, Godi, Basic Typography, ABC Verlag Zurich (1978). [17] Smith, David Canfield, Irby, Charles, Kimball, Ralph and Verplank, Bill, Designing the Star User Interface, Byte (Apr. 1982). [18] Van Wyck, Christopher J., IDEAL User's Manual, Computing Science Technical Report No. 103, Bell Laboratories (1982). [19] Waltz, David, Artificial Intelligence, Scientific American 247, 4 (1982). [20] Warnock, John, Personal communication regarding the mapping of prototype rectangular grid designs on to curve paths (1982). [21] Warnock, John and Wyatt, Douglas K., A Device Independent Graphics Imaging Model for Use with Raster Devices, Computer Graphics 16, 3 (1982). GraphicalStylePaper.tioga Copyright c 1983, 1985, 1986 by Xerox Corporation. All rights reserved. Rick Beach, May 23, 1986 11:05:12 pm PDT Rick Beach, January 2, 1987 3:45:59 pm PST [Artwork node; type 'ArtworkInterpress on' to command tool] [Artwork node; type 'ArtworkInterpress on' to command tool] [Artwork node; type 'ArtworkInterpress on' to command tool] [Artwork node; type 'ArtworkInterpress on' to command tool] [Artwork node; type 'ArtworkInterpress on' to command tool] [Artwork node; type 'ArtworkInterpress on' to command tool] [Artwork node; type 'ArtworkInterpress on' to command tool] [Artwork node; type 'ArtworkInterpress on' to command tool] [Artwork node; type 'ArtworkInterpress on' to command tool] 226 firstFolio"docgraphicslucida" styleMark lastEditedIcode lastEdited m=HK lastEdited(K lastEdited*IunleadedcenterVersoHeadersLcenterRectoHeaderLcenterVersoFooter""LcenterRectoFooterL ArtworkClassRuleArtworkRule footSeparatorItitle2I pagebreakM2Iauthors i%EIabstractb e#1bhead1 IbodyRRRNz eRRaLRuleRuleInserttopIcenterG97.71943 mm topLeading 97.71943 mm topIndent 1.411111 mm bottomLeading Bounds:0.0 mm xmin 0.0 mm ymin 144.2861 mm xmax 94.89721 mm ymax  Interpress InterpressInterpress/Xerox/3.0 fjkjWB9"5j` {xjXerox PressFontsTimesRoman-brr$dContentXerox PressFontsTimesRoman-brrޠb5TitleXerox PressFontsTimesRoman-mrrޠ!pb:main!p`ssubtitle]Heading!p\1st#a\level!p[(2nd#[(level!pYe3rd#Yelevel!pW4th#WlevelUText!pTnormal!pU quotations!pRV footnotes!pPcaptionsNҊTables!pNcaptionsI Numbering!pIfolios!pG illustrations!pE footnotesXerox PressFontsTimesRoman-brr$%jH ParametersXerox PressFontsTimesRoman-brrޠ)(j{TypefaceXerox PressFontsTimesRoman-mrrޠ)(c1.+\c2.-c3./j{Typesize/c1.1c2.4.j{ Type-weight4.dlight6ccmedium8cbold:c semi-bold=c extra-bold?4jxSlope?4dregularAicitalicCj{LeadingCcsolidEdpointsHj{ LetteringHdall-capsJ;c all-lowerLod initial-capNj^ColorNcblackS j^ Column-widthS dpicaWuj{Type-of-columnUAd justifiedWud unjustifiedYccentred[d flush-right^jbIndent^dpointsccs_ c!_aڙa^aڏ!_!_`_^`!_^S^7^^S!_\\s^\!_!_Z̙Z^Z̏!_!_YX^Y!_WEW)^WE!_UUe^U!_!_SS^S!_!_QQޏ^Q!_P7P^P7!_NsNW^Ns!_!_LL^L!_JJЏ^J!_I(I ^I(!_EEw_ E!_GeGI^Ge!_'s'Ew's_ s^ÎEw_ s* h)E* h,Bh,E,Bh.vs .SE.vs 0h0E0h2s 2E2ߎs 5h4E5h7Hh7%E7Hh9|h9YE9|h;h;E;h=s =ŽE=s @h?E@hBNs B+EBNs DhD_EDhFs FEFs HhHȎEHhMTs M1EMTs OhOeEOhK hJEK hQs QEQs ShSΎEShV&s VEV&s X[hX7EX[hZhZlEZh\s \E\Îs kkgtopn==IcaptiontopLRuleRuletopR RLRuleRuleT4 in topLeading 4 in topIndentTLRuleRuleNhead2&R-! 'RRR R &R NLRuleRuleS,Interpress/Xerox/3.0 fjkjWB<2 WBrjxj$ZJ$ZUZ@$ZJ$ZU$\$\$kR$kG$[$[$ZJ$ZUZ@$[$[$k=kR$\$\$ZU$Z@$ZJ$[$[$kG$k=$[$[$Z@$ [#[Z$ [#[E[E[AW[An[F[F[$ [#[ZEZEZAWZ[E[E[#[#Z$ [F[F[An[AWZEZEZ#Z&_v&_&_v&_^&_v&_H9J)c)cJ]Hp&_u&_&_vGJ9`)c塒)cJH6&_&_v&_^HJ)c͡)cJ9]G&_u&_^&_vHpJ`)c塒)c͗JH&_^)c)c)c)c͗)c)c+^{i?3&i䡒3Ei͗^ Tf)c塒)c)cPEdSM,fޡ,fSfP6)c,f,fߗ\A 0 Y3i͡3&ic1i\hb,f)c)c͗+^{i3&i3i͗^! T,f)c塒)c͙)cPdT,fޡ,fǗSeP)c̡,fǙ,fߗ\ 0 Y3Di͡3&ic1iQ\h3,fȡ3Ei͙3&i3i͗3&i3Ei͙3&is2~z [>[)[)[[[<[<[Z>Z>Z)Z[>[>[<[Z>Za)=aP)a?P LR,Ye,eQOW|)>aO)a?)alPSB,eۡ,YeRP I)a>,eڙ,Yf,ee,Ye,eڙ,Yf.{ =fkJ5k5k×gy]h,eۡ,Yf,e. Nc_4zk4kd.J ,Zf4k4zkokp5kߡ5kqk5k4k,ee.8 bek5kkߏe[h,e,e,Ye.{ /fj5k5ke%[hl,e,Ye,eڗWf6--of졒-Ef,feW<,Ye-Ef-of_ 2k45ká5k2W4_G *-Ef5kÙ5k5kߗk5k5kÙ5k{S?Ojv?zjI<95ká5k5kߗ{ ? je?Pjv[j?Pj? j-gjL;k35k5k×|X?yjI?Pj 3@?zjH?Pjv? jd@ Ah顒B(h @a?Pju? jdj-@D Ahh @? jd? j-?Pj@a B(hAh @D? j-?Pj?zjI@> 5BRhΡB(h @a?PjV,G\eڏ5k×\,G5\kÏ?=jI\5Ž,G\eڏ?=jI\,GXerox PressFonts Helvetica-brrG&l`yB[ŠxAff(x)+[Ya>[b2Z(a+b)/2&Y Trapezoidal0Y Rule5OY for8gY n=1Interpress/Xerox/3.0 fjkjWB9栢 WBrjxj$Ar$A|Ag$Ar$A|$C/$C/$Ry$Ro$C%$C%$Ar$A|Ag$C$C$RdRy$C/$C/$A|$Ag$Ar$C%$C%$Ro$Rd$C$C$Ag$ B/#B9B$$ B/#B9EB9EB9AWB9AnB/FB/FB/$ B/#B9B$EB$EB$AWB$B9EB9EB9#B9#B$$ B/FB/FB/AnB/AWB$EB$EB$#B$&F&FF&F&FGJ{)K)K JHCf&F&FFGHJ{)K)KJ~H&F&F&FHCfJ)K )KJ~HE&F)K )KK)K )K+j^fPY3P35P^ TM)K )KK++^fPD3P顒P^f-TqM)K)K)K RL-]N/O/OXqRL)K/O/O0c2 m35P3PgOcD/Oꡒ35P3PP35P3Psŀ~eI?qN ?N"=NB9>B9)B9)B/B/B/B$>B$)B$B9>B9>B9B$>B$ Trapezoidal+>Rule.>for1>n=14`>and7>n=2.)B/)B9B$)B/)B9)))Aڡ)AЗ)B%)B%)B/)B9B$)p)p)AšAڏ)B/)B/)B9)B$)B/)))AС)AƗ)B)B)B%35B/3B9B$35B/3B9333Aڡ35AЗ35B%35B%35B/3B9B$3p3p3AšAڏ3B/3B/3B93B$35B/353535AС3AƗ3B3B3B%B9>B9)B9)B/B/B/B$>B$)B$B9>B9>B9B$>B$OVQ experimentDVQwithFVQtheseIaVQideasL,VQ.LVQ.MVQ.RʊsystemBrRʊwasDRʊ developedIRʊ.JRʊ.KOOv>O@OOv?O2\2K2͎\2L(K6L(27K GeometricAAZ>A@AAZ?A+b4*ώ=ӏ+b4*> =ӏ/> *ώ0v= Conclusions0v?`head13?` StyleRule/>ߙ/[= />ߏ/[=*= D<=*/[D= D<>ߏD= D<>Ù>ߏ/[>ÏD<2=*2:L2͎=*2::L2:2::L6:28P::L8 :9k::L9$::::L:>:Xerox PressFontsTimesRoman-mrr'cDocument+b4*ώ6ŏ+b4*66ŏ/6*ώ166ŏ1m6266ŏ26366ŏ36Xerox PressFonts Helvetica-mrr؊ SIGGRAPH'833؊1E؊BeachJ'؊&K؊Stone/GraphicalV؊Stylekkkg Interpress80.0 mm xmin 0.0 mm ymin 106.5389 mm xmax 120.65 mm ymax G123.4722 mm topLeading 123.4722 mm topIndent 1.411111 mm bottomLeading top==TtopLRuleRuletopLRuleRule144 pt bigger keepSInterpress/Xerox/3.0 fjkjWBKE WBrjxjXerox PressFonts Laurel-mrrqƊStructureFig2.tiogaXerox PressFontsTimesRoman-mrr5dposition:-daxis5f5 ArtworkClassOf5 ArtworkNode5e˙4ߎc5eˏ4dcEVd4ߎE3cEVeˏE3cEVeeˏ4ߎeEV1g1md1g1mdd5d1m76d6a876d6apa8:ap6;|adraw>>ay?5a-axis;|bŊ ArtworkPath,BFbŊaxisD{bŊ StyleRule:bD:b`r:bD:b``rJَ`:bJ`rJَbDJ`rJb(bD:bb(JَXerox PressFontsTimesRoman-mrr"hl2 Trapezoidal)l2Rule-Ol2Figure/[hposition3hfigure/[i ArtworkClass6.i=7i ArtworkNode.diR.Ag.diR.Agg>g.A>g>iR>g>i6iR.Ai6>)k$)hF)k$)hhF.dh)5^4ߎ\5^4]\EV]4ߎE3\EV^E3\EV^^4ߎ^EV76]6Z*76]6ZbZ*:Zb6;|Y܊draw>>Y܊x-axis:[6:bYd:[6:bYYdJَY:bJYdJَ[6JYdJ[[6:b[Jَ5_& ArtworkClass<_&=>O_& ArtworkNode5]position:-]axis;|[ ArtworkPath,BF[axisD{[ StyleRule5W4ߎUݏ5W4UUݏEVU4ߎE3UݙEVWE3UݏEVWW4ߎWEV76U6S76U6STS:ST6;|RΊdraw>>RΊcurve:T(:bRV:T(:bRrRVJَRr:bJRVJَT(JRVJT T(:bT Jَ5X ArtworkClassOX ArtworkNode5Vrposition:-Vrcurve;|T ArtworkPath,BFTcurveEGT StyleRule1g1m]1g1m]]5]1m1g1mV1g1mVۙV5Vۏ1m5P4ߎNϏ5P4NNϏEVN4ߎE3NϙEVPE3NϏEVPP4ߎPEV76N6L 76N6LFL :LF6;|Kdraw>>Karea:M:bKH:M:bKdKHJَKd:bJKHJَMJKHJLM:bLJَ5Q ArtworkClassOQ ArtworkNode5Odposition:-Odarea;|M ArtworkPath,BFMarea1E4M StyleRule1g1mO1g1mO͙O5O͏1m6JJJ5ՎJ76JJJ6J8PJJJ8 J5Gϙ4ߎE5GϏ4FEEVF4ߎE3EEVGϏE3EEVGGϏ4ߎGEV76F6C;76F6CtC;:Ct6;|C)y5H8 ArtworkClassOH8 ArtworkNode5Fposition:-Flabel;|D̊ rightCaptionAD̊ StyleRule1g1mJJ1g1mJJJ5J1m1g1mFÏ1g1mFFÏ5F1m:DH:bBv:DH:bBBv>aB:b>=Bv>aDH>=Bv>aD+DH:bD+>a5@4ߎ>5@4? >EV? 4ߎE3>EV@E3>EV@@4ߎ@EV76? 6<-76? 6OA* ArtworkNode5?position:-?label;|=centeredCaptionC= StyleRule:=9:b;h:=9:b;;h>a;:b>=;h>a=9>=;h>a==9:b=>a594ߎ759477EV74ߎE37EV9E37EV994ߎ9EV7676576765W5:5W6;|4f(x)5: ArtworkClass<:=>O: ArtworkNode58sposition:-8slabel;|6 leftCaptionA>6 StyleRule:6+:b4Y:6+:b4v4Y>a4v:b>=4Y>a6+>=4Y>a66+:b6>a1g1m?1g1m??5?1m1g1m81g1m8ߙ858ߏ1m633[5Վ37633[638P33[8 31g1m3[1g1m33[531mXerox PressFonts Helvetica-mrr؊ SIGGRAPH'833؊1E؊BeachJ'؊&K؊Stone/GraphicalV؊Stylekkkg Interpress:0.0 mm xmin 0.0 mm ymin 106.1861 mm xmax 150.6361 mm ymax G153.4583 mm topLeading 153.4583 mm topIndent 1.411111 mm bottomLeading ==TLRuleRuleRR R RR R Iitem 2V #/V #RwV )CV .YVKRR   V lwV 4?NLRuleRuletop13 pt topLeading 3 pt topIndent 3 pt bottomLeading stylefigure22 pt smaller topLeading 1 pt smaller bottomLeadingtop((W22 pt smaller topLeading 1 pt smaller bottomLeadingtop 22 pt smaller topLeading 1 pt smaller bottomLeadingtop##W22 pt smaller topLeading 1 pt smaller bottomLeadingtop22 pt smaller topLeading 1 pt smaller bottomLeadingtop%%W22 pt smaller topLeading 1 pt smaller bottomLeadingtopW22 pt smaller topLeading 1 pt smaller bottomLeadingtop22 pt smaller topLeading 1 pt smaller bottomLeadingtop$$W22 pt smaller topLeading 1 pt smaller bottomLeadingtopW22 pt smaller topLeading 1 pt smaller bottomLeadingtop22 pt smaller topLeading 1 pt smaller bottomLeadingtop%%W22 pt smaller topLeading 1 pt smaller bottomLeadingtopW22 pt smaller topLeading 1 pt smaller bottomLeadingtop22 pt smaller topLeading 1 pt smaller bottomLeadingtop%%W22 pt smaller topLeading 1 pt smaller bottomLeadingtop??W22 pt smaller topLeading 1 pt smaller bottomLeadingtopW22 pt smaller topLeading 1 pt smaller bottomLeadingtopW22 pt smaller topLeading 1 pt smaller bottomLeadingtop22 pt smaller topLeading 1 pt smaller bottomLeadingtop%%W22 pt smaller topLeading 1 pt smaller bottomLeadingtopW22 pt smaller topLeading 1 pt smaller bottomLeadingtop22 pt smaller topLeading 1 pt smaller bottomLeadingtop&&W22 pt smaller topLeading 1 pt smaller bottomLeadingtopW22 pt smaller topLeading 1 pt smaller bottomLeadingtopTtopLRuleRuletop13 pt topLeading 3 pt topIndent 3 pt bottomLeadingV bnV7F RIexampleR 9  C 4RYI hungoveritem  Y JY  AY # 9Y # 8Y 5@Y 7CY3BRY 2;YY  ?Y    [Y ' bY )Y *Y,Y %Y:IY 7CR 24 pt bigger keepRR< Rw NLRuleRuletopI styletable(8 pt size 9.5 pt leading 2.5 in tabStopstop Ttop1 pt smaller leadingLRuleRuletopN Rhead3 RY /YPY4BY6 VY . dY=MY3EY+@LRuleRuletopSaInterpress/Xerox/3.0 fjkjWBΡ>FBWBrjxjLݙL"Lݏ!L"R`!L"RDR`RD"R`LÎR`@XeroxResearch RGBLinear.O.>N.O.>N[=N[=N,1Pp,uQ\\.O.>N.O\ P \ P ,uQ,1Pp[<[<.>N,uQ,1Pp,uQ,1Pp,1,,1,,1O,uP՗,u,u,uQ,1Pp,uQ,u,u,uPա,1O,1,,1,,1Pp,uPՙ,1O,uPՙ,1OT)OT)O'O'TP՗+P+P,tPա,1O,uP՗TPTP'UPա'O+O+O,1O'TPՙ'O'TPՙ'OFF& Pp&NQFF'TPա'O'TP՗FF&NQ& PpFF'O&NQ& Pp&NQ& PpB8PpB8Pp"Pp"QCQCQ&NQ& Pp&NQCQCQ"Q"PpB7PpB7Pp& Pp"Q"Pp"Q"Pp9PC9PC$N$O:gż:gż"Q"Pp"Q:fQ:fQ$O$N99"Pp$O$N$O$N>N>N"L衒"N0?Rs?Rs$O$N$O?SO?SO"N/"L>>$N"N0"L"N0"L:L:L& L顒&NN0:N0:N0"N0"L"N0:N0:N0&NN0& L:L:L"L顒&NN0& L&NN0& LCC'Mˡ'TODWDW&NN0& L&NN0DYDY'TO'M˗CC& L顒'TO'M˗'TO'M˗GMGM,1Mˡ,uO'O'O'UO'M˙'TOHOHO,tO,1M˗'M'M'Mˡ,uO,1M˗,uO,1M˗,1=,1=,1L顒,uN0,u,u,uO,1M˙,uO,u,u,uN0,1L,1=,1=,1Mˡ,uN0,1L,uN0,1LVPMVPM.>N.OW6W6,uN/,1L,uN0WN]WN].O.>NVQaVQa,1L衒.O,uQPՏ'T&NQ"$O"N0&N'TO,uN0.O.O.P.pPO.Oٗ.O.P\P;\P;,|Qҡ,Q\J\J.O.P.pP[P1[P1,cQȡ,|Qҗ\\.P.pPO[P[P,cQQȏ[[.pP.pO.Oٗ\P\P,|Q,cQ[O[O.pO⡒.Oٙ.O\KP \KP ,Q,|Q\1\1.Oء,Q,|Qҗ,cQȗQ,|Q,Q,|Qҗ,|R,|R,|P,P՗,,,Q,|Qҙ,cQȗ,c4,c4,cP桒,|P,|R,|R,|Qҡ,cQșQ,c,c,cPġP,c4,c4,cQȡ,cQ,|Q,|Ű,|Ű,|P,cPŗ,c,c,cQ,|Q,Q,,,Pա,|P,|Ű,|Ű,|Q,Pՙ,|P,cPPŏ,|P,Pՙ,|PU PU P'\P'jP՗,P,P,Pա,|P,cPTPTP'CP桒'[P+P+P,{P,cPPŏTPTP'CPšP+P+P,cP桒,cPř,|PU PU P'\P'CPŗ+P+P,cPš,|P,P՗U7PU7P'kPա'[P+P+P,{P'jPՙ'[P'CPPŏ'[P'jPՙ'[PF4F4&UQҡ&dQGG'jPա'[P'CPFF&=Qȡ&UQҗF4F4'[P'CPPŏFóFó&=Q&QPՏ87Q46O4N078O>N0@&O@ Qҡ>/Q66@Qȡ> Qҗ  @-P@POPP>QQȏ@P@O@-Oٗ P P> Q>QOO@O⡒@-Oٙ@/Q> Q 1 1@-Oء>/Q> Qҗ>QȗQ> Q>/Q> Qҗ> R> R> P>/P՗>/>/>/Q> Qҙ>Qȗ>4>4>P桒> P> R> R> Qҡ>QșQ>>>PġP>4>4>Qȡ>Q> Q> Ű> Ű> P>Pŗ>>>Q> Q>/Q>/>/>/Pա> P> Ű> Ű> Q>/Pՙ> P>PPŏ> P>/Pՙ> PPP9P9P՗=P=P>/Pա> P>PPP8P桒9P=P=P> P>PPŏPP8Pš8P=P=P>P桒>Př> PPP9P8Pŗ=P=P>Pš> P>/P՗#P#P9Pա9P=P=P> P9Pՙ9P8PPŏ9P9Pՙ9P{4{47Qҡ8 Q||9Pա9P8P{{7Qȡ7Qҗ{4{48P8PPŏ{ó{ó7QQȏ{{8P桒8Př9P{Ò{Ò7Q7Q{ð{ð8Pġ9P9P՗{{8 Q7Q{Ò{Ò8P8 Q7Qҗ7QȗQ7Q8 Q7QҗxQxQ4Qҡ4Qx4Qx4Q8 Q7Qҙ7QȗwQwQ4vQȡ4QҗxQxQ7Qҡ7QșQwQwQ4vQQȏwQwQ7Qȡ7Q7QxQxQ4Q4vQwQwQ7Q7Q8 Qx5Qx5Q4Q4QxQxQ7Q4Q4Qҗ4vQȗQ4Q4Q4QҗogQogQ6P6Oożoż4Q4Qҙ4vQȗoQoQ6P6Poh oh 4Qҡ4vQșQoQyoQy6O⡒Po o 4vQȡ4vQ4QogQoogQo6Oء6Oo Ōo Ō4vQ4Q4QoQoQ6O6Oٗohnohn4Q6O6P6PO6Oٗ6O6PtTOtTO4NJ4N0tsts6O6P6Pt Ot O4vN@4NKtStS6P6POt Ot O4vNNAt t 6P6O6OٗtTOtTO4N4vNt @t @6O㡒6Oٙ6OtOtO4N/4NtS"tS"6O١4N04NK4vNAN4N4N04NKoNKoNK7NK8 N0pN0pN04N04NK4vNAoNAoNA7NA7NKoNKoNK4NK4vNANoNoN7NNAoNAoNA4vNA4vN4NoNoN7N7NoNoN4vN4N4N0pN0pN08 N07NoNoN4N8 N07NK7NAN7N8 N07NKyZEyZE8O-9Oyy8 N07NK7NAy'y'8O#9O-y[Ey[E7NK7NANyy8OO"y$y$7N@7N7NyZyZ8N8Oyy7N7N8 N0yy9O9Ny[y[7N9O9O-8O"O9N9O9O-}O-}O-> O->/O9O9O9O9O-8O"}_O"}_O">O"> O-9O-9O-9O-8O"O}_O}_O>O>O"9kO"9kO"8O"8O9N}N}N> N>O9kO9kO8O9N9O}O}O>/O> N9N9N9N>/O> O->O"O> N>/O> O-> c> c> NK>/N0>/>/>/O> O->O">B>B>N@> NK> c> c> O->O"O>>>NNA>E>E>O#>O> N> > > N>N>>>O> N>/O>/>/>/N0> N> > > N>/N0> NK>NAN> N>/N0> NKNxNx@-P@/N/> NK>NANnNn@P@-P> NJ>NANNLNL@O㡒Pii>N@>N> NNBNB@-O١@O>N> N>/N0JN]JN]@ N@LݙLE1Lݏ@ՎELE1R`ELE1RDR`@ՎRDE1@R`@ՎL@R`kkkg Interpress:0.0 mm xmin 0.0 mm ymin 104.0694 mm xmax 16.22778 mm ymax A19.05 mm topLeading 19.05 mm topIndent 1.411111 mm bottomLeading top==TtopLRuleRuletopR   RRLRuleRuletop144 pt bigger keepSG42.33333 mm topLeading 42.33333 mm topIndent 1.411111 mm bottomLeading :0.0 mm xmin 0.0 mm ymin 157.6916 mm xmax 39.51111 mm ymax  InterpressAInterpress/Xerox/3.0 fjkjWB_{&7WBrjxj,)6H,6l++6H+6#,,)6H,6l,)6H,6l+,+6l+6H+6l+6H+6#+6H+6#,+,6#,)6H,6#)8 )n80)D)/8 )D7)n)8 )n80)8 )n80)D)n)D80)/8 )D80)/8 )D7)/8 )D7)n)D)n7)8 )n7)7*)n7N)D)/7*)D7)n)7*)n7N)7*)n7N)D)n)D7N)/7*)D7N)/7*)D7)/7*)D7)n)D)n7)7*)n7"7*"7N""7*"7"ю"7*"7N"7*"7N""ю"7N"7*"7N"7*"7"7*"7"ю""7"7*"7!8 !~80!T!?8 !T7!~!8 !~80!8 !~80!T!~!T80!?8 !T80!?8 !T7!?8 !T7!~!T!~7!8 !~7+8 808 7+8 80+8 80808 808 78 77+8 76H6l{6H6#6H6l6H6l6l{6H6l{6H6#{6H6#6#6H6#+4444`+44+4444444`44`4`+44`!4!~4!T!?4!T4`!~!4!~4!4!~4!T!~!T4!?4!T4!?4!T4`!?4!T4`!~!T!~4`!4!~4`"5f"5""5f"5A"ю"5f"5"5f"5""ю"5"5f"5"5f"5A"5f"5A"ю""5A"5f"5A)5f)n5)D)/5f)D5A)n)5f)n5)5f)n5)D)n)D5)/5f)D5)/5f)D5A)/5f)D5A)n)D)n5A)5f)n5A)4)n4)D)/4)D4`)n)4)n4)4)n4)D)n)D4)/4)D4)/4)D4`)/4)D4`)n)D)n4`)4)n4`)83)8 83 88؎3883ώ8838 8 }3 8!t8!_3!t8"V8"@3"V8#78#"3#78$8$3$8$8$3$8%8%Ȏ3%ݎ8&8&3&8'8'3'8(8(m3(8)d8)O3)d8*F8*03*F8+'8+3+'8, 8+3, 8,8,֎3,888,888,8747,746R6=,6R5q5[,5q44z,433,3, 6H+6V+6H+6:, 6H+6VTR6TR6)Z8)g8 Tzt~Tzt~, 6G+6V+6HT(6uT(6u)L8 )Y8TPtTPt+6U+6H+6:TR6gTR6g)Z7)K8 T&t~T&t~+6G+6:, 6HT|6uT|6u)h8 )Y7TPtTTPtT+69)g8 )Y8)K8 )Y7)g8 )Y8)Yy')Yy')Y77)g7*)gy)gy)g8 )Y8)K8 )Kx)Kx)K7))Y78)Yy*)Yy*)Y8)K8 )Y7)Yx)Yx)Y7)K7*)Ky)Ky)K8 )Y7)g8 )gx)gx)g7))Y7)Yx)Yx)Y7)g7*)Y78)K7*)Y7)g7*)Y78K/78K/78"78"7*(7*(7*)g7*)Y78)K7*K7*K7*"7*"78(78(78)Y78)K7*)Y7K/7K/7"7"7*(7*(7*)K7*)Y7)g7*KY7*KY7*"7*"7(7(7)Y7"7*"78"7*"7"7*"78"w "w !i8!w8 9v9v"7)"78"7*"v"v![8 !i88w 8w "77"7*"7"v"v!i7![8 8v8v"7)"7"7*"v"v!w8 !i78v8v"7!w8 !i8![8 !i7!w8 !i8 8 888 !8 !8 !x8 !i8![8 8 8 8 8 8 8!i8![8 !i7 7 778 8 8 ![8 !i7!w8 !8 !8 8 7 7 7!i78 88 78 8(7(76U6H)x)x8 88 (7(76G6V(x(x88 7(7(7696H(x(x8 78 )7)76G6:(x(x76H6V6H6:6H6V/G6)/G6)44/rso/rso6H6V6H/6/644/Es/Es6V6H6:/G6 /G6 4v4/so/so6H6:6H/q6/q644v/EsE/EsE6:4444v44q4q4!i4!w444444c4c4![4!i4q4q4444vq4vq4v!i4v![4c4c444v444!x4!i4vq4vq4v4v!w4!i4![4!i4v!w4!i4!o!o"5t"5f5n5n!w4!i4![4!}n!}n"5f"5t5o5o!i4![4!i4v!n!n"5X"5f5n5n![4!i4v!w4!n!n"5f"5X5n5n!i4v"5f"5t"5f"5X"5f"5t;P5t;P5t)Y5t)g5f#s5f#s5f"5f"5t"5f;&5f;&5f)K5f)Y5t#e5t#e5t"5t"5f"5X;P5X;P5X)Y5X)K5f#W5f#W5f"5f"5X"5f;z5f;z5f)g5f)Y5X#e5X#e5X"5X)g5f)Y5t)K5f)Y5X)g5f)Y5t)Yq8)Yq8)Y4)g4)gq)gq)g5f)Y5t)K5f)Kq)Kq)K4)Y4)Yq8)Yq8)Y5t)K5f)Y5X)Yp)Yp)Y4v)K4)Kq)Kq)K5f)Y5X)g5f)gq)gq)g4)Y4v)Yp)Yp)Y5X)g4)Y4)K4)Y4v)g4)Y4M4M4+6V, 6HN"o5N"o5)h4)Y4)K4M4M4+6H+6VMo_Mo_)Z4)K4)Y4vM4M4+6:+6HMo5Mo5)L4)Y4v)g4N 4N 4, 6H+6:Mo Mo )Z4v161^1D1ȗ11=1^1D11Q21Ȏ111Q22%1ώ121Q21e22121e2{1y2ח2m22{1y21y2љ13'2Î2m2ї.2/@3i/.213 342ю23 13-13v323-/@3b/M3}/؎/3b13o133:33o/M3v/30p/3v13133o3:3131333o3/3/30ӎ0p3/330ڎ03/3/4100313143̎331314J333/4/4/1104/4)/4J114)/4C/4C04]334C04W0B4434W0B40i4Ǘ4<440i4044P4<404ۙ05144P4ۗ05+Q05+15Y445+15R1055R45R105z1D555R5z1D51X55551X51y56&551y515З66&515ə15ݗ765ɗ15֙157w75֗15157͎7w5151577515159751516;951516 <;51616<<616 16=<6 162 6,==62 6&2+6@>=6&2+6:286N>I>6:286G26[>>I6G26T26[>>6T26T36h>Ύ>6T36a36o>>6a36h36u>>6h36o36|? >6o36u4W6?? 6u4W64d6??64d646˗??646ř46җ@ ?6ŗ46˙5Y6@h@ 6˗5Y65z7@u@h65z657@@u657 6T7.@؎@7 6T7(675@@7(67.67<@@7.6757P7PA@757P7I77VA(A7I77P97cA<7AA7><7>P7A͎A7>P7>7͗AA7>7Ǚ?7BA7Ǘ?7?>8B7B7?>7?z8BQB77?z8?8>BBQ8Cg8C28_CCn8?87?8KBB87?8D@@8sBŽB8DC28XC8yCC8X@@8l@8BB8lC8sB8CC8s@8@8CC8@8A8ܗCĎC8A8cA8ܙA]9CގC8ܗA]9A9@CC9A99A9aCC99A9ZB9DC9ZB9B9D D9B9A9D D 9A9A:4D.D 9A:.A:HD4D.:.A:BBK:\D;D4:BBK:UBr:iDAD;:UBr:cB:wDA:cB:pB:DHDA:pB:C:ڗD\DH:C:әDc;)DiD\:ӗkkkgtop==TtopLRuleRuletopLRuleRulebottomS|Interpress/Xerox/3.0 fjkjWB1AƠWBrjxj!9%"@ޏ&A$@=W*lD>.,;>D͎=b=M,;=b͎<I11=0>I0H>x1e1>I0H>x0p>101e>x0p>0? 10>0<0<00<0<0.<0}0<1<ʙ0= 1D1<ʗ0.<0=0\0}<0= 0=-0ڎ1= 1= 1=1J1D= 1=1J=[11J=0=/{=v/؎0\=0=-0V=U00=-1=N0=|1#1=N0V=U0=0\0=U1J=[1r=11=[/{=v/=/Ď/=v0=|0=161#=|/=/=ٗ0/=1r=1=11=0=0=00=0=1=1J16=0=0=0O0\=0=0B=ٗ0}0O=0=0=00=1=1=11=0=0=0ӎ0=1=1)=̗1e1J=0=0=̗00=1)=̙1X>11e=̗0=̙0=ٗ00=̗/=ٙ/>050=ٗ0=ٙ0=10=ٗ0B=ٙ0V=00}=ٗ1=1=11=0=0=11=1=1>1=0V=0p>00=0=0>11=1X>1Q>1>0>0>01>1Q>1>P1J1>0p>0>(00>/>0 >/0H05>0>(0>W0>(0 >/0V>00H>/1>P0>x1#1J>P0>x0>01#>x0V>0i>00>0i>0>0>1=1>62S1=1>61X>22S>61X>1>Η22>1>Ι0? 3N2>Η0? ?3U3N? 0?1)?f33U?1)?f1?2׎3?f1?1?—2ю2?1?™1@22?—1@2Z@h2@1=1>21=1>1e>x12>2?>(2>d22?>(2>d1>k22>d1>k1>22?>k2?>k2{>2Î2>k1e>x1Q>11>x1Q>0? 11>1>1>12>2{>2>ԗ32>2?>2>22?>1>1X?11>2>ԙ2>ۗ3 3>ԗ2>ۙ2? 3H3 >ۗ2>2>22>2>1?282F>2F>2S>22>2S>2{?2ʎ2>1?1?2%28?2? 3?3U3H? 0? ?11? 3?3 ?$3H3U?0?1?R1Q1?1??2+2%?1X?1?2?12L2+?1X?1?E1Վ1?2{?2?>22?3 ?$3:?83H?$2?12 ?82S2L?12 ?82%?R2t2S?82?>2?K22?>1?E1?m11?E2?K2m?22?K1?R1?_1e1Q?R2%?R2+?Y2m2t?R2+?Y2?f2`2m?Y1?_1Q?11e?_2?f2?z2S2`?f1?m1?z21?m1?z1?2F2S?z1?2?2F?1Q?1y?11?2m?2S?—22?1y?1?ɗ1܎1?2S?™2%@2g2?—1?ə1?21?ɗ1?1@2%2?1@22@G2g@3U?3'?K33U?3'?K2?43?K2?2?4q4?2?2?4Վ4q?2?2Z@h44?2Z@h2@44@h2@2@44@2@3A@4d4@3A@3A<4J4d@3A<46Ap4JA<3U?3A?*3v3U?3A?*2?33v?*3?E3}?s33?E3}?s3v?43?s3v?3A?ɗ3}3?3?3?464?3?3?4P46?3?4?—44P?2?2?—3 3?3?™3?43?—4?™46?З44?—2?™2`@a23 ?—3A?ə34?3i3}?ɗ46?Й4d?4Վ4?З34?2@M3-3i?4d?4x?4Ύ4?4x?4?4Ύ?3??4)4?4?4@4?3?3@4/4)?3@3@33@3@4@&4x4/@3@3}@,33@4@&4@,44x@&3}@,3o@:3ӎ3@,4@,4J@@44@,3o@:3}@@33@:3}@@3@T43@@4J@@4@4P4@@2@M2@T3A3-@M3@T3@[44@T2@T3@n3o3A@T3@[3@n44@[2`@a2Z@h22@a2Z@h2@22@h3@n3@34@n3@n3N@33o@n3@3@33@2@2@32@3U@13U@3@ؗ3@2@2@ė3A3@4@4@ė4C4P@4@ę3A44C@ė2@ę3'@33A@ė3'@3-@33@3-@3}A33@3}A3A(4A3A(4A]4A(4?4@ 5>4?4@ 4@,55>@ 4@,4@M65@,4@M4@a66@M4@a4JA56[6@a4JA546Ap6T6[A546Ap4A6G6TAp4A51AƗ6@6GA51Aƙ5A6:6@AƗ5A6:BA4?4?44?4?4@44?5+@5@&5z5+@5@&5@:5Ў5z@&5@:5@@55@:5@@4@5$5E@@5E@@5s@M6,5@@5s@M5@a66,@M5@a5@n6@a5@n6 @|6|6@n6 @|6|@@|5_@|5Y@5Ў5_@|5Y@5L@6@5@4@4@55$@4@4@5s5z@җ6 @ؙ5AO6&6:@ؗ5>@@55s@5>@58A5Ў5@58A858A5fA5Ɏ5A5fA5A!5ɎA5A!5A55Î5A!4A!4A<5>4A!5A54A<4AO55RA<5AB5AO55AB4AO51Ac55AO5AO45$A4A4A55>A4A5A5֎5A5A5A66 A5A6AA6@a6|@u66@a6|@u@7c6@u6|@@7ڎ7c@6|@@8Q7@6|@6TAc8K8Q@6TAc6:B8D8KAc6:B6B8>8DB6B7B7B*7B08>B>B06@a@h66@a6@h6aA(66@h6@n6@76@n6@@8Q7@6@6@8Q@6@6A67@7@7!@8Q@7!@7@8Q@7@8Q@@7.@ؙ@77.@ؗ7.@7(@87@7(@7(A 7VA 7A8A 6A7A7A8A7A7A88A6A6A66A7(A!7!A(7VA!6aA(6[A56A(7!A(6[A56@A6u6A57!AB>:;Aj9@B>:;BDB>8Q@@88Q@8Q@8KAO8y8@8@,8@,8@9@ԡ9A(9A(9A:A(8A<8A8܎A<9A<8KAO9AV9 A9AV8KAc8>B8s8yAc9nA9nA9A8AΡ8>BhΡ9%B>:BDB>:;@@<8;6@:;@Aw<+<8@:;AwBD<<+Aw;0BD<BKBD:;@_:@@;e:@:@@<8;e@:@@<2<8@:@3:@:@ę;@˗<2@ď;@˙<2@җ@ˏ;@A;;@;Aǡ;A(;A(A;;A(:A<;A<:;AV;AV1Ρ:;AjE;eA;eA;^A;A;A;A;B;;A:AΡ;A;AA:;BB;:iB:;BTΡ;BD;BKBD<8@@<<8@<8@<2@=:<@<2@@ˏ==:@<2@˙@ߏ>C=@˗<2@ߙ<$A>>C@ߗ<$A<BK=>A<BK(=o@<@ؙC>(@ؗ<@ߙ=@>C@ߏ=@=@>C@=@>C@=|A!A5C@ߙ>ǎ>C@ߗ>6A!?K>A>6A!>/AO?Ў?KA!>/AO>(A~@M?AO>(A~>BD?@MA~>BD=B?ݎ?BD=B>dB?֎?B>dB>B?Ɏ?B>B?>Bܗ??B?>Bܙ?C?Bܗ>C@ߙ@>x>C@ߗ>C@>A>P>x@>@>A?>@>A>A5??A>A5>A>>A5>A5?1AI?Ɏ?A5?1AI?RAV??AI?RAV?Aj@?AV?Aj?A~@M@Aj>Ap>A?z>Ap?A~?A@G@MA~?A@A@GA@A@:A@GA>A>A??zA>A>A>A>kB>>A>A>A?$A?$A?mA??A>A=B_>(>PA>AA??$A>A>Aԗ??A?mA?Aڗ??A>Aԙ>A?E?Aԗ?Aڙ?BK?Ž?Aڗ>AA?s?EA>A? B?sA? B?8B?m?sB?8B?1B*?f?mB>kB>dB*>>B?1B*?*B7?_?fB*>dB*B7?>B*?*B7>dB7>xB>?*?B7>xB>>BX?R?_B>?BK?B_??BK>BX?EBy?RBX?B_?fB??B_=B_=B>>(B_=B>B>ǎ>B>B>WB?>B>WB>B?R?B>B>B?f?RB>B?Bϗ??B?Bϙ?B?Bϗ@MA~@3A@ˎ@MA~@3A@AAB@A@A?B>AABA?B>?BB*AB>?B?CAԎB*B?C@C2AAC@C2@uCgAAC2@uCg@CAcACg@CA5CAcC@MA~@GA@@MA~@GA?BD@3@A@A@AڗA@A@Aڙ@AA5AAڗ@A@hB>@@A@AABApA5AABA!BA~ApBA!BApBKA͎A~B@B0@BlAV@B0@hB>@aBX@@B>?BD?B?@3BDAwBKAByBABK@aBX@,B—@a@BX@BlBrA]AVBl@Br@B@ABrABrABBAA]BrAByABB*BByABABBB*B@B@B@@BABBApBAƎABABBBBB@B@BA@B@B@BAAB@B@B—A.ABApBAB—AAB@,B™@&B֗@@aB—AB™ABC%A~AB—@B™@BϗABA.B—@Bϙ@BܗA5ABBϗ@&B֙@:B@@B֗@Bܙ@BA(A5Bܗ@:B@C@@B?B?C@?B@B@CAA(B@C@C AC?C?C@,@C@C @CFAC ?C@C2@n@,CABC%A5C?ApA~C%@C2@C9@u@nC2@C9@aCa@@uC9A5C?ACA&\~ \g$\[ \>$v\%J\L4 \&Q\q \Gy\, N\\s NN