Re: Some questions regarding transformations in SVG

Steve Schafer wrote:
> On Sat, 15 Nov 2014 19:37:35 +0100, you wrote:
> 
>> You really want to tell me that the SVG WG does not even want to 
>> consider non-affine transformations for SVG because it might take more 
>> computational power than "simple matrix math"?
> 
> Not just more computational power, but more expressive power. The space
> of "non-affine transformations" is effectively infinite. Are you willing
> to limit that to some subset (e.g., projective geometry)? Or do you want
> everything? The more you encompass, the more your means of expressing a
> transformation begins to look like a general-purpose programming
> language. There's no point in reinventing JavaScript within SVG--it's
> already there.

I do not want "everything" out of "infinity", for sure! If 
transformations other than affine ones had been discussed before in the 
SVG WG, coming to some sort of conclusion, I will see what to make out 
of it. Unfortunately, the specs (the existing 1.1 as well as the 
upcoming 2) as well as my Google search on the topic (probably using the 
wrong keywords) don't reflect such a discussion. That's why I ask what 
might have been discussed before!

Of course, "projective geometry" might be a candidate for such a class 
of transformations, especially with regard to the z-index which 
hopefully makes it in SVG2!

And regarding your comments about JavaScript, I am completely with you! 
I would not necessarily favour to have "dynamic content" realized 
directly with SVG when there is a way to do it via JavaScript, but 
"static usecases" should be supported without the help of JavaScript, if 
they are worth to be explicitly supported at all. That's obviously also 
the reason for having affine transformations in SVG1 (which you could 
also do via JavaScript)! So, why not consider other transformations as 
well for SVG2? And remember also that even when you can do something 
with the help of JavaScript, it will not show up in all your 
presentations of the very same SVG depending on the way of inclusion in 
HTML due to "security and privacy considerations".

Juergen Roethig

Received on Sunday, 16 November 2014 08:44:03 UTC