RE: [cgmo-webcgm] COMMENTS: Chapter 5

[Lofton Henderson <lofton@rockynet.com>]

At 07:59 PM 5/6/2008 -0400, Bezaire, Benoit wrote:
> Let's
> take the A, B, C example you have. If you set a 90 degree rotation on B,
> I would say that C "inherits" a 90 rotation. Mainly because if
> I want to render the content of B and C correct, all that geometry
> (including C) needs to be rotated.
>  
> So for me, combine or replace
> affect how the 'computed' value is calculate.
>  
> Alternatively, another way of
> looking at it. What the return value for the following calls (assuming a
> 90 deg rotation on B):
> i)
> C.getTransformSP("specified");
> ii)
> C.getTransformSP("ctm");
>  
> BTW, getTransformSP needs
> clarification, but I would think:
> i) empty string
> ii) [values for a 90 degree
> matrix]
>  
> So C 'kinda' inherits the
> transform, no?

Yeah, "kinda".  I kinda' can see your point. 

While it is an unconventional way -- compared to most graphics standards
and texts -- to describe transforms, on the other hand it might be
useful.  I want to think about it a bit more.  In particular,
see if we can describe it precisely in terms of the
Specified/Computed/Actual/... model.

Maybe for example, we could present the SP/CSS2 description model of
geometric transform as an informative alternative to the more traditional
sort of description (normative).  That would allow, for example, to
get rid of the 'red' stuff and the apologetic "this doesn't inherit
and behave like other SPs".

If that doesn't work out...

Alternatively, maybe we should put some distance between the
"Geometric Transform attribute" on the one hand, and
"Style Properties" and "APS Attributes" on the
other.  I.e., don't worry about trying to squeeze it into some
category or another.

Bottom line.  We don't have any substantive issue here about how the
functionality works.  Just about how we describe it.  Correct?

Cheers,
-Lofton.

---

From: Lofton Henderson [mailto:lofton@rockynet.com]
Sent: Tuesday, May 06, 2008 3:49 PM
To: Bezaire, Benoit; CGM Open WebCGM TC
Subject: Re: [cgmo-webcgm] COMMENTS: Chapter 5

Hi Ben,

Again, thanks for your review comments.  Looking at another of them...

At 11:30 AM 5/6/2008 -0400, Bezaire, Benoit wrote:

5.4.4.2: Not sure if we should give the 'red' example? It raises questions about specified, computed and actual values.

Okay.  Can you suggest a different example -- StyleProp or ApsAttr -- that illustrates the difference between these graphical attribute thingies and transform? 

Or should we change the wording to qualify it somehow?

Aren't the inheritance rules the same for transforms than other style properties (with the exception of 'replace' and 'combine'). 

I'm not sure I understand your point here.  In fact, I suspect we have some little disconnect.  But here goes...

The CD describes a 2-step process to determine the CTM on each node.  The starting point (default) is that the transform on every node is Identity.

1.) a transform is set on a node by a DOM call.  'replace' or 'combine' apply to the action of setting a transform on the node. 
2.) once the outcome of the setting action for each node is determined, *then* the CTM for each node in affected parts of the tree is computed (5.4.4.2) by combining it with the transforms of the ancestor nodes.

Example, A contains B contains C:
A
...B
......C

If I set a 90 degree rotation on B, then the CTMs are:  A: Identity; B: 90 rot; C: 90 rot.  The CTM applies to everything within the object (including hierarchically nested objects), right?  Because the contents of C are within B, then they are rotated 90.

Conceptually, I would not say that C "inherits" a 90 rotation.  That would tempt me to compute a 180 rot for the CTM on C.

Again, suppose then that set a 45 rotation on C.  Then the CTMs are:  A:Identity; B:90 rot; C:135 rot.

I have trouble reconciling the SP inheritance model, as described, with how transforms actually behave.  It's just a conceptual disconnect for me.

Btw, we patterned after SVG in some respects, especially the CTM description: 
http://www.w3.org/TR/SVG11/coords.html#TransformAttribute

They call it an attribute, but that is purely in the sense of "XML attribute", I believe. 

I questioned before -- in an earlier draft with an in-line editors note (to which no one commented) -- that perhaps the transform stuff ought to be moved out of 5.4 into a subsection of its own.  And/Or maybe we shouldn't call it a Style Property? 

While it is like SP in being DOM/XCF settable, and having transient visual effect, on the other hand it behaves fairly differently.  At least that's how I see it conceptually.  And the SP association is not useful when it comes to actual behavior (IMO).  (If we stop calling it a SP, then we don't really need the 'red' example at all, do we?)

What do you think?

-Lofton.