- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 23 Nov 2004 13:09:04 +0000 (UTC)
- To: Peter Sorotokin <psorotok@adobe.com>
- Cc: www-svg@w3.org
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