Re: SVG 1.2 Comment: vector effects

Ian,

Ian Hickson wrote:

>On Wed, 24 Nov 2004, Dean Jackson wrote:
>  
>
>>On 24 Nov 2004, at 00:09, Ian Hickson wrote:
>>    
>>
>>> ...
>>
>>This has a number of problems.
>>
>>- It makes it much harder to use tools like XSLT.
>>    
>>
>
>That's an XSLT limitation, and should not restrict the SVG group from 
>making a good quality language.
>  
>
I think that making a good language would include making one that can be 
operated on easily by existing tools. I think that complex attribute 
syntaxes should be avoided because they significantly increase 
implementation complexity.

>>- It adds another micro-syntax to the language that implementers have
>>  to handle.
>>    
>>
>
>So does adding a bunch of new elements.
>  
>
As Thomas said it much easier to add elements to an XML based language 
than complicated attribute syntaxes.

>>- [...]
>>
>How about a new kind of paint server that defines the paint servers that 
>should be used?
>
>As in,
>
>   <paintServer id="foo">
>    <solidColor solid-color="blue" solid-opacity="0.8"/>
>    <solidColor solid-color="red" solid-opacity="0.8"/>
>   </paintServer>
>
>   <circle fill="url(#foo)"/>
>
>Here you only need one element to introduce the idea of multiple fills, 
>and it fits into the current model well.
>
>For multiple strokes, the simplest solution would be to just have multiple 
><path> elements all using the same path definition, each with a different 
>stroke. Alternatively you can introduce a new "strokeServer" which would 
>take one or more elements <stroke> which have all the stroke-* properties:
>
>   <strokeServer id="bar">
>    <stroke stroke="red" stroke-width="4"/>
>    <stroke stroke="white" stroke-width="2"/>
>   </strokeServer>
>
>   <circle stroke="url(#foo)"/>
>
>Again, this introduces minimal new elemenst while allowing the requested 
>features.
>  
>
This does not solve many of the solutions vector effects does, in 
particular where strokes, fills and markers can be combined in different 
orders.

>
>  
>
>> [...]
>
>
>Each individual feature can be easy to implement while still resulting in 
>a specification that is, overall, over-engineered and overly complex.
>
>
>The requirements Peter listed as reasoning for the vectorEffects feature 
>were:
>
>- there is a need to scale stroke outlines and stroke/fill patterns 
>  differently from the rest of graphics
>- there is a need to assign multiple strokes and fills to an object 
>  (drawing tools had this for long time)
>- there is a need to "set back" strokes around the markers while 
>  preserving actual path data
>- there is a need to reuse edges in several shapes (esp. on maps)
>- all of the above should integrate with animation (e.g, path animation) 
>  and not cause substantial file size bloat.
>  
>
These may not be the only requirements, Peter adding the caveat "In 
short" to the start of this list.

Craig

>[...]
>  
>

Received on Tuesday, 23 November 2004 22:43:11 UTC