Hi Jeff, Jeff Rafter wrote:
> Yes, upon further review I consider this a bug in my code. I think I > have pinpointed how I came to the conclusion I did at the time and have > outlined it, along with the rest of my thoughts on getCTM in this document: > > http://jeffrafter.com/svg/tests/getCTM.html This is a nice write up. >> Your definition may be more useful than the one in the >>SVG specification but I think it would be hard to consider it >>conformant. > > I think that my new one is backed by the spec. The section in my > document in red is the part that is likely not conformant (strictly) but > is more useful. There are two such places. In particular the second one: # The implementation should first collect the consolidated transform matrix for the current element. [...] [part in red] It should be noted that if the current element is a child <svg> element then the consolidated transform matrix would always be equal to [ 1 0 0 1 0 0 ] as the "automatic transformation" (described in point c.) would not apply to the <svg> element itself. In the case of elements that establish a new viewport and are themselves transformable, the resulting consolidated transform would be equivalent only to the value specified in the transform attribute. [end part in red] I agree that this is not conformant (at all) but is more useful, except to be useful I would think that it should include any translate due to X/Y on the SVG element (which unlike the 'x'/'y' on rect _do_ change the coordinate system). Without this you still couldn't chain getCTM calls. To be a little more explicit on why I don't consider this implementation at all conformant the definition of getCTM is very clear that it goes from the _userspace_ of the current element. This is also very clearly defined for the SVG element to be the coordinate system after the application of the viewBox transform (if any). >> This is clearly wrong. getCTM goes from the user-space of >>the current element - which for an SVG element is clearly defined to >>include the viewBox transform. > > I agree with this... > >>This is the main reason getCTM is >>almost useless if you try to chain 'getCTM' calls up the rendering >>tree you get 'double' viewBox transforms. > > I don't agree with this. Unless you are talking about your 'modified' getCTM call which doesn't include the viewBox transform then you get double viewBox transforms when you chain them. Can you explain why you think the getCTM as defined by the SVG specification is useful? >> I don't really know why you are interested in this (implementation >>or usage), but the really useful methods to use are >>'getTransformToElement' and 'getScreenCTM' > > In cases where you are using the viewports to create "windows" into a > document and you are establishing a clipping region, it can be very > useful. But yes for the common cases (e.g. mouse events) getScreenCTM is > what should be used. The real problem is that getCTM goes to 'viewport' coordinates. Essentially everything else in SVG is done in userspace. Even for the case of creating 'windows' what you probably really want is either: elem.getTransformToElement(elem.getViewportElement()) or elem.getTransformToElement(elem.getViewportElement().parent) For moving the window around use the parent version to map points and just update the 'x' and 'y' attributes on 'elem.getViewportElement()'. > > Thanks, > Jeff Rafter > > > ----- > 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 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/ <*> 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/
