RE: [cgmo-webcgm] ISSUE: In what components is 'transform' defined?

["Galt, Stuart A" <stuart.a.galt@boeing.com>]

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.  



--
Stuart Galt
SGML Resource Group
stuart.a.galt@boeing.com
(206) 544-3656