Re: SVG 1.2 Comment: vector effects

Ian,
You state that "have built-in support for GIS analysis", but in fact SVG 
does not include built-in support for GIS analysis. As a matter of fact, 
the SVG WG went to great effort to take multiple overlapping functional 
requests from multiple industries (GIS, CAD, graphics design, UI design) 
and design a general-purpose, easily-implementable, but highly-leverage new 
feature which fits in easily with the existing SVG processing model.

The key parts of vector effects are that it allows great control over the 
rendering of a particular shape. In SVG 1.1, you had one options: exactly 
one stroke operation, then exactly one fill operation, and then one marker 
operation. As a result, in order to implement SVG 1.1, user agents have to 
have the ability (you guessed it) stroke a shape, fill a shape and put 
markers on a shape. With vector effects, you now have extra flexibility to 
change the order and the number of times you stroke, fill and draw markers. 
Vector effects also adds a few bits of flexibility, such as applying a 2x3 
transformation (a feature that is already in SVG user agents). The vector 
effect management layer is modeled after filter effects so that the same 
underlying code can be used for both filter effects and vector effects. As 
a result, most of the features in vector effects take advantage of 
facilities already in the user agent. My key point is that the SVG WG spent 
a lot of time defining vector effects to be easily implementable and 
leveragable across multiple industry requirements.

But the SVG WG will readily admit that there are a few aspects to SVG 1.2's 
vector effects that will require significant implementation work. In 
particular, <veJoin>, <veUnion>, <veIntersect> and <veExclude> require some 
significant graphics programming skills. The SVG WG recognized that these 
operations were difficult and as a result there is a good chance that they 
might get dropped from SVG 1.2. We decided to include these elements in the 
Last Call draft because there is proof of industry usefulness for these 
operations, and even if they get dropped from SVG 1.2, we wanted to make 
sure the architecture accommodated those operations. These features are 
definitely challenging, but most of the other features in vector effects 
are readily implementable and in fact, because of their great general 
utility and implementation ease, are a candidate to consider for a future 
version of SVG Tiny, particularly when SVG Tiny integrates with XBL because 
vector effects are often a good match for custom visualization components.

Jon

At 04:07 AM 11/10/2004, Ian Hickson wrote:

>On Sat, 6 Nov 2004, Andreas Neumann wrote:
> >
> > As a content creator and cartographer I can only second Peters and Dougs
> > comments. Many of the more complex map symbolization problems can be
> > adressed using vector effects. [...]
> >
> > Besides that, vector effects can help to solve quite a few GIS analysis
> > features (such as intersection, excluding, merging of elements). Doing 
> it all
> > by script would be complex and slow, besides the problems that Doug 
> mentioned,
> > regarding semantics.
>
>I don't really see that it is appropriate for the Web browser to have
>built-in support for GIS analysis. I don't doubt that it would be very
>useful in your domain, but there is a line to be drawn at how much a Web
>browser needs to support.
>
>To give parallels with HTML -- HTML has support for a definition list -
><dl>/<dt>/<dd> -- which can let you write, for instance, a glossary.
>That's great, but dictionary and encyclopedia authors ask why doesn't HTML
>also have support for saying that a word is a noun? Or an adjective? Why
>is there no way to define the syllables of a word? Why is <dd> only one
>level deep, allowing for multiple definitions but not sub-definitions? Why
>is there no markup for highlighting the root of the word, the
>pronounciation of a word, the etymology of a word?
>
>The answer is that HTML -- like SVG! -- should be a generic language,
>suitable for a wide range of fields, relatively simple to implement. For
>more specific work, like writing a dictionary, more specific languages
>should be used, which can then be transformed into HTML when it comes to
>the final stage of showing it to the user.
>
>The same should apply to SVG. Sure, on the server side you probably want
>to embed custom namespaces to label roads, altitudes, gradients, and other
>geographical and geological features. But when the map is finally shown to
>a Web UA, it would be inappropriate to expect the user agent to be able to
>intelligently handle all that data.
>
>So yes; simple things like keeping the strokes the same width despite
>zooming seem like they could be cheaply supported in SVG. More complicated
>things such as client-side fill intersections, unions, etc, seem excessive
>for a Web UA.
>
>
> > Of course, not every SVG viewer needs to implement vector effects. 
> That's why
> > we have profiles. I totally understand, that a SVG basic or SVG tiny 
> renderer
> > cannot adress vector effects.
>
>I am concerned about the "Web UA", that is, the UA that normal Web authors
>will target. If a feature isn't included in the "Web UA", then it might as
>well not be in the spec -- as several people have said, the SVG Full specs
>represent what the working group think should be implemented by Web UAs.
>
>Note that since I do not want to see a fragmentation of Web standards,
>where browsers support one language on small devices and another
>incompatible language on desktops, I only consider there to be one "Web
>UA" version of SVG. Whatever desktop UAs implement is what mobile UAs
>should implement. (The same is true for CSS, HTML, DOM, etc -- Mozilla and
>Opera, the two UAs that are available on desktop and mobile spaces, both
>implement the same specs in both spaces.)
>
>--
>Ian Hickson               U+1047E                )\._.,--....,'``.    fL
>http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
>Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 10 November 2004 14:05:51 UTC