Proposals for SVG 1.2

Hi,

I'm writing this in response to a previous thread on the mailing list.  
It involves some of the ideas I've had toward improving the SVG 
specification (particularly woith respect to animation), and also some 
features that I believe would improve a SVG renderer and animator I'm 
developing at http://svgsalamander.dev.java.net.

Mark McKay

Suggestions for SVG 1.2
Mark McKay
mark@kitfox.com
http://www.kitfox.com
===============================

I'm writing this in response to the on going discussion of features to be added to the SVG specification.  I'm coming at this from the point of view of a programmer who wishes to use SVG to provide an easy mechanism for artists to design graphical content that can then be used in Java applications to provide rich interfaces.  Ideally, the artist would not need to know more than JavaScript to create their content, could test their work on their own development machines, and simply give their art resources unique names that the program could then reference.  It should also be easy for the programmer to simulate events and receive notification of events from the SVG.  In particular, it should also be easy to create rich 2D animation in SVG and use SVG as a universal file format for animation clips that must play within Java programs.  Art resources would include backgrounds, rich menu interfaces (drop down menus, push buttons, checkboxes), periodic animation (walk cycles, game sprites punching or kicking) and non-periodic animation (cartoons).

I'm also writing this from the perspective of someone who learned SVG form O'Reilly's SVG essentials and who has occasionally looked over the W3C recommendations.  I'm not sure how valid the below is to the intent of the SVG working group, or if some of these features have already been implemented.  Please let me know if they are.

I'm also building an opensource SVG viewer and player in Java (http://svgsalamander.dev.java.net) which implements much of the SVG specification, with a focus on the goals described above (and to get around the limitations of Batik).  It's currently a work in progress, based mainly on the O'Reilly book.  (I'm doing this in my spare time)  At the time of this writing, I have implemented most display features, am nearly finished implementing SVG 1.1 animation, and am about to start on integrating JavaScript.



Background
----------

When I first started exploring SVG, I was interested in using it to create nice looking graphical summaries of tennis scores (http://www.auto-ref.com).  With a little XML, XSLT and an SVG file I had created using Adobe Illustator, I thought I could create a rich image that I could render when I wanted to display the score.  Unfortunately, Batik did not do quite what I wanted, so I began writing svgSalamander.



Color Interpolation
-------------------

Animated colors currently change state linearly in a RGB color model.  While straight forward, this has the artistic problem of colors greying at the midway point in the transition.  For example, interpolating between a bright red (255, 0, 0) and a bright cyan (0, 255, 255) will lead through a dull, mid grey (128, 128, 128).  Richer and more stable colors can be produced using the HSV color scheme.  The HSV (hue, saturation, value.  aka HSL - hue, saturation, lightness) model maps RGB values into a hue component (measured in degrees, representing a point on a circular rainbow of hues), a saturation component (representing the closeness to grey or the spread of the color values), and value representing the brightness of the color.  With this scheme, interpolating between bright red and bright cyan would produce a smooth hue shift of red, orange, yellow, green, cyan without the color dulling to grey and with a linear change in brightness.  This produces more natural and appealing color transitions.

It might be a good idea to add a style attribute to <animateColor> called 'color-interpolation' which could take on the values:

'RGB-linear', 'default' - linear interpolation with RGB color components
'HSV-CW' - HSV linear interpolation with hue interpolation progressing in a clockwise direction for the hue component
'HSV-CCW' - HSV linear interpolation with hue interpolation progressing in a counter clockwise direction for the hue component
'HSV-closest' - HSV linear interpolation with hue interpolation going in the direction of smallest arc between the two colors (eg, interpolating from red to yellow will pass through orange)
'HSV-farthest' - HSV linear interpolation with hue interpolation going in the direction of greatest arc between the two colors (eg, interpolating from red to yellow will pass through magenta, violet, blue, cyan and green)

Most artists will prefer HSV-closest.  This will allow them to blend from, say, red to brown without desaturating at the half way point.  This will lead to richer colors and fewer keyframes.  The artist's second choice will likely remain RGB-linear.

This may also be a useful addition to the <gradient> stops.


Path Animation
--------------

Providing some way to animate paths would be helpful.  Perhaps providing a way to describe paths as a collection of tags, each representing a point, instead of the current dense 'd' attribute woudl provide enough freedom for artists to animate individual points and tangents within the path.


Menus
-----

A Java program ought to be able to easily use an SVG document as a front end to a system of menus:

-The underlying program needs to be able to stop and start animated events.  For example, say I have a text field saying 'connected' that I want to set visible whenever my engine detects a connection to a server.  While this can be done by editing the document tree directly, it would be better to have it occur via a <set> tag that is triggered by a simulated time event from the Java program.

-SVG needs to be able to start animations conditionally.  For example, suppose a user event causes a JavaScript method to be called.  This method does a complex calculation that ends in a switch statement, where case 1 indicates a certain animation should start playing immediately, case 2 indicates it should start playing in 5 seconds, and case 3 does not trigger an animation at all.

While it is possible to get around these issues by having the Java program tweak the SVG, this is not ideal and blurs the boundary between programmer and artist (it also prevents the artist/javascripter from testing their work).

It would also be nice if a standard library of XSLT could be developed to provide easy creation of common SVG menu elements, such as push buttons or dropdown menus.



Tiles and Tracks
----------------

More related to video games, SVG is a great potential base for defining animated characters.  It already supports a wide range of shapes (useful for collision detection and clipping), images, and image portions.  I've already created my own XML libraries to do my own character animation, but think it may be useful to add some of these things to SVG.

One useful tag to add might be the imageTile.  This is used to interpret an image which has been gridded into tiles.  For example, suppose you created an animation of a character walking and composited each frame to a single .png file.  Each original frame fits within a 16x32 rectangle and there were 64 frames.  To draw a particular tile in this tile grid you could:

<defs>
    <imageTile id="walk" xlink:href="abc.png" xoffset="0" yoffset="0" width="512" height="64" xperiod="16" yperiod="32">
</defs>

<g>
    <!-- Draw the tile in the oth row and 1st column at screen position (20, 30) -->
    <useImageTile href:xlink="#walk" x="20" y="30" xtile="0" ytile="1"/>
</g>

You could create 'tracks' amde of several tiles, which would provide units of animation:

<track id="walkAnim" fps="15">
    <trackItem><useImageTile href:xlink="#walk" x="20" y="30" xtile="0" ytile="0"/></trackEntry>
    <trackItem><useImageTile href:xlink="#walk" x="20" y="30" xtile="1" ytile="0"/></trackEntry>
    <trackItem><useImageTile href:xlink="#walk" x="20" y="30" xtile="2" ytile="0"/></trackEntry>
    ...    
    <trackItem><useImageTile href:xlink="#walk" x="20" y="30" xtile="31" ytile="1"/></trackEntry>
</track>

This creates a simple walking animation that plays at 15 frames per second and repeats every 64 frames.  By creating many tracks, I can build up a library of animations that my engine can play at any time it wants.


It would also be nice to have a more dynamic form of track that allowed more dynamic animation:

<track id="circleSize">
    <circle r="25" x="50" y="50">
        <animate attribName="r" attribType="XML" begin="0" dur="5s" by="20"/>
        <animate attribName="r" attribType="XML" begin="5s" dur="5s" by="-20"/>
    </circle>
</track>

In this case, a track represents a regular SVG animation with a known start and duration time.  You could the use tracks by instancing them:

<g>
    <useTrack xlink:href="#circleSize" x="20" y="10" begin="22s" repeat="indefinite"/>
    <useTrack xlink:href="#walkAnim" begin="2s" repeat="4" speedUp="2" fill="freeze"/>
</g>

This would start an instance of the circle animation 22 seconds after the page loaded, offset it by (20, 10), and play the animation indefinitely.

It would also start an instance of the walking animation at 2s, repeat it four times, play it at twice the speed it was defined to be, and display the last frame indefinitely after it finished playing.

The end time of a track would be defined as the end of all animated elements within the track.


Another useful features would be to add tile grids.  The trouble with many fill patterns is that they have no variation, which makes them appear static.  While this can be broken up by strategicly placing foreground objects, it's better to provide the ability to modify the background itself.  For example, if I'm creating an image of a brick wall, while I'd like to have the wall looking mostly like a solid pattern of bricks, I'd also like to give the wall bricks some variety.  Some will be cracked, some will be off color, and a few will be dirty.  This can be done easily with a grid and a three or four source brick tiles:

<tileGrid width="100" height="100" tileWidth="10" tileHeight="10" shift="5" shiftDir="horizontal">
    <tile x="0" y="0" xlink:href="#redBrick"/>
    <tile x="1" y="0" xlink:href="#brownBrick"/>
    <tile x="2" y="0" xlink:href="#redBrick"/>
    <tile x="3" y="0" xlink:href="#crackedBrick"/>
    ...
    <tile x="9" y="9" xlink:href="#brownBrick"/>
</tileGrid>

This creates a regular grid of 10x10 squares, with the referenced tiles filling in the grid cells indicated by the x,y attributes.

The shift attribute describes a shift of 5 units that should occur for each horizontal row rendered.  This will give the bricks on offset effect.  The grid itself will not change shape - it will still be square.  However, the portion of the bricks that would be rendered outside the bounds of the grid would wrap around and be drawn on the left side of the grid.

This grid would also be useful for creating tiled environments, such as those seen in 2D side scroller games.



Locators
--------

Another very useful thing is the locator.  A locator is an object which contains position and orientation data, but no display information.  They are used to position other objects and provide reference points for the underlying Java program.  (these are used extensively in 3D applications)

For example, say I'm designing a Parchisi board in SVG that will be the graphical interface for a complex Parchisi engine I'm designing in Java.  The artist designs a game board with little squares that will hold game pieces.  They would also put locators at the center of each square so that when it's time to update the position of the game piece, it can simply set it's coordinates to the position of the locator.  For example, say my piece needs to move from board square #6 to board square #8.  If there exists

<locator id="boardSq_8" x="30" y=90"/>

updating becomes a simple matter of changing the position of my playing piece to the location of this locator.  While this can be done by using invisible rectangles and such, it would be cleaner to have a special class of elemnts with no display information at all.

Some variations would include having rotation and scale attributes for locators, a locator that defines an area or a locator grid that returns the locations of squares within the grid.