OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmo-webcgm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [cgmo-webcgm] COMMENTS: Chapter 5


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?


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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]