> This is a nice write up. Thanks :)
> 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). Okay, this is it. This is exactly the point where we disagree... I think that the wording in section 7.9 spells out pretty clearly that the coordinate system that is established by the <svg> element and it's viewBox attribute is _separate_ from it's own user coordinate system. This line in particular drives this thinking: "The orientation of the new viewport coordinate system and the new user coordinate system correspond to the orientation of the current user coordinate system for the element establishing the viewport. A single unit in the new viewport coordinate system and the new user coordinate system are the same size as a single unit in the current user coordinate system for the element establishing the viewport." [1] I am not sure where else in the recommendation this is addressed. Did you have a specific reference for your reading? The only other reference I could come up with was section 7.7 which I think further supports my reading. As you know, in section 7.7 the viewBox transformation is equated to a supplemental transformation included on a child <g> element. This points to it being treated separately. Additionally, the simple fact that the new coordinate system established by the viewBox is not applied to the x, y, width, height demonstrate it's different treatment. The most specific paragraph from 7.7 is: "The effect of the viewBox attribute is that the user agent automatically supplies the appropriate transformation matrix to map the specified rectangle in user space to the bounds of a designated region (often, the viewport). To achieve the effect of the example on the left, with viewport dimensions of 300 by 200 pixels, the user agent needs to automatically insert a transformation which scales both X and Y by 0.2. The effect is equivalent to having a viewport of size 300px by 200px and the following supplemental transformation in the document" [2] Here the spec again treats the user space of the <svg> element and the coordinate system it is establishing as separate artifacts. <snip>other important points we need to talk about once we agree on the above</snip> [1] http://www.w3.org/TR/SVG/coords.html#ElementsThatEstablishViewports#EstablishingANewViewport [2] http://www.w3.org/TR/SVG/coords.html#ElementsThatEstablishViewports#ViewBoxAttribute Thanks again, 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 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/
