|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:||Bezaire, Benoit (bbez...@ptc.com)|
|Date:||Jan 25, 2008 6:29:42 am|
Sorry I missed the call.
I'm not exactly sure what this action item is... Here are some thoughts I'm not sure group members have talked about: - Does a transform affect the stroke? - Does a transform affect a pattern? - How does transform work with restricted text and append text?
From: Weidenbrueck, Dieter [mailto:dwei...@ptc.com] Sent: Thursday, January 24, 2008 9:27 PM To: Lofton Henderson; cgmo...@lists.oasis-open.org Subject: RE: [cgmo-webcgm] transform and Style Property inheritance 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.
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.
Visible links 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 3. http://www.w3.org/TR/SVG11/coords.html#TransformAttribute 4. http://www.w3.org/TR/SVG11/painting.html#StrokeProperties