Hi David,
--- In [email protected], "David Dailey" <ddailey@...> wrote: > > (sorry for duplication, this seems not to have gone through the first time) > > Hi Domenico, > > > > Those poor lizards. > > > > Yes, I agree that the behavior is not consistent with what users would > expect - not in Opera, ASV, Chrome, Safari or Firefox. It looks like both > some browser bugs and a spec bug to me. > > > > I simplified the code as per your suggestion (and borrowed your bus), and > embellished a wee bit. > > > > http://cs.sru.edu/~ddailey/svg/lizard2.2a.svg > > > > Two buses each follow one of two paths (for a total of four buses). The blue > one is simple (no transforms) and all browsers agree. I rotate the red bus > by 15 degrees and you are right - it is as though I've rotated the path and > the bus in Opera and ASV. FF and webkit seem to do what I like (at least in > Windows) by rotating only the bus. > > > > But then I scale the path that the green and yellow buses follow and the > transform has no effect. Probably consistent with the spec, the > animateMotion simply grabs the d attribute of the path, prior to application > of the transform. There are good reasons that an author might want to > rescale the path that an animation is to follow. And there are good reasons that an author might want the opposite, I would guess in more than 50% of the cases. In fact, you define your motion path which, in terms of locomotion translates to an itinerary. Then you want your buses and a taxi to follow the same itinerary. You then say that your yellow bus is really a taxi and you want to scale it. But you don't want the city to grow smaller and move somewhere else, or even lose its North if you rotate the taxi! This is the same as if we were defining orbits and planets for example, are the orbits proportional to the size of the planets? No! You define the orbits and then you use planet instances, each with a different scale property. Imagine when you make miscalculations in scaling, do you have to redefine the orbit each time? I would suggest that since we have the option to have the animateMotion as a descendant element, or to have it outside and reference the target element, when using the former we can expect the motion path to inherit the transformation attributes defined for the element, and when using the latter we expect the motion path to remain immune to transformations. > > > > Let's see if Robert L. or Erik D. or someone chimes before I move this > conversation to www-svg. You can move it there or pick up the thread pointed by Ken. This is the last post of that thread: http://lists.w3.org/Archives/Public/www-svg/2011Sep/0011.html Domenico > > > > Cheers > > David > > > > /fyi the original example with crawling lizards (and ones with incorrectly > replicated ids) is at http://cs.sru.edu/~ddailey/svg/lizard2.svg > > > > > > > > > > From: [email protected] [mailto:[email protected]] > On Behalf Of domenico_strazzullo > Sent: Wednesday, October 26, 2011 4:27 PM > To: [email protected] > Subject: [svg-developers] Re: browsers bug or spec bug > > > > > > Hi David, > > I salute your efforts to trace a safe path for your young lizards! > > In file: http://cs.sru.edu/~ddailey/svg/lizard2.svg : > > To be a replicant doesn't mean you can have a duplicate ID ("P1" at lines 67 > and 115) :) > > Supposing that we call "P1" "P2" at line 115, then: > > The rotation in the <animateMotion> is "applied after the supplemental > translation transformation that is computed due to the `path' attribute" as > the spec says. Although we only read "translation" there, it's good to know > that if you also specify scaling, the motion path is also scaled. Opera, > Safari and Chrome all seem to apply this principle (I haven't tested ASV, > and I haven't seen any of these animations running in FF3.6.8). I also have > the impression that the path rotation is applied to the motion path, as > well. > > I really don't think that authors find this behavior to correspond to what > they expect. I personally would find this acceptable when the > <animateMotion> element is a descendant of the element to animate, but when > the <animateMotion> is outside and references the element to animate through > the xlink:href attribute, then I would expect the element's transformations > not to affect the motion path (BTW, the spec says that xlink:href is "An IRI > reference to the `path' element which defines the motion path." whereas it > really is a reference to the element to animate, right?. The motion path is > specified by the path attribute or referenced by the mpath element). > > Under these conditions it becomes quite a mission to determine the correct > position of a shape, and in any case I don't think you want the motion path > to be transformed. This problem was discussed in the past and the best (the > only?) solution is to redraw the orange lizard path so that its origin is > the center of the BBox, and right off with the intended orientation. > > A simpler test to prove all this: > > <path id="bus" d="M0 -10h40v20h-80v-20z" fill = "green"> > <animateMotion dur="10s" rotate="auto" repeatCount="indefinite"> > <mpath xlink:href="#Q"/> > </animateMotion> > </path> > > If you apply transformations to the bus it simply gets out of control, > whether the <animateMotion> is a descendant or not. > > Nico > > > > > > [Non-text portions of this message have been removed] > ------------------------------------ ----- To unsubscribe send a message to: [email protected] -or- visit http://groups.yahoo.com/group/svg-developers and click "edit my membership" ----Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/svg-developers/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/svg-developers/join (Yahoo! ID required) <*> To change settings via email: [email protected] [email protected] <*> To unsubscribe from this group, send an email to: [email protected] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
