Compiling SVG: How and Why

Keywords: Graphical User Interface

Dr. Michael R. Levy
Vice-President, Research
NewHeights Software Corp.
British Columbia


Michael Levy received his Ph. D. from the University of Waterloo, Ontario. He was a professor at the University of Victoria for 18 years prior to being lured to an industrial position at NewHeights Software where he directs research into telephony and collaborative applications.

Quetzalcoatl Bradley
Software Developer
Microsoft Software Corp.
British Columbia


Quetzalcoatl Bradley graduated from the University of Victoria before joining NewHeights as Senior Applications Architect. He has subsequently accepted a position at Microsoft in Redmond, Washington.

Calin Somosan
Software Developer
NewHeights Software Corp.
British Columbia


Calin Somosan has a Masters of Science from the University of Victoria. He spent several co-op terms at NewHeights before joining full time. He thesis topic was the evaluation of sets in interval constraints.


One of the less discussed effects of web applications is the liberation of interface design from the constraining shackles of "human interface guidelines". What were revolutionary manifestos are now ossified collections of constraints. In the first place, metaphors that were relevant in a period where humans were to be persuaded that their (real) desktops could be automated must be seen as irrelevant to generations who are only likely to see file folders and filing cabinets in museums. But, more importantly, the mechanisms of enforcement, namely the class libraries required to realize these guidelines are so complex that they necessarily put the power in the relationship between software architect and industrial designer in the hands of the software architect. This is precisely where it does not belong. The job of today's software architect is to design and guide the development of a product that reflects a projection of a customer's product or service offering in the manner considered to be most appropriate by the customer.

Because HTML form tags are hopelessly primitive, and because it is self evident that programming talent and graphic design talent are generally not co-resident, successful Web applications have relied on graphic designers to design the look-and-feel of their Web applications. The lack of a sound technological underpinning for graphics is one of the reasons why SVG is going to be at the heart of a dominant development paradigm for Web applications.

Our interest, however, lies on the desktop. As advantageous as Web applications are, they cannot compete with traditional rich-client applications in responsiveness. Humans are continuous, not transactional. Good desktop applications must appear to behave continuously, however they are delivered.

Our company, NewHeights Software Corporation, has developed an OEM product for Mitel Networks. Mitel Networks manufactures PBXs and telephones. Their most recent product lines include a range of Voice-over-IP telephones and PBXs. The product we developed for them is called "Mitel Network's 6600 Your Assistant". The development of this product has followed a path that is significantly different from the usual applications developed in the telephony world. The product is a desktop application that manages contacts and calls. It shows caller id information for incoming calls, allows its users to initiate outgoing calls, maintains call logs, and so on. In fact, the full product is feature rich - way beyond the capability of a Web application. Nevertheless, as is outlined in this article, the application has more in common with Web applications than desktop applications. The reason why this approach was taken is the main point of the article: the product design occurred in the industrial design laboratory, not in the software development shop. The people who designed the look-and-feel of the product also design telephones. Their computer tools are Adobe Illustrator, not Microsoft's Visual Studio. Our challenge was to take the illustrator images and accompanying behavioural specifications and implement them. We claim that this is not only a "disruptive" approach to software design, but it is an approach better suited to the modern world of convergence between the desktop PC, networked services and intelligent devices

The paper will present a brief evaluation of the product. One of the conclusions of this evaluation has led to our interest in compiling SVG, by which we mean the translation of SVG to a set of C++ or C# classes that use the Microsoft GDI+ library. We will describe our approach and discuss the major challenge, which is to find an alternative to DOM manipulation for generating dynamic, interactive graphics.

Table of Contents

1. Introduction
     1.1 The Changing Role of Software Architects
     1.2 Form and Function: The Designer
2. The changing face of GUI: HTML meets Swing
3. Your Assistant Architecture in Brief
4. Why SVG?
5. Why compile ?
6. How to Compile SVG
     6.1 Compiling Static Elements
     6.2 Dynamic Properties
7. Conclusions

1. Introduction

1.1 The Changing Role of Software Architects

In many cases, the purpose of a software system is to provide access to a service offering, often including hardware components. In our case, the software we developed is an adjunct to Mitel's 3300 IP PBX. (A PBX or Private Branch Exchange, is a telephone exchange use by organizations to manage their internal phones. An IP PBX uses IP for call-control and the Voice-Path. The connection to the outside world is not IP based.) The product we developed is called Mitel's 6600 Your Assistant. It is a software program that manages and provides assistance with telephone calls. It works with a desk-phone or with a built-in "soft" (voice over IP) phone. Its functionality includes pop-up windows that occur on an incoming call events, the ability to log and annotate calls, call recording, integration with PIMs (such as Microsoft Outlook) and a host of other features.

One of the most interesting parts of Your Assistant was the process by which it was developed. Mitel Networks is primarily a hardware company. They manufacture PBXs and a wide variety of enterprise telephones. Unlike home phones, enterprise phones may support a large feature set, such as conference-call set-up, transfer, multi-line capability and so on. Mitel have extensive experience in usability testing for hardware.

Mitel's 6600 Your Assistant was designed to project the service offerings of the 3300 PBX. That is, it was designed to help its users take advantage of the many features of the 3300. The design of the product was the culmination of almost eight years of experience in providing access to enterprise telephone functionality from a personal computer.

At the time actual software development started, the Mitel Design Centre had developed an extensive GUI document, containing many colour diagrams that had been generated using Adobe Illustrator. This document constituted a significant part of the requirement specification of the product. As software architects, our role was to figure out a way to deliver the required look-and-feel in a timely manner. Thereafter, there was a more-or-less continuous interaction between our development team and the Mitel design centre, at least until the visual design had stabilized.

1.2 Form and Function: The Designer

The look and feel of the product was designed by the Mitel Design Center. The people involved were both industrial designers and GUI designers. The tools they used were Adobe Illustrator and Macromedia Flash. Flash was used to test design concepts in the usability laboratory. Adobe Illustrator was used to produce illustrations of every aspect of the product, including screen shots, buttons in normal and depressed state, the look of menus, and so on.

The designers were concerned with both form and function. Their vision for the product was that the program should be obviously related to the Mitel telephone sitting on the users desk, next to the monitor. They therefore did not want to develop an application that looked like a conventional menu driven, multi-document Windows application. The earliest attempt to achieve this integrated appearance was essentially a bit-mapped rendition of the Mitel 5020 desk phone. Although this met the objective of being obviously tied to the phone, its functionality was equally obviously inadequate. Not only was it clumsy to use, especially when compared with using the desk phone directly, but it did not exploit the extra "space" that was made available by a computer monitor. Such an interface is used by a competing product, as shown in Figure 1 .


Figure 1: 3Com pcXset

The point is not to denigrate the competition, but to show that other design groups also wanted to project a vision of their software that was different from conventional applications.

A telling example of superior functionality is for the establishment and tear-down of a conference call. This functionality is available through special buttons on the 5020, but its use is non-obvious, leading to frequent inadvertent hang-ups when used by people who only occasionally needed conferencing capability. The obvious way to achieve a conference call on a PC is too allow the user to drag an icon from their contact list to the communication window.

The overall design of the product evolved to its present form to achieve the objective of projecting a distinctive look-and-feel, and also to offer users simple and intuitive access to the advanced feature offerings of the PBX. The design was so successful, that other Mitel groups have adopted what is now called the "Mitel end-user look and feel". Figure 2 is a screen shot of the main application view. Note that the panels can be detached and/or hidden from view, giving users a high degree of control over their own visual space.


Figure 2: Mitel's 6600 Your Assistant

2. The changing face of GUI: HTML meets Swing

A significant aspect of the design of the Apple Macintosh computer was its "Human Interface Guidelines" [HINTFC] . These guidelines were not exactly enforced, but the set of APIs that came with the Macintosh made it relatively easy for developers to conform to the guidelines, and very difficult to deviate from them. Most other graphical shells, including of course Microsoft Windows, have followed the lead set by Apple. One of the motivations for these guidelines was to make a the functionality of a variety of applications easy for users to learn. The central idea was the use of a common metaphor, and the introduction of a highly simplified "natural" language whose nouns were objects (such as files and folders) and whose verbs were a limited set of mouse actions (click, double click, held click, drag). Semantic richness was achieved by the use of a metaphorical object model and by using intelligent contextual information. For example, if I click on a folder, I want to see the contents of the folder. I probably do not want to open all the documents in the folder. There is naturally no doubt that these innovations were timely and brilliant. But it might be time to move on.

When Web applications became a reality, many people realized that programmers were not necessarily good graphic artists. In our own company, for example, this lead to the creation of a separate department whose job was graphical design. The earliest (programmer made) Web applications used the simple form tags provided by HTML. Today's web applications use a large variety of graphical techniques, and present a multitude of approaches to human-computer interaction. The influence of web applications is migrating to ordinary applications. A simple example is the sign-in screen used by Microsoft's Windows Messenger as shown in Figure 3 . Instead of a button, there is a hypertext link. In fact it is most likely that the entire inner frame shown is a rendered DHTM page.


Figure 3: Windows Messenger Sign-in Screen

Other applications, such as Intuit's Quicken, have also merged conventional GUI design with HTML-like paradigms. A small sample from Intuit's web site is shown in Figure 4


Figure 4: Intuit's Quicken Sample

Our view is that the rise of the graphics designer has had a liberating influence of the way in which people use PCs. The file/folder/desktop is obviously useful as a transitional metaphor, but is does not make sense to those people who did not need to make the transition, because they used PCs from the start. Furthermore, the Apple guidelines certainly projected Apple's corporate image, but the objective of other companies is to project their own image. Mitel's Design Centre is part of a collection of innovative groups who are breaking the guidelines, and offering new ways of visualizing service and product offerings.

3. Your Assistant Architecture in Brief

At the time we started the development of the product, we did not think we could meet the required delivery schedule using traditional techniques of Windows GUI design. We felt that we could achieve the required look-and-feel using an appropriate rendering engine, provided the engine supported a rich enough set of graphical elements.

Event handling and session management are at the heart of telephony applications. Early in the design process we decided to seperate the event model (for telephony events) from the modules that managed the graphical elements. We also decided to use the Model-View-Controller paradigm so that we could achieve the requirement of being able to "reskin" the product without writing any C++ code.block. We developed our own system for creating and managing graphical elements. This system is called "HelixRAD" because it is based on an earlier NewHeights product called Helix.

We devised an xml schema that divides a graphical element into four main parts:

  1. Parameters - these are formal parameters that are set by the caller
  2. A template - a DHTML document (using IE HTML and CSS);
  3. An attribute section which allows the association of an arbitrary JavaScript expression with any element's attribute;and
  4. A semantic section which defines event handlers for the elements defined in the template.

The template can reuse common components using the special "widget" element. We illustrate with a small (contrived) example in Figure 5 .

<widget id="SimpleWindow">
      <default>'SVG Open 2003'</default>
    <html xmlns:v="urn:schemas-microsoft-com:vml">
        v\:* {behavior: url(#default#VML);}
        <div id="mainPanel">
          <v:rect id="messagebox" style="position:absolute;width: 299;height:99%;left:0px;top:0px;">
            <v:stroke on="true"/>
            <v:fill color2="rgb(241,241,241)" color="rgb(204,204,204)"
              method="linear sigma" angle="90" type="gradient" />
        <div id="message" style="position:absolute"/>
	    <v:rect id="button" style="position:absolute;width: 80;height:20;left:100px;top:60px;">
	    <v:stroke on="true"/>
	    <v:fill color2="rgb(241,0,241)" color="rgb(204,204,204)"
	      method="linear sigma" angle="90" type="gradient" />
       	<div id="buttonText" style="position:absolute;width:40;height:114;left:130px;top:60px;"/>


  	this.message = "You have won $1,000,000!";



        <element id="window">
         <attribute id="width">300</attribute>
         <attribute id="height">100</attribute>
         <attribute id="top">150</attribute>
         <attribute id="left">150</attribute>
          <attribute id="title">this.attributes.title</attribute>

	<element id="message">
	<attribute id="style.left">50</attribute>
	<attribute id="innerHTML">this.message</attribute>
	<element id="buttonText">
	<attribute id="innerHTML">this.attributes.buttonCaption</attribute>

    <event name="window::activate"> = true;
    <event name="window::deactivate"> = false;
    <event name="button::mouseEnter">
    <event name="button::mouseLeave">
    	this.message="You have won $1,000,000!";

Figure 5: HelixRAD Message Box

The visual parts of Your Assistant are defined by a collection of such components. Common components (such as metalic buttons) can be re-used, both to reduce the number of components and to provide a consistent look-and-feel. Reskinning is easily achieved by providing a different set of components. There are many other aspects of HelixRAD which will not be described in this article, because they are not relevant to the main point, which is about the need for SVG and for compiled SVG.

4. Why SVG?

At the time we began the development of HelixRAD, we could not to commit to SVG because it was not yet generally available. We therefore chose the Internet Explorer engine, using VML [VML] , CSS [CSS] and DHTML [DHTML] . Although this gave us enough flexibility to produce the requested look of the first "skin", it has proven to be difficult to manage the templates. Part of the reason is that the range of choices is too wide. For example, div tags and CSS can be used as a kind of bit-level language for achieving any look-and-feel, but the resulting code.block is time-consuming to develop and almost impossible to modify. VML is a significant step forward, but we had to fall back on CSS and DIV tags whenever we hit VML limitations. SVG would be significantly better in this regard. Indeed, as we mentioned earlier, the product visionaries, working out of Mitel's Design Centre, used Adobe Illustrator to define the complete set of graphical elements for the product. Our job as developers was often to look at Illustrator hard copy, laboriously develop VML/DHTML templates, and send the results back to Mitel for review. Graphical issues that were important to them were sometimes not even noticed by the diligent developer. For example, two developers might be working on two separate but related elements, and not realize that the graphic designer had envisaged a fixed light source to cast shadows in a consistent way on the elements. These shadows were not only visually subtle, but they were difficult to achieve by hand. Clearly, SVG is superior, not only because it is graphically richer, but because of its superior tool support.

5. Why compile ?

It is clear that SVG, because of its design and tool support would have saved us development time, and would have produced more manageable code.block. However, it became (unfortunately) clear to us that there is a performance question to be considered.

One of our motivations for using our approach was because it enabled us to exploit a very sophisticated and powerful graphical rendering engine that is freely available on our target platform. We refer of course to the rendering engine used by both Internet Explorer and the Windows Operating System shell. This engine is implemented as a COM object, and is extensively and thoroughly documented by Microsoft. It is the presence of this engine that allows Web developers to "deploy" sophisticated Web applications with small DHTML files.

An alternative that is now available is to use an SVG rendering engine such as Adobe's SVG plug-in. This would have to be redistributed, but it is sufficiently powerful (almost by definition) to produce the kinds of graphical elements that were required for our product.

Note, however, that both the DHTML engine and the SVG engine are interpreters. They read and parse XML (or at least HTML in the case of the DHTML engine), producing and internal tree structure, which we will slightly inaccurately call the DOM tree, and then traverse the DOM tree, generating graphical images. Scripting languages provide the ability to modify the DOM tree, either before rendering, or in response to a user's actions. Now consider a small but common element such as a menu. A sensible way to create a menu is by parameterizing the menu name, and then by providing clonable components to represent the items in the menu. Unfortunately, the amount of work required just to respond to a menu-drop down request is quite large:

  1. Load the XML
  2. Create the DOM
  3. Change the text attribute for the Menu name
  4. Clone an item node for each menu item
  5. Set the text attribute of each item
  6. Traverse the resulting DOM tree, rendering it.

A little work can be saved by eliminating the cloning step by having distinct, predefined menus, but this choice comes at the price of increasing development complexity, and reducing reuse. Furthermore, there is still work to be done if we need to provide multi-lingual support.

If we compare this to the work required in a traditional compiled application, we can imagine that implementing a drop down menu is simply a matter of drawing rectangles and text at computed locations.

Time is not the only performance factor. The current rendering engines use a substantial amount of memory, both because of their generality and because they include other components including typically a complete JavaScript engine. High memory utilization has an effect on the responsiveness not only of the high-consumption application, but of any other concurrent applications, because of the increasing number of page-faults that the kernel must deal with.

Although the performance price might be worth paying in the case of web applications (where the dominant performance issue is connectivity, not rendering or local responsiveness), we now believe that users who are used to a seemingly continuous experience of conventional so called rich-client applications, may not be satisfied with GUI performance of interpreted DHTML or SVG.

We do require experiments to determine the speed up we could expect when compiling SVG compared to interpreting it. We would expect something like an order of 100 times, but such conclusions will have to be the result of future work.

6. How to Compile SVG

There are two distinct issues to deal with, which we will call the static and dynamic aspects.

6.1 Compiling Static Elements

Roughly speaking, compilation of the static elements of SVG is relatively straight-forward. Each SVG element is translated into a sequence of graphic calls in the target language. For the purpose of illustration, we will assume that the target is C++. More importantly, a graphics library called GDI+ is distributed with Microsoft's windows architecture. Most of SVGs elements map almost directly into a GDI+ object. Not only does GDI+ support the common geometric elements (such as rectangles, curves and so on), but it supports paths, including Bezier paths, and even graduated fills. Figure 6 shows a simple SVG document containing the renedring that may be produced by a designer for a simple drop-down menu, while Figure 7 shows the complete output of the compiler for this example. The compilers class library is required of course to compile the code.block.

	<rect id="Background" fill="lightgrey" width="200" height="200"/>
	<text font-size="14" font-family="CourierNewPSMT" x="20" y="28">File</text>
	<path fill="none" stroke="black" d="M10,10 L10,34 L 60,34"/>
	<path fill="none" stroke="white" d="M10,10 L60,10 L 60,34"/>
	<text id="menuname" font-family="CourierNewPSMT" font-size="14" x="120" y="28">File</text>

	<path fill="none" stroke="black" d="M10,150 h80 v-80"/>
	<path fill="none" stroke="white" d="M10,150 v-80 h80"/>
	<text font-size="14" font-family="CourierNewPSMT" x="20" y="90">New...</text>
	<text font-size="14" font-family="CourierNewPSMT" x="20" y="110">Open</text>
	<path stroke="black" stroke-width="0.25" d="M15,120 h 70"/>
	<path stroke="white" stroke-width="0.75" d="M15,124 h70"/>
	<text font-size="14" font-family="CourierNewPSMT" x="20" y="140">Exit</text>


Figure 6: SVG For Drop-down Menu (including roll-over)

class SVGDoc_1: public SVGDoc {

	SVGrect m_1;
	SVGtext m_2;
	SVGpath m_3;
	SVGpath m_4;
	SVGtext m_5;
	SVGpath m_6;
	SVGpath m_7;
	SVGtext m_8;
	SVGtext m_9;
	SVGpath m_10;
	SVGpath m_11;
	SVGtext m_12;
	void m_3_init(){
	void m_4_init(){
	void m_6_init(){
	void m_7_init(){
	void m_10_init(){
	void m_11_init(){
		m_1.setBrush(new SolidBrush(Color(211, 211, 211)));
		m_3.setStroke(Color( 0, 0, 0),0);
		m_4.setStroke(Color(255, 255, 255),0);
		m_6.setStroke(Color( 0, 0, 0),0);
		m_7.setStroke(Color(255, 255, 255),0);
		m_10.setStroke(Color( 0, 0, 0),0.25);
		m_11.setStroke(Color(255, 255, 255),0.75);
	void draw(HDC hdc){
		Graphics* g = new Graphics(hdc);
		delete g;

Figure 7: HelixRAD Message Box

Of course it should go without saying that an image rendered using a reference engine such as Adobe's SVG plug-in should produce identical results to those produced by GDI+. Unfortunately, we have not always found this to be the case. For example, Adobe seem to use a better anti-aliasing algorithm to Microsoft's GDI+ library. We have also found that lines whose specified width is less than 1 pixel do not render correctly in GDI+. In some cases, the differences are the result of subtle bugs which we expect to be corrected as they are discovered and repaired in the GDI+ library. In other cases, the differences are the result of slight differences in algorithms. For example, consider the butterfly sample from Mozilla [MOZILLA] as generated by our compiler, shown in Figure 8 .


Figure 8: Mozilla SVG Sample Butterfly

The same SVG code.block as generated by Adobe's plug in is almost identical, but close inspection does show some differences. Figure 9 shows and enlarged view of part of the central of the butterflies body.


Figure 9: Mozilla SVG Sample Butterfly Inset

Although such slight differences may not matter for illustrations, they may be problematic for designers who are using Adobe's engine as a reference. Guaranteeing that an SVG compiler will exactly match the SVG rendering engine would be difficult.

Support for filters is the most notable absence in GDI+. To support the built-in filters (such as Gaussian blur, for example), it is necessary to implement the filter in C++, or to find a suitable library.

Our draft compiler uses a predefined class hierarchy for the common elements. It is a three pass compiler:

Compiler Passes
Pass 1
Create a DOM-like tree, using an XML parser [FastXML]
Pass 2
Attribute the tree with semantic properties.
Pass 3
Generate a C++ class that subclasses the "SVGDocument" class in the predefined hierarchy.

The rest of the job is relatively straight forward. There is a predefined class corresponding to each SVG element type. The compiler generates statements that call methods on instances of these classes to set the appropriate attributes. Each defined element is declared and its draw method is called in the document's draw method.

6.2 Dynamic Properties

When SVG is to be used to generate GUIs, we have to deal with the dynamic aspect of SVG. Note that SVG is designed to support animation, and to integrate well with SMIL [SMIL] . However, in our Model-View-Controller pattern, these are not relevant. We do wish to be able to "program" a number of visual effects. The obvious and relatively straight forward ones are attribute changes. For example, we can easily change background colours, size and positions. The more interesting examples correspond to DOM changes in more traditional SVG/Web applications. The standard approach is for the rendering engine to include access to a JavaScript engine. The JavaScript code.block can access the root element, which is a DOM 1.2 tree. By manipulating the DOM, more or less arbitrary changes can be effected.

We can certainly imagine a hybrid compiler that generates C++ classes, but which also supports DOM. Briefly, we would do this by stitching the compiled instances together so that the DOM tree was preserved. It is also relatively easy to use a JavaScript engine (such as SpiderMonkey [SpiderMonkey] ) at run time. However, if performance is paramount, the hybrid approach is not acceptable.

Our preferred approach is to dynamically attach C++ event handlers to instances. For example, consider the menu example described above. We can achieve a similar effect in compiled code.block as follows:

The three elements making up a particular menu are compiled into three classes, M1, M2 and M3 (all subclass SVGElement). When the GUI element containing the menu is first drawn, we make an instance of M1 with the appropriate attributes (size, position etc). We attach a "MouseOver", "MouseOut" and "MouseDown" handler to the element.

The MouseOver handler creates an instance of M2 and hides M1. MouseOut does reverse. MouseDown instantiates M3 adding the appropriate handlers.

The work flow is:

  1. SVG elements - compiler - C++ classes
  2. C++ code.block with handlers
  3. XML "glue" specification + C++ classes - classes for GUI elements

This approach will be used as we extend the functionality of the prototype compiler. We should note that there are no present plans to replace the exisiting HelixRAD components with compiled SVG, just because of the amount of work such a re-write would require to an otherwise stable product.

7. Conclusions

Web programming is about more than distributed applications, or single point-of-deployment. The proliferation of tool support for Web application development, particularly in the area of graphics has led to a range of approaches to the visual aspect of applications that goes far beyond traditional client-side applications. Client-side applications are now undergoing a similar change. The file/folder/desktop metaphor was a wonderful transition from command line to more intuitive applications, but the metaphor is also a victim of its own success: the more people rely on personal computers (and other intelligent devices), the less familiar they will be with desktops, files and folders,

Enterprises that are in the business of selling product or services want applications that reflect the companies vision of the product or service offering. Software Architects will have to adapt their roles from the creators of the GUI to the realization of a GUI created in design laboratories.


Macintosh Human Interface Guidelines,
Kelvin Yeow, R. Nigel Horspool, Michael R. Levy,Expeditious XML Processing IDEAL 2002: 148-153
Mozilla SVG Project,
Vector Markup Language (VML), World Wide Web Consortium Note 13-May-1998,
Cascading Style Sheets, level 1,
HTML and Dynamic HTML,
Jeff Ayars, et. al. Synchronized Multimedia Integration Language (SMIL 2.0),
SpiderMonkey (JavaScript-C) Engine,,

XHTML rendition created by gcapaper Web Publisher v2.0, © 2001-3 Schema Software Inc.