AW: [cgmo-webcgm] Ideas about a Transform Interface

["Ulrich Laesche" <ulrich@ematek.de>]

Hi Benoit,

Our people referred to the possibility that a script writer moves
(rotates, scales, transforms) an object and does not take into account
side effects such as overlapping another object, which should stay
visible.

From my point of view, the only way to avoid this is to generate a
script or a CGM image from an application enabling the user to simulate
the transform effect, and to apply changes if the result doesn't meet
the expectations.
  
And that's the question, do we want to work towards a standard structure
that can be applied to applications, or do we want to quickly give a
tool to people trying to add budget animation to CGM images and taking
the risk of the outcome by themselves (trial and error).  May be we want
both (as different work items) and I should concentrate on the pure
transformation stuff.

In this respect, the second approach (DOM only), which I am in favour
off, would also allow to "animate" already existing WebCGM images if
they contain properly designed APSs.

Regards
Ulrich


-----Ursprüngliche Nachricht-----
Von: Bezaire, Benoit [mailto:bbezaire@ptc.com] 
Gesendet: Dienstag, 16. Oktober 2007 22:20
An: cgmo-webcgm@lists.oasis-open.org
Betreff: RE: [cgmo-webcgm] Ideas about a Transform Interface

Hi Ulrich,

One simple question for now if I may... I don't have a clear
understanding of the rectangle problem you and your team are talking
about. Could you try to explain it differently?

Many thanks,
Benoit. 

-----Original Message-----
From: Ulrich Laesche [mailto:ulrich@ematek.de] 
Sent: Tuesday, October 16, 2007 12:40 PM
To: cgmo-webcgm@lists.oasis-open.org
Subject: [cgmo-webcgm] Ideas about a Transform Interface

Hi All,

Attached you will find a statement from our dev team, summarizing their
opinion about what could be done regarding a transform interface. It is
not a concrete spec but provides ideas for discussion based on the last
phone conference. There is also a second statement by myself, trashing
all of this and suggesting a much simpler approach. First comes the
team's statement:

"We have read the according chapter from SVG, and it seems that it's
exactly what needs to be done for CGM regarding animation, probably in
some simplified version. SVG has all these transformations, moving,
rotation, scaling, also timing, and it works there already.

From our point of view, if we don't want to reinvent the wheel,
animation needs to be done using the existing SVG transform approach
with some adaptions. For example, in WebCGM, the objects (e.g., the APS
types 'para', 'subpara', 'groject') are used for navigation and picking
operations. We think the simplest is to add here more (transformation)
operations, like movement, rotation, scaling and so on. Viewers already
are supposed to do something with the APS (scale them to fit, or
highlight), so they would just need to implement more operations.
Currently, the exact viewer behavior is controlled be a set of "object
behavior keywords", associated with the link, and the presence or
absence of certain "APS attributes" on the object ('viewcontext',
'region', etc). (This is a phrase from the WebCGM documentation).

Looking at the table enumerating the object behaviors available in
WebCGM 2.0 (containing "full", "zoom", "move", "newHighlight",
"addHighlight", etc) we could add more keys here, such as "moveAPS",
"rotateAPS", "scaleAPS"...  Furthermore, we could extend the APS
attributes. There are already attributes with similar meanings, such as,
'visibility', 'interactivity', 'linkuri'...  So, we could add the
keyword 'animation', which means, that when its value is 'on', a viewer
has to apply the 'object behavior' keys to this APS (moveAPS,
rotateAPS...). Whether or not the animation actually occurs needs to be
defined via the WebCGM event model, which is triggered via API call or
some other actions (mouse movement, mouse click, initial loading...).

SVG uses a lot of different "transform" animations, we can just take
some of them:

transform(a,b,c,d,e,f) - which means mathematical transfromation with
matrix [a,b,c,d,e,f]
translate(x,y) - which means just move with offsets x,y
scale(x,y) - scale along the x,y
rotate(angle) - rotate
motion(path) - move the APS along the motion path, where path will have
several parameters, like "from" (initial position), "to" (end position),
"duration" (how quick), "counts" (number of intermediate positions), and
so on...

The described approach deals with WebCGM on an element level, i.e.
requires changes to the WebCGM document itself. Another approach would
be to just add some DOM API commands for animation, but from our point
of view, if the movement is not defined in the document itself, then the
externally triggered actions will not result in anything good. For
example, you have two rectangles one by another. Then you move one and
it will appear on top of another. Thus, the possibility of movement of
the rectangle, and the limits of such a movement, should be defined
inside the document. The API should just trigger this movement."

So far the team's statement, which leans to Benoit's preference of
keeping animation in the file. In the opposite, I would say that
completely relying on 4-5 external DOM API calls for transforms is OK.
There are two reasons. As a reply to the problem of overlapping
rectangles (see above), or of user defined change of the coordinate
system, I would say we are talking about budget animation. If somebody
wants to go this route it would only be fair to offload responsibility
regarding the results of budget animation to the script writer without
having to offer too much of protection. Secondly, we may very quickly
agree on the exact syntax of 4 or 5 additional DOM calls, such as
"Rotate(APSid, rotation angle)" or "Move(APSid, newx, newy)" (point of
reference could be center of APS etc), but it can be foreseen that
adding CGM transform elements will take some time for specification.

The negative impact of the pure DOM API based approach is that we won't
lay any foundation for future animation related work, but I am still in
favour of it in the scope of the 2.1 standard.

Looking forward to your replies
Ulrich