Hello all,

This may be way off in "left field"...

I looked at the link that Lofton provided: http://www.w3.org/TR/SVG11/coords.html and read sections 7.4 and 7.5

I also read 6.10, and 7.10 and 7.10.4 (the transform part) of 8632-1:1999

I think that the math behind the two approaches is identical and the differences are in how interfaces are defined. SVG defines a 3x3 matrix with the bottom row hard coded to 0,0,1. CGM defines a 2x2 matrix that it calls the scale and rotation matrix (It can also be used to define skew) and a 2x1 matrix for translation. The scale/rotation part is the same as the a,b,c,d part of the matrix shown in the SVG documentation. The second part of the CGM transform is the x,y translation and corresponds to the e,f terms in matrix shown in the SVG documentation.

CGM seems to make the assumption that it can just say that it is a "transformation matrix" and the user will know what to do with it, while SVG gives examples and shows how to combine scaling, rotation, and translation into a single transformation matrix.

The one thing that is not described in either spec is how to scale or rotate around an arbitrary point. To do this you need to first add a virtual translation to move that "point" to the origin the do the transform and add a second translation to move the point back. If the user wants a complex transform made up of more than one of a scale, a rotation, and a translation it is their responsibility to create a single combined matrix that does that...

I started thinking that maybe we should look at how segments work and use it as a basis for our transforms. Yes, I know that segments are not allowed in the webCGM profile. One thing that bothers me about the CGM segments is there does not seem to be a good way to package a SEGMENT TRANSFORMATION and a COPY SEGMENT together. I think that when the interpreter finds a COPY SEGMENT it just applies the most recent transformation?

IF (and this is a BIG IF) we allow segments and the transforms to go with them we have half of what could be used to do transforms. The way segments are defined in the spec it allows graphic primitives to be reused in a static way.. If we could wrap the segment within an application structure and expose the transform to the DOM we could have dynamic transforms! To make them easier to use you could define convenience routines (scale, rotate, translate) that would populate the matrix for the user.

Style property or APS attribute: In my mind a style property is one that has an equivalent graphic primitive while the APS attributes in general do not have an equivalent graphic primitive. So I would come down slightly on the side of our transforms should be a style property. I also think that to support the ability to do a relative transform I would need to be able to get (or know) the current transform which would mean that we want read access which makes it more like an APS attribute... Argh, I am not sure what the right answer is here!

CGM, XCF or DOM: Segments are already part of the CGM, but if we insist that they are associated with and APS structure it would make sense to support them within the CGM file and the XCF file as well. While I could implement dynamic behavior by sequentially loading XCF files it would probably be a good idea to allow write and probably read access via the DOM.