RE: [cgmo-webcgm] transform and Style Property inheritance

[Lofton Henderson <lofton@rockynet.com>]

Stuart,  

Good job on researching the details.  

I agree with your recommendation -- the CGM:1999 standard addresses how
these things behave under transformations (segment, copy, VDC-to-device,
etc), and we should pattern the new 'transform' SP after those
prescriptions.  I.e., we should say for example that the behavior of
these things under a 'transform' Style Property is the same as if they
were in a segment with segment transform.

I was wrong when I guessed that the "<xxx>...Specification
Mode" elements were excluded from the WebCGM profile.  I
checked the PPF, and they are indeed allowed, with no restrictions on
values.

Regards,
-Lofton.

At 07:19 AM 1/25/2008 -0800, Galt, Stuart A wrote:

From the spec:
6.6.2.1 Transformation of line elements

If the LINE WIDTH SPECIFICATION MODE has the value absolute', then all line aspects line width, line cap, line join, line dash and gap lengths are subject to the VDC-to-Device mapping (see 6.4.7) as well as to both segment and copy transformation (see 6.10.4.2 and 6.10.5). Note that the entire locus of an arc is subject to these transformations. In the case of an anisotropic mapping or transformation, the rendered width of the line will change with the direction of the line segment.

If the line width is specified in mode scaled', fractional', or mm', it is not affected by any transformations.

...

6.6.3.5 Transformation of text elements

The vectors specified by the CHARACTER ORIENTATION element (see 6.7.3.2) are subject to the VDC-to-Device mapping (see 6.4.7) as well as to both segment and copy transformation (see 6.10.4.2 and 6.10.5).

...

6.6.4.7 Transformation

The entire mathematical locus of rectangles, circular and elliptical filled-area elements is subject to the VDC-to-Device mapping (see 6.4.7), segment transformations (see 6.10.4.2) and copy transformations (see 6.10.5). Because anisotropic transformation does not preserve angles between non-parallel lines, rectangles may become parallelograms and circles may become ellipses.

If the INTERIOR STYLE SPECIFICATION MODE is absolute', the geometric aspects of fill interiors are subject to all transformations. These aspects include PATTERN SIZE; direction, spacing, and width of hatch lines; and reference geometry of interpolated interior. If the mode is scaled', fractional', or mm', then none of these aspects is subject to transformation.

Geometric aspects of edges are treated in exactly the same way as the corresponding aspects of lines.

 

It looks like if specification modes are absolute then they are affected by the transform but if it is set to other modes it appears to not be affected.  I would suggest that our transforms behave the same way.

--
Stuart Galt
SGML Resource Group
stuart.a.galt@boeing.com
(206) 544-3656

 

---

From: Lofton Henderson [mailto:lofton@rockynet.com]

Sent: Friday, January 25, 2008 7:03 AM

To: Bezaire, Benoit; cgmo-webcgm@lists.oasis-open.org

Subject: RE: [cgmo-webcgm] transform and Style Property inheritance

At 09:29 AM 1/25/2008 -0500, Bezaire, Benoit wrote:

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?

I don't have time to look now, but CGM:1999 has ways to control some of these -- e.g., whether strokes are calligraphic or not.  I suspect that these "<xxx>...Specification Mode" elements are not allowed in WebCGM, and are set to some default state.  Most likely "not calligraphic".  That means that the defining geometry is transformed, and then the stroke is generated.

I'm not sure what you mean about RT and AT.  Are you thinking of the case that someone puts a sub-string APS on an AT, and then attaches a transform to it alone?   Otherwise ... CGM:1999 itself has rules for what sorts of text attributes can change between RT and AT, and I assume we would mimic these restrictions if 'transform' opens up new possibilities/

-Lofton.

---

From: Weidenbrueck, Dieter [mailto:dweidenbrueck@ptc.com]

Sent: Thursday, January 24, 2008 9:27 PM

To: Lofton Henderson; cgmo-webcgm@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.

 

Regards,

Dieter

 

---

From: Lofton Henderson [mailto:lofton@rockynet.com]

Sent: Donnerstag, 24. Januar 2008 21:12

To: cgmo-webcgm@lists.oasis-open.org

Subject: [cgmo-webcgm] transform and Style Property inheritance

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.