Re: SVG 1.2 Comment: vector effects

On Wed, 24 Nov 2004, Craig Northway wrote:
> 
> I agree with some of your earlier comments regarding the more complex 
> effects. I raised some objections with the working group. As Jon has 
> already mentioned, all proposed effects were included in the last call 
> draft, but pending comments from the community may get dropped.

With all due respect, I would feel more comfortable if the SVG 
specification was designed with simplicity in mind, rather than starting 
with everything and then only removing features if enough people complain.

> > Ok here's a proposal which would dramatically simplify all this (and 
> > which, in conjunction with the two other proposals to address the two 
> > other use cases mentioned for this chapter, would reduce the entire 
> > chapter to about three minor extensions).
> > 
> > Add a new command to the path language that imports another path at 
> > that point. Instead of:
> > 
> >   <defs>
> >     <path id="border1" d="..."/>
> >     <path id="border2" d="..."/>
> >     <path id="border3" d="..."/>
> >     <path id="border4" d="..."/>
> >     <path id="border5" d="..."/>
> >   </defs>
> >   <vectorEffect>
> >     <vePath>
> >       <vePathRef xlink:href="#border1"/>
> >       <vePathRef xlink:href="#border2"/>
> >       <vePathRef xlink:href="#border3"/>
> >     </vePath>
> >     <veFill color="red"/>
> >     <vePath>
> >       <vePathRef xlink:href="#border4"/>
> >       <vePathRef reverse="true" xlink:href="#border2"/>
> >       <vePathRef xlink:href="#border5"/>
> >     </vePath>
> >     <veFill color="blue"/>
> >   </vectorEffect>
> > 
> > ...you would do:
> > 
> >   <defs>
> >     <path id="border1" d="..."/>
> >     <path id="border2" d="..."/>
> >     <path id="border3" d="..."/>
> >     <path id="border4" d="..."/>
> >     <path id="border5" d="..."/>
> >   </defs>
> >   <path d="url(#border1) url(#border2) url(#border3)" fill="red"/>
> >   <path d="url(#border4) reverse-url(#border2) url(#border5)" fill="blue"/>
>
> I will pretty much repeat some of Dean's earlier comments because this 
> solution shares some problems with your earlier solution. This is 
> difficult to animate and makes parsing more difficult by adding another 
> micro-syntax. The path syntax is difficult to specify animation and for 
> an author to animate. This makes it even more difficult.

Could you explain the use case for animation vePath?

Also, I don't buy the "this is harder to parse" argument. the url() syntax 
already has to be supported by SVG UAs. The above is no harder to parse 
than the extended <paint> syntax.

In fact, writing a parser for the above is probably on the same order of 
complexity as writing the code to handle the trees you get in 
vectorEffect elements.


> > That would also get around another problem I have with vectorEffect, 
> > which is the way you can make any random shape (e.g. a <circle>) look 
> > like any other random shape (e.g. a country). That seems to defeat the 
> > point of having shapes in the first place. It also makes trying to 
> > understand SVG markup quite hard.
>
> I don't understand how vector effect makes a circle look like another 
> random shape? Please explain this further, perhaps with an example?

Please correct me if I'm wrong, but as far as I can tell this circle is a 
square:

   <circle vector-effect="url(#square)"/>
   <defs>
    <vectorEffect id="square">
     <vePath>
      <vePathRef xlink:href="#square-path"/>
     </vePath>
     <veStroke/>
    </vectorEffect>
    <path id="square-path" d="M0,0 L10,0 L10,10 L0,10 Z"/>
   </defs>

(I may have gotten the syntax a bit wrong but hopefully you get the idea.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 29 November 2004 05:03:27 UTC