RE: Proposals for SVG 1.2

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 ;).

That being said, I reviewed your proposal, and here are my thoughts:


| Color Interpolation
| -------------------

I like what you proposed about color interpolation. Frankly, I haven't
really looked into other color spaces, but what you said seemed sensible.


| 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? 


| 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().

|  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 

You might be able to do something like this with the new sockets. If you're
talking about doing it declaratively, I've proposed something similar in my
BAM proposal.


| -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.

In SVG1.2, 'switch' can be a child of any element. And if you're already
using script, script can solve this easily (unless I'm misunderstanding
you).

| 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.

This is one of many use cases, perhaps the primary use case, for sXBL. I
think you should review the new SVG1.2 draft, if you haven't already.


| 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.

  
| 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.

There are some time controls in SVG1.2:
	
http://www.w3.org/TR/2004/WD-SVG12-20041027/animation.html#timemanipulation

As far as referencing individual sections of reusable content, I agree. I've
proposed something similar in BAM. Don't know yet what the mechanism would
be.


| 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.

| 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)

I don't see the need for this at all. If something can be done using
existing SVG elements (and this could, as you said, with display='none' on
existing shapes), it seems an unnecessary addition. If new features are to
be added, I think that they should be things that SVG cannot currently do,
or which can only be done inefficiently. Unless I misunderstood your
explanation, this is only a semantic/syntactic distinction.


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.

Also, keep in mind that I'm a "civilian" like yourself.

Regards-
Doug Schepers

doug . schepers  @ vectoreal.com
www.vectoreal.com

"Move into the future..." 

Mark McKay wrote:
| 
| 
| Hi,
| 
| There wasn't any response to the suggestions I made about SVG 
| 1.2, and was wondering what folks thought of them?  They do 
| take SVG slightly away from simply displaying information, 
| but I think they are potentially strong additions to the 
| specification.
| 
| I'd be interested in any feedback, either positive or negative.
| 
| Mark McKay
|

Received on Friday, 29 October 2004 16:51:20 UTC