SCALABLE VECTOR GRAPHICS (SVG)

FEATURES OF INTEREST

overview
this document is *not* an exhaustive list of the features of svg. for that you should refer to the most recent official spec referred to on the w3c's svg working group page. this document is a list of the svg capabilities and limitations of key interest to web designers and flash developers.

svg: so what can it do?
generally, svg is a vector graphics format that is full featured in its native support for vector basics: lines, fills, gradients, beziers, and text. svg is also quite extensible in the sense that it supports additions which provide filter-like capabilities, and it can be expanded in modular ways by other xml applications. For instance, it works with the scripting, events, and object models defined by the dom, and it can be dynamically restyled with CSS, but it also could be integrated with something like smil to incorporate animation.

text is text
i put this first because i've seen quite enough flash sites with unreadable, unsearchable, unmanageable, inaccessible text content. in svg, the text is selectable, searchable, indexable, and extractable. this means great things for accessibility, internationalisation, and variable rendering on multiple output devices. further, because the markup of svg is text-based itself, external scripts and database hooks will be able to follow nearly exactly the model of existing html-based dynamic systems. authoring, server, and client side tools will have no problem working with text based content in an svg file. (flash developers will greatly appreciate the ability to search and replace text in a vector file from an editor, external tool, or unix command line).

yes it supports bitmaps
svg has the usual xml ability to embed objects. bitmaps will be available within the syntax of svg via an <IMAGE> tag.

svg is accessible
everything in svg can have alternate content. this has two intriguing applications. 1) if you have a graphic of a bicycle, you can offer an alternative text description of the bicycle itself, and then of each wheel, then of each spoke, and so on. this information could be used by non-graphical clients or for non-pc output or for alternative renderings by accessibility applications. 2) any component can be substituted with an alternate component depending on environment variables, so for instance a bitmap could have a series of formats provided as alternatives. if the application doesn't render png, then do a jpg, if not, then a gif.

bezier curves
even if you've been starting to feel the zen of flash's free flowing drawing tools, you'll probably be happy to hear that svg is based on beziers. it'll be up to the authoring app to provide the editing of them, though.

fills: flat or patterns
shapes can have an outline and a fill. fills can be any colour, gradient, or author-defined pattern.

lines
lines can be weighted and styled (as in illustrator, freehand, etc). they could also be filled with a pattern.

gradients
the capacity for gradients is built into svg. radial and linear were demonstrated at www8. gradients can have multiple gradient stops.

patterns
svg can define vector or bitmap patterns for use as tiled fills of lines, fills, and text.

transformations
all the typical transforms can be applied to shapes: skew, rotate, scale etc.

reusable objects
in svg you can create an object, then place multiple instances of that object on the canvas. instances inherit the qualities of the parent object. this is conceptually identical to graphic symbols in flash, except that because svg (and xml) are modular in nature, you could have an object exist in a separate file, and have that object referred to throughout your site, even styling it differently with each instantiation (think of page elements that are based on one file, but are coloured differently depending on the section in which they happen to reside).

grouping
multiple shapes and objects can be grouped semantically together for global styling or manipulation. this is different from the grouping feature in flash which is an authoring-only tool. a group in svg can have a style applied to it, so you might group 10 lines together in order to colour them all red.

styling with css
this is where svg gets really cool. svg files can have stylesheets attached to them. that gives the usual high level control to the author, where a stylesheet could be applied to many svg files, and one change to the stylesheet would affect all the files. for authors, stylesheets can indicate most of the visual modifiers, like colours, line weights, line style, transparency, and text attributes. however they also offer control to the end user. if a provision were made in an svg viewer to alter a stylesheet, or select another style sheet, then the user could select an alternate view...this could be anything from a single change (like thicker lines or larger font sizes) to a global change in a whole range of visual decoration (eg. the "formal" or "office" or "casual" styles found in word processing templates). because css can also show and hide elements, stylesheets could conceivably used to show completely different views of a document--say a text view and a graphical view.

fonts
so far, svg handles fonts with css's webfonts. there's also talk of an svg based font implementation where fonts could be described by svg within the file, but there's the usual licensing issues invovled. fonts are a bit up in the air in that regard, but things like kerning, tracking, leading, and size are all stable and supported.

xhtml support
you can embed xhtml right into your svg. svg allows you to place it and determine clipping regions for it. if the client can render svg but not xhtml (or any other embedded xml), then svg will provide alternative content with the <switch> tag. for more details, refer to the svg spec's description of embedding foreign xml objects into an svg file.


masks/clipping paths
elements (shapes, objects, groups, text, etc) can have masks associated with them, so you can only show a specified region of an element (a circle in the middle of a square picture for instance).

transparency
because it uses css for styling, svg allows for transparency, from hidden completely to partially transparent to completely opaque. besides the normal uses of tranparency, svg transparency combined with gradients and html can do strange things like make a form input box disappear into the background of a page or even another vector shape. not sure how wise that specifically is but it sure gives you something to think about.

scripting
in addition to the server side scripting mentioned above, svg works with the dom to allow full event-driven client side scripting. so things like vector based rollovers that work even when zoomed, and objects that animate programmatically across the screen are supported. also, because svg will share document space with other things in the dom, actions in the svg world will be able to communicate seamlessly with xhtml in the browser (a mouse click on a graphic could result in a form field being filled in, for instance).

animation
so far, svg will not support animation natively but will rely on existing xml frameworks to describe movement. those frameworks are both -procedural (external scripting, the dom) and declarative (smil).

3d
in a word nope. have a look at the what the web 3d consortium is doing with an xml 3d standard called x3d. x3d, according to chris lilley, will not be incompatible with svg.

sound
again, nope. this is a graphics standard, remember?

file size
in a test at www8 (based on public draft 2 of svg) a larger than 1 meg native adobe illustrator file with lots of objects, paths, gradients, and layers, turned out to be a 639K svg file. the same file translated into .swf format was 1544K. this was just an early test, but so far it looks like svg files will be smaller than those produced by other vector file formats. it's also important to note that http 1.1 can gzip files on the fly, and text-based svg can be highly compressed (the above sizes gzipped are: svg--173K, swf--1002K). a week or so after i wrote this article, i sent chris a very simple sample file including a triangle, a square, and a circle. here's how the sizes compare with the simpler file (n.b. the exporter to svg is still very experimental. production code will certainly produce different results):

UNZIPPED
illustrator: 61 208 bytes

       .fla:  5 632 bytes

       .swf:    239 bytes

       .svg:    996 bytes


ZIPPED
       .swf:    327 bytes

       .svg:    623 bytes