Re: [SVG Transforms 1.0, Part 2: Language (2009-03-20)] - Feedback for "3. TransformList Extensions"

Hi Dr. Olaf,

Your recent email [1] and Steve's email has prompted me to respond to your 
original comments. See me responses inline below.

Cheers,

Anthony

[1] http://lists.w3.org/Archives/Public/www-svg/2009Nov/0082.html


Dr. Olaf Hoffmann wrote:
> 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>])
> 

Yes. Personally I think this should be changed.

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

The original proposal was to use different names and as you can probably tell I 
think the wider community would probably prefer different names as well.

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

This is probably something worth discussing. This would be more of a band-aid 
solution and be somewhat inelegant compared to adding new names for the 3D 
transforms.

> 
> 
> The matrix in 1.2.3 represents only a rotation
> with cx=cy=cz=0 ?! -> should be noted.

Ok. Can do.

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

Your assumption is correct. SVG Transforms 1.0 does use the right handed system 
with positive z pointing perpendicular towards the screen. The reasons is the 
vanilla 2D rotate value specifies an anti-clockwise rotation. Additionally, I 
feel it is easier from an authoring point of view to have the perspective point 
appear to be behind the screen (thus giving positive z in the direction towards 
the monitor). Given that you've made a comment on this, is there anything you 
feel should be fixed or clarified?

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

The conflict with filters is something that the SVG Working Group should 
probably discuss to see if anything can be done about it. Thank you for pointing 
this out.

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

The wording sounds fine to me.

> 
> 
> Best wishes
> 
> Olaf
> 
> 
>

Received on Friday, 4 December 2009 07:11:27 UTC