[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cgmo-webcgm] Straw horse application structures
Hi Stuart, I'm not sure what to say about your email. It is closer to what we have implemented than anything suggested so far, which makes me happy. A couple of comments: - I still think we don't have clear enough requirements. We've made progress on the 'flow' requirements with the line style and start offset, which is good. But we haven't gone into the specifics of the 'transforms' requirement. I think we should focus on that. - I'm not sure I like the idea of animation in the XCF. Yes, we do it ourselves, but it was the only way we could remain compliant with the specification. Having the animation in the XCF has advantages (ex: CGM remains 'static' graphics only), but there are also disadvantages (ex: users can mess up the animation with a text/xml editor). We should be careful here. - Would transforms be additive or not?; assuming we come up with requirements for this. See problem below: (simplified markup) APS 'myAps' // geometry is here APS 'aSequence' APS 'aStep' APS translate 50, 100 EndAPS EndAPS APS 'aSecondStep' APS rotate 50, 100, 45 EndAPS EndAPS EndAPS EndAPS // in js script (approx code) var aps = picture.getAppStructureById("myAps"); aps.firstStep(); // this should apply the translate the first translate aps.nextStep(); // this should apply the second step (the rotation) Where does the rotation take place? at the new position after the translate or at the old position before the translate? It would be important to know because the rotation center point needs to be exact! For the DOM interface, I would build on what you suggested and re-word it as follows: option 1: use list concept APS.GetSequences... returns a list of Sequences Sequences.GetSteps... returns a list of Steps Step.apply()... applies the current Step option 2: use first/next concept APS.GetFirstSequence... returns a Sequence Sequence.GetNext()... return the next Sequence Sequence.GetFirstStep... return the first Step in the current Sequence Step.GetNext... return the next Step Step.apply()... applies the current Step Regards, Benoit. -----Original Message----- From: Galt, Stuart A [mailto:stuart.a.galt@boeing.com] Sent: Wednesday, October 10, 2007 6:38 PM To: cgmo-webcgm@lists.oasis-open.org Subject: [cgmo-webcgm] Straw horse application structures Hello all, Okay, I have spent some time reading SVG animation [1] and SMIL [2]. I guess that implementing full blown animation as part of webCGM 2.1 would be too much work. However, I think that we can lay the groundwork by defining the supporting infrastructure to handle some of the easy stuff. The film-strip or "budget" animation (yes I know that might be the wrong word) is described in SMIL as the calctype="discrete" mode. I no longer want animation, I want sequential discrete transformations :) My proposal would be to introduce some new application structures that can be either embedded within the CGM image or expressed in an XCF file. All that is needed is that the application structures exist in the DOM tree after the image is loaded. An important design decision to make early on is do the sequence and steps have to be a child of the grobject that is being transformed? I would prefer the answer to be no but then you need to have an ability to call out the apsId . Here are the application structures that I have come up with: APS sequence: An apsId is required. A targetId would be optional but if it is not specified the targetId would need to be defined for all of the individual steps. I think this is similar to the structure that Benoit talked about minus any attributes that have to do with timing. APS step: A targetId would optional, but if it is not specified it would need to be specified in the parent APS or all of the atoms would need to be specified. Once again it is similar to the structure that Benoit talked about minus any attributes that have to do with timing. I would also define the following "atom" application structures: (note that apsId is optional) Style ( apsId?, styleName, styleValue ) - this would the names and values that can be set via the DOM Translate(apsId?, dx, dy) - this just takes all of the x and y coordinates within the APS and translates them by dx,dy Scale(apsId?, orgin, sx, sy) - this just scales about the specified orgin. X(new) = (X(old) - x(origin)) * sx + X(origin) Rotate(apsId, origin, angle) - this rotates the apes angle degrees around the origin. By restricting ourselves to calctype="discrete" type of animations I would expect all of the atoms of a step to be implemented at once. To be able to make something happen the sequence APES structure needs to be visible in the DOM so I can get to it. I would then propose the following methods: firstStep() - This applies the atoms contained in the first step. lastStep() - This applies the atoms contained in the last step applyStep(n) - This applies the atoms contained in the nth step. If n is <0 or > number of steps and exception should be thrown? nextStep() - This applies the atoms contained in the next step. Not sure how to handle the case when we apply the last step and ask for one more... does this return a value or should an exception be tossed? If this gets delayed and becomes part of a longer term project timing at the sequence and step level could be added. Adding a path atom might also prove useful. [1] http://www.w3.org/TR/SVG11/animate.html [2] http://www.w3.org/TR/smil-animation/ -- Stuart Galt SGML Resource Group stuart.a.galt@boeing.com (206) 544-3656
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]