cgmo-webcgm message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [cgmo-webcgm] transform and Style Property inheritance
- From: "Weidenbrueck, Dieter" <dweidenbrueck@ptc.com>
- To: "Lofton Henderson" <lofton@rockynet.com>,<cgmo-webcgm@lists.oasis-open.org>
- Date: Thu, 24 Jan 2008 21:27:10 -0500
Lofton,
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?
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).
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.
So,
long story short, the combination of matrices is the one and only way to go
IMO.
Regards,
Dieter
All --
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:
[1]
http://www.w3.org/TR/2007/REC-webcgm20-20070130/WebCGM20-DOM.html#L2666
[2]
http://www.w3.org/TR/2007/REC-webcgm20-20070130/WebCGM20-DOM.html#L5070
But
I was looking and thinking, for example at a couple of items in SVG.
Compare 'transform' attribute and 'stroke' property:
[3] http://www.w3.org/TR/SVG11/coords.html#TransformAttribute
[4]
http://www.w3.org/TR/SVG11/painting.html#StrokeProperties
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 [3], it is clear now transforms
should behave.
Whatever you call it, 'transform' does not inherit in the
conventional sense of WebCGM 5.4 [1]. 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 [1] and in the "Common specifications" of [2]
do not apply to 'transform', no matter what we call it. We may have to add
new subsections to [1] and new stuff to [2], 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.
-Lofton.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]