Re: [Transforms] specification feedback

Hi Steve,

Thank you for your feedback on the Transforms specification.

Steve Withall wrote:
> Esteemed experts,
> 
> I'd like to make some comments on the "SVG Transforms 1.0, Part 2: 
> Language" document, draft dated 11 March 2009:
> 
> 1. Section 2: The references to 'Z position' confound me. Does that mean
>     that specifying z-order by a proper Z co-ordinate rather than an
>     index is on the cards? I would argue strongly in favour of doing so.
>     An index serves no purpose except ordering, but a *position* can
>     be used for all kinds of purposes (as I was attempting to argue in my
>     previous email).
> 

My apologies for the confusion. Evidently my attempt to make it clear did the 
exact opposite. The purpose of the 'Z position' is as the name suggests a 
position for an element on the z axis. Note that the purpose of the z position 
is purely for transforming the points of an object to achieve a 2.5D effect. By 
default all objects are still rendered according to painters algorithm, however 
they may have a 3D transform applied to them to change their location and/or 
appearance.

>    Also, since transforms will use proper Z positions, to use artificial
>     integers for z-ordering (rather than positions) would introduce an
>     inconsistency. And every inconsistency makes something harder to learn.
> 

I agree. The idea is to make things as consistent as possible.

> 2. Section 2: I see no need for special elements (layeredG or g3d).
> 

Ok. Noted. As far as I'm aware the SVG Working Group is looking at defining a 
rendering model for SVG 2.0 that will hopefully solve these '3D issues'. 
Defining the rendering model for SVG 2.0 may result in the working group deeming 
layeredG to be unnecessary (note this is all purely speculation, in the end I 
have no idea what we'll decide on).

> 3. Sections 2.1, 2.2: I'm confused when you refer to 'properties'. Are
>     'transform-origin' and 'perspective' intended to be defined in the 
> 'style'
>     attribute (or from a style sheet)? If so, that doesn't seem natural to
>     me: these aren't style-related at all.
> 

Correct; if this was purely for SVG they would definitely not be style related. 
The SVG Working Group decided that these should be properties as the CSS 3D 
Transform specification had these defined as properties. Personally I'd prefer 
them to be attributes, however, having them as properties allows them (as you) 
suggest to be put in a style sheet.

> 4. Section 2.1: Whenever I see a property or attribute that contains
>     multiple values, I ask myself whether it could be achieved another
>     way. Multi-values are a pain to animate. In the case of 
> 'transform-origin',
>     if this were an attribute, its value could be a property list
>     (eg. transform-origin="ox:0; oy:100; oz=50"). If <animate> and
>     <set> were made a little more intelligent, it would be easy to
>     animate a single value within a property list for any attribute.
> 

Ok, so would you prefer: transform-origin-x, transform-origin-y, 
transform-origin-z? I guess something like that is a little verbose, but non the 
less I think it is something the SVG Working Group should consider.

> 5. Section 2.1: Naming things 'o' is to be avoided whenever possible,
>     because of possible confusion with '0' (that's a zero), especially
>     things with numeric values. Can't you use another letter? Why not
>     call these plain x, y and z?
> 

Hmm. Ok. Sure, I don't really see a problem with making them plain x,y,z.

> 6. Section 3: I think you should maintain more backward compatibility.
>     Can't you maintain *complete* backward compatibility if you:
> 
>     (a) Introduce rotate3D() for 3D rotations, and keep rotate() as
>          it is (for 2D rotations).
> 
>     (b) Make the <cz> values optional in rotateX() and rotateZ().
> 
>    Since the bulk of SVG documents are purely 2D, you shouldn't impose
>     a burden on their authors for 3D features that they don't want to
>     use. So in addition to backward compatibility you shouldn't force
>     authors of 2D documents to do more work (supply more values).
> 

Right. Once again I agree with this. However, the SVG Working Group decided at 
one point to change the syntax for this. I can't remember why exactly, I think 
the answer lies in the minutes from the Sydney face-to-face this year. As a side 
note, from memory CSS Transforms uses rotate for 2D rotations and rotate3D for 
3D rotations. I would be in favor of changing this to match the CSS specification.

> 7. General: I don't like matrices, and I daresay the vast majority of
>     SVG document authors don't either. You should make it as intuitive
>     as possible for a non-techo to specify rotations in 3D - especially
>     about a horizontal or vertical axis.
> 

Currently the Transforms specification defines rotateX, rotateY, rotateZ or is 
there something else that should be added or have I missed the boat completely 
on this one?

> 8. General: Following on from point 7, this specification is crying out
>     for some examples. Devise what you consider to be a range of common
>     cases and show the sources of the elements that implement them.
>     Until you do that it won't be possible for a reader (reviewer)
>     to judge how easy this stuff will be to write.
> 

Examples - definitely need them. The specification is very incomplete given the 
lack of examples. That'll be one of the things that will go into the next revision.

> Now a few things that go beyond the scope of this specification:
> 
> 9. This specification addresses just the transform extensions
>     themselves. By implication that means it affects just graphical
>     elements. But that need not be so. The case that interests me
>     is <animateMotion> along a path 'tilted' in three dimensions, which
>     I think can be achieved straightforwardly (famous last words!).
>     Your perspective stuff is able to define the tilt. For example, you
>     could have collection of objects 'orbit' together in a horizontal
>     plane. I hasten to add that the path itself will still be defined
>     in 2D.
> 

Possibly. This is an interesting case which I think I'll make a test case for to 
see what happens.

> 10. Also on a wider note, I'd prefer to be able to express 3D effects
>      in terms of what I want to achieve, rather than having to calculate
>      all the details and then express them in terms of transforms
>      (which are, let's face it, an unintuitive implementation contrivance
>      when you go beyond the trivial). That is, I'd like the software do
>      the tedious calculation of perspectives, say to align graphical
>      elements relative to a virtual horizon.
> 

This kind of goes beyond the scope of what SVG Transforms is trying to achieve. 
Perhaps this might be a good use case that the layout specification could handle.

> 11. Another feature that could be added is adjusting the rendered size
>      of elements according to their z positions - so as an animation
>      moves an element 'outwards' it appears to get bigger. Again, this
>      should be done without the document author having to do the hard work.
> 

Ahh ok. This was one of the reasons for adding the perspective transformation; 
to give the illusion of depth. The size of objects does change according to its 
z position when a perspective transform is applied.

> Regards, Steve.
> 
> 
> 

Once again thank you for the feedback Steve. I hope this answers some of your 
questions/comments. If not please let me know, I'm happy to discuss any of the 
points further.


Kind Regards,

-- 

Anthony Grasso

Software Engineer

Canon Information Systems Research Australia
1 Thomas Holt Drive, North Ryde, NSW 2113
AUSTRALIA

Phone: +61 2 8873 8821
Email: anthony.grasso@cisra.canon.com.au

--

The information contained in this email message and any attachments may be 
confidential and may also be subject to legal professional privilege. If you are 
not the intended recipient, any use, interference with, disclosure or copying of 
this material is unauthorised and prohibited.

If you have received this email in error, please immediately advise the sender 
by return email and delete the information from your system.

Received on Friday, 20 November 2009 05:53:59 UTC