More Re: [cgmo-webcgm] transformations in SVG

[Lofton Henderson <lofton@rockynet.com>]

[... I wrote this yesterday but didn't send it.  I see there's lots of 
discussion today about transform.  This might contain some useful 
background stuff.  Probably familiar to most, but maybe not...]

Benoit, All --

As I thought about Benoit's comment yesterday, I was unsure exactly what he 
was asking for, about "precise mathematical description".  But it seems to 
me at least that it needs to start with fundamentals:  e.g., what is the 
mathematical matrix equivalent of rotate(72); and how do individual 
transformations attached to nodes in an object tree compose to give the 
effective transformation everywhere in the tree?

Maybe I'm aiming too low and being too trivial.  But taking off from a 
comment in my previous message...

At 03:39 PM 1/17/2008 -0700, Lofton Henderson wrote:
>[...mistakenly sent to the WG list on first try...]
>
>Yesterday we were talking about where transform would appear:
>-- DOM
>-- XCF
>-- ApsAttr in metafile
>
>Secondary but obviously related question was whether it would be:
>-- Style Property
>-- ApsAttr
>
>Benoit suggested that we needed to start nailing down the technical 
>mathematical details before we could ask and answer questions like, "What 
>is the effect of successive bind-by-id elements carrying 'transform'?"
>
>I volunteered to supply a link to the SVG chapter that deals with a lot of 
>this stuff, as a resource and reference for our own use.  Here is the 
>chapter [1]:
>
>[1] http://www.w3.org/TR/SVG11/coords.html
>
>It's worth a read.
>
>Caveat:  IMO, there is lots in here that is irrelevant to WebCGM, and I'm 
>not sure that I like the model of presenting and explaining transformation.

What I mean here is this:  a given transformation can be viewed as 
transforming a point p (coordinate pair) in user space to a p' (transformed 
coordinate pair) in the same user space.   Alternately, the transform can 
be viewed as a change in coordinate system.  SVG chapter 7 (see 7.4 and 
7.5) explains transform in the latter way, and appropriately (IMO) given 
the complexity and the potential inclusion into an SVG document of content 
from multiple different coordinate spaces.

In fact, the two views are mathematically equivalent.  See for example 
Foley & Van Dam Second Edition, section 5.8, for a lucid and precise 
explanation.  I sense that we have been leaning towards the simpler 
"transform the object in the single coordinate space" viewpoint.

In any case then, the material in SVG 7.4 is useful:  the homogeneous 3x3 
matrix illustrations of the matrices corresponding to the primitive 
operations (translate, scale, ...) can be adopted directly.

(However, the representation of a matrix in the DOM/XCF/ApsAttr content 
would only need and use 6 numbers, of course).

The discussion of nesting (7.5) can also be used.  If you look at the 
"Example Nested", and mentally change the <g> to APS, then the composite 
transformation matrix (CTM) that is listed at the end is the correct matrix 
for the points in the innermost APS, were this example translated to WebCGM.

In my view, our first order of technical specification is just this:
1.) to define what the transformations look like as matrices;
2.) and to define how they combine or compose in a hierarchy of objects;

I think both of these are done for us, in 7.4 and 7.5.  I.e., if we have a 
static WebCGM object hierarchy, APS-A contains APS-B contains APS-C, and if 
each has a specific resolved 3x3 homogenous transformation matrix attached, 
Ma, Mb, Mc, then the effective transformations are as follows:

-- for the points within APS-C:  the composite transformation is the matrix 
product Ma*Mb*Mc.  I.e., the transformed points p' are defined by:
p' = Ma*Mb*Mc*p, where p is the 3x1 homogenous representation (x,y,1).

-- for points within APS-B but outside of APS-C:  Ma*Mb is the composite 
effective transformation, and
p' = Ma*Mb*p

-- for points within APS-A but outside of APS-B:  Ma is the composite 
effective transformation, and
p' = Ma*p

So these details would just establish our vocabulary, how we talk about the 
effect.  They start from the point of "a static WebCGM object 
hierarchy".  That latter is the result of a sequence of DOM transactions, 
or XCF applications, or ...

Our real job then is this:  to start with conceptual descriptions of the 
functionality we want available via DOM, via XCF, etc.  Things like:

-- compose versus replacement mode for specification of a transform;
-- the effect of a (time) sequence of changes to the transform on a single 
node via DOM, in compose mode (and in replace mode);
-- the effect of processing an XCF with transformations (i.e., resolve it 
all to one static tree state, then display);
-- the effect of a series of consecutive XCF 'transform' elements (or style 
properties) similarly aimed at the same node (whether rot(80) then 
tran(.2,.3)  or M1 then M2);
-- the effect of a series of bind-by-id 'transform' elements;

Benoit, is this in the right direction.  Or did I miss your point yesterday?

-Lofton.

>But there is also useful stuff, like the matrix equivalents of the 
>primitive transform operations (translate, rotate, scale, see 7.5), use 
>and manipulation of the normalized form (3x3 matrices instead of 2x3), etc.
>
>Observation:  What we do for transform, if 2.1 is going to become a W3C 
>REC, will need to be compatible with SVG in our usual sense:  we can map 
>WebCGM into SVG (at least).  For example, in the object tree, nested 
>objects which each carry an individual transform better combine into a 
>composite transform in the same way as nested <g> in SVG.  Right?
>
>More later,
>-Lofton.
>
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  You may a link to this group and all your TCs in OASIS
>at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php