RE: [cgmo-webcgm] WG: transform proposal 2

["Bezaire, Benoit" <bbezaire@ptc.com>]

Hi,

 

Thanks Ulrich for the updated proposal.

 

1) ok.

2) ok, although more specific information would be needed for finishTransform().

3) I think we need the origin, or else the sample I sent a while back doesn't work.

4) Here I disagree. Every transform needs to be mapped to 3x3 matrices. So far the translate and the rotate are, but not the scaling. If we want the API to be scale( sx, sy ) with respect to the center point, then the proposal needs to map this to 3x3 matrices.

 

This is the typical 2D scaling matrix:

[sx 0  0

 0  sy 0

 0  0  1]

 

If all the points of a given grobject are transformed by that scaling matrix, the result is different than what is describe in the latest proposal.

 

5) ok.

6) ok, this should be added to the proposal. BTW, is WebCGM "always" Y up?

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.