- From: Craig Northway <craign@cisra.canon.com.au>
- Date: Wed, 24 Nov 2004 09:42:35 +1100
- To: Ian Hickson <ian@hixie.ch>
- Cc: www-svg@w3.org
Ian, Ian Hickson wrote: >On Wed, 24 Nov 2004, Dean Jackson wrote: > > >>On 24 Nov 2004, at 00:09, Ian Hickson wrote: >> >> >>> ... >> >>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. > > I think that making a good language would include making one that can be operated on easily by existing tools. I think that complex attribute syntaxes should be avoided because they significantly increase implementation complexity. >>- It adds another micro-syntax to the language that implementers have >> to handle. >> >> > >So does adding a bunch of new elements. > > As Thomas said it much easier to add elements to an XML based language than complicated attribute syntaxes. >>- [...] >> >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. > > This does not solve many of the solutions vector effects does, in particular where strokes, fills and markers can be combined in different orders. > > > >> [...] > > >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. > > These may not be the only requirements, Peter adding the caveat "In short" to the start of this list. Craig >[...] > >
Received on Tuesday, 23 November 2004 22:43:11 UTC