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: Lofton Henderson <lofton@rockynet.com>
- To: "Bezaire, Benoit" <bbezaire@ptc.com>,"CGM Open WebCGM TC" <cgmo-webcgm@lists.oasis-open.org>
- Date: Tue, 06 May 2008 13:48:34 -0600
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]