cgmo-webcgm message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [cgmo-webcgm] COMMENTS: Chapter 5
- From: "Bezaire, Benoit" <bbezaire@ptc.com>
- To: "CGM Open WebCGM TC" <cgmo-webcgm@lists.oasis-open.org>
- Date: Tue, 6 May 2008 19:59:55 -0400
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?
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]