- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 29 Nov 2004 05:03:22 +0000 (UTC)
- To: Craig Northway <craign@cisra.canon.com.au>
- Cc: www-svg@w3.org
On Wed, 24 Nov 2004, Craig Northway wrote: > > I agree with some of your earlier comments regarding the more complex > effects. I raised some objections with the working group. As Jon has > already mentioned, all proposed effects were included in the last call > draft, but pending comments from the community may get dropped. With all due respect, I would feel more comfortable if the SVG specification was designed with simplicity in mind, rather than starting with everything and then only removing features if enough people complain. > > Ok here's a proposal which would dramatically simplify all this (and > > which, in conjunction with the two other proposals to address the two > > other use cases mentioned for this chapter, would reduce the entire > > chapter to about three minor extensions). > > > > Add a new command to the path language that imports another path at > > that point. Instead of: > > > > <defs> > > <path id="border1" d="..."/> > > <path id="border2" d="..."/> > > <path id="border3" d="..."/> > > <path id="border4" d="..."/> > > <path id="border5" d="..."/> > > </defs> > > <vectorEffect> > > <vePath> > > <vePathRef xlink:href="#border1"/> > > <vePathRef xlink:href="#border2"/> > > <vePathRef xlink:href="#border3"/> > > </vePath> > > <veFill color="red"/> > > <vePath> > > <vePathRef xlink:href="#border4"/> > > <vePathRef reverse="true" xlink:href="#border2"/> > > <vePathRef xlink:href="#border5"/> > > </vePath> > > <veFill color="blue"/> > > </vectorEffect> > > > > ...you would do: > > > > <defs> > > <path id="border1" d="..."/> > > <path id="border2" d="..."/> > > <path id="border3" d="..."/> > > <path id="border4" d="..."/> > > <path id="border5" d="..."/> > > </defs> > > <path d="url(#border1) url(#border2) url(#border3)" fill="red"/> > > <path d="url(#border4) reverse-url(#border2) url(#border5)" fill="blue"/> > > I will pretty much repeat some of Dean's earlier comments because this > solution shares some problems with your earlier solution. This is > difficult to animate and makes parsing more difficult by adding another > micro-syntax. The path syntax is difficult to specify animation and for > an author to animate. This makes it even more difficult. Could you explain the use case for animation vePath? Also, I don't buy the "this is harder to parse" argument. the url() syntax already has to be supported by SVG UAs. The above is no harder to parse than the extended <paint> syntax. In fact, writing a parser for the above is probably on the same order of complexity as writing the code to handle the trees you get in vectorEffect elements. > > That would also get around another problem I have with vectorEffect, > > which is the way you can make any random shape (e.g. a <circle>) look > > like any other random shape (e.g. a country). That seems to defeat the > > point of having shapes in the first place. It also makes trying to > > understand SVG markup quite hard. > > I don't understand how vector effect makes a circle look like another > random shape? Please explain this further, perhaps with an example? Please correct me if I'm wrong, but as far as I can tell this circle is a square: <circle vector-effect="url(#square)"/> <defs> <vectorEffect id="square"> <vePath> <vePathRef xlink:href="#square-path"/> </vePath> <veStroke/> </vectorEffect> <path id="square-path" d="M0,0 L10,0 L10,10 L0,10 Z"/> </defs> (I may have gotten the syntax a bit wrong but hopefully you get the idea.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 29 November 2004 05:03:27 UTC