Gargoyle will be an synthetic graphics illustrator in the tradition of Draw, Griffin, Gremlin (U. C. Berkeley) and Unicorn (University of East Anglia) and MacDraw. Our orientation is systems that enable a designer to achieve graphic art quality output using an interactive workstation and a digital printer. Each part of the design will be defined in a device independent manner, typically as an analytic outline. The designer works principally to produce a visual effect on the target device, but the image can also be rendered usefully on a set of devices for proofing, etc. In our systems, design elements consist of line and curve bounded regions. The boundary is a continuous function, such as a line or cubic splines. A region can be colored with either a constant or a sampled color, following the model defined by Interpress. The user thinks of the regions as shapes or objects that can be copied and transformed. The objects overlap opaquely (always?) in a defined order. This approach is in contrast to "painting" systems where the designer works directly with the pixels on the display.

Our current illustrator of this form is Griffin. Griffin supports line and curve bounded areas, a primitive form of graphical style, and one-line captions in a limited number of rotations. Griffin was designed as an Alto Mesa program in 1978 and was carefully crafted to match the imaging model of the printing format Press. Griffin exposed a number of research issues in computer graphics, user interfaces, printing and interactive systems. Among these are the mathematics of "wide lines", high speed incremental refresh, color definition, user interfaces for shape editing including mathematical tranformations, control of a large number of graphical style properties, proper management of shared objects such as fonts and styles, and overall reliability including user friendly fail-safe mechanisms.

Gargoyle will exploit the advances we have made in device independent graphics, printing and computing environments. Gargoyle will use the full power of the Imager, Interpress and Cedar.

Like Griffin, Gargoyle will be a single page illustrator. The size of the page is not limited except, of course, when you actually print it. The point is, we are not investigating issues of pagination or large document management except in the use of graphical style. In this project we will focus on making a single, complex page.

If you take Griffin as a starting point, Gargoyle will advance from it in several different areas. First, the objects themselves will be more complex and the editing model will be richer. Gargoyle will support contours with holes, where each trajectory in the contour can contain different types of curves (conics and cubics with a range of continuity constraints). We intend to allow users to break contours at (nearly) arbitrary points and insert pieces of other contours. We intend to have special tools for creating objects with symmetry (and other structure). Eventually we would like to include the full set of Boolean point set operations on contours (e.g. union, intersection, and difference) for constructing shapes. We would like also to explore the use of curve-fitting algorithms [Plass and Stone] to explore a combined painting and construction model for defining shapes. All in all, Gargoyle will be a test-bed for shape editing. For text editing, Gargoyle will attempt to leverage off of Tioga as much as possible. Actual integration with Tioga will have to be driven by Tioga development. As a minimum position, Gargoyle will interactively "paste-up" text from the Tioga formatter. Placement points for text will integrate with the shape editing point control mechanisms. Gargoyle style will support Tioga-like style for text.

Second, the relationship between the objects in the scene will be more complex. There will be multi-level clustering, special tools for defining symmetry (and other structure), and (later) a simple constraint solver. We will provide a mechanism for explicily defining objects that touch. Eventually, we will include user defined "grids" and other alignment mechanisms. Gargoyle will employ an "intelligent dragging" mechanism for object placement which shows symmetry and alignment in real-time.

Third, Gargoyle will support graphical style. Graphical style describes a set of named formulas for rendering illustrations from their raw "geometry". Work with Griffin, Tioga and TiogaArtwork convince us that there is merit (and many hard problems) in trying to separate the basic "skeleton" of the figure from such issues as font, color and line weight. This separation provides a mechanism for ensuring consistancy across a number of related illustrations, gives a way to codify some esthetic decisions, such as the relationship between font, line weight and arrowheads, in a manner that can be used by the esthetically naive, and leads us to consider defining "meta-illustrations" that can be rendered for significantly different viewing environments simply by changing style. An example of this last point is the illustrations for a conference paper and the acompanying talk. The "style" for slides and the "style" for the procedings are very different, but the same illustration needs to appear in both. We can imagine designing a meta-illustration that is rendered with two different styles, a bold, multi-colored "slide style" and an elegant, monochrome "procedings style".

Fourth, Gargoyle will be an integrated Cedar program for making illustrations, posters and slides. We hope to make a system that is useful and "feels good" to members of the Cedar community and serves as an example of the kind of application that Cedar makes "easy". We intend to leverage as much as possible off of the Cedar environment, in contrast to Griffin which had to build everything above BitBLT from scratch. We want to make full use of our research on device independent graphics and quality printing to give the user the ability to predict the printed version of their illustration from the displayed one.

Below, we describe Gargoyle in more detail. First, we describe the scene hierarchy as the user will perceive it. With this structure in mind, we detail the desired capabilities and our impressions of how they should be partitioned into operations. Next, we describe a possible user interface. Finally, we define the Gargoyle programmer's interface as it may appear in the Cedar Language.

A Gargoyle scene is (almost) a strict hierarchy. In this section we describe the levels in the hierarchy and define our terms. Proceding from root to leaf, a Gargoyle scene consists of clusters, outlines and captions. Outlines consist of trajectories and trajectories consist of segments. Geometric points for defining segments are specified using control points. Some Gargoyle objects remember symmetry information about their sub-components, to be used by the alignment tools, as noted below.

Segments. Shapes are made from curve segments. A segment is any space-curve with specified endpoints and tangent vectors. Some examples of segments are: a single straight vector, a cubic Bezier segment, a cubic spline, a conic segment or a conic spline. Segments in Gargoyle will be object oriented so that we can separate the representation of these curves from their use in a Gargoyle trajectory. As a practical matter, it should be possible to approximate the segment with an Imager trajectory so it can easily be displayed.

Joint. The point at which one curve segment touches its neighboring segment.

Control points. Each segment has a set of data values which determine its shape. These data values may be represented by x-y points in the plane called control points. For different editing situations the control points have different interpretations. We would like to set the interpretations in a manner similar to Tioga Looks.

For example, to define a segment control points can be interpreted as follows:

Trajectories. A trajectory is an ordered sequence of segments with the constraint that each segment must meet its neighboring segment at a joint. In an open trajectory, the first and last segments have no neighbors. In a closed trajectory, the first and last segment are neighbors.

A trajectory knows (some of the) symmetry groups to which its control points belong.

If we allow arbitrary interpretations assigned to arbitrary sequences of control points, the various possible relationships between control points and joints makes it difficult to enforce continutity in an intuitive manner. Between interpolatory segments the relationship is clear; adjacent segments share a control point. If one of the segments is approximating, then the control point at the joint will automatically control the placement of both segments, even though this point may not normally be explicit for the non-interpolating segment (imaging a Bezier and B-Spline segment). This could cause a problem by overconstraining the solution for the non-interpolating segment. For adjecent non-interpolating segments, the problem is even more complex. Possible solutions: Don't allow arbitrary combinations. Insert extra segments to interpolate between the ends. Sacrifice locality.

Outlines. An outline is a set of trajectories which define an object with holes. A single trajectory behaves also as an outline. The outline is the basic shape object in Gargoyle.

An outline knows (some of the) symmetry groups to which its trajectories belong.

Clusters. A cluster is defined recursively as a set of one or more outlines and clusters. The outlines and clusters may overlap in the image plane. The result of rendering a cluster is determined by the priority of its components (see below).

A cluster knows (some of the) symmetry groups to which its outlines and sub-clusters belong.

Rigidity. Unclustered outlines and trajectories can always be edited if the control points are visible. The control points of a trajectory can always be moved whenever they are visible. Thus, the command to make control points invisible, enforces rigidity. A more permanent form of rigidity can be achieved by clustering the outline.

Wrap number. A trajectory may intersect itself; the set of points which are inside such a contour is determined by the Imager wrap-number machinery. The multiple trajectories in an outline also follow the Imager wrap-number conventions. The user interface will make it easy to define the containing object or fence vs. the hole-defining trajectories. Ideally, the user would produce an outline by selecting a trajectory for editing, selecting a second trajectory as a "cookie cutter" then "cut" holes in the first trajectory using the second. We may have to compromise on this ideal to get started because general purpose trajectory intersection code is non-trivial. At the minimum, there will be a way to indicate that one trajectory is the fence and the rest are holes. To start, only holes that do not intersect other trajectories will work "correctly."

Priority. Every outline has a priority number determining its position in the drawing order. Priority numbers are unique. Thus, all of the trajectories in a given outline have the same priority. Most likely, this priority number will be the number originally held by the fence trajectory.

Text. We wish to give the user the full facilities of Tioga to edit text, without complicating Gargoyle. The general approach will be to edit the text off to the side and then position it in the scene. Text may be positioned with the same operations which apply to outlines.

Entity. For convenience, we use the term entity to denote an object which could equally well be a control point, a trajectory, an outline, or a cluster.

Gargoyle must provide the following sorts of operations, grouped by the entities to which they apply:

Attributes, Styles and Properties. Attributes, styles and properties all affect how an object appears. Attributes usually affect the geometry of a trajectory (the shape of its centerline). Styles and properties affect the way in which the final visible shape depends upon the centerline geometry. Attributes can only be applied to objects while they are editable. Styles and properties can be applied anytime. In the sane, ordinary world, style involves line width and color. In the wild, untamed world, this might involve rendering trajectories as dotted lines with strange and wonderful dots, or with candy canes onto them.

In Gargoyle, at each joint the user may specify whether or not slope continuity should be preserved across that joint. In other words, there are segment attributes, and joint attributes. Continuity is a joint attribute. We will preserve this continuity using a scheme such as in Darlene Plebon's PathTool. <This implies a method for selecting joints.>