W3C home > Mailing lists > Public > www-svg@w3.org > September 2008

Re: [1.2T-LC] inverse and constrained transformations

From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
Date: Sun, 28 Sep 2008 18:09:17 +0200
To: www-svg@w3.org
Message-Id: <200809281809.17673.Dr.O.Hoffmann@gmx.de>

David Woolley:

>Can you provide a concrete example.  I would have though that, if the 
>inverse didn't exist, there will always be points that don't have a 
>unique image when the transform is reversed.

If the determinant of the transformation matrix is zero, 
2-dimensional and 1-dimensional structures are mapped
to 1-dimensional structures or points. Just looking at the
result, it is not possible to reverse such transformation,
it is not a bijective function, just surjective.

For example matrix(0 0 0 0 e f), matrix(1 1 1 1 e f), matrix(0 1 0 1 e f),
matrix(1 0 1 0 e f), matrix(1 1 0 0 e f), matrix(0 0 1 1 e f) 
etc with e,f numbers have no inverse.

Or in an animateTransform of the type scale one may 
try values="-1;1" - without keyTimes at 50% of active
duration obviously the scaling is zero, the determinant too,
but before and later there is an inverse again. Or
if someone uses values="-1 1;0 2;0 -2;1 -1" this is not only
one moment, it is a complete time interval without an inverse,
but using the new vector-effect non-scaling-stroke a structure
remains visible as a line (or point). 
As an application, if one rotates (with animateTransform of type
rotate) an element with vector-effect non-scaling-stroke and scales 
one dimension to zero, the result is an exact representation of an 
harmonic oscillator, else only available as approximation in SVG, 
resulting from some number crunching. An author can use this to 
check the accuracy of such an approximation for example.

And obviously if an element with transform="<transform-ref>" 
is inside such a structure, it is intended, that it remains unchanged 
as 2-dimensional object. An implementation cannot use the 
not existing inverse to get it unchanged, it has to do it in another
way (what is practically not a big problem, because the document
itself contains much more information about the transformation
and structure than the CTM, or the implementation can extract such
objects with constrained transformations in general, before they
are transformed and just put them back for rendering only).

Doing tests about this feature, for me such degenerate cases would
be the first thing to explore, whether an implementation crashes or 
fails with this feature of constrained transformation or not.
The second thing would be a skewX/Y around +-90 degree ;o)

Received on Sunday, 28 September 2008 16:54:43 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:15 UTC