Re: SVG 1.2 Comment: vector effects

On Wed, 24 Nov 2004, Dean Jackson wrote:
> On 24 Nov 2004, at 00:09, Ian Hickson wrote:
> > > > > 
> > > > > - there is a need to assign multiple strokes and fills to an 
> > > > > object (drawing tools had this for long time)
> > > > 
> > > > This could be done in the same way that the CSS working group is 
> > > > handling multiple backgrounds on elements, namely, let the 'fill' 
> > > > and 'stroke' properties take multiple comma-separated values.
> > > 
> > > That was certainly one of the ideas WG members had as well. It works 
> > > for fill, but stroke is not controlled purely by stroke property. 
> > > Typically one wants to change either stroke-width or 
> > > stroke-dash-array as well.
> > 
> > Allowing those properties to take multiple values as well would 
> > address this (and is how 'background' is being handled in CSS).
> 
> 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.


> - It adds another micro-syntax to the language that implementers have
>   to handle.

So does adding a bunch of new elements.


> - It makes it extremely difficult, if not impossible, to animate
>   different sub-properties or individual entries in the properties
>   independently (without adding a whole set of language features just
>   to do this).

Fair point, although I don't see that the current model's complexity is 
outweighed by the fact that it can be animated using the current animation 
model. You're just introducing a new rendering model instead of extending 
the animation model.

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.


> > While I now understand why you feel these new features are important, 
> > I still think the current proposed way of doing them is hugely over- 
> > engineered and overly complex. It allows shapes to have other paths 
> > arbitrarily applied to them, for instance.
> 
> Actually the stylistic effects are fairly easy to implement, and IMO are 
> an obvious extension to the existing rendering model. It is also a nice 
> match to the raster effects.

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.

My proposal is to solve these problems with small incremental changes 
instead of a large number of new features. (The vector effects chapter 
basically invents a new scripting language that uses imperative XML 
elements as function calls.)

The need to scale stroke outlines and stroke/fill patterns differently 
from the rest of graphics can be addressed by simply introducing a new 
unit that is unaffected by transforms.

The need to assign multiple strokes and fills to an object can be achieved 
using the <paintServer> and <strokeServer> ideas described above.

The need to "set back" strokes around the markers while preserving actual 
path data can be achieved by introducing a single 'stroke-offset' property 
much like all the other 'stroke-*' properties.

The need to reuse edges in several shapes (esp. on maps) can be addressed 
by allowing path data to import other paths, as in d="M 20 20 url(#path)".

All of the above animate using the existing animation mechanisms and all 
of them use significantly _less_ file size than the current proposal.

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

Received on Tuesday, 23 November 2004 16:52:28 UTC