(a)
Jojada Janto Tirtowidjojo, School of Computer Science and Software Engineering, Monash University, Clayton Campus, VIC 3800, Australia jojada@csse.monash.edu.au
Kim Marriott[HREF1], School of Computer Science and Software Engineering, Monash University, Clayton Campus, VIC 3800, Australia marriott@csse.monash.edu.au
Bernd Meyer[HREF2], School of Computer Science and Software Engineering, Monash University, Clayton Campus, VIC 3800, Australia bernd.meyer@acm.org
The current SVG specification does not yet provide for truly flexible layout in the context of different viewer requirements and browser capabilities such as screen size and available fonts. The problem is that an SVG specification gives absolute positions and sizes for its elements and only performs uniform scaling. This is not powerful enough. Displaying a diagram in very different contexts may require radically different layout. We suggest that this problem can be rectified by adding two additional capabilities to the SVG specification: semantic zooming and differential scaling. We describe how by adding constraints and alternative layouts for groups of SVG elements we can provide SVG with these capabilities. Our prototype system demonstrates the feasibility of our concepts.
The Scalable Vector Graphics (SVG) format [HREF3] is set to dramatically improve the way graphics look on the Web. SVG, as is stressed by the word ‘scalable’, provides high-level image detail at any scale and on different device resolutions. This is because unlike other Web graphic standards such as GIF, JPEG, and PNG, which use bitmap file format, SVG format is vector-based. The SVG vector format also provides a compact description of graphics in plain text necessary for faster download speed and hence, bandwidth saving.
However, despite the potential of SVG for dynamic viewing, zooming, panning, and object manipulation, the current SVG specification does not yet provide for truly flexible layout in the context of different viewer requirements and browser capabilities such as screen size and available fonts. The problem is that an SVG specification gives absolute positions and sizes for its elements and only performs uniform scaling. This is not powerful enough. Displaying a diagram in very different contexts may require radically different layout. We suggest that this problem can be rectified by adding two additional capabilities to the SVG specification: semantic zooming and differential scaling. We describe how by adding constraints and alternative layouts for groups of SVG elements we can provide SVG with these capabilities. A prototype system we have built demonstrates the feasibility of our concepts.
To understand the current limitations of SVG, consider the Local Area Network (LAN) topology diagram shown in Figure 1. The network, shown in Figure 1a, connects three different buildings A, B, and C via a site-wide backbone. Shrinking the whole diagram uniformly may cause buildings A, B, and C to become too small to display their internal details. By using an alternative presentation for each of the buildings we can solve this problem. Figure 1b shows the result. Such zooming which preserves the semantic presentation of the LAN topology diagram but changes its appearance is called semantic zooming.
We would also like SVG to provide differential scaling. In contrast to uniform scaling, differential scaling enables a user to differentially control the size of the objects during the scaling of the diagram. A sight-impaired user, for instance, may want to shrink the overall size but to preserve text font size in labels. This may require non-uniform scaling and other layout adjustments so as to ensure labels still fit in surrounding boxes. As an example see Figure 1c.
As a final example of how a user may want to interactively explore a diagram, Figure 1d shows the diagram resulting from semantic preserving manipulation. Semantic preserving manipulation allows a user to change the diagram layout by resizing or moving elements in the diagram, for example, without breaking the connection lines of the network. In Figure 1d, the system preserves the connection information when the user extends the width of building C’s bounding rectangle and interactively moves the LAN segment boxes as well as the repeater circle. In the same way, dynamic layout specification can help the user to preserve any other semantic relation that must remain among the graphic objects.
The above examples clearly demonstrate how semantic zooming, differential scaling and semantic preserving manipulation greatly improve SVG’s flexibility. The main problem is now how to equip SVG with these features. Current SVG static layout specification forces authors to write a script procedure to maintain the unifying layout relationships of graphic objects when an interactive feature is enabled. This task is tedious and complicated. Ideally, the overall graphic layout should be able to be generated automatically based on an abstract layout specification. We demonstrate shortly that constraint-based layout specification and support for alternative layouts for groups of SVG elements can be used as the basis of extending SVG with these capabilities.
(a)
(b) (c)
(d)
Constraints have been used for many years in interactive graphical applications for such things as specifying window and page layout, relationships among parts of a drawing, and animations; maintaining consistency between application data and a view of that data, and consistency between multiple views; and representing physical laws in simulations. For instance, see I. Cruz, K. Marriott, and P. V. Hentenryck, 1998. Recent research on using constraints for the Web (A. Borning, R. Lin, and K. Marriott, 1997; R. Lin, K. Marriott, and P. J. Stuckey, 1999; and G. Badros, A. Borning, K. Marriott, and P. J. Stuckey, 1999) and for Java applets (A. Borning et al., 1997) has also shown the significant benefits constraints can provide.
In the context of computer graphics, constraints provide a mathematical formalization of geometric relationships among graphic objects (K. Marriott and P. J. Stuckey, 1998). By using constraints, authors can easily specify the layout relationships they wish to hold true, rather than on detailing how to maintain the desired invariants procedurally. A constraint solver is used to automatically update geometric attributes so that the specified relationships are maintained. A good illustration is the way JavaTM lays out a Container based on a layout constraints object. The JavaTM layout manager [HREF4] allows programmers to only specify the layout relationships they wish to hold true and to leave the maintainance of those relationships to the layout manager.
We now give an example to explain our idea of embedding constraints in an SVG document. Recall the network topology diagram of Figure 1a. Using constraints, the layout specification of the site-wide backbone would be partially expressed as follows:
The constraint-based layout specification defines the object’s geometric size and position in the form of variables and linear arithmetic equations/inequalities. Since this only fixes relationships between the elements, not their absolute placement it provides the basis for flexible layout. The concrete layout in the context of the viewer’s requests and browser capabilities is determined by a constraint solver. This solver computes variable values that satisfy the specified constraints. When a user changes an object’s position or size the constraint solver responds by resolving the current set of constraints. The system always uses the solution given by the solver to repaint the graphic objects. The flowchart of this process is depicted inside the constraint solving engine of our prototype system’s architecture shown in Figure 2.
We now detail the syntactic extensions to SVG which allow constraints in SVG document. We propose two additional elements: <cons> for constraints and <var> , for constraint variables. To express constraints, the W3C markup standard for mathematics, MathML [HREF5], is employed. Each constraint imposed on the SVG document needs a single <cons> element and each variable which is mentioned in a constraint and is not associated with an SVG attribute needs one <var> element. From the previous example, variables which are associated with an SVG attribute include BackboneBox.x, BackboneBox.width, and BackboneBox.height while those which are not associated with an SVG attribute include BackboneBox.cy, ATMSwitch1Box.cx, and ATMSwitch1Box.cy. The <var> element is optional for a constraint variable that is associated with an SVG attribute. For example, the constraint: (11)ATMSwitch1Box.cy = BackboneBox.cy, can be written in an SVG document as follows:
Figure 2: The Architecture of Our Prototype System>
In many applications, some constraints are strictly required to hold while other groups are merely desired. Constraint hierarchies (A. Borning, B. Freeman-Benson, and M. Wilson, 1992) allow an arbitrary number of different constraint strengths such as required, strong, or weak. The idea is that for a pair of conflicting constraints, the stronger one overrides the weaker one. In our extension to SVG, strength levels can be defined as one of the <cons> element’s attributes.
As an example, a designer might consider that the backbone box of Figure 1a must contain the ATM switch boxes at all times. This consideration fits into the criteria of giving ‘required’ constraint strength to constraint (1) above. Other constraints such as positioning ATM switch 1 completely to the left of ATM switch 2 and ATM switch 2 completely to the left of ATM switch 3 might be considered not essential. Hence, a ‘weak’ strength may be given to them. Figure 1b and 1c show the resulting layouts when these weak constraints are violated.
Finally, for specifying alternative group layouts for groups of SVG elements we introduce a switching element, <docase> , with one or more <gcase> elements. The number of <gcase> elements that a <docase> element has reflects the number of group visualisation alternatives. Each <gcase> element holds a group of objects as one possible group visualisation with an associated condition value. As a group, a <gcase> element may also have its own embedded constraints which apply to its members. When the specified condition of a <gcase> element is satisfied, the group it holds is made visible and its constraints are combined with other existing constraints outside the group to present the final unified appearance of the whole graphic.
As previously described semantic zooming may trigger a layout change and/or alternative group visualisation if the current group’s precondition is no longer satisfied. The change between Figure 1a and 1b is an example of changing group case when a precondition becomes violated; in this case a minimum page size. Another possibility is to let the user interactively switch from one group case to another.
The prototype system we have built consists of a simple document editor, a viewing tool and a constraint solving engine, QOCA (K. Marriott, S. S. Chok, and A. Finlay, 1998). Figure 2 presents the system architecture. It can be seen that the text editor’s main task is to create an SVG document with its embedded constraints. The viewer parses an SVG document and feeds all the defined constraints and variables to the constraint solving engine. When the solution is available the viewer paints the graphic objects. Everytime a user initiates a resize or movement of an object, the new size or coordinate position of the object is used for setting the associated constraint variables’ desired values. The engine then is called to find a new solution which reflects the new presentation of all graphic objects in the layout. The same process happens when the validity of group preconditions changes due to interactive manipulation. In the case of switching to another <gcase> element, the constraints of the previous <gcase> element are removed from the engine and the new constraints are added before the engine can find a new solution.
We have demonstrated how extending SVG with constraints makes Web layout considerably more flexible and dynamic. In particular, it supports semantic zooming, differential scaling, and semantic preserving manipulation. This allows flexible layout in the presence of very different viewer requirements and also supports interactive exploration of a diagram by the viewer.
A. Borning, B. Freeman-Benson, and M. Wilson. Constraint Hierarchies. Lisp and Symbolic Computation, 5(3):223-270, September 1992.
A. Borning, R. Lin, and K. Marriott. Constraints for the Web. In Proceedings of the 1997 ACM Multimedia Conference, pages 173-182, 1997.
G. Badros, A. Borning, K. Marriott, and P. Stuckey. Constraint Cascading Style Sheets for the Web. Technical Report UW-CSE-99-05-01, University of Washington, Seattle, 1999. To appear in Proceedings of the 1999 ACM Symposium on User Interface Software and Technology.
I. Cruz, K. Marriott, and P. V. Hentenryck. Special Issue on Constraints, Graphics and Visualization. Constraints: An International Journal, Volume 3, Number 1, April 1998.
K. Marriott and P. J. Stuckey. Programming with Constraints: An Introduction. The MIT Press, 1998.
K. Marriott, S. S. Chok, and A. Finlay. A Tableau Based Constraint Solving Toolkit for Interactive Graphical Applications. In Proceedings of the 1998 International Conference on Principles and Practice of Constraint Programming, pages 340-354, 1998.
R. Lin, K. Marriott, and P. Stuckey. Flexible Font-Size Specification in Web Documents. In Proceedings of the 22nd Australasian Computer Science Conference, pages 15-26, 1999.
J. J. Tirtowidjojo, K. Marriott, and B. Meyer, © 2000. The authors assign to Southern Cross University and other educational and non-profit institutions a non-exclusive licence to use this document for personal use and in courses of instruction provided that the article is used in full and this copyright statement is reproduced. The author also grants a non-exclusive licence to Southern Cross University to publish this document in full on the World Wide Web and on CD-ROM and in printed form with the conference papers and for the document to be published on mirrors on the World Wide Web.
[ Proceedings ]