- From: Doug Schepers <schepers@w3.org>
- Date: Sun, 02 Nov 2008 10:58:31 -0500
- To: www-svg <www-svg@w3.org>, "Dr. Olaf Hoffmann" <Dr.O.Hoffmann@gmx.de>
Hi, Dr. Olaf- This was accidentally sent to the SVG WG list instead of the public SVG list (www-svg), so I'm reposting it here. Please let us know if you are satisfied with this response. Thanks- -Doug -------- Original Message -------- Date: Wed, 22 Oct 2008 02:40:58 +1100 From: Anthony Grasso <anthony.grasso@cisra.canon.com.au> To: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de> CC: W3C SVG Public Working Group <public-svg-wg@w3.org> Hi Dr. Hoffmann, Thank you for your feedback. Please see my comments below. Dr. Olaf Hoffmann wrote: > Hello, > > Anthony Grasso: >> Hi Dr. Hoffmann, >> >> The SVG Working Group discussed this issue. Please see my comments below. >> >> Doug Schepers wrote: >>> Hi, Dr. Olaf- >>> >>> Thanks for your comment. I've recorded this as ISSUE-2089 in our >>> Tracker. The SVG WG will discuss this and get back to you soon. >>> >>> Regards- >>> -Doug >>> >>> Dr. Olaf Hoffmann wrote (on 10/1/08 10:19 AM): >>>> Hello SVG WG, >>>> >>>> SMIL notes about the underlying value of an animation: >>>> "The base value of a target attribute 'a' at time t is the value of 'a' >>>> to which animation is applied at time t." >>>> and >>>> "Animations can be defined to either override or add to the base value >>>> of an attribute. In this context, the base value may be the DOM value, >>>> or the result of other animations that also target the same attribute. >>>> This more general concept of a base value is termed the underlying >>>> value." and >>>> "The underlying value u of a target attribute 'a' of an animation >>>> element at time t is the value of 'a' to which the animation effect is >>>> applied at time t." >>>> >>>> In the table of SVGT1.2 '16.2.18 Attributes and properties that can be >>>> animated' it is noted for transform: >>>> "Additive means that a transformation is post-multiplied to the base set >>>> of transformations." >>>> >>>> and in 16.2.17 The 'animateTransform' element: >>>> "When an animation is active, the effect of non-additive >>>> 'animateTransform' (i.e. additive="replace") is to replace the given >>>> attribute's value with the transformation defined by the >>>> 'animateTransform'. >>>> The effect of additive (i.e. additive="sum") is to post-multiply the >>>> transformation matrix corresponding to the transformation defined >>>> by this 'animateTransform'." >>>> >>>> The obvious conclusion is, that the underlying value for an additive >>>> animateTransform is the base set of transformations at the time t >>>> and that the result of the animateTransform has to be post-multiplied >>>> to the underlying value (which includes results from lower priority >>>> animations too). >>>> >>>> Surprisingly 16.2.17 notes too (different from SVG 1.1): >>>> "The underlying value of transform animations (see SMIL discussion of >>>> animation function values) is the corresponding identity transformation >>>> value." >>>> >>>> This means especially, following this sentence new in SVGT1.2 compared >>>> with SVG1.1, that >>>> a) the underlying value is time independent >>>> b) the underlying value is always the same >>>> >>>> Effectively this sentence prevents any visible effect from additive >>>> animateTransform in conflict with the table of 16.2.18 and the additive >>>> sample of 16.2.17 and example: 19_01.svg of 16.2.3 and samples in the >>>> test suite like animate-elem-81. >>>> >>>> My impression is, that it is neither intended that additive >>>> animateTransform show no difference to non-additive animateTransform nor >>>> that these conflicts are intended. It looks more like a misunderstanding >>>> of the meaning of the SMIL definition of the 'underlying value', >>>> therefore I suggest simply to skip in 16.2.17 the sentence >>>> "The underlying value of transform animations (see SMIL discussion of >>>> animation function values) is the corresponding identity transformation >>>> value." >> I would like to clarify your suggestion. Do you mean delete _only_ the >> sentence "The underlying value of transform animations (see SMIL discussion >> of animation function values) is the corresponding identity transformation >> value."? >> >> The reason I ask this is the following sentence, bullet points and the next >> paragraph relate to that first sentence. I think if the first sentence is >> deleted either one of two things has to happen >> 1) Delete the following bullet points and next paragraph. >> 2) Reword following sentence before the bullet points and reword the next >> paragraph. >> >> Which do you think would best address the issue? and can you please suggest >> any wording if option (2) is best? >> > > You are right, after the changes noted below, the underlying value is defined > at points in the draft, where it is relevant, for additive="sum". > > Therefore we can take the following fragment: > > --> > The 'values' attribute for the 'animateTransform' element consists of a > semicolon-separated list of values, where each individual value is expressed > as described above for 'from', 'by' and 'to'. > > The underlying value of transform animations (see SMIL discussion of animation > function values) is the corresponding identity transformation value. Thus, > the underlying value for > type="translate" is tx = ty = 0 > type="scale" is sx = sy = 1 > type="rotate" is rotate-angle = cx = cy = 0 > type="skewX" and type="skewY" is skew-angle = 0 > Note that this results in counter-intuitive results for a to animation. Since > the underlying value is identity, and the 'additive' attribute is ignored on > to animations according to SMIL, such animations will behave like a > non-additive from-to animation where the "from" value is identity. > > If 'calcMode' has the value paced, then the "distance" for the transformation > is calculated consisting of the sum of the absolute values of the differences > between each pair of values as further described in Paced animations and > complex types. > <-- > > > And replace it with something like: > > --> > <p> > The 'values' attribute for the 'animateTransform' element consists of a > semicolon-separated list of values, where each individual value is expressed > as described above for 'from', 'by' and 'to'. > </p> > <p> > <em>from-to, from-by and by animations</em> > are defined by SMIL to be equivalent to the related <em>values animations</em> > (see <a > href="http://www.w3.org/TR/2005/REC-SMIL2-20051213/animation.html#AnimationNS-FromToBy">SMIL</a> > ). > </p> > <p> > The animation effect for animateTransform is post-multiplied to the underlying > value for additive animateTransform (see below) instead of added > to the underlying value due to the specific functionality of animateTransform. > </p> > <p> > The idea of <em>to animations</em> is a mixture of additive and > non-additive behaviour (see <a > href="http://www.w3.org/TR/2005/REC-SMIL2-20051213/animation.html#animationNS-ToAnimation">SMIL</a> > ) providing a specific functionality to get a smooth change from the > underlying value to the <em>to</em> attribute value, which conflicts > mathematically with the requirement for additive animateTransform to be > post-multiplied.<br /> > Currently within SVG tiny 1.2 this conflict is not resolved and therefore the > behaviour of <em>to animations</em> for animateTransform remains > undefined and may result in not predictable behaviour instead of the > expected functionality as defined by SMIL for <em>to animations</em>. > </p> > <p> > If 'calcMode' has the value paced, then the "distance" for the transformation > is calculated as further described in 'Paced animations and complex types'. > </p> > > <-- > > I think, this does not change, what we already have, provides more > relevant information on what to expect or how to implement, > and it does not conceal the remaining problem with the to animation > (and gives some reasoning, why it is a problem to specify something > useful for to animations). > > The last paragraph is shortened a little bit, because I discovered, that > it still contained some confusing stuff, not required anymore, because > the referenced table covers this completely. > Agreed. This change now appears in Section 16.2.17 [1] of the specification. > > > > >>>> and to explicitly note 'underlying value' in the table of 16.2.18: >>>> "Additive means that a transformation is post-multiplied to the base set >>>> of transformations representing the underlying value." >> Agreed. This change can now be found in the published version of the >> specification [1]. > > yes, ok. > >>>> and in 16.2.17 too: >>>> "The effect of additive (i.e. additive="sum") is to post-multiply the >>>> transformation matrix corresponding to the transformation defined by >>>> this 'animateTransform' to the the base set of transformations >>>> representing the underlying value." >> Agreed. This change can now be found in the published version of the >> specification [2]. >> > > yes, ok. > >>>> Because from-to, from-by and by animations are defined in SMIL already >>>> to be equivalent to the corresponding values animation (tests are >>>> already available in the test suite), there remains no specific problem >>>> for those notations for animateTransform too. >>>> >>>> What remains is the problem with to-animateTransform, because this >>>> animation type is neither pure additive nor pure non-additive. >>>> The following requirements for to-animations come from SMIL: >>>> a) begin (additive) with the underlying value >>>> b) end non-additive with the to value >>>> c) specific formula defined in SMIL has to be used - >>>> the formula defines a specific feature or behaviour or >>>> functionality, not available with other combinations of animations in >>>> SMIL/SVG. The main functionality it typically a smooth change from the >>>> underlying value to the value specified with to >>>> d) specified attributes additive or accumulate have to be ignored >>>> >>>> The following requirement comes from SVG animateTransform >>>> e) animateTransform has to be post-multiplied to the underlying value >>>> >>>> There is especially a conflict between c) and e). >>>> There are different more or less useful and simple possibilities to >>>> solve this conflict. >>>> 1) If e) is skipped, this requires an animation of the complete >>>> transform matrix in general to meet c) - this might be not completely >>>> trivial but is possible. Mainly one has to express the underlying value >>>> as a matrix as well as the value of the to attribute and to interpolate >>>> between those two values as specified in SMIL to get the desired smooth >>>> change. Because to-animations behave always quite different from >>>> the other animation types, this does not create any inconsistency. >>>> 2) If c) is skipped, this results in the complete loss of the >>>> functionality of to-animations for animateTransform. If we accept this, >>>> possibilities could be >>>> 2.1) to define to-animateTransfrom always to be a discrete >>>> animation, this avoids a direct conflict between c) and e) too, because >>>> SMIL defines the behaviour of discrete to animation not conflicting with >>>> e), therefore to-animateTransform has effectively the same functionality >>>> as a set animation, not directly available for transform currently. 2.2) >>>> to define an arbitrary initial value as done by the current draft, using >>>> effectively the identity transformation as initial value. This provides >>>> no interesting functionality as well and means, that a) has to be >>>> skipped as well due to the problem with the underlying value as >>>> discussed above. >>>> 2.3) to specify that to-animateTransform has no effect, to >>>> indicate, that not all requirements can be met. >> We agree that this is an outstanding issue since SVG Tiny 1.1. We intend on >> doing a comprehensive review and address this issue in the next version of >> the SVG specification. > > I included the 'undefinition' already in the suggested wording above ... > > >>>> Side note: >>>> In the table of 16.2.18 there are two notes about color conversion. >>>> This looks like a missing word: >>>> "Only additive if each value can be converted an RGB color." >>>> -> >>>> "Only additive if each value can be converted (in)to an RGB color."? > > What about this missing word? > Oh sorry, this has now been fixed in Section 16.2.18 [2]. > > > > Olaf > Please let us know at your earliest convenience if the changes are satisfactory. Kind Regards, Anthony Grasso. [1] http://dev.w3.org/SVG/profiles/1.2T/publish/animate.html#AnimateTransformElementTypeAttribute [2] http://dev.w3.org/SVG/profiles/1.2T/publish/animate.html#AnimationAttributesAndProperties
Received on Sunday, 2 November 2008 15:58:42 UTC