Re: ISSUE: current user space and <svg>

SVG WG,

I should point out that the current behaviour exibited by Mozilla in 
regard to the issue I described in the email below is the opposite to 
that exibited by Adobe's SVG Viewer alpha 6. In other words, getBBox, 
getCTM, getScreenCTM and getTransformToElement (for example) will behave 
differently in these two implementations of SVG.

I would urge you to consider the pros and cons of the different 
implementations, decide on one, and clarify the spec as soon as possible 
for the sake of SVG authors.

Regards,
Jonathan


Jonathan Watt wrote:
> 
> Jon,
> 
> Thanks for replying. It would be useful if a statement could be added to 
> the spec to clearly define "current user" coordinate system. I presume 
> such clarification would/should be added to the errata? However, the 
> concept of coordinate systems is fairly well understood, and I don't 
> think this is the most important issue.
> 
> The spec frequently refers to the user coordinate system (singular) of 
> an *element*. In the case where all of an element's attributes represent 
> values in the same coordinate system, it is clear what the user 
> coordinate system of *that element* is; but in the case of the 'svg', 
> 'symbol', 'marker', 'pattern' and 'view' elements, four of the element's 
> attributes represent values in one coordinate system, and any others 
> represent values in another. In this case, as you note, there are *two* 
> "current user coordinate systems" for the element.
> 
> The real issue as I see it is that refering to the coordinate system 
> (singular) of an *element* (either explicitly or implicitly) leads to 
> ambiguity in the spec when used in the context of elements that may have 
> a viewBox attribute.
> 
> I haven't had time to examine the spec to try to find all the places 
> where such ambiguity arises as a result of this issue, but one such 
> place is the sentence that describes the behaviour of the getCTM method 
> of the SVGLocatable interface:
> 
> getCTM
> "Returns the transformation matrix from current user units (i.e., after 
> application of the transform attribute, if any) to the viewport 
> coordinate system for the nearestViewportElement."
> 
> In the context of an 'svg' element say, this is ambiguous. The 
> clarification that "user space" means the coordinate system established 
> by the transform attribute is fairly redundant (although probably useful 
> to leave for clarification) since elements that can have a transform 
> attribute will only have one user coordinate system. What is really 
> necessary, but omitted, is clarification on which user coordinate system 
> is meant if a viewBox attribute is present. For our 'svg' element the 
> spec leaves scope to argue that it's either the user coordinate system 
> that exists before the viewBox attribute is applied (to which the x, y, 
> width and hight attributes refer to), or to the user space that is 
> established by the viewBox attribute (and to which any other attributes 
> refer to).
> 
> I would very much like to see some discussion on what would be most 
> useful, followed by a decision and clarification by the WG on what is 
> meant in the case where a viewBox attribute is present. This ambiguity 
> also exists for the other three methods of the interface of course. It 
> would seem desirable that all the methods refer to the same user space 
> when a viewBox attribute is present.
> 
> -Jonathan
>

Received on Monday, 24 January 2005 18:06:35 UTC