Re: Some questions regarding transformations in SVG

On Sun, Nov 16, 2014 at 12:43 AM, Juergen Roethig <roethig@dhbw-karlsruhe.de
> wrote:

> 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!
>

Can you give an example of what such non-affine transformations look like?
Do you know of any tools that offer them?


> 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!
>

I don't understand why z-index is special. Can you eleborate?


> 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
>
>