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