Bullseye
you are in savethegaywhale || msc || literature
2 Review of Literature
Macromedia's Flash is the primary means of delivering interactive vector graphics
over the Internet (Neumann and Winter, 2001). It is a proprietary format requiring
Macromedia's Flash editor to generate an editable .fla file or a non-editable binary
.swf format file suitable for use on the Internet (Probets et al, 2001).
The .swf files require a browser plugin, which is free a 466Kb download from Macromedia
Inc (Macromedia Inc (2), 2003). A recent survey undertaken by NPD for Macromedia
Inc (Macromedia Inc (4), 2003) argues that that 98% of Internet viewers have access
to Flash content, however this is a survey commissioned by Macromedia. Consequently
it cannot be regarded as truly independent, especially as Macromedia Inc. (Macromedia
Inc (4), 2003) concede that they have merely extrapolated the U.S.A. based results
to give a global figure.
Fig 1: Plugins on Internet enabled computers. Source Macromedia Inc. ((4), 2003).
Flash has been available since 1996 and has iterated through 7 versions, so can reasonably be considered a mature Internet technology.
SVG is a W3C recommendation, based on XML (it is an XML namespace), for an open standard (Johnson-Eilola, 2002) for interactive vector graphics on the Internet (Duignan et al, 2003). As an XML namespace the file format is text based so any text editor as well as bespoke graphics programs can create SVG files (.svg) (Trippe and Binder, 2002).
Like Flash, SVG format files also require a browser plugin, being an open standard, there are a number of implementations. To date, the dominant plugin is Adobe SVG viewer version 3 (ASV3) (Duignan et al, 2003). The small number of Internet viewers with access to SVG enabled browsers compared to the near ubiquity of the Flash plugin is a disadvantage for SVG (Neumann and Winter, 2001). The emergent nature of SVG compared to Flash is demonstrated in table 1.
Summary of key events in the development of SVG.
| Aug 2000 | SVG 1.0 is W3C candidate recommendation |
| Sept 2001 | SVG 1.0 is W3C recommendation |
| Jan 2001 | Adobe viewer 2 released |
| Nov 2001 | Adobe viewer 3 released |
| Nov 2002 | SVG 1.1 is W3C proposed recommendation |
| Nov 2002 | SVG 1.2 is W3C 1st working draft |
| Jan 2003 | SVG Mobile Profiles are W3C recommendation |
| Jan 2003 | SVG 1.1 is W3C recommendation |
| July 2003 | Adobe beta viewer 6 released incorporating features of the current W3C Working Draft on SVG 1.2, released in July 2003 |
Table 1: Summary of key SVG events. Source: World Wide Web Consortium ((1), 2003).
The dominant format for delivery of 2D graphics on the Internet is bitmap. Bitmaps are a matrix of pixels values that compose an image (Badros et al, 2001). This means that images of similar dimensions and format will have similar file size. The primary formats, summarised from Chapman and Chapman (2002) are:
· Graphics Interchange Format (GIF) a lossless compression restricted to 256
colours, its ability to assign a colour as transparent combined with its simplicity
makes it suitable for the display of icons and simple cartoon images, with small
file size.
· Joint Photographic Experts Group (JPEG) a lossy compression, so image degradation
can be problematic; however it is suitable for reducing images of a complex nature
or high resolution to a size suitable for display on a monitor.
· Portable Network Graphics (PNG) developed to supersede GIF and circumvent the
patent restrictions (owned by Unisys) on GIF. It is a W3C recommendation as of October
1996 (World Wide Web Consortium (4), 2003). It is not restricted to 256 colours
and has better support for transparency.
Whilst bitmaps are very limiting with respect to interaction (Neumann and Winter, 2001), they do reflect the evolution of the Internet. The Internet started out as a text based medium, followed by the introduction of static images in bitmap format, which require limited client side resource. Bitmaps are also the native form of source image; such as scanned, screenshot captured and digitally photographed images (Chapman and Chapman, 2002) and therefore relatively simple to create (Cagle, 2002) which encourages their use. Such images are often rich in texture, which bitmaps are ideal for (Cagle, 2002).
Vector graphics are very different from bitmaps. Whilst bitmaps state the properties
of each individual point of colour, in vector graphics the logical entities (curves,
lines and text) are described, only when the image is to be rendered are the low
level pixel values calculated (Duignan et al, 2003). This gives vector graphics,
some key differentiating characteristics from bitmaps.
Vector graphics are:
· Many times smaller than for a similar bitmap, reducing bandwidth requirements.
· Scalable and transformable.
· Resolution independent.
A further key difference is in the way that vector graphics are delivered over a network, such as the Internet, to the user: the bitmap is rasterized server side whereas the vector graphic is rendered client side as shown in figure 2.
Delivery of bitmap across network Delivery of vector graphic across network

Fig 2: Image display across a network. Source: Badros et al, 2001.
In addition to Flash and SVG, other vector graphic formats include:
· Postscript, Adobe Systems page description language
· PDF, Adobe Systems Portable Document Format, very similar to Postscript level
2 and is de facto cross platform standard for displaying documents on the Internet,
in addition to above features; PDF files have limited interaction.
· Precision Graphics Markup Language (PGML), draws on the former two formats; when
the W3C requested submissions in 1998 for a new vector graphics standard on the
web, PGML was a submission from Adobe Systems.
· VML, Microsoft's Vector Markup Language, originally submitted to W3C along with
PGML. VML has native support in the Internet Explorer browser.
The PGML and VML submissions were heavily drawn on for the SVG proposed recommendation of August 2000, with PGML providing much of the graphics model and VML providing the tags and their attributes. (Probets et al, 2001)
2.5 Relative dominance of Flash
Flash is the de facto standard for delivery of interactive vector graphics on the Internet. This, as Norman (1999) asserts, is a substantial impediment for any other new technology seeking to enter a marketplace as, provided the existing technology is satisfactory, users will be reluctant to switch unless the perceived benefits outweigh the costs of implementation and new learning. Considering empirical evidence, Bassanini and Dosi (1999) argue that a market dominated by one technology is likely to be long lasting and stable. Such a market can reasonably be expected to resist the introduction of a competing technology. These arguments are pertinent to the following section.
The greatest limitation, and accessibility issue at the time of writing, has to be the limited penetration of browser plugins (Watt et al, 2002) (Neumann and Winter, 2001). The leading implementation (Duignan et al, 2003) is the Adobe SVG viewer 3 (ASV3) and its successor version 6 (ASV6) (Adobe Systems, 2003). This plugin (ASV3) ships with the Adobe Acrobat Reader and other Adobe software, it is only available to 18% of all Internet users according to a survey by Macromedia (Macromedia Inc (4), 2003), although care must be taken as such a survey cannot properly be regarded as truly independent. This does suggest a question; is the lack of penetration due to a lack of suitable content or is the lack of content due to a lack of viewer penetration? Bassanini and Dosi (1999) imply the latter to be the case. If this is so, then wider distribution of plugins or viewers embedded into browsers is a prerequisite for the widespread uptake of SVG. This situation is also not assisted by the size of plugin (Watt et al, 2002) (2.3Mb for ASV3 and 2.9Mb for ASV6), whereas the equivalent plugin for Flash is only 466Kb.
This situation will be improved if browser vendors add native SVG support to their products. Mozilla (Mozilla SVG Project, 2003) are in the early stages of implementation, but it is far from fully featured. However, Mozilla account for approximately 2.3% of web page accesses, whereas Microsoft Internet Explorer account for 94% of all accesses (Upsdell, 2003). However the following extract from Microsoft could arguably be interpreted as an intention on their part to natively integrate SVG viewing into Internet Explorer.
'Due to the cutting-edge nature of SVG and its current lack of native support across all major browsers, Web site visitors will often need to download and install a specialized viewer, such as the Adobe SVG Viewer or the upcoming Corel SVG Viewer, to see SVG content within Web pages (at least until the browsers themselves natively support SVG as they do most other graphics formats). (Microsoft.com, 2003).'
Probets et al (2001) observe that when the W3C initially asked for proposals for a new vector graphic standard, one of the proposals was Microsoft's VML, which is native to Internet Explorer. It is a matter for conjecture that Microsoft may have been waiting to see if VML became the dominant means of delivering vector graphics over the Internet, before seeing if native support for SVG was necessary.
The W3C have undertaken a study (World Wide Web Consortium (6), 2003) of SVG viewers. This involved testing each implementation against a test suite of SVG features. The results, summarised below, could be considered poor. A key area of failure was with respect to (hyper) links. Given that one of the primary areas of Internet interactivity is hyperlinks, this can be considered a significant weakness in the implementations (shown as 'link fails' in table 2). The test suite is also limiting in that it does not test combinations of interactive features (such as JavaScript) within a single file containing SVG. This is a potential area for further work.
Summary of analysis of SVG viewers' performance done by W3C.
| ASV6 | ASV3 | Batik | CSV | Amaya-81 | Mozilla SVG | |
| pass | 173 | 168 | 150 | 116 | 51 | 48 |
| fail | 6 | 10 | 30 | 53 | 104 | 126 |
| partial | 2 | 3 | 1 | 12 | 26 | 7 |
| unknown | 0 | 0 | 0 | 0 | 0 | 0 |
| total | 181 | 181 | 181 | 181 | 181 | 181 |
| link fails | 5 | 5 | 0 | 40 | 3 | 3 |
Table 2: SVG viewer performance. Source: World Wide Web Consortium (6), 2003.
Key:
ASV6 is Adobe SVG Viewer, version 6 (beta).
ASV3 is Adobe SVG Viewer version 3.
Batik is Apache Batik Squiggle browser (JAVA platform).
CSV is Corel SVG viewer, version 2.
Amaya-81 is the Amaya Editor/browser version 8.1.
Mozilla SVG is Mozilla SVG project.
A primary difference between Flash and SVG as observed by Trippe and Binder (2002) is that SVG is an open standard owned by the W3C and governed by its 7 points (World Wide Web Consortium (7), 2003) whereas Flash is a propriety format owned by Macromedia. Whilst Macromedia have made the SWF file specification available to the public, (Macromedia Inc (3), 2003) a software development kit (SDK) they used to distribute is no longer available. This is contrary to what Trippe and Binder (2002) state, but in line with their concern that Macromedia is free to change the format or suspend distribution of tools as it sees fit. Neumann and Winter (2002) observe that as an open standard SVG will have a longer life cycle, however there would be limited commercial logic in Macromedia significantly altering a commercially successful format beyond their current strategy of incremental development. In order to access the full functionality of the Flash format, applications must be developed in Macromedia's authoring tools, (Duignan et al, 2003) whereas SVG can be developed in any text editor as well as authoring tools such as Adobe Illustrator. Furthermore, it is argued by Neumann and Winter (2002) that open source projects are better documented and tested. Cagle (2002) observes that the open standard nature of SVG is encouraging the development of numerous authoring tools, this variety and quantity is very likely to drive down the price of individual applications and encourage some developers to work with SVG rather than (or as well as) Flash.
Neumann and Winter (2002) express concern that cartographers would be unable to protect their source code due to the text based nature of SVG, for cartographic data, this is potentially significant as it will normally be subject to United Kingdom copyright. As will be discussed later SVG lends itself to cartographic display over the Internet, Neumann and Winter (2001) suggest that non-visible noise can be added to reveal infringements. It is questionable as to whether that would be sufficient to prevent infringement. The Flash SWF format is non-editable (Probets et al, 2001) and it is reasonable to suggest that this may encourage the development of applications in that format as it better protects intellectual property.
Flash in final form is a non-editable, binary format rendered by a browser plugin,
whereas SVG is in plain text and also requires a browser plugin to view. A list
of file format differences compiled by Neumann (2002), are summarised in appendix
1.
Probets et al (2001) undertook early work on the conversion of Flash to SVG and
compares the key differences in the semantics of the graphics. Many of these differences
arise from the essentially linear nature of Flash, it moves along a timeline on
a frame by frame basis. Whereas in SVG the declarative animation model permits animation
using the animate tag, this allows any attribute (position, opacity) to be changed
over a defined period of time. This potentially creates greater complexity for SVG
than Flash at rendering time and may, in part, explain why SVG viewers have a larger
file size than Flash players. This may also be a partial explanation (as discussed
in 6.13) as to why computers can lock up when rendering SVG.
Probets et al (2001) indicate that an SVG files are up to twice the size of their
flash equivalents (when compressed using gzip compression as supported by the SVG
specification). SVG (as an XML based language) has a hierarchical model that supports
groups and subgroups of primitives with inherited properties. This does imply that
simple final form Flash (SWF) files will be smaller than their equivalent SVG files,
which have overheads in declarations. However as the images and animations become
more complicated, such as, observes Probets et al (2001), the inclusion of multiple
instances of a bitmap, Flash movies would embed each instance of the bitmap whereas
SVG images would reference to a single instance source of the bitmap, which would
probably be cached client side.
Probets et al (2001) argued that much of the existing Flash material on the Internet will be converted to SVG. However he and his colleagues were writing before SVG 1.0 was only a W3C candidate recommendation. The converter that was developed was limited in its features, it could not support Flash features beyond Flash version 2. It can be argued that in order for SVG to become a significant format for the delivery of vector graphics over the Internet, SVG has to demonstrate advantages over Flash rather than the mere sense of equivalence conversion brings. Given the previously mentioned dominance of Flash plugin there seems little need to convert widely accessible material. This is borne out by the fact that Probets et al (2001) appear to have done no further published work in the area of Flash to SVG conversion, in addition the links provided to the converter prototypes no longer function at the time of writing.
Accessibility can be considered from 2 aspects, in order to make Internet pages available to as wide an audience as possible they should be available to search engines and accessible to those with special needs.
Leading search engines such as Google, rank pages by the number of links pointing to them (Yaltaghian and Chignell, 2002) and it is harder to extract links from a Flash page than from an HTML page (Trippe and Binder, 2002). This can be partially alleviated in pages made up of hypertext markup language (HTML) and SWF files where it is easier to include Meta data. However as SVG has a human readable text based format it can easily be read by any search engine.
Trippe and Binder (2002) also observe that it is easier to build accessibility into Internet pages for those with special needs in SVG rather than Flash, a significant consideration for many commercial developers, especially in countries that have relevant legislation. Trippe and Binder (2002) argue that the features of SVG they list for special needs access to Internet pages are clearly superior to Flash based pages, however Moock, (2002) discusses the Accessibility object in Flash MX ActionScript which can communicate with accessibility aids. This does suggest that Flash is more accessible than Trippe and Binder (2002) imply, however their underlying point that the open standard and text based nature of SVG makes it innately more accessible. Watt et al (2002) also note that SVG as a language is designed from first principles to be accessible according to theW3C 'Web Accessibility Initiative' (World Wide Web Consortium (7), 2003), arguing that accessibility in part comes down to good coding.
The next generation computers will be non-desktop devices, such as smart phones and PDA's (Vuorimaa et al, 2002).
Badros et al (2001) and Marriot et al (2002) proposed (and developed proof of
concept) introducing constraints into SVG to enable SVG to render on different devices
or with different emphasis on elements of the image to assist users with special
needs (as shown in figure 3):
· Semantic zooming: this allows users to view subsections of a diagram whilst retaining
the form of the whole.
· Differential scaling: this is a technique to zoom in on one aspect of an image,
such as the text elements.
· Semantics preserving manipulations: users can perform transformations without
altering the semantic content or logical structure.

Fig 3: Effect of alternative zooms on a network diagram. Source: Badros et al, (2001)
However this work is already dated, the W3C have released mobile profiles (World Wide Web Consortium (3), 2003) as have Macromedia (Macromedia Inc (1), 2003)
Trippe and Binder (2002) argue that the greatest difference between Flash and
SVG is workflow. They argue that designers using software such as Adobe Illustrator
can simply save work as SVG and developers can use a variety of scripting languages
with which they are already familiar. Neumann and Winter (2002) develop this last
point by outlining a variety of workflows for SVG beyond exporting from graphics
software, such as printer drivers, similar to PDF print drivers, where the application
can 'print' to an SVG file. Neumann and Winter (2002) also observe that for corrections
and additions to an SVG file any text editor is suitable, an option not available
to the binary format Flash. Whereas to design and develop in Flash it is necessary
to use Macromedia's Flash program, which is inflexible and has a steep learning
curve assert Trippe and Binder (2002). This judgement, it can be argued, is harsh
as the amount of Flash content on the Internet could be said to contradict this.
But it does suggest that developers and designers with skills in XML and suitable
drawing programs will have to do little new learning.
Apart from Probets et al (2001), no work exists which compares any aspect of Flash to SVG.
Rutledge et al (1999) undertake an evaluation of Synchronised Multimedia Integration Language (SMIL), which is a W3C recommendation. SMIL (an XML based language) can be used to control relationships between multimedia elements, such as SVG (Vuorimaa et al, 2002). The evaluation considered scenarios for multimedia presentation and attempted to identify weaknesses and propose solutions (extensions to SMIL). The discussion by Rutledge et al (1999) does not wholly explain the criteria used for the evaluation (it would not be possible to replicate this work). However, evaluating applications as a whole, rather than considering isolated features, does have real world merit.
Duignan et al (2003) seek to evaluate SVG for software visualisation in a detailed study that considers how individual features SVG deal with the specific requirements of software visualisation. One deficiency identified is that SVG does not support text wrapping, a point developed by Badros et al (2001), this is being addressed in the working draft for SVG 1.2 (World Wide Web Consortium (5), 2003). The macro approach of Duignan et al (2003) contrasts with the micro approach of Rutledge et al, (1999). Both have merit; however it could be argued that both evaluations are limiting and that a more complete evaluation should involve a detailed examination of key attributes of the technology and an examination in the intended environment.
One aspect of evaluating any application for Internet use is that of response time (Nielsen (1), 1994), which is a function of both download time (bandwidth) and client side processing resource required by (and available to) the application, which have a direct effect on response time.
Card et al (1991) discussing response times suitable for a user interface concluded:
· Up to 0.1 sec, the user feels the interface is continuously running.
· Up to 1.0 sec, the user remains engaged with the interface.
· Up to 10 sec, a user will wait for the interface to render sufficient information
to permit further interactivity.
Bandwidth, file size and client side resource are significant,
as all can affect rendering time.
2.13 Potential Applications of SVG on the Internet
When considering the benefits of SVG, it is useful to look at some potential applications as envisaged in the literature. Trippe and Binder (2002) discuss using SVG for an interactive seat booking system at an entertainment venue or on an aeroplane. A baseball stadium seating plan could, it is argued, be displayed with available seats highlighted according to selected criteria:
· Proximity to aisles, for accessibility
· Availability for daytime fixtures during a specified time window.
· Availability of adjacent seats, depending on the size of the party.
To display available seats according to such criteria would, with a bitmap based
library, be effectively impossible argue Trippe and Binder (2002). Even if it were
possible, it would require downloading a fresh bitmap for each request. This would
be too slow for effective interaction with the site, the seating availability, at
busy periods could be inaccurate, as multiple users of the booking system submit
requests.
To display such images in SVG would require interaction with a database. SVG is
based on XML which is suitable for data exchange and JavaScript is suitable for
client side event handling such as mouseover (Neumann and Winter, 2001). This emphasises
as Cagle (2002) states, the power of SVG is not as a standalone image media, but
as a language that is designed to work in conjunction with several others providing
graphically displayed real time information about seating availability (Trippe and
Binder, 2002).
Another area of application for SVG considered by Watt et al (2002) is that of Blueprints and CAD (Computer Aided Design) drawings for building and engineering projects. Physical drawings of structures will have 'paper hyperlinks' on them to a more detailed drawing of that section of the structure. It is reasonable to suggest that such a series of plans would lend itself to display and navigation via SVG. If, argue Watt et al (2002), the open ASCII interchange format of AutoCAD (the de facto standard for CAD) called DXF is used to translate, using an application such as CAD2SVG (Savage Software, 2003), CAD drawing files to SVG files , interactivity can be added using JavaScript. With the attributes of Scalability and Interoperability discussed earlier this will make design collaboration and distribution mainstream (Watt et al, 2002) with updates immediately available to all project team members.
The final main application considered in the literature for SVG is cartographics; the combination of GIS (geographic information system) and SVG is very compelling (Trippe and Binder, 2002). This is in part due to the explicit use of coordinates in SVG to position primitives and objects (Cagle, 2002), Neumann and Winter (2002) advocate SVG as a means of displaying high quality web maps, arguing that cartographic display on the Internet has until now been bitmap based, with the relevant bitmap being created server side at every time the user wishes to alter their viewing parameters. However as Christel and Huang (2001) note that large scale views can be zoomed client side, that is without referral to the server, thus speeding up and enhancing the user experience. A restriction, however, of the current zooming function of SVG is that it does not alter the level of detail (LOD). This is discussed in greater depth in the next section.
Certain features of SVG lend themselves to cartographics argue Neumann and Winter (2002). SVG elements can be grouped, given a unique identifier, the attributes of which can be changed using scripts. Grouping elements can be used client side to control attributes of an SVG image, using the g element and given a unique identifier (id) tag. A simplified example for illustrative purposes is given in appendix 2.
Maps contain many small symbols which can be repeatedly reused using elements such as defs and use. Using defs allows objects to be defined without being rendered until called, the call can the be made with use, very quickly it is possible to start building an image using objects rather than graphic primitives (Probets et al, 2001) (Cagle, 2002). This, assert Neumann and Winter (2002) allows small file sizes and such templates allow changes to be efficiently applied.
Neumann and Winter (2002) also discuss sample implementations of interactive choroplethe (maps data by classification, then displays graphically). The examples use substantial amounts of data. The map shown in figure 4 is 100Kb in SVGZ format which unzips to 287Kb, it then runs entirely client side with no further server communication. This demonstrates a restriction of SVG noted by Trippe and Binder (2002) that there is no way to stream SVG, it is necessary to wait for the entire application to be downloaded before there is any display. Watt et al (2002) observe that an SVG (rendering device) can place high loads on the CPU, if the image is a complex one, and some (older) computers can lock up.
These examples demonstrate the complex feature set of SVG and its role in the
'semantic web' (World Wide Web Consortium (7), 2003) and along with attributes of
SVG discussed in earlier sections imply a positive outlook for SVG. One of the key
attributes to emerge from the examples is the emphasis placed on the client side
processing, this could make the concerns of Watt et al (2002) that lock up of SVG
based web pages can occur, suggesting that guidelines for developers as to how this
may be alleviated by methods such as HTML alternatives could be useful. However
the potential applications discussed in the literature do not include such applications
as education, games or other entertainment based application, such as an interactive
quiz, which could combine the former two. This could in part be due to the concerns
raised in the previous section of (Neumann and Winter, 2001) and also noted by Watt
et al (2002) that the availability of the source code could allow copyright infringement
of material and make intellectual property vulnerable.
A choroplethe map rendered in SVG.

Fig 4: A choroplethe map. Source: Neumann and Winter (2002)
These potential applications do all demonstrate that SVG as
an XML namespace is part of a transparent and open standard, capable of allowing
interactive display of data, according to multiple parameters, much more quickly
than any similar bitmap based application.
2.14 Actual Examples of SVG on the Internet
Whilst there is a significant amount of SVG material on the Internet, virtually
none of it serves any purpose beyond demonstrating features of SVG rather than actually
imparting information to the user.
Table 3 below highlights features of some of the more interesting sites concerned
with SVG. More detailed comments and URLs are given in appendix 3.
| Title | Comment |
| Adobe SVG Zone | Adobe Systems showcase for SVG. Adobe have heavily backed SVG and developed the leading SVG viewer. |
| KevLinDev | The homepage of Kevin Lindsey, a software developer. Site demonstrates how SVG and JavaScript can combine. |
| Carto.net | Developed to promote the display cartography on the Internet |
| DBx Geomatics Inc | A Canadian cartographic company that recognises the potential of SVG. |
| National Cancer Institute (USA) | A site displaying interactive mortality charts and graphs, a variety of formats including SVG. |
| SVG Games | Created in November 2003 to promote games developed in SVG |
Table 3: Summary of selected SVG on the Internet.
2.15 Conclusion to review of literature
Whilst Flash is a mature technology, SVG is a relatively new and rapidly developing technology, as such there is not an extensive amount of literature pertaining to it. The literature has dated quickly.
At this preliminary stage the literature suggests the following points to be significant:
· Flash is proprietary and SVG is an open standard.
· Flash is an established and mature technology, whereas SVG is unproven in widespread
use.
· Accessibility is an increasingly significant issue.
· The trailing position of SVG with respect to plugin distribution is significant.
· Current thinking for SVG implementation is primarily in technical areas rather
than multimedia applications.
Conversely the literature makes partial or total omission in some areas:
· The fact that SVG could be used for games (for entertainment or education)
receives limited attention.
· No academic work has been done to compare equivalent Flash and SVG applications.
This and the preceding point will be researched in this project by the development
of an interactive game of similar design in both Flash and SVG format. Evaluation
criteria will be developed and the applications evaluated.
· No evaluation of leading SVG viewers in the real world. The only evaluation is
that undertaken by the W3C (World Wide Web Consortium (6), 2003), against specific
criteria of the SVG standard. Whereas an evaluation of an Internet page of SVG content
which includes JavaScript might be more meaningful.
· Limited evaluation of SVG development environments, and where they do exist they
focus on the drawing tools in the applications (Trippe and Binder, (2002) being
a example) rather than any ability they may have to support JavaScript and other
features which provide interaction.