A single object in Gargoyle is geometrically equivalent to an Interpress mask [Interpress]. Informally, masks are two dimensional shapes with complex boundaries and holes. A single shape is called an outline. Each closed loop in the outline is called a trajectory. Each trajectory is defined as a sequence of segments. Each segment is a straight line or curve, where the curves can be defined as circular arcs, conics or cubics. We want to support multi-level clustering of outlines to provide a method for combining simple shapes to produce complex ones. We have not yet decided whether to include both instancing and copying.

Given this object structure, the editing model for objects needs to support all the different segment types and a range of continuity constraints between segments. We would like to allow users to break trajectories at (nearly) arbitrary points and insert pieces of other trajectories. We would like to be able to easily select clusters, outlines, trajectories, segments and control points (or whatever mechanism we come up with for editing curves) in a manner that is reminiscent of the Tioga selection mechanism.

Gargoyle will employ intelligent dragging as the mechanism for controlling point and object placement. Intelligent dragging is the combination of the following three techniques: 1) a "gravity function" to snap a cursor to points and curves is of interest; 2) the "points and curves of interest" include not only the objects in a scene, but also points and curves which can be derived from these by a simple rule, e.g. "the circle of radius 25 centered on that vertex," or "the intersection point of those two curves;" 3) objects are translated, rotated, or scaled in a smooth motion coupled to the motion of the same cursor that snaps to points and curves. Hence all of the motions can be performed with precision without grids or global constraint systems. Intelligent dragging is designed to provide more precision than grids without the complexity and uncontrollability of global constraint systems.

We intend eventually to have special tools for creating objects with symmetry and other structure. We would like to include the full set of Boolean point set operations on outlines (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 experiment with a combined painting and construction model for defining shapes.

Gargoyle will be an open system with useful interfaces available to other Cedar programs. We intend to make it easy to generate Gargoyle objects from a Cedar program. Gargoyle graphical objects and segments will be Cedar programming objects to allow clients to easily extend the definition of Gargoyle shapes. A programming object is a record that contains pointers to data and to procedures that define the functionality of the object. This technique separates the functionality of the object from its implementation and allows run time creation of object classes.

For text editing, Gargoyle will attempt to leverage off Tioga as much as possible. As a minimum position, Gargoyle will interactively "paste-up" text from the Tioga formatter by using TiogaImager, which is a package that accepts as input a fragment of a Tioga document plus its style and produces a handle on a programming object that can be displayed through the Imager. Placement points for text will integrate with the shape editing point control mechanisms. Gargoyle style will support Tioga-like style for text and eventually for graphics.

Graphical style describes a set of named formulas for rendering illustrations from their structure or "geometry" [Beach and Stone]. Work with Griffin, Tioga and TiogaArtwork convinces 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 the style definition. These three issues can be demonstrated by considering the problem of illustrating a paper that is submitted to a conference. All the illustrations in the paper should look similar, so they should use the same set of properties defined as the style for that paper. If the conference is sponsored by the ACM, it would be appropriate to have an expert define a style that accurately encodes the ACM standards. Finally, since the author is also responsible for presenting the information in a talk, the same illustrations could be used to produce slides. The style for slides and the style for a proceedings are very different, but we can imagine designing a meta-illustration that can be rendered with two dramatically different styles, a bold, multi-colored "slide style" and an elegant, monochrome "proceedings style".

A Gargoyle scene contains clusters of outlines. Outlines are built from trajectories and segments as above. There exist data structures and procedures for manipulating this hierarchy. GGModelTypes defines the data structures for Scene, Cluster, Outline, Traj, and Segment. GGObjects contain the current set of procedures for manipulating clusters, outlines, and trajectories. Once we understand the set of necessary operations, we would like to make the Cluster definition a Cedar programming object.

The Segment definition is currently a Cedar programming object. GGSegment contains the procedures for creating the segment classes that currently exist: Line, Arc, Conic, Cubic and CubicSpline. The class procedures for the Segment (from GGModelTypes) define the operations for manipulating Segments. The endpoints of a segment are called joints. A segment may have additional points associated with it called control points. A Bezier cubic, for example, is defined by two joints and two control points.

The Gargoyle implementation currently produces Interpress masters and will interpret Interpress to produce Gargoyle objects, one per mask operation. Producing an Interpress master from Gargoyle and reading it back in is not idempotent because an object that is outlined and filled will generate two Interpress mask operations which will then be interpreted to produce two Gargoyle objects. A more stylized use of Interpress could make it possible to correct this.

The object hierarchy data structures and procedures are exported to provide a programmers' interface for building Gargoyle objects.

No work has been done here yet. Objects have color and line weight properties.

While Gargoyle is currently robust enough to play with, it is lacking several features that are necessary to make it useful as an illustrator. We believe the following are all necessary before we could call it a working illustrator: