OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmo-webcgm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


At 08:33 AM 1/3/2008 -0800, Cruikshank, David W wrote:
I agree that when transforms are stored in the XCF the result of all the transforms occur on the load and apply step.  The concern was that someone might think they can store a series of transforms in the XCF that would result in an animation sequence. 

Without any timing facilities, that would not be possible in any standardized way.  Multiple transforms applying to a single APS would, at load-and-apply, resolve to a single transform (either composed or replacement, depending on how we're defining it), that would then be applied for the display.

Without id's on each transform, there is no way to trigger or control that animation sequence.  This functionality would be limited to the DOM interface, in my mind.

Without timing information, there would be no "sequence".  There is only a single resolved resultant transform.

So yes, animation could only be done through the DOM, using scripting and its timing capabilities.  It can't be recorded in XCF.

When defining XCF, we said it does not preserve or reflect metafile structure.  Similarly, it obviously doesn't preserve or record time-dependent script sequences.

-Lofton.

 


From: Lofton Henderson [mailto:lofton@rockynet.com]
Sent: Wednesday, January 02, 2008 4:48 PM
To: Weidenbrueck, Dieter; cgmo-webcgm@lists.oasis-open.org
Subject: RE: [cgmo-webcgm] ISSUE: In what components is 'transform' defined?

Dieter, All --

I'm trying to catch up on the status of this one.  Dieter said (below) that we need XCF as well as DOM, and gave some criteria for deciding whether APS Attr as well.

The last telecon, which I had to leave early, said this:
[[[
Geometric transforms
See ISSUE tread http://lists.oasis-open.org/archives/cgmowebcgm/
200712/msg00054.html
Lofton proposes options
If it is a style property in the XCF or an APS attribute in the CGM file, the
question of how the transform is triggered was raised, unless we limit it to a
single transform on an APS and it is triggered during the load and apply step.
There is also a potential problem in the XCF if a style property is attached to the
bindByName structure, since applying a transform to a group of APS objects may
not make sense. It might be easier to implement this if it is only addressed as a
style property in the WebCGMAppStructure DOM interface and not in the XCF.
As a result, only advanced script writers would probably use this function, unless
authoring tools would generate scripting code to support the various
transformations. Dave will follow up on the thread with some thoughts.

]]]

I missed the discussion and don't quite understand the above.  What does the first sentence mean?  If it is an APS attribute, I would think the answer is straightforward:  in the static tree structure of the metafile, there is a well defined transform (possibly identity) for every APS, once we have defined the model for composition of transforms.  So each APS is displayed with its (composite) transform.  With XCF, it would seem that the same situation pertains after load-and-apply -- every APS has a well defined transform, they compose, and the display after load-and-apply reflects it. 

Perhaps I'm missing some subtleties?  It seems to me that its implementation difficulty in DOM and XCF should be comparable, if XCF rules are clearly defined and that definition reflects the DOM meaning.  (E.g., the effect of XCF load-and-apply would be more or less identical to a DOM sequence of:  suspendRedraw ... bunch of DOM xform method calls ... resumeRedraw.)

Any case, I need some clarification as I don't quite grasp all of the telecon discussion notes.

Dieter below -- supporting DOM and XCF forms at least -- poses the right question about the intra-metafile ApsAttr form:  do we need it or not?  (As I said once, I can think of cute use cases for it, but do they actually correspond with solving useful technical problems for our constituents?)

-Lofton.

At 03:03 AM 12/18/2007 -0500, Weidenbrueck, Dieter wrote:
[...]
(1) is definitely needed.
 
We should consider whether transform is a r/o, a w/o, or a r/w attribute. If there is any need for reading, an APS attribute would be the best way to go. This would add (2) as well. If we don't need to read the current transform of an object, we would not need it.
 
Regards,
Dieter


From: Lofton Henderson [mailto:lofton@rockynet.com]
Sent: Montag, 17. Dezember 2007 19:33
To: cgmo-webcgm@lists.oasis-open.org
Subject: [cgmo-webcgm] ISSUE: In what components is 'transform' defined?

[Just to be sure this loose end about 'transform' is not lost...]

ISSUE:  In which of the three components -- DOM, XCF, metafile instances -- is the APS 'transform' functionality defined?

DISCUSSION:  Previous issue discussion has settled that there will be DOM method(s) for 'transform', and has resolved many of the details.  There has been no decision (or discussion) yet about whether it will also be available through XCF, or even as a new APS Attribute in the metafile itself. 

OPTIONS:
(1)  'transform' is defined in XCF (as well as DOM);
(2)  'transform' is defined as a new APS Attribute (as well as DOM);
(3) both #1 and #2
(4) neither #1 nor #2

RECOMMENDATION:  #3. 
(Note:  I don't have particular reason for this choice, but rather I'm just making some choice to stimulate discussion.)

Regards,
-Lofton.

At 12:45 PM 12/13/2007 -0700, Lofton Henderson wrote:
At 08:38 AM 12/13/2007 -0500, Weidenbrueck, Dieter wrote:
All,
 
we agreed to use a Y-up coordinate system in mm in the viewer, i.e. any dimension for a viewport etc will be described this way.
Hence we should to the same here.

Yes, NVDC is Y up.  I was not thinking about it before -- what are the units of coordinate-related bits in the transform?  The transform_draft3 document does not say.  For a DOM interface, it should be NVDC.  If it also appears in XCF, also NVDC.  Which reminds me...

I asked the question before, and I don't think we have answered it.  Where does 'transform' appear?

1.) DOM method (yes, as in transform_draft3)

2.) XCF? (open question)
3.) New APS Attribute in the metafile instance? (open question)

I don't yet have an opinion on #2 and #3.  I can think of use cases for both.  For example for #3, it would allow you to put into the metafile a canonical definition of the object, and include in its header an APS Attribute that sizes it, positions it, and orients it.

If #2 is "yes", then units should be NVDC.  If #3 is "yes", then its units need to be VDC, I think.  (Similar to how we have other things like Style Properties that are NVDC in DOM/XCF, but correspond to VDC things in the metafile instance.)

Thoughts?

-Lofton.

P.S.  There is no restriction in WebCGM 1.0 or WebCGM 2.0 on what is the VDC coordinate system in the metafile instance.  It can be Y-up or Y-down.



From: Bezaire, Benoit [mailto:bbezaire@ptc.com]
Sent: Donnerstag, 13. Dezember 2007 08:35
To: cgmo-webcgm@lists.oasis-open.org
Subject: RE: [cgmo-webcgm] WG: transform proposal 2

Hi Lofton,
 
I agree with you and what you wrote below should be put into the WebCGM 2.1 specification (transform interface).
 
How frequently are Y+ down used? How much work is it to get this transform interface going for Y+ up and down?
 
Benoit.


From: Lofton Henderson [mailto:lofton@rockynet.com]
Sent: Friday, November 30, 2007 5:49 PM
To: Bezaire, Benoit; cgmo-webcgm@lists.oasis-open.org
Subject: RE: [cgmo-webcgm] WG: transform proposal 2

Catching up on some past technical dialogs...

At 09:59 AM 11/7/2007 -0500, Bezaire, Benoit wrote:
[...]
6) ok, this should be added to the proposal. BTW, is WebCGM "always" Y up?

Here we should follow CGM:1999 itself.  By default, +Y is up.  But one can reverse this by appropriate specification of the VDC EXTENT element in the Picture Descriptor of the metafile instance.

I disagree that positive angles should be clockwise.  CGM:1999 specifies the positive angular direction precisely.  By default (if +Y is up), positive angles are counter-clockwise.  If +Y is down, then the reverse.

It is all properly, mathematically specified.  I.e., it is like the "normal" right-handed Cartesian coordinate system you learned about in school.  (Unlike the raster-screen addressing systems that one sees elsewhere in graphics, where +Y is down.)

WebCGM transformations should follow the CGM:1999 conventions, unless someone can demonstrate a compelling reason to deviate.  Deviation will cause headaches, because then the sense of object transformations will be different than (for example) the sense of text-transform matrices that implementations construct from text attributes (the ORIENTATION vectors, etc).

-Lofton.

7) ok, this should be added to the proposal. It should also be mapped to 3x3 matrices.
 
Yes, the group needs to have a discussion about where these API should be: picture level or APS level?
 
Regards,
Benoit.


From: Ulrich Laesche [mailto:ulrich@ematek.de]
Sent: Wednesday, November 07, 2007 8:16 AM
To: cgmo-webcgm@lists.oasis-open.org
Subject: [cgmo-webcgm] WG: transform proposal 2

Dear All,

 

As a reply to Benoit’s two mails (Thanks for that, Benoit) attached please find the response from our develoment team as well as an updated transform spec.

 

Regards

Ulrich

 

1. Yes, we replaced move by translate”. Also, we replaced the absolute coordinates for the new location by distances. This means we just move relatively to the old position. That's how it's done in SVG.

2.
We would like to use the additive transformation. Only in this way we can do some complex transformations using a chain of the simple transformations, like scale down by 1/2, move to the right by 3 and up by 5, and rotate clockwise by 35 degrees. If it would be replace then we would not be able to do these transformations, as we should start always from the beginning.

May be we should add a new API function, like finishTransformation(). For example, if we want to show only the final position, and not the intermediate:
scale(1/2,1/2)
translate(3,5)
rotate(35)
finishTransform()

3. Rotate - yes, we introduced the origin for convenience, see spec. However, we could always rotate around the center and then move (see 2).

4. Scale - no, we don't need the origin point. If the element has the w,h=4,6 and we scale 1/2, then the new size would be w1,h1=2,3 and the same origin. Then you can translate to the new position using translate API.

5. Yes, Transform was an attempt to do a motion along the path, but it appears to be more complicated and does not fit the budget approach, so we drop it for now.

6.Rotation is clockwise, if angle > 0, and counterclockwise if < 0.

7.Yes, the scale can be > 0, then it's zoom-in,  and < 0, then it's zoom-out.

 
-----Ursprüngliche Nachricht-----
Von: Bezaire, Benoit [mailto:bbezaire@ptc.com]
Gesendet: Mittwoch, 24. Oktober 2007 21:19
An: CGM Open WebCGM TC
Betreff: [cgmo-webcgm] Feedback on transform proposal (was RE:
[cgmo-webcgm] Telecon REMINDER - agenda)

Hello,

Here is more feedback on the transform proposal...

About the move() API... why is this not a translate() API? Is there a
specific reason? I ask because a translate can be expressed in a 3x3
matrix, a move can't.

About the scale() API... can x/y be negative? i.e., mirror or do we
stick with > 0? (note a center point is also needed here, same as
rotation question)

About the transform() API... I'm not sure I understand. We see
parameters a..f similar to a 3x3 matrix, but the description talks about
a motion path? Are we attempting to do a general matrix transform, or is
the intent to do a motion along a path? We talked about both, that's why
I'm asking.

Kind regards,
Benoit.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]