From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>

Date: Tue, 29 May 2007 14:18:12 +0200

To: www-smil@w3.org, cogit@ludicrum.org

Message-Id: <200705291418.12974.Dr.O.Hoffmann@gmx.de>

Date: Tue, 29 May 2007 14:18:12 +0200

To: www-smil@w3.org, cogit@ludicrum.org

Message-Id: <200705291418.12974.Dr.O.Hoffmann@gmx.de>

> I thought we had something in there somewhere to make the fill value take > the exclusive endpoint value (as all authors would want, if not expect, and > even if they understand the interval timing model as we do). No, if one understands this interval timing model and maybe the mathematical concept of a limes, it would be surprising to have an additional specific rule to get the exclusive endpoint. There is no need for a specific rule. Some more of such exceptions and the interval timing model with exclusive end is not useful for anything ;o) The main reason to discuss the situation of the exclusive end for a continuous (linear, paced or spline) animation seems to be to avoid that implementors have to identify this themselves as the correct limes in the interval timing model with exclusive end. In a perfect world for those continuous animations there is no need for a specific rule, but I can understand this as a simplification for implementors. But for discrete animation these rules do not create the correct result related to the mathematical limes for the time interval model, therefore for the discrete animation the result from the simplifying formulars in SMIL2 gets counterintuitive using the exclusive endpoint as a frozen value. With interactive begin or end the probabilty that it happens is very low and the main application doing this with offset values is to test, if the time interval model is implemented correctly in a viewer. Else I cannot imagine any other expectation for this relatively exotic situation for authors as the mathematical correct limes within the interval timing model ;o) Using the interval timing model and having a discrete animation, we identified in another discussion a problem with the value 1 for keyTimes. According to the definition of keyTimes for discrete animation, 1 is allowed, but it creates always an empty or invalid interval at the end. For this, there can be some wording interpreted as specific rule to take this as the frozen value (if there is no cut off simple duration). But this creates some more curious effects concerning accumulative animations, because within the active duration the empty interval related to keyTimes 1 is always ignored. But freezing the animation at a multipe of the simple duration results in a multiple of the value for the keyTimes 1, creating a surprising big jump at the end. Therefore keyTimes 1 for discrete animation is a surprising thing too, surprising that it is allowed together with the interval timing model, not useful at all and creating maybe minor specific implementation trouble to get it right with accumulative animation ;o) > > I forget where this was, but I remember discussing it. Will hunt around > when I get back online (writing from the train). > > Patrick >Received on Tuesday, 29 May 2007 12:20:12 UTC

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 20:34:26 UTC
*