Re: [cgmo-webcgm] resolutions about geometric transform

[Lofton Henderson <lofton@rockynet.com>]

Hi all,

Hearing no comments to the contrary, can we assume that the SUMMARY of
geometric transform resolutions is acceptable to all?

Ulrich, when do you expect to have a first draft of the bits for sec.5.7
(the interface(s)), and ch.4 (the XCF)?

Regards,
-Lofton.

At 09:56 AM 2/20/2008 -0700, Lofton Henderson wrote:
> All -- 
>
> Here is my summary of how the technical issues about geometric transform
> have been resolved.  See "SOURCES" below for more
> references supporting this summary.
>
> Please comment immediately if you think any of this is inaccurate, or if
> any critical details are omitted.
>
> SUMMARY:
>
> 1.) available via:  method on DOM interface(s), plus XCF;
>
> 2.) They replace the *specified* transform associated with the target
> object (which defaults to Identity);
>
> 3.) When a transform is set or specified on a target node, it composes
> with transforms on ancestor nodes in the object tree like SVG [3], and
> this composition results in the effective CTM on the node that is
> targeted by the transform-setting method (or XCF);
>
> 4.) When a transform is set or specified on a target node, it composes
> with transforms on descendent nodes in the object tree like SVG [3], and
> this composition updates the effective CTM on those nodes;
>
> [3]
> http://www.w3.org/TR/SVG11/coords.html#NestedTransformations
>
> 5.) we would like them to be parameterized both as a single matrix (six
> numbers needed [2]), or as convenience components (scale, rotate,
> translate, ...)
>
> 6.) we agree that they should have an associated parameter, with values
> 'replace' or 'combine' (or some such values) that control whether the
> method replaces the current modally defined transform on the target node,
> or combines with it.  (In either case, then CTMs are recomputed as
> per #3 and #4 -- the effect of the parameter concerns the modally-defined
> *specified* value of the transform for the node, not the CTM)
>
> 7.) We call them Style Properties, but they don't 'inherit' like the
> model of 5.4;  they compose/combine as per #3 and #4.
>
> 8.) Accordingly, per today's telecon, for simplicity and clarity we
> should put them in methods of their own, setTransformSP() and
> getTransformSP().
>
> 9.)  The methods would be defined on the ????? interface?  The
> current Style Property methods are on the Picture and APS
> interfaces.  ("Picture" has been questioned for the new
> geometric transform SP.)
>
> 10.) CGM:1999 (hence WebCGM) contains controls that determine how
> transforms affect line width, patterns, etc.  Nothing more need be
> specified for the new 'transform' SP.
>
> SOURCES:  The thread [0] contains some precise detail, about exactly
> what is meant by composition of transforms up and down the object tree,
> how replace/combine works, etc.  There is also information in thread
> [1] about the mathematics, where 'transform' is defined, etc.
>
> [0]
> http://lists.oasis-open.org/archives/cgmo-webcgm/200801/msg00078.html
> [1]
> http://lists.oasis-open.org/archives/cgmo-webcgm/200801/msg00001.html
> [2]
> http://www.w3.org/TR/SVG11/coords.html#TransformAttribute
>
> Regards,
> -Lofton.