Thomas DeWeese wrote:
>> 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).
Jeff Rafter wrote:
> 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 agree that this does tend to indicate that the user coordinate
system and the viewport coordinate system are identical. However,
I think that it is useful to consider the definition of the viewBox
attribute which says:
The value of the viewBox attribute is a list of four numbers
<min-x>, <min-y>, <width> and <height>, separated by whitespace
and/or a comma, which specify a rectangle in user space which
should be mapped to the bounds of the viewport established by
the given element, taking into account attribute
preserveAspectRatio.
In particular the part "a rectangle in user space" if we take your
definition of user space one must wonder what "user space" they are
referring to here - it can't be the SVG element's user space as that is
'fixed' to the viewport coordinate system. My interpretation is
that the description in 7.9 Establishing a new viewport is focused
mainly on the 'viewport' part and the talk about the new user space
is talking about the default case of no viewBox attribute (in
which case the viewport and user coordinate systems do align as
described).
Also scattered through the specification are things like for
clipping paths from section 14.3.4 Clipping to viewport vs. clip
to ViewBox:
To set the initial clipping path to the bounds of the viewBox,
set the bounds of 'clip' property to the same rectangle as
specified on the viewBox attribute.
If you take this with the definition of 'clip':
Unitless values, which indicate current user coordinates, are
permitted on the coordinate values on the <shape>.
It seems clear that the values in the viewBox are in
the current user coordinate system of the SVG.
> 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.
I disagree this is done for illustration purposes and is not
intended to be a complete equivalence. For example the above
description of 'clip' is clearly incompatible with this substitution.
> 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).
Once again we must wonder what "user space" is being referred to
here if it is not the user space of the SVG/viewport element.
> 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.
If you read a bit further in 7.7 though it clarifies this and says:
Unlike the transform attribute (see effect of the transform on
sibling attributes), the automatic transformation that
is created due to a viewBox does not affect the x, y, width and
height attributes (or in the case of the 'marker' element, the
markerWidth and markerHeight attributes) on the element with the
viewBox attribute. Thus, in the example above which shows an
'svg' element which has attributes width, height and viewBox,
the width and height attributes represent values in the
coordinate system that exists before the viewBox transformation
is applied. On the other hand, like the transform attribute, it
does establish a new coordinate system for all other attributes
and for descendant elements.
This last sentence clinches it for me. If all the other
attributes and children are evaluated in this new coordinate system
what else could you call it but the user coordinate system?
Finally at the start of 7.4 Coordinate system transformations:
A new user space (i.e., a new current coordinate system) can be
established by specifying transformations in the form of a
transform attribute on a container element or graphics element
or a viewBox attribute on an 'svg', 'symbol', 'marker',
'pattern' and the 'view' element. The transform and viewBox
attributes transform user space coordinates and lengths on
sibling attributes on the given element (see effect of the
transform attribute on sibling attributes and effect of the
viewBox attribute on sibling attributes) and all of its
descendants.
> <snip>other important points we need to talk about once we agree on the
> above</snip>
Do you agree with me yet?
>
> [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 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/
