Re: SVG 1.2 Comment: vector effects

Ian Hickson wrote:
>> 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?

Yes, why have markers, to start with? :-)
Just compute, manually or with an authoring tool, where to put symbols 
on the path, with correct rotation.

>> 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

I first thought it was something like avoiding to define twice common 
edges in tesselations/grids/meshes, but I am not sure now.

> 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.)

This is probably seen as bad use, at least in the case of text: if you 
repeat a text several times just to make an effect, it would hurt 
accessibility.

>> > 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.

Of course, but at least that would be a good starting point, consistent 
and all. :-)

> 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.

The fact it cannot be implemented simply doesn't mean it won't be 
implemented at all... Most of the spec. is probably already existing in 
commercial vector drawing programs, so it is doable.

Now, maybe you mean that the spec. shouldn't be implementable by only 
one vendor, and I agree here.

Note that I was pleasantly surprised to see implementation suggestions 
of the most difficult algorithms in SVG 1.1. Some may object it is not 
the purpose of a spec., but at least it shows it is doable, and try and 
help to do them.

> (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.)

Indeed, so CSS points are complex and puzzling too...

-- 
Philippe Lhoste
--  (near) Paris -- France
--  Professional programmer and amateur artist
--  http://Phi.Lho.free.fr
--  --  --  --  --  --  --  --  --  --  --  --  --  --

Received on Thursday, 11 November 2004 20:10:02 UTC