RE: agenda+ SVG 2 Features and Approach

Rick Graham wrote:

Has anyone considered using SMIL semantics for replication?  It occurs
to me that such an approach could lead to some efficient code reuse
and merge a learning curve.
----------

Indeed. Replicate was designed [1] with an eye toward reuse of as much as
possible of the SMIL semantics. It also has suggested interesting
possibilities for the expansion of SMIL based on reflection of the metaphor
back again from space to time.

The conceptual approach as well as syntax are pretty similar (though some
modifications were needed as time and space are in some ways rather
different).

Transferability of skill sets to authors would presumably be high. Alas, as
Patrick Dengler points out, we don't have enough SMIL users yet for MSFT to
implement SMIL, so who's to say if I'm right about this?

In working with <replicate> a number of ideas appear naturally (like this
drawing in 5D example [2], or 3D animation [3]) allowing bivariate attribute
pairs to take values from two dimensional curves which naturally motivate
the question "wouldn't that make a lot more sense for <animate> than using
keyTimes?" As Charles has pointed out, <replicate> has some very nice
interplay with InkML Also, we've seen some possibility for use in the HTML
context as well (replicated inputs for multi-valued form elements).

In its recent meeting [4], the SVG WG resolved:
" We will not include replicate in SVG2 unless accompanied
    by concrete use cases and demonstration of author/implementor
    interest.
It was also suggested that an actual spec for <replicate> could be helpful
in future consideration. (At least that's how I took the suggestion in the
minutes.)

I think that for any implementor that has already implemented SMIL in SVG,
the code base could largely be shared, and along the same lines, I think
that for any implementor that has done neither, the code base used for
<replicate> and for <animate> in projects such as FakeSMILe or SMILScript
could be merged into one code base that could assist in the parsing of
either. Basically, all one needs is an interpolation engine that knows how
to interpolate between d attributes of paths, multivalued transforms,
colorNames and so forth, and then, voilą, one has both animation and
replication. Of course the timing module of SMIL is a bit more complex, but
the implementation of <replicate> for anyone who already has <animate>
should be less than a person month of activity.

Since Microsoft won't have SMIL for some time presumably, work on a
JavaScript code base for SMIL becomes crucial to SVG; why not, therefore,
combine eggs?

I think implementing <replicate> would be a very cool way for an implementor
to "show off" since the speed differential between the JavaScript
implementation (using persistent DOM objects) and a native implementation
using hardware acceleration and optionally suppressed shadow DOM would be
enormous particularly for the more advanced effects such as using filters
with feTurbulence (notice, in a Parthenon, how the grain of marble becomes
denser as marble columns recede into the distance).

To be honest, I don't know if many people are using <replicate>. I have
gotten maybe 20 questions about it from far flung parts of the world in the
year since the proposal was made at SVG Open 2010 in Paris. Largely, those
have been questions like "why can't you interpolate" the following...
Presumably the user base that is happy doesn't fuss, so I have no way of
knowing. 

I’d like to work on consolidating the use cases -- I sense that SVG has, of
necessity, become more pragmatic and less visionary than in its early days,
so I can understand the growing sense that user demand should precede
functionality. In my mind, <replicate> presents one unified syntax that
simultaneously addresses three oft-stated use cases: richer gradients [5],
2.5 dimensional effects [6], and richer classes of patterns and tilings [7],
including non-affine transforms [8]. 

Help with any of these things: extensions of the script (there are a lot of
things it doesn't handle at present), writing use cases, writing an actual
spec, persuading just one implementor to implement it, or drumming up users
would be most certainly welcome! I'd like to be able to form a proper
response to the Working Group's resolution, if any interested parties have
unused cycles in their schedules! 

Cheers
David

[1]
http://svgopen.org/2010/papers/46-A_proposal_for_adding_declarative_drawing_
to_SVG/index.html 
[2] http://srufaculty.sru.edu/david.dailey/svg/text/replicatePath8.svg 
[3] http://srufaculty.sru.edu/david.dailey/svg/text/replicatePath9.svg 
[4] http://www.w3.org/2011/10/28-svg-minutes.html 
[5] http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2010/Color9.svg 
[6] http://srufaculty.sru.edu/david.dailey/svg/text/plastic8.svg 
[7]
http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2010/nestedReplicates6.svg

[8] http://srufaculty.sru.edu/david.dailey/svg/replicate/repRectsGrad2g.svg

Received on Sunday, 30 October 2011 20:51:39 UTC