Re: Proposals for SVG 1.3

Hi; originally I accidentally sent this email to Doug Schepers only.  
I'm reposting it to the main mailing list to see if the community would 
like to comment as well.

In brief, my suggestions are some small additions to the SVG 
specification that would allow SVG to act as a general purpose animation 
and graphical resource library that more sophisticated programs could 
use.  I can envision an API library that can load SVG files and then 
serve animations and images to video game and other rich media programs.

Also, I realize that it is too late to provide these additions to the 
1.2 spec, but hope folks would find them useful for a potential SVG 1.3.


=======================


Quoting Doug Schepers <doug@schepers.cc>:


>> Hi, Mark-
>> 
>> Unfortunately, it's pretty much too late to make proposals for new 
>> features in 1.2. I think you would be better off aiming at 1.3 or 
>> later. As you can see, SVG1.2 has entered Last Call (well, Last Call 1 
>>  ;) .
>  
>

Where could I submit 1.3 proposals?


>> | 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.
>> 
>> I'm not sure what you mean by path animation. You can already animate 
>> paths in SVG, using the 'animate' element. What do you feel is missing 
>> from that?
>  
>

For example, suppose I have

<path d="M 10 10   l 50 50   l -50 -50"/>

and want to smoothly transition it to 

<path d="M 10 10   l 50 0   l -50 0"/>

over 6 seconds.  This animates the components of the path, rather than the
path itself.  In other words, I'd like to see something like the start of:

http://gazelle.sourceforge.net/jazz_plugin.html

(please excuse the hokeyness)


>> 
>> 
>> | 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.
>> 
>> There already exist DOM calls to do this, beginElement() and 
>> endElement().
>  
>

Where can I find out more about the DOM?  I'm going to be implementing JS
soon in my SVG renderer, and don't have much to go on besides a handful of
examples.
 Also, a full list of the standard functions it should offer would be very
helpful.


>> | Tiles and Tracks
>> | ----------------
>> 
>> I must confess I didn't quite see the reasoning behind this. Animation 
>> is already possible on 'path' elements, and combining multiple shapes, 
>> each optionally animated in several ways, and in several combinations, 
>> seems like a more generic and flexible way to achieve the effect 
>> you're looking for.
>  
>

The use of these tags would serve several purposes:

-For documents that heavily rely on images rather than geometric shapes, it
would save memory and support common practices to have a more sophisticated
way of handling images.  In particular, tools to aid using a composite image
would be helpful.  The composite image is an image where the image is
composed of several subimages placed adjacent to each other (eg, an image of
four faces - one happy, one sad, one frightful, one mad).  The composite
image is used not used itself, but it's sub images are.  The new tag I
proposed essentially adds some bookkeeping information to the traditional
<image> tag to make it particularly easy to access these sub images.

-These new tags, while they would aid the existing SVG specification, are
primarily intended for functions outside of the traditional SVG document.
For example, if I'm writing a racing game, it would be useful to have an
image library defined in SVG.  Then, instead of rendering the document
directly, I would call my SVG API and retrieve the image segment or
animation that I need.

-Many applications need animation libraries.  The <track> tags are meant to
make it easy to define a unit of animation.  Again, the primary use of these
would be by external programs that pull out an SVG animation via an API
(although they could be useful to traditional SVG documents too)

-As more sophisticated image tags would help with using composite images, a
sophisticated frames-per-second animation tag would be a big help too.  For
example, once I've defined several images I want to use in an animation, it
would be nice to have a simple tag that means "I'm going to animate these 36
frames at a rate of 10 frames per second", and then have the SVG renderer
render the animation directly.  This would be a very nice shorthand that
would free the developer from having to define a lot of hard to maintain
<set> tags.


>> 
>> | 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:
>> 
>> One way to get close to this in SVG would be to have 2 background 
>> rectangles, each filled with a different pattern. The top pattern 
>> would be mostly blank, but would have some odd bricks to overlay the 
>> regular ones in the back. However, I also think it would be nice to 
>> have some way to do irregularity in patterns automagically.
>> 
>  
>

While this is a potential solution, it does have drawbacks:

-The parts of the underlying pattern that are obscured by the overlain tiles
will have been drawn needlessly.
-This will be hard to maintain, as the overlain tiles can be placed
anywhere. 
While this freedom might be nice for a true floating image such as a text,
if you're trying to align tiles who's edges must fit precicely, this will be
a maintenance nightmare.
-Some documents naturally lend themselves to grids.  When they do, it would
be nice to have a grid control that would make layout easier and more
maintainable.



>> If the tone of this email sounded negative, please don't take it that 
>> way. I really like the fresh approach you've taken, and I like the way 
>> you're trying to help SVG fill a market need that you see.  It may 
>> also be that I don't quite grok some of what you've said, so take that 
>> into consideration.
>  
>

Thanks for your reply.  I think I'm trying to adapt SVG as an animation
library, while the working group is focused on SVG's original intent as a
document. 
There is enough similarity that I think that with a few additions (most of
which just add additional ways to organize the existing elements) SVG could
serve both purposes.

Mark McKay

Received on Sunday, 31 October 2004 08:20:15 UTC