Loading ...
Sorry, an error occurred while loading the content.

RE: [svg-developers] Re:

Expand Messages
  • David Dailey
    Hi Richard, In terms of shading, the SVG WG seems to prefer mesh-gradients, though their use as a declarative tool (sans package) seems a bit prohibitive.
    Message 1 of 7 , Dec 1, 2011
      Hi Richard,

      In terms of shading, the SVG WG seems to prefer mesh-gradients, though their
      use as a declarative tool (sans package) seems a bit prohibitive.

      Nevertheless, it will take some time for SVG 2.0 to be standardized and some
      time after that for gradient meshes to be implemented in the browsers, and
      in the meantime one has a pretty broad class of rich gradients available
      through <replicate>. Here are some examples I cobbled together in less than
      an hour this morning (unfortunately, the examples are using a different
      version of the base code than the "trunk" since it looks like we broke


      These examples are fairly simple, using <replicateModifier> to retrieve the
      gradient applied to the rectangle and to change the colors in that gradient
      as the gradient's footprint is changed.

      Basically, replicateModifier is used to retrieve some of the modifiers of an
      SVG object (these might, in theory, be gradients, clipPaths, masks, filters,
      animations, patterns, or even replicates) and to modify those as the other
      attributes of an object are also modified. *

      My own sense is that replicate makes it easier for the author, working
      without a tool, to design custom gradients, but I'd have to agree, that the
      folks who have cobbled together examples for replicate have been more
      worried with extending the concepts, building the code and making the
      examples than with explaining how to do it. One of my students points out
      that a political mistake we may have made was to display too broad a range
      of its abilities, overwhelming, perhaps, folks who didn't have time to
      consider the proposal seriously.

      On the other hand, Inkscape and Illustrator give access to very rich,
      customizable gradients - it is just that the code exported for such
      gradients is not particularly accessible to a human who might later wish to
      polish it, program with it, or make it accessible to those who, for whatever
      reason, need access to that geometry, or to search engines of the future and
      the like. The "semantics" of replicate, being based on the semantics of
      animate makes more sense, at least to me.

      In terms of the declarative randomness, I'm in general agreement. I think
      fire, water, clouds, and even wood grain (see
      http://cs.sru.edu/~ddailey/svg/feTurbulence18.svg -- in either Firefox or
      Opera or IE/ASV) are perhaps easier with filters since feTurbulence does a
      nice job of pseudo-randomness with "fuzzy" things.

      When it comes to making crisp objects though, ( see for example,
      http://cs.sru.edu/~ddailey/svg/feTurbulence19.svg ) feTurbulence is a bit
      hard to shape into things like grass or hair, and even though we could
      distort it, post-hoc, by another feTurbulence using feDisplacement (as in
      http://cs.sru.edu/~ddailey/svg/feComposite5.svg or
      http://cs.sru.edu/~ddailey/svg/feComposite8.svg ) so as to convey a bit of
      wave or wind to the grain of the grass or hair, it is ultimately going to be
      easier to just draw a hundred or so proto-hairs into a pattern space with
      declarative randomness than to try to trick filters into giving us that

      I rather get the sense that some are declaring (using non declarative
      methods) that the golden age of declarative approaches to graphics is all in
      the past and that all will be henceforth be done with script, CSS and
      packages - a curious proposition since the packages have not yet been built!
      While this may appeal to the community of non-authors, I'm not so sure
      appeals to authors.



      *It would be nice if <animateModifier> were included in SVG 2.0, since it is
      a natural thing to want to do; I remembered to ask for <animatePath> to
      allow more precise control over all attributes of an animated object, but
      forgot to ask for the more obvious animateModifier.

      From: svg-developers@yahoogroups.com [mailto:svg-developers@yahoogroups.com]
      On Behalf Of cremnosedum
      Sent: Tuesday, November 29, 2011 1:00 PM
      To: svg-developers@yahoogroups.com
      Subject: [svg-developers] Re: <replicate>


      I'd like to use replicate for my web comic, where I'm trying to make things
      look realistic in SVG. It would be very useful for things like realistically
      shading complicated shapes. Unfortunately, my big problem so far is that I
      haven't found a good explanation of how to use it. There are some examples
      but I haven't had the time or patients to figure out how they work and how
      to modify them for the space ship parts and things I need.

      > I'm also interested in incorporating "declarative randomness" - if one
      > to generate a few hundred objects into the DOM, why not have them be
      > random?

      I think this would be useful for drawing things like hair, grass, woodgrains

      > Might anyone want to help contribute to such an open source project?

      I would consider it.

      Richard Pearman http://www.pixelpalaces.com/
      The next stage in the evolution of web comics:
      Read my Helium articles: http://www.helium.com/users/212199
      South Alberta Cactus and succulent society:

      [Non-text portions of this message have been removed]
    • David Dailey
      Yes, I agree, Francis. It is already being deployed in large enterprise projects, as I know from one of my former students now at IBM. As Jon points out he s
      Message 2 of 7 , Dec 1, 2011
        Yes, I agree, Francis. It is already being deployed in large enterprise
        projects, as I know from one of my former students now at IBM.

        As Jon points out he's been experimenting with some uses of replicate-like
        ideas in D3 already.

        I also agree with him that it's not clear how much of it could be added into
        D3. For example the <replicateModifier> stuff such as at

        http://cs.sru.edu/~ddailey/svg/feComposite8.svg and the replicatePath stuff
        (e.g. http://cs.sru.edu/~ddailey/svg/pathRep2JS.svg ) require awareness of
        the SVG DOM, but D3 is clearly very powerful already and is teeming with new
        development. Learning how to use D3 is next on my list of projects, once the
        current list frees up a bit!

        Of course, <replicate> like <animate> is intended as a declarative approach,
        so adding replicate to D3 would not likely mean discontinuing development of
        it by itself. Having a solution that enables our IE brethren (and sistren)
        to actually see existing SMIL content would be quite a nice gesture.



        From: svg-developers@yahoogroups.com [mailto:svg-developers@yahoogroups.com]
        On Behalf Of Francis Hemsher
        Sent: Wednesday, November 30, 2011 9:59 AM
        To: svg-developers@yahoogroups.com
        Subject: [svg-developers] Re: <replicate>

        David Wrote:
        > a) The Working Group recently decided [3] not to adopt <replicate>,
        > unless it is accompanied by "concrete use cases and demonstration of
        > author/implementor interest."

        Hi David,
        For the past few weeks I have been evaluating the d3 Javascript library that
        is used to generate SVG from data. I believe it will be substantially
        employed within svg enterprise projects.

        I would like to suggest that the replicate .js library file could make a
        nice addition to the d3 library. This would most assuredly demonstrate is


        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.