|Lofton Henderson||Jan 24, 2008 6:11 pm|
|Weidenbrueck, Dieter||Jan 24, 2008 6:26 pm|
|Bezaire, Benoit||Jan 25, 2008 6:29 am|
|Lofton Henderson||Jan 25, 2008 7:02 am|
|Galt, Stuart A||Jan 25, 2008 7:19 am|
|Lofton Henderson||Jan 25, 2008 4:24 pm|
|Lofton Henderson||Jan 27, 2008 10:38 am|
|Weidenbrueck, Dieter||Jan 27, 2008 10:56 am|
|Lofton Henderson||Jan 27, 2008 3:30 pm|
|Bezaire, Benoit||Jan 28, 2008 7:42 am|
|Lofton Henderson||Jan 28, 2008 8:08 am|
|Bezaire, Benoit||Jan 28, 2008 8:16 am|
|Galt, Stuart A||Jan 28, 2008 9:22 am|
|Lofton Henderson||Jan 28, 2008 9:52 am|
|Weidenbrueck, Dieter||Jan 29, 2008 10:11 am|
|Subject:||RE: [cgmo-webcgm] transform and Style Property inheritance|
|From:||Lofton Henderson (lof...@rockynet.com)|
|Date:||Jan 28, 2008 8:08:52 am|
At 10:42 AM 1/28/2008 -0500, Bezaire, Benoit wrote:
SVG has the 'additive' attribute. Possible values are: 'replace' or 'sum'. See the example here: http://www.w3.org/TR/SVG11/animate.html#AnimateTransformElement
Is this what is meant?
Yes, sort of. The switch itself encapsulates the sense of what we mean by our proposed switch.
But that SVG switch is defined in terms of declarative animation, for SVG's 'animateTransform' element, so it applies at every one of the implementation's (viewer's) computations of the value of the (animated) transform. And we're not talking about declarative animation in WebCGM yet.
In WebCGM, we are talking about single changes to the value of the 'transform' SP on an object node, one per API call.
The defined effect of the switch is the same: replace or post-multiply.
I want to be careful that we don't confuse our one-per-API-call 'transform' SP setting -- which might be used in WebCGM with script-driven "step animation" -- with SVG's declarative-animation functionality. Excuse me if I'm beating it to death -- just want to be sure we don't introduce any confusion with the reference to the latter.
From: Lofton Henderson [mailto:lof...@rockynet.com] Sent: Sunday, January 27, 2008 6:31 PM To: Weidenbrueck, Dieter; cgmo...@lists.oasis-open.org Subject: RE: [cgmo-webcgm] transform and Style Property inheritance Dieter,
I think you have made a good case for the utility of the replace/combine switch on the 'tranform' method.
And we agree on what the switch means -- it determines how the transform parameter affects the final effective transform on the target node, only. (And of course the tree descendent from the target node then is recomputed after the target node changes.)
Does anyone disagree about the utility of the switch, or have a different understanding of the meaning of the switch?
At 01:56 PM 1/27/2008 -0500, Weidenbrueck, Dieter wrote:
[...] you are right, I probably misunderstood the intent as having an impact on composition with descendant/ancestor nodes.
replace: Ma'' = Ma' combine: Ma'' = Ma' * Ma We would need both to be able to reset an object or to set it to a specific transform. Other options: - all transforms are "replace": That would require the scriptwriter to maintain a list of all transforms that he has ever set in the file to be able to combine them with additional transforms outside of the CGM, and then supply the combined matrix to replace whatever is on the object
- all transforms are "combine": That would prohibit the scriptwriter from setting a specific transform, which may be an identity matrix to reset the object. Of course, he might compute the inverse of the current matrix on the outside, and then submit that inverse matrix, but that's quite complicated IMO.
So we should have a "replace" and a "combine" mode under control of an attribute of the DOM call.
From: Lofton Henderson [mailto:lof...@rockynet.com] Sent: Sonntag, 27. Januar 2008 13:39 To: Weidenbrueck, Dieter; cgmo...@lists.oasis-open.org Subject: RE: [cgmo-webcgm] transform and Style Property inheritance At 09:27 PM 1/24/2008 -0500, Weidenbrueck, Dieter wrote:
[...] excellent summary. IMO, we don't need a "switch" between replace/combine.
A "replace" would need a very precise wording to avoid ambiguities, for very rare use cases (if any). Example: Ma -- inside APS-A, but outside APS-B. Ma*Mb -- inside APS-B, but outside APS-C and APS-D. If Ma is a rotate and combine, and Mb is a translate and replace, how will the result look like?
I'm not sure that we're talking about the same thing. Here is what I had in mind:
Suppose Ma is the existing transform matrix on A, and suppose that a new matrix Ma' is passed through the transform method. If Ma'' is the effective resultant on A, then I was envisioning the switch would have this effect:
replace: Ma'' = Ma' combine: Ma'' = Ma' * Ma
Then Ma'' would behave in the object tree exactly as Ma had behaved before. All of the views within APS_A will have to be recomputed because the transform on A has changed, and it must be composed with the descendants of APS_A in the "normal" way. (The equations of my original mail, below.)
In essence, Mb will be applied to the content fo APS_B first, then Ma will be applied to the content of APS_A (including APS_B).
I'm not sure your meaning, but are you thinking that replace/combine would affect whether or not the new transform on APS_A composes with the transforms on descendant nodes?
I'm opposed to that -- complex without any useful case.
The replace/combine that I was talking about only affects how Ma'' is derived for the transform on APS_A, then everything else -- i.e., all views within APS_A -- get recomputed as usual:
Ma'' -- inside APS-A, but outside APS-B. Ma'' * Mb -- inside APS-B, but outside APS-C and APS-D Ma'' * Mb*Mc -- inside APS-C. Ma'' * Mb*Md -- inside APS-D.
So if Mb is a replace operation, what does it actually replace? Ma? or any other transform higher up in the hierarchy? That would rather be some kind of protected mode for the content of APS-B, where only Mb gets applied, and then thereafter nothing else. Now imagine the rotate of Ma happens. Would that mean that the content of APS-B will stay unrotated in its previous position? This will lead to weird results I think.
I wasn't thinking of anything like that, and would be really against it. I was trying to summarize a capability that I thought I heard in the telecon. Someone correct me if I misunderstood what the replace/combine idea was about.
From my impression, the only thing that replace/combine would affect is how the resultant transform on the specific target node is computed. Then, having changed that transform, the view of the whole tree is updated/recomputed by the usual rules.
So, long story short, the combination of matrices is the one and only way to go IMO.
Certainly for computation of the effective transform on all descendant nodes down a tree, given the effective value of the transform on a given node.
From the telecon minutes:
[[[ Action Item for Forrest to research how this style property would be inherited down through the tree. ]]]
I want to make a contribution to Forrest's action item. It is still needed to look at all of the stuff about Style Properties in 5.4 and 5.7.5, to make sure we're not missing something, and explain 'transform' properly:
But I was looking and thinking, for example at a couple of items in SVG. Compare 'transform' attribute and 'stroke' property:
Notice that the inheritance model is dealt with on 'stroke', but is nowhere to be seen on 'transform'. We shouldn't get hung up on the attribute versus property naming thing here -- those are just handles. But looking at our previous emails, and the SVG sections preceding , it is clear now transforms should behave.
Whatever you call it, 'transform' does not inherit in the conventional sense of WebCGM 5.4 . E.g., give an object tree where A contains B, which contains C and D:
APS-A ....APS-B ........APS-C ........APS-D ,
then it is a reasonable concept that placing 'red' on A potentially supersedes and redefines the color on B and C&D to red.
But this is not how we think of transforms. Placing a transform on node A transforms all of the geometry within A, including the contents of B, C, and D. But it doesn't supersede any transform that might be on B, C, and D. It combines with them as we discussed and agreed in earlier emails -- you post-multiply the matrix representations so that the various contents in the tree are transformed as follows:
Ma -- inside APS-A, but outside APS-B. Ma*Mb -- inside APS-B, but outside APS-C and APS-D. Ma*Mb*Mc -- inside APS-C. Ma*Mb*Md -- inside APS-D.
So the static-tree concepts of inheritance that are described in  and in the "Common specifications" of  do not apply to 'transform', no matter what we call it. We may have to add new subsections to  and new stuff to , to make it clear how this new 'transform' Style Property behaves.
Furthermore, IMO, we definitely do NOT want any sort of controls on how a 'transform' SP on a node in the tree composes with ancestors or descendants -- i.e., there is no sensible or useful analogy to 'inherit' or 'no-inherit'. Transforms in a static object tree behave and combine in one simple way.
That said, we might well want a control on whether a DOM method that sets a transform on a node in the object tree does it in 'replacement' mode or 'combine' mode. But once that method has been executed, then there is some well-defined transform on that node, and it combines with its ancestors and descendants according to the usual rules.
I'm not close enough to the applications to say whether or not we want such a replacement/combine control on the method.