Re: SVG 1.2 Comment: vector effects

Ian,

the browser vendors did not care about SVG 1.0 when it was released, 
when it was simpler than SVG 1.2. Suddenly, they complain that it might 
get too complex. 4 years after SVG 1.0 was released. I would be 
perfectly happy if the browser vendors would provide a full, clean 
implementation of SVG 1.0/1.1 and for now leave SVG 1.2 to more 
specialized SVG UAs, such as ASV/Batik or others.

As to the complexity of vector effects: yes, they might not be trivial 
to implement, but they are certainly doable. And there are tons of 
graphics applications out there that do implement them. Or do you know 
any serious vector graphics application out there that does not 
implement union/intersect/path offset, etc? There is also open source 
code there and papers that describe the algorithm. Implementing vector 
effects is certainly not too easy, but it is doable. Otherwise the 
working group would not propose it. And it's certainly not innovation. 
All of the effects are out there for years. And many of the vector 
effects features are now supported by graphics APIs, such as Java2D.

see f.e.:
http://java.sun.com/docs/books/tutorial/2d/display/complexshapes.html

I am sure that these feature are not only supported by Java2D, but also 
many other graphics libraries.

---------------------

As to your other argument, that vector effect would only be needed by 
less then 10%:

I don't buy this argument. There are many features in HTML/CSS that less 
than 10% of the people use, and still they are here and used.

Finally, I really think that quite a few of the vector effects are not 
only useful for domain experts, but also for the general public. Or do 
you think that the path operations in Illustrator and co are just used 
by cartographers/GIS people?

If you want, you could also do a poll on the svg developers list and 
would find out that a lot of people on this list would have a use case 
for one or more features of the vector effects proposal.

Andreas

Ian Hickson wrote:

>On Wed, 24 Nov 2004, Dean Jackson wrote:
>  
>
>>At this point in the long thread, I'm not sure what the best way to 
>>proceed is.
>>
>>Ian is the main person opposed to the current model and syntax. I don't 
>>see many other people on his side raising new data (Boris sent in a 
>>grammatical comment for example).
>>    
>>
>
>There isn't much "new data" to raise. (Several people have told me that 
>they agree it is complicated but didn't feel they had anything to add and 
>so didn't send any comments on the matter.) The model is IMHO excessively 
>complicated for a spec aimed at use on the Web.
>
>The current vectorEffect language would actually be pretty good if it was 
>a vector language in itself, without the rest of SVG. It can do a lot, 
>it's very powerful. On its own, it's pretty simple and easy to understand. 
>But when you add to it the entirety of the rest of SVG it's just too much.
>
>
>  
>
>>On the other hand we have at least three implementers (Adobe, Apache and 
>>Canon), a number of domain specialists (from GIS and graphics 
>>backgrounds) and SVG content developers supporting the existing model 
>>and syntax.
>>    
>>
>
>I agree that many parts of SVG 1.2 would be very useful for experts in 
>specialist domains. If that's the target audience for SVG 1.2 then that's 
>fine, but it should say so, and Web browser manufacturers could relax and 
>ignore SVG 1.2. On the other hand if the target audience of SVG 1.2 is the 
>popular Web, then features like vectorEffect and the various other areas I 
>mentioned as too complex should just be dropped or dramatically simplified 
>to address only the critical issues missing from SVG 1.1. (Ideally, this 
>effort would be done in parallel with massive simplification of SVG 1.1 
>itself, which is sadly also a very complicated spec.)
>
>  
>

Received on Monday, 29 November 2004 08:58:58 UTC