Re: SVG 1.2 Comment: vector effects

On Wed, 10 Nov 2004, Andreas Neumann wrote:
> 
> Ian, you are right, that some of the vector effects goals could be met 
> by using different syntax, but what the SVG working group (and quite a 
> few SVG users) wanted to have, was an extensible architecture, where 
> later you could add more effects or geometry operations.

All the more reason _not_ to introduce it. Vector effects as described in 
SVG 1.2 are already very complicated -- extending it even further would 
be, IMHO, very bad for implemetors and authors alike.


> What if, at a later SVG version (2.0?) we want to add a 
> buffer/contour/offset effect, or any other line effect?

Ideally, we don't add it at all.


> > 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.
>
> no, that would not handle all use cases/scenarios - what if you want to 
> draw the markers first, then the stroke? or other way round. Or stroke 
> first and then fill? Or draw a pattern on top of a gradient?

My point is that handling _all_ the use cases shouldn't be a goal. Handing 
the cases that will be needed 90% of the time is all that should be aimed 
at, in oder to keep things simple.

For the more complex cases, you can always just use multiple shapes. Yes, 
it makes animation harder, it means UAs have to handle the "compound 
shapes" specially, etc. That is, IMHO, a price worth paying for the 
simplicity of authoring for the common case.


> > > - 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)
> > 
> > Not sure what you mean by these, could you give examples?
> 
> set back means that a stroke is not stroked with a certain offset to a 
> vertex or end point. F.e. you could have a gap before drawing a marker. 
> I think, that's a very useful feature for high-quality graphics

Oh, right. Why does this need to be supported explicitly? You can do it 
today just by having multiple lines, some of which are shorter than 
others. Sure, animating it requires more thought, but exactly how common 
is it that this will be animated?


> reusing edges: if you draw adjacent polygons you have redundancy, 
> because every polygon has to have a closed path. With you reusing edges, 
> you can centrally define edges, f.e. in the <defs> section and then 
> build a new path out of individual edges, thus avoiding redundancy

How is this different from having a shape <use>d several times with 
different cascaded values for 'stroke' and 'fill' and different applied 
transforms? (I'm not saying it is, I'm just trying to understand exactly 
what the use case is here.)


> > I'm not denying tha there are use cases for the vector effects work. 
> > All I'm saying is that to handle 90% of these use cases, it seems like 
> > a significantly simpler model could be used, instead of introducing 
> > something that, frankly, is frightening in its complexity.
>
> thats why it is not in the SVG basic profile, but in the full profile. 
> We, as the SVG users would already appreciate, if Mozilla/Opera would 
> implement at least the SVG Basic profile.

And once we've implemented the Basic profile, we will immediately receive 
requests to implement the Full profile.

There is only one profile that matters, and that's the whole thing. 
Anything that isn't implemented simply shouldn't be in the spec. If it 
isn't implemented, authors can't use it, and thus the spec is basically 
lying if it claims that the language has that feature.

(That is why, for instance, the CSS working group decided to send CSS2 
back through the standardisation process with a real "Candidate 
Recommendation" period, and why we threw out a number of features that 
browsers had, by and large, not implemented, or poorly implemented.)

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

Received on Wednesday, 10 November 2004 12:21:52 UTC