- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Sun, 22 Mar 2009 18:39:56 +0100
- To: www-svg@w3.org
Hello SVG WG, 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>.' Best wishes Olaf
Received on Sunday, 22 March 2009 18:05:24 UTC