This document is a NOTE made available by the W3 Consortium for discussion only. This indicates no endorsement of its content, nor that the Consortium has, is, or will be allocating any resources to the issues addressed by the NOTE.
This document is a submission to W3C. Please see <http://www.w3.org/Submission/> Acknowledged Submissions to W3C regarding its disposition.
This document presents an outline proposal for representing schematic graphics in web documents. Approaches taken by a variety of document production systems are reviewed and some key issues identified. An approach to a schematic graphics markup language is described. A number of open questions and stylistic issues are identified that can form the basis for discussion of the proposal in a workshop. A key question is the extent to which the approaches taken in graphics standards such as GKS-94 are applicable in the web context. The model of primitives and attributes in graphics standards in particular, is rather different to the model of content and attributes in SGML/HTML. The need for a clean model to underpin markup of schematic graphics is highlighted and this should be a key issue to be addressed in discussion of this document.
In this document we present an outline proposal for representing schematic graphics in web documents. First we examine what we mean by schematic graphics and why such a proposal is necessary.
We use the term "schematic graphics" to encompass the types of diagrams typically found in scientific (including mathematics) and engineering papers, essentially 2D diagrams constructed from boxes, lines, arrows, curves and text.
At the current time, graphics may be represented in a web document using CGM, GIF, PNG, VRML, etc. Why should we need yet another way of representing graphical content? Four reasons come to mind:
In the next section we briefly review the approach to schematic graphics taken in some document production systems. At some stage compatibility with CGM will need to be considered.
WYSIWYG document production systems such as Word and FrameMaker contain built-in drawing tools and also provide the ability to import diagrams created with other tools. It is the functionality of the built-in drawing tools that is of interest here.
FrameMaker provides:
drawing tools. It supports control of:
Diagrams are constructed on a coordinate grid. Two options are provided to facilitate drawing on a grid, snap to grid and gravity. Snap to grid attracts graphical objects to grid lines, gravity attracts graphical objects to each other.
For drawing many types of diagram, especially diagrams with repetitive structure, grouping and ungrouping functionality lessens the construction work.
The drawing model in FrameMaker is essentially 2 1/2 D graphics, i.e. one can think of objects being drawn on planes, filled objects in front obscure objects behind. "Bring to Front" and "Send to Back" functionality is used to control the ordering of objects in the 2 1/2 D stack.
Align and distribute functionality is also used extensively for controlling the positioning of objects. Tops, bottoms, left sides, right sides, top/bottom centres and left/right centres of objects may be aligned with the align command. Distribute allows objects to be positioned with equal space between them. The space may be specified explicitly or computed by FrameMaker forequidistant centres or equidistant edges. Horizontal and vertical spacing may be specified independently.
From this author's experience, align and distribute are used extensively in creating even the simplest of diagrams.
Objects may be flipped - up/down and left/right. This provides a convenient way to create symmetrical parts of diagrams.
Rotate and scale commands are also provided.
The drawing editor in Word is similar to the FrameMaker editor, though at least in this author's view, somewhat less powerful.
Two approaches will be described here, troff and LaTeX.
The Unix document production system, troff, has rather fallen out of fashion in recent years, but it does contain some very useful functionality which is worth considering carefully. In line with the Unix philosophy, document production in troff employs a number of filters - programs which process languages for pictures, equations, tables, references, etc. These are applied as preprocessors before troff itself is invoked to do the actual layout of the document. The filters translated their own languages into troff commands, making extensive use of the macro facilities, number registers (variables) etc. in troff.
For diagram production, two languages were provided: pic - a graphics language for typesetting designed by Brian Kernighan and IDEAL - a language for describing pictures designed by Christopher Van Wyck. This author has significant experience with pic, but little with IDEAL.
pic was designed to draw simple figures on a typesetter. The basic objects in pic are:
Dotted and dashed styles were provided for boxes and lines, though circles and arcs could not be dotted or dashed.
The important point about pic is that it is language based. So, for example, the diagram:
could be described by:
.PS box "a box" .PE
The coordinate system in pic is inches, by default, though this could be changed by a scaling factor. Objects have default sizes. These could be overridden by specifying new values for global variables, such as boxwid and boxht, or by specifying local values for each object, for example:
box wid 2.0i ht 3.0i "Another box"
Being a language, pic provided macro constructs, loops, conditional statements and variables, to facilitate the construction of complex structured diagrams.
Objects could be placed at absolute positions, or at relative positions. The relative positioning functionality turns out to be very powerful. pic has a (changeable) default drawing direction, so, for example, the diagram:
can be produced with:
left; box; arrow; ellipse; arrow; circle
Notice that the objects have been positioned relative to each other in a way consistent with the drawing direction.
Objects could be positioned relative to named compass points, for example:
box ht 0.75i wid 0.75i box ht 0.5i wid 0.5i with .sw at last box.se
Arithmetic could also be performed on coordinate positions, for example:
box ht 0.75i wid 0.75i box ht 0.5i wid 0.5i with .sw at last box.se +(1.0,0.0)
Objects can also be named, for example:
A: box B : box with .se at A.ne
Equations could be incorporated into diagrams, using the eqn preprocessor, for example:
box "$int from 0 to 1 x dx$"
(The "$" character is an escape character introducing an eqn statement.)
One thing that pic could not do, which was a consequence of the filter pipeline model into which pic had to fit, was that it was not possible to say, "give me a box of the right size to enclose this text".
IDEAL was based on a constraint approach. IDEAL programs essentially defined pictures by a set of simultaneous equations over significant points in the picture and a set of drawing instructions to be carried out with respect to the points. A box, for example, could be described by:
rect {
var ne, nw, se, sw, wd, ht;
nw = sw + (0,1)*ht;
ne = nw + wd;
se = sw + wd;
conn ne to nw to sw to se to ne;
}
LaTeX 2e provides a picture environment for drawing pictures composed of:
Only two linewidths (thinlines and thicklines) are provided.
Pictures are defined in a Cartesian coordinate system whose extent can be defined by the user. The basic ideas are quite similar to pic, though the syntax is different. For example, the program to draw a box containing the text "gnu", is
\put(1.3,4){\framebox(3,1.1){gnu}}
This draws a box width 3 units, height 1.1 units, with its bottom left hand corner at the point (1.3,4).
There are ways to save parts of pictures though these are less powerful than the macro facilities in pic.
The major difference from pic is that LaTeX does not provide any constructs for positioning graphical objects relative to other graphical objects.
There are a number of packages available that extend the drawing capabilities of LaTeX, some of these use special fonts and construct pictures by drawing graphical characters; others use extended device drivers to interpret drawing commands. The book by Goossens et al. describes many of these packages in detail [Goosens].
Thot, developed at INRIA Rhone Alpes, is a "generic system for the development of document centred applications". The Thot models seems to be based on a layered collection of languages, the S language for describing document metastructure, the P language for describing presentation rules and the T language for describing translation to other document systems for the purposes of document transportation.
The layout model in Thot is related to the model in TeX. Presentation elements occupy boxes; boxes are positioned in order to generate a physical presentation. A two level approach is used to presentation, an abstract level and a physical level in which the abstract level is realized within the constraints of the particular physical device to which the presentation is addressed.
The graphical elements provided in Thot are:
The positioning language allows constructs such as:
ElemGraph = BEGIN VertPos : Top = Enclosing.Top + 1 cm UserSpecified; HorizPos : Left = Enclosing.Left UserSpecified; ... END;
and
LinkedBox: BEGIN VertPos : Top = A.Bottom; HorizPos : Left = A.VMiddle; Height : Bottom = B.Top; Width : Right = B.Left; END;
Control over linestyle, line thickness, fill pattern and colour are provided.
A stacking order for boxes can be defined in the presentation language, through a depth attribute which may be zero or a positive integer.
The basic issues are:
Question 5 relates to the overall model of yML (y = HT, Math, X, ....) document presentation. Is there a common rendering model, defined in these or other W3C standards, e.g. a box-based model, or is this outside the scope of current standards? Clearly Thot has a well-defined model, but do all browsers have similar rendering models? CSS1 seems to have an underlying model of layout based on positioning boxes.
CSS1 assumes a simple box-oriented formatting model (p16). Every displayable element has a rectangular core content area, surrounded by optional padding, border and margin areas which are also rectangular. CSS1 defines properties to control the size of these optional areas and the appearance of the border. Top, right, bottom and left edges of the border may be controlled separately. Border width may take the values:
thin | medium | thick | <length>
Border styles may take values:
none | dotted | dashed | solid | double | groove | ridge | inset | outset
Colour is specified by colour name or rgb triples.
Width and height may be specified explicitly or automatically:
<length> | auto
With the functionality of CSS1, it is possible to draw a box which encloses some centred text. This suggests that it makes sense to build schematic drawing functionality on this basic formatting model.
After discussing the reasons for wanting a schematic drawing capability for web documents and the rendering/presentation model inherent in HTML/CSS1, we arrived at a number of fundamental decisions, which shape our approach.
Graphical elements need to be defined in some coordinate system. The CSS1 document defines a canvas as that "part of a UA's (user agent) drawing surface onto which documents are rendered". CSS1 suggests that the initial size of the canvas be based on the window size but leaves this to the UA to decide. CSS1 defines relative and absolute units of measurement. Relative units may be em, ex (x-height) or px (pixel); absolute units may be inches, cm, mm, point or pica. Percentage units are also possible, oftenpercentages are percentages of font-size.
In pic, the default coordinate system is inches. A scaling factor may be specified to change the default coordinate system.
It is proposed that a schematic diagram is delimited by the opening tag <SCHEMATIC> and the closing tag </SCHEMATIC>. Absolute and relative units are allowed, including inches, cm, mm, points and picas, and relative units, x-height and ems. Pixels are not considered to be a useful system of units at this level. Units are specified by the attribute units, with values:
units = inches | cm | mm |pt | pc | ex | em
The systems described in sections 2 and 3 provide a variety of different graphical primitives from which to construct drawings. There is some degree of overlap between the systems. 2D graphics systems also provide graphical primitives, for example, the ISO/IEC standard, GKS-94, provides 6 classes of output primitives:
Each primitive class provides a number of output primitives:
| CURVE | SET OF POLYLINE SET OF NURB SET OF CONIC SECTION |
| MARKER | POLYMARKER |
| AREA | SET OF FILL AREA SET OF CLOSED NURB SET OF ELLIPTIC SECTOR SET OF ELLIPTIC SEGMENT SET OF ELLIPTIC DISC |
| CHARACTER | TEXT |
| IMAGE | CELL ARRAY |
| DESIGN | DESIGN |
Each output primitive has an associated set of attributes which control its appearance when rendered on a display device.
Output primitives for the systems described in sections 2 and 3 are summarized below.
| FrameMaker | pic | LaTeX 2e | Thot |
| line | line | line | lines |
| polyline | polyline | arrow | arrows |
| rectangle | arrow | box | rectangle |
| polygon | box | circle | rectangle with rounded corners |
| rounded rectangle | circle | oval (box with rounded corners) | lozenge |
| arc | ellipse | quadratic Bezier curve | closed curve |
| oval | arc | open curve | |
| text (column and line) | spline curve | ellipse | |
| freehand | text |
We suggest the following minimum primitive set:
Whilst the inclusion of Non-Uniform Rational B-Spline curves has some attractions (because of their ability to represent precisely a wide range of other types of primitives), NURBS are considered to be too powerful and cumbersome for the applications envisaged here, at least at the first stage.
The representation of primitives is considered further after discussion of coordinate systems.
In SGML, an element has the form:
START-TAG CONTENT END-TAG
which in the usual concrete syntax is:
<tag>content</tag>
Tags in SGML can have one or more mandatory or optional attributes, which provide further information about the element which they delimit.
In the formatting model, when the content is formatted, it occupies a rectangular region with computable boundaries. Thus we propose that all graphical elements should be renderable into regions with a well-defined bounding box.
The next question to address is "what is the CONTENT of a graphical primitive"? How, for example, should a polyline be defined? What is the content of a polyline?
Eric van Herwijnen in his book Practical SGML [Herwijnen] gives a DTD for the GKS output primitives (the 1985 standard, not the 1994 standard) and for the CGM primitives. He represents a polyline as:
<Polyline>(0,0),(0,1), ... </Polyline>
The content of the polyline is the list of vertex coordinates.
He represents circles by:
<Circle center = "0,0" radius = "2.0">
The circle has no content; SGML attributes are used to define the geometry of the circle.
This seems to us to be inconsistent. Why not define a polyline as:
<Polyline vertexlist = "(0,0),(0,1), .."'>
or a circle as:
<Circle>((0,0),2.0)</Circle>
A deeper form of markup is:
<POLYLINE> <VERTEX>(0,0) </VERTEX> <VERTEX>(1,1) </VERTEX> ... </POLYLINE>
but this seems to us to be more detailed than is necessary.
It is not clear what the content of a graphical element really is. Our initial view was that content is a description of the geometry of a primitive, to be rendered into a bounding box. We assume that documents are searched on content (in the SGML sense of the word) and hence we included geometry in content. However, there is a counter example in the HTML AREA element, which is used to specify client side image maps. The AREA element has attributes shape and coords that are used together to define a polygonal area. The value of the coords attribute is a comma separated list of coordinate values. In view of this we follow the approach exemplified by the AREA element and specify the parameters that control the geometry of a primitive as attributes of the primitive element.
Thus a sawtooth waveform with 3 teeth might therefore be defined by:
<POLYLINE coords = "((0,0),(1,1),(1,0),(2,1),(2,0),(3,1),(3,0))">
with no end tag. The bounding box for this primitive is the rectangle with height 1 and width 3. The coords parameter of the AREA element is a comma separated list of values. We have included more structure in the coords parameter (use of brackets to delimit pairs of coordinates of each point and the whole list) in the interests of clarity.
A line is defined by start and end vertices:
<LINE coords = "((0,0),(1,1))">
Arrowheads may be drawn on either or both ends of a line. This is controlled by the "arrowhead" attribute of the LINE element. Thepossible values are:
arrowhead = none | start | end | both
The values "start" and "end" draw an arrowhead at the start and end positions of the line respectively. The value "both" draws arrowheads at each end of the line as shown below.
<LINE arrowhead = " start " coords = "((0,0), (1,0))" > <LINE arrowhead = "end" coords = "((1.5,0), (2.5,0))" > <LINE arrowhead = "both" coords = "((3,0), (4,0))" >
We recognize the need to include a simple curve drawing capability in a schematic drawing system. More thought is needed before we can decide which particular type of spline to include. We include the SPLINE element as a placeholder.
<SPLINE> ... </SPLINE>
GKS-94 provides a general conic section primitive which is used to draw arcs of conic sections (circular, elliptic, parabolic, hyperbolic). The primitive is defined by a 3 x 3 matrix and start and end points of the arc section. The Computer Graphics Metafile (CGM) provides a range of elements for representing different types of arc and different parameterisations. In this proposal, we follow the CGM approach as this is better-suited to the needs of simple schematic graphics. A single type of element:
<ELLIPTICARC>
is included. The parameterisation is based on the CGM parameterisation:
coords = "(centrepoint, firstCDPendpoint, secondCDPendpoint, startpoint, endpoint)"
The arc is defined as follows (based on the text in CGM ISO/IEC 8632-1: 1992, page 179).
The centrepoint parameter specifies the centre of an ellipse. The CDP endpoints define one end point for each conjugate diameter of the ellipse and with the centrepoint they define the two conjugate diameters. The startpoint and endpoint, together with the centrepoint define two semi-infinite rays from the centrepoint through the start point (the start ray) and through the endpoint (the end ray). The arc begins at the intersection of the start ray with the ellipse and ends at the intersection point of the end ray with the ellipse. The direction of the arc is defined as follows. The line segment from the centre point to the first CDP endpoint defines the first conjugate radius of the ellipse. Similarly, the line segment from the centre point to the second CDP endpoint defines the second conjugate radius. The two radii meet at the centrepoint and define two angles, whose sum is 360 degrees. One angle is less than 180 degrees, the other is greater than 180 degrees. The drawing direction of the elliptic arc is the direction from the first conjugate radius to the second, through the smaller of the two angles.
There are two ways in which text surrounded by boxes is used in schematicdrawings. In the first, the box is dominant; the size and shape of the box is important (and may have a particular meaning, for example the different shapes of symbols used in flowchart notations). The text labels the box. The text may not even be inside the box but connected to it by an associating line (it could be aruged that this is a stylistic convention). For intricate schematics, this is often the norm. In the second, it is the text that is dominant and the box serves to delimit or highlight the text. To differentiate these two usages, we propose two different elements, BOX and TEXT.
The BOX element has attributes boxwid and boxht that control the size of the box. The content of the BOX element is any block element. Thus, using MathML, we could write:
<BOX boxwid = "2.0in" boxht = "1.0in"> <math> <mrow> <mi>x</mi> <mo>+</mo> <mn>4</mn> </mrow> </math> </BOX>
which produces the presentation:
The element
<TEXT> <math> <mrow> <mi>x</mi> <mo>+</mo> <mn>4</mn> </mrow> </math> </TEXT>
will generate a box whose size matches the rendered size of the text string x + 4.
Schematic diagrams are frequently constructed from libraries of shapes such as rectangles, circles, ellipses, diamonds, etc. Whilst these can be constructed using polyline or conic section primitives, it is convenient to provide some basic shapes which may be associated with labels (TEXT elements) or have labels associated with them (BOX elements) by specifying the shape to be inscribed in the bounding box of a BOX or TEXT element as a "shape" attribute to the element. Suggested values are:
shape = none | rect | ellipse | rounded-box | diamond .....
The value "none" indicates that no shape is to be drawn on the bounding box. This value is useful for positioning text in a schematic. Examples of shape values are shown below.
<BOX shape = "rect">A string</BOX> <BOX shape = "ellipse">A string</BOX> <BOX shape = "diamond">A string</BOX>
The value "rounded-box" denotes a box with rounded corners.
It could be argued that "shape" should be specified via a style sheet rather than as an attribute of BOX or TEXT elements. The view one takes on this seems to depend on the extent to which the shape is considered an intrinsic part of the geometry of the picture, or an appearance characteristic that the user agent should have some ability to control. It seems to the authors that shape is a part of geometry and hence should be specified as an attribute, though further consideration of this point is needed.
The POLYGON element denotes a closed polygon, defined by a list of vertices. If the first point does not match the last point, an additional edge is implicitly added to close the figure. The elements
<POLYGON coords = "((0,0),(0,1),(1,1),(1,0),(0,0))">
and
<POLYGON coords = "((0,0),(0,1),(1,1),(1,0))">
both denote the unit square. Polygons may be filled with a variety of interior styles. Patterning with a replicated image (wallpaper viewed through a stencil defined by the polygon's interior) could also be allowed and seems to match facilities proposed for HTML 4.0.
We could define a polygon by a vertex list in a similar way. The vertex list is implicitly closed if the first point does not equal the last point.
<POLYGON coords = "((0,0),(0,1),(1,1),(1,0))">
would define a unit square.
There are two ways in which we could think about the polyline element:
<POLYLINE coords = "((0,0),(1,1),(1,0),(2,1),(2,0),(3,1),(3,0))">
The first is that it is an object anchored to the points (0,0), (1,1) etc. in the coordinate system of the schematic element in which it is defined. An alternative view is that the coordinates of the vertices are coordinates relative to some origin, so that the vertex list defines an object that may be placed relative to other objects.
Experience suggests that both alternatives have their uses. ten Hagen et al. in their Intermediate Language for Pictures [ten Hagen], introduced an attribute "position", with values "fixed" and "free" to distinguish these two alternative interpretations. In this proposal we regard the position of an object as free unless it is explicitly anchored. The element:
<POLYLINE coords = "((0,0),(1,1),(1,0),(2,1),(2,0),(3,1),(3,0))">
denotes a polyline that is free to be positioned relative to other objects, or anchored to another position. Anchoring is controlled by the attribute "with" and the composition element "GROUP".
Since all graphical elements have a well-defined bounding box, it should be possible to place elements relative to each other using defined compass points on the bounding box (N, NE, E, SE, S, SW, W, NW) using "with" as in pic. We also need a way of naming elements. HTML provides an ID attribute (CSS1, p10) which is guaranteed to have a unique value over a document. ID could thus be used to refer to an element. However, for many purposes, it is much more convenient to have names that are unique over a smaller scope than the whole document, for example within a SCHEMATIC element. For the moment, we suggest that graphical primitive and constructor elements have a name attribute. To avoid confusion with the HTML "name" attribute, we will call the name associated with graphical primitives "gname". We assume also that we can refer to positions on the bounding box of a graphical element using the notation name.position. We can then express structures such as:
<BOX gname = "box1">First box</BOX> <BOX with = "n at box1.se">Second box</BOX>
and
<POLYLINE with = "n at(5,5)" coords = "((0,0),(1,1),(1,0),(2,1),(2,0),(3,1),(3,0))">
Whether we should allow names to be nested as in the grouping construct in pic:
A: [B: box .... ]
where A.B is used to refer to the box is an open question.
We need to define elements that can be used to describe the composition of a schematic from graphical elements. Drawing on the approaches in FrameMaker and pic, we could describe a schematic with the label "A saw-tooth waveform" centred above the curve defined by the polygon by:
<GROUP direction = "down"> <TEXT align = "center">A saw-tooth waveform</TEXT> <POLYLINE align = "center" coords = "((0,0),(1,1),(1,0),(2,1),(2,0),(3,1),(3,0))"> </GROUP>
This approach mirrors the approach in TABLE and IMG elements. The align attribute defines how an element is aligned with respect to its parent element. Thus in the example above, the TEXT and POLYLINE elements are both centred with repsect to the bounding box of the parent GROUP element. The group also has some similarities to the <mrow> element in MathML which horizontally groups any number of sub-expressions. An attribute to control vertical alignment, valign, is also defined.
Obvious values for these are
align left | center | right valign top | middle | bottom direction left | right | up | down
When a GROUP element is formatted, the result is a bounding box containing the formatted content. Thus constructs such as:
<GROUP direction = "right "> <GROUP direction = "down" align = "top"> <TEXT align ="center">A saw-tooth waveform</TEXT> <POLYLINE align ="center" coords = "((0,0),(1,1),(1,0),(2,1),(2,0),(3,1),(3,0))"> </GROUP> <GROUP direction = "down " align = "top"> <TEXT align = "center">A square waveform</TEXT> <POLYLINE align = "center" coords = "((0,0),(1,0),(1,1),(2,1),(2,0),(3,0))"> </GROUP> </GROUP>
have a well-defined meaning.
Depending on how we define content, the expression:
<TEXT><POLYLINE ....></TEXT>
could also be given a well-defined meaning, drawing the bounding box around the object defined by the polyline object.
The style sheet statement:
POLYLINE {border-style: solid}
will (we think!) cause the bounding boxes of all polyline elements to be rendered with solid edges.
By analogy with the FrameMaker distribute function, the GROUP element can also distribute space equally between the elements to be combined. This is controlled by the attributes hspace and vspace. For example,
<GROUP hspace = "1.0 in" direction = "right"> <TEXT align = "middle">A waveform</TEXT> <POLYLINE align = "middle" coords = "((0,0),(1,0),(1,1),(1.5,1),(1.5,0),(2,0))"> </GROUP>
will display the two objects with their bounding boxes separated by a horizontal space of 1.0 inches. When non-zero spacing is defined, the elements to be grouped must have position "free".
In computer graphics, graphical primitives (such as polyline, polygon) are usually specified by a set of parameters which determine the basic geometry of the primitive (such as the positions of the vertices of a polyline or polygon) and a set of attribute values which determine other properties of the primitives. Attributes may also contribute to the definition of the geometry of a primitive. The question of what does and does not determine the geometry of a primitive, which is linked to the question of what precisely we mean by the geometry of a primitive, can be quite subtle.
The style in which a line is drawn: solid, dotted, dashed, etc. may be considered part of the geometry of the primitive, or may be used to differentiate the appearance of one class of lines from another. The "correct" interpretation will depend on the application concerned.
In many applications it is convenient to define components of a diagram with the aid of local transformations (scale, translate, rotate, etc.) applied to basic drawing elements. Picture parts, for example, are frequently defined in a convenient coordinate system and then scaled to the size required for the picture. Transformations are also very useful for constructing pictures that contain some degree of symmetry in their components, for example, rotational symmetry.
By analogy with GKS-94 we define a local transformation property that applies to all types of primitives. The local transformation is applied to the primitive before the bounding box is constructed. The bounding box thus encloses the transformed primitive. Note. This may need some more thought. We cannot apply the transformation after the bounding box has been constructed as the transformation can distort the shape of the box and produce a non-rectangular shape which could cause problems for the meaning of the with attribute. The problem with applying the transformation first is that the with attribute applies to positions on the bounding box of the transformed primitive. Applying the transformation to the compass positions of the bounding box of the untransformed primitive does not necessarily generate the compass positions of the bounding box of the transformed primitive.
We suggest initially that the local transformation is specified by a 2 x 3 matrix, which includes the specification of translation transformations.
An alternative approach, which avoids some of the pitfalls associated with the transformation of the bounding box is to restrict the allowable transformations to scaling/inversion followed by rotation. In this approach we could define properties scale and rotate, operating about the centre of the bounding box of the untransformed object, with values:
scale = scale_factor flip_horiz flip_vert rotate = angle flip_horiz = YES | NO flip_vert = YES | NO
The flags flip_horiz and flip_vert determine whether the shape is to be inverted in the vertical or horizontal centrelines of the bounding box.
Style sheets seem to provide a mechanism for handling attributes which mirrors the mechanisms used in standards such as GKS-94, for controlling the values of attributes used for differentiation. These attributes may be specified globally (meaning that they have the same value for all display surfaces (workstations in GKS terminology) on which the primitive is to be displayed) or locally (meaning that they can have different values for different display surfaces).
Style sheets do not appear to limit which style properties may be associated with which element types. In this proposal we identify a number of CSS properties (graphical attributes) which have meaning for particular element types as shown below.
| Properties | Primitives |
curve-type curve-width curve-colour |
LINE, POLYLINE, SPLINE and ELLIPTICARC |
edge-flag edge-type edge-width edge-colour |
TEXT, BOX, POLYGON |
| interior-style | POLYGON |
| local-transformation | All primitives |
The values of curve-type are a subset of the allowable values for the border style property:
curve-type = dotted | dashed | solid
It is not clear that the double, groove, ridge, inset and outset values defined for border style are meaningful for curve-style.
Similarly, curve-width is based on border width:
curve-width = thin | medium | thick | <length>
The curve-colour property is defined in the same way as the colour attribute in HTML.
The edge-flag property controls whether edges of a polygon should be drawn or not. The values are:
edge-flag = on | off
Edge-type, edge-width and edge-colour are defined identically to curve-type, curve-width and curve-colour.
In computer graphics curves and edges are fundamentally different and we reflect that here in the use of different properties to control them. In GKS-94, for example, curvetype and edgetype are different attributes, though their values are drawn from the same value range.
It is an open question how the appearance of the shape associated with a BOX or TEXT element should be controlled. For the present we suggest that the edge properties are used.
Note that shape = none and edge-flag = off have the same visual presentation (the shape is invisible). However, the intent seems to us to be different.Edge flag enables visibility to be set independently of style, which gives more flexibility for exercising local control. Using the edge flag, edges can easily be turned on and off, whilst retaining the style in which they are displayed if the edge flag is on. If style none is used, then one has to remember what the style was before the change to none was made.
The style with which the interior of a polygon is filled is controlled by the interior style property. Thought needs to be given to what values this should take. For the time being, we assign colour values to indicate the solid colour with which the interior is to be filled.
interior-style = none | colour>
No control over the convention used to determine the interior of a polygon is provided. (This needs to be addressed.)
The local-transformation property is specified by a 2 x 3 matrix.
local-transformation = <matrix23>
No control over the convention used to determine the interior of a polygon is provided. (This needs to be addressed.)
The style control mechanisms can be used in very flexible ways. Suppose we wanted to control the appearance of the waveforms in all the schematics in a document. We could do this by defining appropriate appearance properties with each element, for example:
<POLYLINE type = "text/css" style = "curve-colour : green" coords = "((0,0),(1,1),(1,0),(2,1),(2,0),(3,1),(3,0))"> <POLYLINE type = "text/css" style = "curve-colour : green" coords = "((0,0),(1,0),(1,1),(2,1),(2,0),(3,0))">
Using the class attribute, we can write:
<STYLE type = "text/css">
POLYLINE.waveform {curve-colour : green}
</STYLE>
...
<POLYLINE class = "waveform"
coords = "((0,0),(1,1),(1,0),(2,1),(2,0),(3,1),(3,0))">
<POLYLINE class = "waveform">
coords = "((0,0),(1,0),(1,1),(2,1),(2,0),(3,0))">
The combination of SGML and style sheets appears to offer some alternative ways to achieve a given effect and it is not clear to the authors of this proposal what the correct approach should be. This is a topic that requires discussion within a workshop setting.
The following example is intended to highlight some of the issues we feel are important.
Suppose that the element BOX has attributes width and height. In order to define a box of width 1.0 in and height 2.0 in we have to write:
<BOX width = "1.0 in" height = "2.0 in"> ... </BOX>
If we want to specify that all boxes in a schematic have width 1.0 in and height 2.0 in we could just specify the values on every BOX element, but this is tedious in the extreme and we need a way to specify these values "globally". One approach that has been suggested to us is to decide that the parent elements (group, schematic etc) have attributes transmitted_width and transmitted_height, which do not affect the parent element, but are inherited by the child elements and used for their width and height. Thus if we wanted all the boxes in one schematic to be width 1.0 in and height 2.0 in and all the boxes in the next schematic to be width 2.0 in and height 2.0 in, we could define the first schematic as:
<SCHEMATIC transmitted_width = "1.0 in" transmitted_height = "2.0 in"> <BOX> ... </BOX> <BOX> ... </BOX> </SCHEMATIC>
and the second as:
<SCHEMATIC transmitted_width = "2.0 in" transmitted_height = "2.0 in"> <BOX> ... </BOX> <BOX width = "3.0 in"> ... </BOX> <BOX width = "3.0 in" height = "3.0 in"> ... </BOX> </SCHEMATIC>
The second schematic also illustrates how inherited values could be overridden by locally specified width and height attributes. The first box in this example would have width 2.0 in and height 2.0 in, the second width 3.0 in and height 2.0 in and the third width 3.0 in and height 3.0 in.
An alternative approach (which we assume to be orthogonal to the approach above) is based on properties and style sheets. We could write:
<STYLE ...>
BOX {width : 1.0in; height : 2.0 in}
BOX.schematic2 {width : 3.0in; height : 2.0in}
</STYLE>
...
<SCHEMATIC>
<BOX> ... </BOX>
<BOX> ... </BOX>
</SCHEMATIC>
...
<SCHEMATIC>
<BOX class = "schematic2"> ... </BOX>
<BOX class = "schematic2" style ="width : 3.0 in"> ... </BOX>
<BOX class = "schematic2"
style ="width : 3.0 in; height = 3.0 in"> ... </BOX>
</SCHEMATIC>
There are some stylistic issues here that need to be addressed.
A schematic is described by the SCHEMATIC element.
| Element | Content | Attributes |
| SCHEMATIC | ? any sequence of block elements | units = in | cm | mm | pc | pt | ex | em |
The proposed graphical elements are listed in the table below, together with the attributes that determine the geometry of the primitive.
| Element | Content | Attributes |
| LINE | none | coords = (start-point, end-point) with = compass-posn at location | compass-posn at vertex gname = name arrowhead = none | start | end | both align = left | center | right valign = top | middle | bottom |
| POLYLINE | none | coords = (vertex-list) Other attributes as LINE |
| SPLINE | none | As POLYLINE |
| ELLIPTICARC | none | coords = (centre-point, firstCDPendpoint, secondCDPendpoint, startpoint, endpoint) Other attributes as LINE |
| BOX | "string", or ? any content | boxwid = length boxht = length with = compass-posn at location | compass-posn at vertex gname = name shape = none | rect | ellipse | rounded-box | diamond align = left | center | right valign = top | middle | bottom |
| TEXT | "string", or ? any content | with = compass-posn at location | compass-posn at vertex gname = name shape = none | rect | ellipse | rounded-box | diamond align = left | center | right valign = top | middle | bottom |
| POLYGON | As POLYLINE |
Definitions of some data types are given below.
compass-posn = n | s | e | w | nw | ne | sw | se location = gname.location | compass-posn | vertex gname = .... start-point = vertex end-point = vertex vertex = (length, length) vertex-list = vertex | vertex vertex-list
Graphical attributes can be defined by style sheet properties.
| Primitive elements | Properties | Values |
LINE POLYLINE SPLINE ELLIPTICARC |
curve-type curve-width
curve-colour |
dotted | dashed | solid thin | medium | thick | length colour |
TEXT BOX POLYGON |
edge-flag edge-type edge-width
edge-colour |
on | off dotted | dashed | solid thin | medium | thick | length colour |
| POLYGON | interior-style | none | colour |
Graphical attributes can be grouped by the following element.
| Element | Content | Attributes |
| GROUP | sequence of content elements; not clear what restrictions are placed on these | align = left | center | right valign = top | middle | bottom direction = left | right | up | down hspace = length vspace = length gname = name |