RE: [svg-developers] Gradient mesh support

Thanks for the link, Jan,  to this working draft. Of the technologies
listed, I see one oversight that addresses all of the requirements:
<replicate> [1],[2].

 

As demonstrated in the suite of accompanying examples, <replicate> enables

 

a.       pseudo 3D

b.       artistic effects

c.       Compact representation

d.      Ease of authoring (the metaphor is based on <animate>, already a
part of SVG)

e.      Compact syntax

f.        Hand authoring

g.       Compatibility with SVG gradient syntax

h.      Control of the spread of color and transparency values

 

Additionally, <replicate> enables certain classes of non-rectilinear
tilings, perspective transforms, and, in conjunction with filters expresses
certain naturalistic scenes quite conveniently [3]. It also provides
considerable potential for integration with multivariate data streams as
suggested from InkML [4]

 

I would suggest that it be added to the candidate technologies being
considered. Its utility is slightly more in the "3D direction" and less in
the "gradient direction" than the other technologies in the advanced
gradient requirements draft, but its expressive power is greater than the
others. I can see it complementing the power of some of the others.

 

For any drawn object (and possibly other items as well, like
gradient-stops), subsets of its attributes and all the attributes of its
modifiers (gradients, filters, patterns, clippaths, masks and animates) may
be modified linearly or curvilinearly as the object is morphed over two-D.
The module for multivariate curvilinear interpolation is patterned upon, but
more powerful than the interpolation module in <animate> and offers obvious
suggestions for desired extensions of the <animate> module (the ability to
change animated values according to any user-defined 2D path). 

 

I believe the WG had informally decided that <replicate>, being already
implemented in JavaScript, didn't need native browser support, but the
JavaScript implementation, in the case of more complex effects is very slow
and would benefit from lower-level implementation.  The majority of the
user-demanded effects enabled by replicate CANNOT currently be managed
within current SVG without script! 

 

Given the broad array of important use cases that it addresses, both within
and outside the Advanced Gradients area, <replicate> offers a powerful
extension to SVG's arsenal, with many suggestions for syntactic
representation having already been examined and explored in detail. Since
browsers that fully support SVG1.1 will already have the code to support
<animate>, and since <replicate> borrows extensively from that syntax
(sharing the interpolation module) implementation is likely to be less
costly than it would be for other less powerful methodologies.

 

It would extend SVG immensely in several directions, allow greater
integration with multivariate data streams, and do so using syntax that is
already familiar to SVG authors.

 

Respectfully,

David

 

 

[1] http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2010/replicate.htm 

[2]
http://svgopen.org/2010/papers/46-A_proposal_for_adding_declarative_drawing_
to_SVG/index.html

[3] http://srufaculty.sru.edu/david.dailey/svg/replicate/repPathTurb2.svg
(Opera or ASV needed)

[4] http://lists.w3.org/Archives/Public/www-svg/2010Jun/0049.html 

 

 

 

Jan wrote:
During searching I've found this document from yesterday! :-)
http://dev.w3.org/SVG/modules/advancedgradients/SVGAdvancedGradientReqs.html