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

[Lofton Henderson <lofton@rockynet.com>]

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.