W3C home > Mailing lists > Public > www-svg@w3.org > November 2004

Re: SVG 1.2 Comment: vector effects

From: Craig Northway <craign@cisra.canon.com.au>
Date: Mon, 29 Nov 2004 16:30:21 +1100
Message-ID: <41AAB3ED.9000702@cisra.canon.com.au>
To: Ian Hickson <ian@hixie.ch>
Cc: www-svg@w3.org

Ian,

Ian Hickson wrote:

>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.
>  
>
I was opposing certain vector effects. I was just relaying the 
justification for the current effect set. Chris has since clarified my 
statement and his clarification better reflects the actual decision in 
the meeting. I would prefer a simplified set of vector effects.

>  
>
>>>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?
>  
>
No. I wasn't trying to justify animation of vector effects.

I was pointing out that I think animating your proposed syntax would 
further complicate the specification of animation for 'd', which is 
currently allowed. This has nothing to do with me justifying the 
animation of 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.
>  
>
This further complicates the current d syntax by adding url fragments. 
As far as I know, no current SVG feature allows multiple urls in this 
way, especially in conjunction with another micro-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.
>
>  
>
I prefer the currently proposed syntax which shares similarities with 
filter effects.

>>>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.)
>  
>
Yeah thanks, Dean already pointed this out. I wasn't sure exactly what 
you meant, but that is clear now.

Craig
Received on Monday, 29 November 2004 05:30:55 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:14:53 UTC