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

["Weidenbrueck, Dieter" <dweidenbrueck@ptc.com>]

Stuart,

interesting idea about segments, however, that would require to turn
every addressable object into a segment. So there is a significant
overhead just for the purpose of somebody eventually applying a
transform.

It would also mean that transforms could not be applied to WebCGM 1.0 or
2.0 (and hence ATA and S1000D) files, which is not really acceptable.

The math is clear, and we already know that we need 3x3 matrices (to be
able to include shearing). That should make our discussion an easy one,
I guess. This is what SVG does, this is what PostScript does.

Regards,
Dieter

-----Original Message-----
From: Galt, Stuart A [mailto:stuart.a.galt@boeing.com] 
Sent: Freitag, 18. Januar 2008 18:34
To: Weidenbrueck, Dieter; Cruikshank, David W; Lofton Henderson;
cgmo-webcgm@lists.oasis-open.org
Subject: RE: [cgmo-webcgm] ISSUE: In what components is 'transform'
defined?

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