Re: SVG 1.2 Comment: vector effects

On Wed, 10 Nov 2004, Peter Sorotokin wrote:
> > 
> > It seems like the simplest way to do this would be to use a new unit, 
> > one that didn't scale with the zoom.
> 
> Yes, we certainly tried that (in pre 1.0 drafts CSS units did not 
> scale). It kind of works for uniform scale, but if x and y scale factors 
> are different it breaks down. In graphs people typically scale the 
> coordinate space to work in their units and scale is typically 
> non-uniform. And what about non-scaled fill patterns?

Could you expand on these problems? I'm not sure I follow. What would the 
problem be with x and y scale factors being different, if the unit simply 
doesn't scale at all?


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


> > > - 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?
> 
> Setback is a break in the line so that it does not overlap with the 
> marker.
> 
> Sharing edges is when you have a map where there are "countries" and 
> "borders". You want to define each border between two countries in a 
> separate path and then plug them together to get the outline of the 
> country. This involves reversing some of the paths. Sharing information 
> like that allows one to have smaller files and to manipulate border data 
> more efficiently; it potentially allows renderer to produce 
> higher-quality antialiasing (shared borders are hard to antialias 
> properly without knowledge that they are shared).

Thanks for the explanations.

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.

I mean, come on. If you want a shared edge on a map, just use one path 
element, with one stroke, instead of having the edge drawn by both 
elements.


> > > - all of the above should integrate with animation (e.g, path 
> > >   animation) and not cause substantial file size bloat.
> > 
> > The two proposals I list above (a new unit and allowing multiple 
> > values on two propeties) seem to handle this.
> > 
> > I'm not denying that 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.

I stand by the above comments.

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

Received on Tuesday, 23 November 2004 13:09:15 UTC