[SVG Transforms 1.0, Part 2: Language (2009-03-20)] - Feedback for "2.1. The 'transform-origin' property"

Hello SVG WG,

It is noted, that the initial value of transform-origin is '0 0 0' and
'Value: <list-of-lengths> | none' and 'Percentages: no', but later in the 
prose as possible values of <ox>, <oy> and <oz> are currently only 
keywords or values in percentage allowed. This is a contradiction.

Note additionally, that currently the definition claims, that the values
are of the type <length> and points to SVGT12:
'The format of a <length> is a <number> optionally followed by a unit
identifier. If the <length> is expressed as a value without a unit identifier
(e.g., '48'), then the <length> represents a distance in the current user
coordinate system.'

This fits to what I think is useful, but does not fit to the current
definition in 'SVG Transforms 1.0', because there are keywords possible too,
but no unitless numbers (what can be essential for SVGT1.2 implementations).
Additional possibilities are in general ok (and in some use cases pretty
helpful for authors), but do not fit to the current definition of a <length>
and <list-of-lengths>.


Else, I think, for many applications it is more useful to note the origin in
user-coordinate pixels and not in percentage of the bounding box, because
for an animated object the bounding box may change. The keywords are related 
to an orientation and alignment in the user coordinate system (of course, 
should be noted however, just for the convenience of readers)?


A notation in percentage or with these keywords might be helpful for a fast
author guess, but for more complex applications or script-generated content
the author/script will typically not calculate the bounding box or the
bounding box is pretty irrelevant for the transformations and will 
prefer a fixed point in the user coordinate system. Without a simple fixed
point this means complex calculations and animation of the transform-origin
to compensate such effects.
As typical examples for applications I have animations representing double
star systems, planetary systems or two particle collisions.
Currently I do the 3D-transformations and the projection within the
PHP-script; to be able to do this in SVG would be a big progress in the
direction of better user experience, smaller file size and maybe static
documents. The bounding box in all these samples changes continuously 
and is larger than the viewBox and pretty irrelevant both for the author and
the audience.
If the transform-origin would change within the animation due to a value
given in percentage or with such a keyword combination the animations would
look rather stupid and wrong. For such applications the currently possible
bounding box related values are useless.
Of course one can simply still use the related translations as today, however
this property could simplify this a little bit.


Best wishes

Olaf

Received on Sunday, 22 March 2009 14:46:16 UTC