SVG for SCADA Applications

A practical approach

Keywords: SCADA, HMI, monitoring, industrial automation

Rodrigo García García, Mr
Ph.D Candidate
Swiss Federal Institute of Technology Lausanne (EPFL)
Software Engineering Laboratory
CH-1015 Lausanne

Switzerland
rodrigo.garcia@epfl.ch
http://lgl.epfl.ch/members/~rodrigo

Biography

Rodrigo García García is a Telecommunication Engineer from the Technical University in Madrid. He is currently doing his PhD studies in the School of Computer and Communication Sciences of the Swiss Federal Institute of Technology Lausanne (EPFL). His collaboration with ABB Switzerland led him to study the applicability of SVG (Scalable Vector Graphics) to the development of operator interfaces for the industrial automation domain.

Esther Gelle, Ms
Dr ès Sciences EPFL
ABB Switzerland Ltd, Corporate Research
Information Technologies Dept.
CH-5405 Baden-Dättwil

Switzerland

Biography

Esther Gelle is a scientist at ABB Switzerland, Corporate Research. Her current research interests focus on configurable software systems, product configuration and monitoring applications in the automation world.


Abstract


In this paper, we study the applicability of SVG to SCADA (Supervisory Control and Data Acquisition) systems. One of the main purposes of a SCADA application is to provide an operator with the graphical interface needed to monitor and control the production processes in an industrial plant. Currently, most SCADA systems are based on bitmap graphics or proprietary vector formats to build the operator's interface. We investigate here the advantages and some of the emerging technical challenges of using a web standard such as SVG for developing the graphical components of a SCADA system and how to connect these components to the data sources that determine their appearance.


Table of Contents


1. Introduction to HMIs for SCADA applications
2. An Architecture for SVG Components
     2.1 CSS applicability to SVG
     2.2 CSS and the <use> element
         2.2.1 CSS composition
3. Conclusions and future work
4. A brief comparison of the SVG viewers available in the market
Footnotes
Bibliography

1. Introduction to HMIs for SCADA applications

The term SCADA defines a computer system used for gathering and analyzing real time data coming from industrial processes. SCADA systems are used to monitor and control a plant or equipment in industries such as water and waste control, energy, oil and gas refining, pulp and paper etc. While many of the tasks of a SCADA system do not need user interaction, some of them require the supervision or the actuation of a human operator. The operator's interface plays therefore a very important role in a SCADA system. All relevant information has to be shown to the operator in a clear and convenient way, conforming to current standards in process display graphics. This part of a SCADA system is commonly known as the HMI (Human Machine Interface) .

An important role in the context of an operator interface play the various symbols as defined in [ANSI/ISA-S5.5] . In order to represent a motor, for example, the motor symbol shown in Table 1 is used. The motor symbol consists of circle with a border containing the uppercase letter M standing for motor. Additionally, the symbol may be framed by a rectangle. The color of the circle, its border and the letter as well as the color of the rectangle and its border are defined by the state (off, on, alarm) of the device representing the motor symbol. A motor in on or run status for example will be represented by a green circle with a black border and a black letter M. The off status will simply make the background color of the circle change to grey. The alarm status on the other hand will be represented by the motor symbol in off status framed by an orange rectangle with black border. As shown, the motor symbol consists of various subcomponents that have a shape and that are assigned colors. However, the motor symbol is always handled in its entirety, it is placed, removed, clicked on by operators and engineers as a whole. In addition, each company may use its own color scheme in a systematic way. Therefore, such process display graphics require means for combining graphical root elements into symbol libraries and means for applying various standardized color schemes to these symbols. Some parameters such as the size of symbols should be applied to a symbol library as a whole in order to guarantee a standard look and feel.

Symbol Description
motoroff.gif
Motor in off state.
motorrun.gif
Motor in running state
motoralarm.gif
Motor in alarm state.

Table 1

Nowadays, this field is dominated by the use of ActiveX controls and bitmap graphics. However, we think that there is a chance for SVG to gain acceptance in this market. It is well-known, for instance, that bitmap images do not scale well. If an image is zoomed in, it soon appears pixelized to the human eye. Moreover, in order to change the state of a device represented by a bitmap image, it is necessary to load a completely different image file; even if the original image just required a color change to represent the new device state. Vector graphics, on the other side, describe an image by means of primitives such as a line, a circle, a rectangle etc. The image obtained is the result from rendering the specified set of primitives, which are independent of the specific user's display device. Consequently, a zoomed vector graphic does not loose quality, since the final value of the image pixels is calculated each time that the zoom is applied and a vector graphic is usually smaller in file size that its bitmap counterpart. Besides, changing the state of a device is usually simpler with vector graphics than with bitmap images, since it suffices to change a property like the color applied to a line or to a rectangle to get the new device state. In some cases though, it can be faster to replace one bitmap image by another than to change a property in a vector graphic and perform its rendering. However, the vector graphics approach is advantageous from the points of view of modularity, customizability and extensibility.

Modularity
The change in the state of a device only affects those graphical elements which have to change their properties. These single changes can be combined to represent a wide variety of different states. With bitmap images, one single image is required for each component state. For relatively complex graphical components, the combination of all possible values of graphical properties such as color, opacity or stroke thickness can lead to a state explosion, requiring lots of bitmap files just to be able to represent all the possible states of a component.
Customizability
Companies usually have their own standards for expressing the state of graphical components. Although there is a generally accepted use of specific graphical properties for representing a determined state, such as the use of the red color for showing an alarm state, the concrete graphical properties applied by one company can be subtly different from those used by another. A component delivered in an open vector format can have its state properties easily customizable by the user, since they can be directly exposed. On the other hand, a component delivered as bitmap images has to be edited with a graphics tool for being able to modify it. Since it is the pixels of the image which are directly modified, even for simple changes it can be difficult to get the desired results (e.g. changing stroke thickness).
Extensibility
Similarly to customization, it is easier to extend the number of possible states of a vector graphic than those of a bitmap image for almost the same reasons explained above.

Many modern HMI displays are built using ActiveX controls. This technology relies on COM (Component Object Model) , a component framework by Microsoft, and on the programming languages that can be used to build COM components, especially C++ and Visual Basic. ActiveX controls can include Windows forms, bitmap images or vector graphics for their visual appearance. Many companies in the industrial automation field have developed their set of symbol libraries for HMI based on ActiveX controls. The graphical quality of these controls may vary widely depending on the quality of the graphical libraries used. Typically, the interfaces based on vector graphics are built procedurally using the primitive functions of GDI (Graphics Device Interface) , a graphics Windows API, contrasting with the declarative nature of SVG. GDI, however, also allows to store vector graphics in metafiles which can later be processed calling the appropriate library functions. This mechanism allows the development of drawing tools able to load, manipulate and save metafiles, keeping the user from directly programming the graphical library. ActiveX controls, like SVG, can also be embedded in web pages, but only a Windows system with Microsoft Internet Explorer will be able to show them. This is one of the most important drawbacks of ActiveX technology: it is proprietary. Besides, ActiveX controls execute native Windows code, posing serious security problems to web users. In any case, ActiveX is a successful technology in the HMI domain thanks to the ubiquity of the Windows operating system, the maturity of COM and the relative easiness to script ActiveX components with Visual Basic.

2. An Architecture for SVG Components

One of the ideas behind SVG diffusion is that each domain community would develop libraries of graphical symbols to meet their needs. The <use> tag allows to reuse the symbols defined in the same or other SVG files [Bézaire 2003] . These SVG fragments can then be combined to form control-flow diagrams, electronic circuits, UML class diagrams or any other domain specific drawing. Industrial automation is one of the fields where a graphical components infrastructure is certainly useful, as demonstrated by the success of ActiveX components in this domain. Our idea was to verify the suitability of SVG graphics to the needs of industrial automation interfaces.

Our original architecture for industrial SVG components was based on four concepts:

  1. Each SVG component is described in a separate SVG file.
  2. Each SVG component is associated to a different CSS style sheet that holds the set of possible states of the component.
  3. Each SVG component is bundled with a piece of Java code (a Javabean) to allow its configuration and define its run-time behavior.
  4. An HMI interface is built from these components by means of the <use> tag. The Java code would apply a different style to each component, depending on the real-time data received from the plant and the user interaction.

However, we realized that this vision suffers from many problems with the current implementation of SVG and the way CSS style sheets are applied to SVG content.

2.1 CSS applicability to SVG

CSS was originally conceived to style HTML pages, not SVG. In a typical web (HTML) page, each tag defines a logical part of the document. For instance, the tag <h1> indicates that the text inside it is a main header. In this case, a CSS style sheet can use a selector h1 to define the style of the text enclosed by a <h1> tag. HTML tags define the logical structure of the document, whereas CSS defines the style of each document structure.

In SVG, however, it usually does not make sense to use a selector for a specific tag like in HTML because a graphic document is not a logically structured document. It is generally useless, for instance, to define the style for all the rectangles in a drawing (it would be rather uniform and not in accordance with a specified standard definition of symbols). The simplest and more used CSS selector in HTML pages is therefore rather useless in SVG.

On the other hand, HTML has a tag that does not describe the logical structure of its content and it only serves to group other elements. We are talking here about the <div> tag. Similarly to what happens to SVG tags, it is not very useful to give a single style to all the <div> tags in a HTML page. It often happens as well that we may want to apply a specific style to different elements of an HTML page, no matter what its tag is. The class attribute makes this possible by associating an HTML element to the specified class. CSS style sheets can define then a selector .classname that applies to all elements of the class classname. This is particularly useful in the case of SVG: we may not want to define a specific style for all the rectangles but only for those belonging to a certain class. In fact, there exists in SVG a tag very similar to the <div> tag of HTML that only serves to group other graphical elements: the <g> tag. As it happens with the <div> tag, the <g> elements especially benefits from the possibility of being assigned to a class, since it is usually a nonsense to apply the same style to all groups defined in a SVG file.

Finally, each element in a SVG or HTML page can be uniquely identified thanks to an <id> attribute. CSS allows to select a single element by using the notation #identifier and apply the style to that single element. CSS selectors can also be combined to reach specific elements of the SVG or HTML tree. This latter point is very important for our SVG components architecture, as we will see below.

2.2 CSS and the <use> element

The <use> allows to reference a SVG component defined in the same or in an external file. This tag is the basis of our component architecture. However, the combination of the <use> tag and CSS has two drawbacks:

  1. The <use> tag hides the tree structure of a SVG component.
  2. An external component (defined in an outer SVG file) can use a style sheet associated to the external document.

In the first case, that means that CSS selectors cannot access the inside structure of the component, which reduces the usefulness of styling <use> elements to none but the simplest cases. For instance, we can associate a style to an use element by means of the class attribute. But this style will affect all the subcomponents inside the component referenced by the <use> tag (at least all those that inherit the style property). It is not possible, for example, to select a subcomponent and give one color to it and, at the same time, specify another color for another subcomponent of the used complex component. In the second case, the problem comes from the fact that the external style sheet is unknown to the hosting document: it is importing the SVG component but not the style sheet. In figure Figure 1 , we see how the color of a simple motor symbol can be modified by setting the appropriate class attribute in the <use> element. The code for this example can be found in figure Figure 2 and the CSS stylesheet in figure Figure 3 .

simplemotor.svg

Figure 1: Simple motor symbols showing state

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<?xml-stylesheet href="simplestyle.css" type="text/css"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" 
         "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg xmlns="http://www.w3.org/2000/svg"
     xmlns:xlink="http://www.w3.org/1999/xlink" width="200" height="200">
	<title>Simple motor symbol</title>
	<desc>Motor process symbol as used in electronic schematics</desc>
	<defs>
		<symbol id="motor" viewBox="0 0 100 100" preserveAspectRatio="xMidYMid meet"
		 stroke-width="2">
			<circle cx="50" cy="50" r="30"/>
			<path d="M 40 60 L 40 40 L 50 50 L 60 40 L 60 60"/>
		</symbol>
	</defs>
	<g>
		<use xlink:href="#motor" class="on" x="10" y="10" height="80" width="80"/>
		<use xlink:href="#motor" class="off" x="110" y="10" height="80" width="80"/>
		<use xlink:href="#motor" class="alarm" x="10" y="110" height="80" width="80"/>
		<use xlink:href="#motor" class="repair" x="110" y="110" height="80" width="80"/>
	</g>
</svg>

Figure 2: Using the simple motor symbol

.on
{
	stroke: black;
	fill: lime;
}

.off
{
	stroke: black;
	fill: lightgrey;
}

.alarm
{
	stroke: black;
	fill: red;
}

.repair
{
	stroke: black;
	fill: deepskyblue;
}

Figure 3: The four states of the simple motor symbol

In the simple motors figure Figure 1 , we have represented the alarm state by painting in red the circle which encloses the big M in the middle. However, in figure Table 1 we have seen that the usual schematic for showing a motor in an alarm state has a red square in the background, keeping the inner circle in grey. In order to represent it correctly, we extend the code of the simple motor and divide it into two subcomponents: the background and the foreground. We differentiate them by means of a class attribute. In figure Figure 4 , we show the code used to implement this extended version of the simple motor. With this example, we want to demonstrate how the <use> element hides the SVG tree of the motor symbol, preventing the CSS selectors to affect its subcomponents. In order to prove this, we have made a copy of the motor symbol in the render section of the SVG document by using a <g> element. Contrary to the figure produced with the <use> element, this copy has its tree available for CSS styling.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<?xml-stylesheet href="motorstyle.css" type="text/css"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" 
         "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg xmlns="http://www.w3.org/2000/svg"
     xmlns:xlink="http://www.w3.org/1999/xlink" width="240" height="120">
	<title>Motor schematic</title>
	<desc>Motor process symbol as used in electronic schematics.</desc>
	<defs>
		<symbol id="motor" viewBox="0 0 100 100" preserveAspectRatio="xMidYMid meet"
		 stroke-width="2">
			<g class="background">
				<rect x="0" y="0" width="100" height="100"/>
			</g>
			<g class="foreground">
				<circle cx="50" cy="50" r="30"/>
				<path d="M 40 60 L 40 40 L 50 50 L 60 40 L 60 60"/>
			</g>
		</symbol>
	</defs>
	<g>
		<!-- A copy of the motor symbol -->
		<g id="motor1" transform="translate(10,10)" stroke-width="2" class="alarm">
			<g class="background">
				<rect x="0" y="0" width="100" height="100"/>
			</g>
			<g class="foreground">
				<circle cx="50" cy="50" r="30"/>
				<path d="M 40 60 L 40 40 L 50 50 L 60 40 L 60 60"/>
			</g>
		</g>
		<!-- Using the motor symbol hides subcomponents -->
		<use xlink:href="#motor" class="alarm" x="130" y="10" height="100" width="100"/>
	</g>
</svg>

Figure 4: Hiding subcomponents from CSS selectors

The stylesheet applied to this code is shown in figure Figure 5 . Basically, the stylesheet says that all elements of the class alarm should be filled with red color, but those of class alarm which are of class foreground at the same time, should be filled with grey color.

.alarm
{
	stroke: black;
	fill: red;
}

.alarm .foreground
{
	stroke: black;
	fill: lightgrey;
}

Figure 5: CSS stylesheet for the subcomponents example

The result is shown in figure Figure 6 . On the left, we have the result of rendering the copy of the motor symbol. In this case, the CSS selectors detect the group element of class foreground, which also inherits the class alarm from its parent element. Thus, following the CSS rules, the inner circle appears in grey and the square background in red as expected. On the right, the result of rendering the <use> element is shown. Here we find that everything is filled with red color, as the alarm CSS rule states, because the foreground subcomponent is hidden from the stylesheet. The subcomponents of a SVG fragment are invisible to CSS selectors.

motor.svg

Figure 6: Result of hiding subcomponents

2.2.1 CSS composition

In our original architecture, we proposed to have a different style sheet per SVG component. However, we have just seen that the style sheet defined for one SVG component is not automatically imported by another SVG file using the component. Therefore, the style sheet has to be manually imported into the SVG file, but even adding it manually does not solve all the problems. CSS is not namespace aware and it was not conceived to be applied to fragments of a document but to a document in its entirety. If all the components used by a SVG file come with their own set of states defined in a different CSS file, there is still the possibility of importing all the CSS files by using the import command within the <style> element. The SVG file can also be linked to the set of CSS files by using several <?xml-stylesheet ...?> processing instructions. However, the selectors names can clash or be combined following the cascade rules of CSS. The result is that each component defined styles are not guaranteed to be kept separated when combining the CSS files where they are declared. In figures Figure 10 Figure 11 , we show what happens when two CSS files are linked to the same SVG document and they have the same rules defined. We present first the code of the big motor schematic in figure Figure 7 . In the definitions section we find some linear gradients that give the motor a three dimensional appearance.

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="bigmotorstyle.css" type="text/css"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" 
         "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg xmlns="http://www.w3.org/2000/svg" width="240" height="80">
	<title>Motor</title>
	<desc>Motor symbol as depicted in process control diagrams</desc>
	<defs>
		<linearGradient id="greyThreeD" x1="0%" x2="0%" y1="0%" y2="100%">
			<stop offset="0%" stop-color="grey"/>
			<stop offset="30%" stop-color="white"/>
			<stop offset="100%" stop-color="black"/>
		</linearGradient>
		<linearGradient id="greenThreeD" x1="0%" x2="0%" y1="0%" y2="100%">
			<stop offset="0%" stop-color="green"/>
			<stop offset="30%" stop-color="lime"/>
			<stop offset="100%" stop-color="black"/>
		</linearGradient>
		<clipPath id="cliprect">
			<rect x="0" y="10" width="120" height="60" stroke="black"
			 stroke-width="2" fill="none"/>
		</clipPath>
		<symbol id="motor" viewBox="0 0 120 80" preserveAspectRatio="xMidYMid meet">
			<circle cx="60" cy="40" r="50" clip-path="url(#cliprect)"/>
			<rect x="20" y="10" width="80" height="60"/>
			<path d="M 110 40 L 114 40 M 114 42 L 114 38"/>
		</symbol>
	</defs>
	<g>
		<use xlink:href="#motor" class="on" x="0" y="0" height="80" width="120"/>
		<use xlink:href="#motor" class="off" x="120" y="0" height="80" width="120"/>
	</g>
</svg>

Figure 7: Big motor schematic with 3D effect

The CSS for the big motor defines the on and off states Figure 8 . They happen to have the same name as some of the states of the simple motor Figure 3 . However, the CSS rules for the big motor refer to the linear gradients defined in the SVG file above, so they are different from the plain colors used by the simple motor.

.on
{
	fill: url(bigmotor.svg#greenThreeD); 
	stroke: black;
}

.off
{
	fill: url(bigmotor.svg#greyThreeD); 
	stroke: black;
}

Figure 8: CSS stylesheet for the big motor

Figure Figure 9 is an example of how the two states of big motor are rendered.

bigmotor.svg

Figure 9: Big motor in on and off states

But let us see what happens if we try to use the simple motor and the big motor in the same file. To be able to style both components, we have to link the SVG file to both the CSS of simple motor and the CSS of big motor. We thus use two xml-stylesheet processing instructions. However, since both files define the on and off states which, in turn, define the fill property, the result will depend on the linking order. If the big motor stylesheet is processed first, the simple motor stylesheet will overwrite the on and off rules and the result will be like the one shown in figure Figure 10 . On the other hand, if the simple motor stylesheet is linked first, the big motor rules will impose and the result will be that of figure Figure 11 . The code for this latter case can be found in figure Figure 12

composition.svg

Figure 10: The style of simple motor wins

composition2.svg

Figure 11: The style of big motor wins

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<?xml-stylesheet href="simplestyle.css" type="text/css"?>
<?xml-stylesheet href="bigmotorstyle.css" type="text/css"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" 
         "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg xmlns="http://www.w3.org/2000/svg"
     xmlns:xlink="http://www.w3.org/1999/xlink" width="300" height="150">
  <g>
    <use xlink:href="simplemotor.svg#motor" class="on" x="0" y="0" width="50%" height="50%"/>
    <use xlink:href="bigmotor.svg#motor" class="on" x="0" y="50%" width="50%" height="50%"/>
    <use xlink:href="simplemotor.svg#motor" class="off" x="50%" y="0" width="50%" height="50%"/>
    <use xlink:href="bigmotor.svg#motor" class="off" x="50%" y="50%" width="50%" height="50%"/>
  </g>
</svg>

Figure 12: Composition of stylesheets

3. Conclusions and future work

Although the concept could seem interesting in the beginning, our original architecture is not valid with the current implementations of SVG and CSS. The facts that style sheets are applied to whole documents rather than to specific components and that the full SVG tree of a component is hidden when it is used in another SVG file really limits our vision of how a component infrastructure could be built upon SVG and CSS.

We shall follow the evolution of SVG with the arrival of SVG 1.2 and RCC (Rendering Custom Content) , an extension to SVG that allows user defined XML to reference SVG content and that serves primarly to create GUI widgets. RCC exposes the internal structure of the graphical components by means of shadow trees and it will probably make possible to apply styles in a component based way, instead of the document based way of CSS. We will follow as well the evolution of different markup languages to define GUIs such as XUL (XML User-interface Language) and XAML (XML Application Markup Language) , on which RCC seems to be inspired. We are sure that XAML will be a particularly important competitor of SVG on Microsoft platforms since, opposite to XUL, it also includes all the necessary to create high quality vector graphics.

4. A brief comparison of the SVG viewers available in the market

During the realization of this project, we have tested three tools for visualizing our SVG components: Corel SVG Viewer 2.1, Adobe SVG Viewer 3.0 and Batik Squiggle 1.5.1 ( Table 2 ). The two former viewers have been developed by well established firms in vector graphics and computer graphics in general and they are distributed as plug-ins for different web browsers. The latter viewer is a Java application developed by the Apache Software Foundation and it is distributed as part of the open source Batik project. The Batik toolkit provides the necessary libraries to generate and manipulate SVG content from Java programs, as well as some utilities to transform SVG to raster formats (PNG, JPEG...).

All three viewers have a similar rendering quality and they all support JavaScript/ECMAscript for user interaction, although Adobe SVG Viewer is the only one that provides SMIL (Synchronized Multimedia Integration Language) based animation. Nevertheless, there were two viewer features that we considered particularly important for our project: the ability to link to external SVG resources and the possibility of using a compilable and modular language for scripting. One of the main goals of this project was to demonstrate wether it was possible to build an operator's interface by using SVG component libraries. That is why it was very important to have a SVG browser that allowed links to SVG content located in external files. Adobe SVG Viewer does not render SVG fragments located in external SVG files. Squiggle is the most flexible: allows external links and scripting in the Java programming language as described in Appendix D of the SVG 1.1 specification [SVG 1.1] . Besides, Squiggle can be configured to restrict access or not to external resources, to enable or disable scripting or to allow or not the scripting language to access the file system or the network.

Comparison among available SVG viewers.
Adobe SVG Viewer 3.0 Corel SVG Viewer 2.1 Batik Squiggle 1.5.1
External SVG resources No Yes Yes
Java Binding No No Yes
SVG/SMIL animation Yes No No
Browser plug-in Yes Yes No

Table 2

Footnotes

  1. The pre-release (beta version) of Adobe SVG Viewer 6.0 does allow links to external resources.

Bibliography

[ANSI/ISA-S5.5]
Instrument Society of America (ISA), ANSI/ISA-S5.5 Graphic Symbols for Process Displays, 1985.
[Bézaire 2003]
Benoît Bézaire, The Next Generation of SVG Files: SVGFragments, Proceedings of the 2nd Annual Conference on Scalable Vector Graphics, SVG Open 2003, July 2003, Vancouver (Canada). Avalilable: http://www.svgopen.org/2003/papers/TheNextGenerationOfSVGFiles/index.html
[SVG 1.1]
W3C (MIT, ERCIM, Keio), Scalable Vector Graphics (SVG) 1.1 Specification, 2003. Available: http://www.w3.org/TR/SVG11
[SVG 1.2]
W3C (MIT, ERCIM, Keio), Scalable Vector Graphics (SVG) 1.2, Working Draft, 2004. Available: http://www.w3.org/TR/SVG12
[Adobe SVG Viewer]
Adobe Systems Incorporated, Adobe SVG Viewer, 2004. Available: http://www.adobe.com/svg/viewer/install/main.html
[Corel SVG Viewer]
Corel Corporation, Corel SVG Viewer, 2003. Available: http://www.smartgraphics.com/Viewer_prod_info.shtml
[Squiggle]
The Apache Software Foundation, Squiggle - The SVG Browser, 2002. Available: http://xml.apache.org/batik/svgviewer.html

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