Constraint SVG

Cameron McCormack
Kim Marriott
Bernd Meyer
Monash University
Clayton, Vic. 3800, Australia
{Cameron.McCormack,Kim.Marriott,Bernd.Meyer}@infotech.monash.edu.au

It has been suggested that SVG be extended in some way to allow attribute values to be specified with expressions and that these expressions be evaluated at display time to determine the attribute values used for rendering. Such an extension would allow the author to create documents with sophisticated layout behaviours which otherwise would not be possible without the use of script.

There are various reasons why diagrams written in SVG may need some form of layout adaptivity. Perhaps the most obvious one is the ability to adapt to the size of text elements. Text is unique in SVG in being the only graphical object for which the bounding box cannot be determined before rendering. Often authors will want to lay out other graphical objects relative to the dimensions of the text (for example, drawing a rectangle around the text). In standard SVG the author would have to either assume the dimensions of the text or use script to get the bounding box after the text has been drawn. Since the user agent might use a font different from the one specified in the SVG document the author could not know for sure the exact dimensions of the text. With the expression-based attribute extension the author could simply specify the coordinates and dimensions of the rectangle in terms of the bounding box of the text element. This form of adaptivity is also required when creating documents which must handle different languages. If a switch element is used to select different text based on the user agent's selected language, the dimensions of the text element will likely be different and the rectangle must be adapted to the new size.

Another form of dynamic layout that could be realised using expressions to specify attribute values is layout adjustment according to the dimensions of the browsing window. Towards the aim of SVG becoming a platform for graphics on a wide range of viewing devices it would be beneficial for authors to be able to create a single document whose content could adapt to the viewing space available. In some cases the simple scaling afforded by SVG will be sufficient but for some documents this could result in illegible text and a non-optimal use of the display area. A very simple example is a linear flow diagram. When displayed on a computer monitor the diagram would be better shown layed out horizontally, as computer monitors typically have a greater width than height. When viewed on a PDA, however, the diagram should be displayed vertically, since a PDA usually has a portrait orientation. If being viewed in a resizable window, we want the diagram to adapt to these changes in canvas dimensions in real time.

Interactive behaviours can also be specified using expressions. Consider a hierarchical diagram such as a filesystem tree. If we want to allow the user to expand and collapse branches of the tree we can specify the position of each node with an expression. This expression would take into account a user variable, which represents whether the branch is open or not, and the positions of the nodes above this node. Clicking on a node in the tree would set or unset the user variable which would cause the expressions to be re-evaluated and the branch to expand or collapse. This is done with a bare minimum of scripting with only the setting of the user variable performed with script.

The reason for avoiding script and using some declarative mechanism for specifying the layout and other properties of graphical objects is the issue of automatic expression re-evaluation. If an object changes size this may require other objects in the document to be moved or resized. When dealing with script, event handlers must be explicitly added to objects to be notified of some property change. These changes must be propagated. One object moving might cause another to move, which in turn causes another to resize, and so on, in a cascading effect. Script must be written to handle these propagations manually. With a declarative syntax for specifying object properties with expressions, the user agent can determine the objects which depend on a particular property and force an update of dependant objects, thus making adaptive documenting creating simpler for the author.

In order to explore better the capabilities that expression-based attribute values would allow we have extended Batik to support this extension and have designed several examples which demonstrate the expressiveness the extension gives the author. Our implementation utilises one-way constraint solving algorithms to propagate changes which occur due to interaction. One-way constraints are efficient to compute, and are used in a variety of applications including GUIs, spreadsheets and customisable graphic editors such as Visio. The syntax is designed to be backwards compatible with standard SVG documents and allows default values to be supplied for browsers which do not understand the extensions. We have also implemented support for a form of RCC using XSLT. These templates, when used in conjunction with one-way constraints, can be used as a powerful prototyping mechanism. In addition to their use for custom graphical elements, the templates can be used to create layout widgets where expressions are generated that specify the coordinates of child elements.