Re: another something to think about -- the <replicate> tag -- SMIL for space instead of time

David,

Pretty well all the existing animation elements could be used by having a
parameter indicating N intervals and the existing dur attribute.

By setting dur to a specific time it would indicate the number of times
that the implementation had to update the drawing. Setting dur to 0secs
would indicate they all had to be drawn on the same frame.

Bob

>
> This morning I was thinking about classes of two dimensional patterns. We
> have the group theoretic tessellations; we have formulaic fractals; we
> have a variety of possible path-generation languages; ... etc.
>
> Currently within SVG we have one construct for those -- the <pattern>. In
> the discussion of non-rectangular tilings at
> http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2008/edges_of_plausibility.htm
> (for more detail see the full paper), ways of extending those tilings
> through script and trickery are discussed.
>
> In talking with Erik D. at SVGOpen we got to playing with the idea of what
> I might call "declarative drawing" -- do a sequence of steps (as in a
> path's "d" attribute) , add a modifier to that sequence (like rotate and
> shrink) and then repeat n times. One can imagine a rather fun class of
> such path-generation languages with a set of path-generation primitives.
> Such is the notion behind the <doodle> tag suggested (with very little
> specificity) at http://srufaculty.sru.edu/david.dailey/svg/spec.html .
>
> The <doodle> could, if properly designed, obviate some of my own
> frustration with having to specify a zillion x-y points within a path to
> generate say a zillion-pointed star. (That's why I do it in script).
> Suppose we had a richer set of path primitives like
>          ((Forward 100) (turn k * 2Pi/zillion)) times (zillion)
> that could draw a zillion-pointed start (if k and zillion are relatively
> prime). Something like
>          ((Forward 100) (turn k * 2Pi/zillion) (shrink .5) ) times
> (zillion)
> Could draw something quite fractal. I'm using words to convey the illusion
> of pseudo-code -- words like forward and turn and shrink would be replaced
> by real SVG vocabulary.
>
> Anyhow that's the idea behind the <doodle>
>
> This morning, though, I was thinking about the class of all possible
> patterns and realized that <doodle> might be somewhat limited and
> cumbersome. I was reminded of the allied suggestion of <contour> -- a
> construct that takes two or more <path>s and interpolates. (It is also
> discussed in http://srufaculty.sru.edu/david.dailey/svg/spec.html .  )  It
> can be used either to create a shape (like a contour map) or a gradient,
> or if one uses the intermediate paths as phases of an animation, as a way
> of animating the morphing of one curve into another.
>
> These two ideas in juxtaposition set the stage for another more intriguing
> speculation:
>
> How about we make a companion to the <animate> tag, called a <replicate>?
>
> It would work sort of like this:
>
> Just as
>
> <object><animate attributename1 propertylist><animate attributename2
> propertylist></object>
>
> succeeds in modifying <object> over time according to the attributes named
> in its child animations
> how about
>
> <object><replicate attributename1 propertylist><replicate attributename2
> propertylist></object>
>
> that would lay out copies of <object> on a page? The number of copies and
> their positions and attributes would be determined by the property lists
> (including keyTimes which now becomes keyPlaces?) associated with each
> attribute.
>
> This concept might obviate the need for both <doodle> and <contour>
> (though I'm not sure it would replace <contour>'s ability to act as a
> gradient) and give something rather powerful.
>
> The cool thing about it is that the browsers that already support SMIL,
> have the coding apparatus already built in to make this transition
> relatively easy.
>
> It could be used declaratively to generate all manner of very rich two
> -dimensional (and simulated 3D) graphics. It's a very powerful yet simple
> addition to the spec I think.
>
> Oh and consistent with my advice of earlier this morning I'll put a <reco>
> mark in this message so that it can be added to the wiki.
>
> What does anyone think?
>
> David
>
>

Received on Saturday, 27 September 2008 19:55:26 UTC