RE: [cgmo-webcgm] ISSUE: In what components is 'transform' defined?

[Lofton Henderson <lofton@rockynet.com>]

A few thoughts after reading the transforms/segments thread...

At 09:33 AM 1/18/2008 -0800, Galt, Stuart A wrote:
>[...]
>I think that the math behind the two approaches is identical and the
>differences are in how interfaces are defined.  SVG defines a 3x3 matrix 
>with the
>bottom row hard coded to 0,0,1.

Correct, they (SVG and CGM) are mathematically equivalent, but 
parameterized differently.  And the conceptual model is described 
differently, although leading to the same mathematics.

Correct me if I'm wrong, but SVG actually parameterizes 'transform' in SVG 
content with six numbers a,b,c,d,e,f.  The *effect* of transform is 
described in terms of homogenous coordinates (x,y,w) that enables all 
transforms, including translation, to be conceptually expressed as affine 
transformations and implemented with simple 3x3 matrix arithmetic.

The same is true of CGM, which parameterizes transform as a 2x2 matrix (4 
numbers) plus a 2x1 (the other two numbers) in CGM content.  The effect can 
and should be conceptually described using homogenous coordinates and 3x3 
matrices.

>[...snip...]
>Style property or APS attribute:
>In my mind a style property is one that has an equivalent graphic
>primitive while the APS attributes in general do not have an equivalent
>graphic primitive.

The way I think of it... A Style Property is a thingy for "transient 
changes to presentation style of graphical objects."  They are creatures of 
the DOM and XCF only.  Whereas most of them have some associated similar 
graphical attribute in the metafile, it is not universal.  Intensity and 
raster intensity are Style Properties that are unique to DOM and XCF.

So it is perfectly fine (IMO) to have 'transform' as a Style Property that 
can be applied via DOM or XCF to a metafile, without 'transform' also being 
defined as part of metafile content.

OTOH, if 'transform' appears in the metafile itself, then it is not a Style 
Property.  Style Properties do not occur in the metafile.  It would be an 
ApsAttr or something else.  ApsAttrs *always* are defined as part of the 
metafile content.  See 3.2.2 in WebCGM.  They are also accessible through DOM.

So ... back to our use cases.  If we want 'transform' only to appear in DOM 
and XCF, for the use case of transient transformation of the geometry just 
during the duration of the user's viewer session (e.g., step animation), 
then Style Properties suffice.  If this is the case, we should stay far 
away from segments -- IMO they are irrelevant overhead for this use 
case.  And such a design (segment-dependent)would preclude applying the 
transformations of a 2.1 DOM implementation to 1.0 and 2.0 metafiles, as 
has been discussed.

But if we want to support use cases that dictate that 'transform' should be 
carried within the metafile, then... it will have to be instanciated as 
either an ApsAttr, or we might pick up CGM segments and segment 
transform.  Such use cases might include:
1.) ability within the metafile itself to copy a single reference instance 
of an object to multiple viewable instances, in different places and sizes 
(like COPY SEGMENT);
2.) or include in the metafile multiple instances of the canonical 
definition of an object, each with its own transform to make it appear in 
different places and sizes ('transform' ApsAttr).
3.) Or being able to record in the CGM the state of a graphical editing 
session wherein the object tree has been saved with transforms attached to 
the nodes, as opposed to saving the tree post-transform-application to get 
a transform-less object tree.

I don't know if these use cases are important enough to impose on the 
vendors to implement segments. They certainly stray from our center-line 
use cases, which are things like step animation.  (Note that Segments were 
in ATA long ago, were also in the NIST test suite IIRC, and some vendors 
did implement them then.  But not all vendors, I would suspect.)

-Lofton.

p.s  Aside:  Note that APS are supposed to be application-oriented and 
entirely non-graphical in effect, according to CGM:1999.  I.e., a viewer 
that doesn't understand WebCGM is supposed to get the same static graphical 
picture if it ignores APS.  So a 'transform' ApsAttr violates that design 
intent.  But we already crossed that line long ago with other things like 
the 'visibility' ApsAttr.