ISSUE-2245: 3. TransformList Extensions
TransformList Extensions incompatible
3. TransformList Extensions
- State:
- RAISED
- Product:
- Module: Transforms
- Raised by:
- Anthony Grasso
- Opened on:
- 2009-03-23
- Description:
- http://lists.w3.org/Archives/Public/www-svg/2009Mar/0185.html
currently this is not an extension of the transform
list of SVG, it is simply incompatible.
In detail:
For the rotate type in this draft it is specified:
'rotate(<rotate-angle> <nx> <ny> <nz> [<cx> <cy> <cz>])'
with ci indicating the rotation center and ni indicating
the vector for the rotation
However, even if it is assumed, that current viewers simply
ignore list items, if there are more than defined for
SVG1.1 and SVGT1.2, the result will be quite different
from that of a 'SVG Transforms 1.0' viewer, because
for SVG1.1 and SVGT1.2 we have:
rotate(<rotate-angle> [<cx> <cy>])
what corresponds here to
rotate(<rotate-angle> 0 0 1 [<cx> <cy> 0])
or
rotateZ(<rotate-angle> [<cx> <cy>])
The other question is, what an arbitrary viewer
really does, if matrix, translate, rotate, scale
appear with a different number of list items.
Maybe it is in general a better idea, to use
completely new types like m3D, t3D, s3D, r3D,
rX3D, rY3D, rZ3D to avoid confusion. With this
there is a good chance that several viewers
will simply ignore the transform attribute
following SVGT 1.2, if they do not have it
implemented.
Else the other way round an 'SVG Transforms 1.0'
gets problems with the old notation for matrix
too, because, within this draft one has to
provide a list of 12 numbers, in SVG1.1 and
SVG1.2 only 6 numbers.
Maybe it would be helpful to
provide a feature string for 3D transformations,
then authors can use a switch to provide some
useful content for all viewers.
The matrix in 1.2.3 represents only a rotation
with cx=cy=cz=0 ?! -> should be noted.
Currently the 1.2.3 is referenced to represent
the complete 3D rotation in the first sentence
of the rotate defintion.
I assume that the rotation vector points from
[cx cy cz] to [nx ny nz] and that the direction
of the rotation can be determined by the
right-hand-grip-rule, correct?
If this is true, SVG Transforms 1.0 seems to
use a right handed systems, with the z-axis
pointing into the direction roughly from the
eye of the user into the screen (perpendicular
to the screen)
Note that SVG filters use a positive z-axis
pointing from the screen to the eye of the
user, see for example the definition of
'fePointLight' and 'feSpotLight' - this does not
fit together, has to be checked and in case
that this observation is true fixed to avoid
inconsistencies.
It is further noted for translation:
'If <ty> and <tz> are not provided, it is assumed to be zero.'
It think, this should be something like:
'If <ty> or <tz> are not provided,
the missing items are assumed to be zero.'
Correspondingly for scaling:
'If <sy> and <sz> are not provided, it is assumed to be equal to <sx>.'
->
'If <sy> or <sz> are not provided,
the missing items are assumed to be equal to <sx>.' - Related Actions Items:
- No related actions
- Related emails:
- ISSUE-2245 (TransformList Extensions incompatible): 3. TransformList Extensions [Module: Transforms] (from sysbot+tracker@w3.org on 2009-03-23)
Related notes:
No additional notes.
Display change log
