Re: FW: Retrieving mouse event co-ordinates in transformed co-ordina te space.

Alan,

At 04:18 PM 3/15/00 +0000, Alan Kennedy wrote:
>Hi Folks,
>
>I sent the attached message on xml-dev@xml.org, since an SVG thread cropped
>up there, but there seemed to be no interest. I still think this is an
>important point however, although I see that there is an explicit mention in
>the "changes to the March 3rd WD", which states 
>
>"Removed ambiguity regarding 'relatedNode' for clientX/clientY on mouse
>events. Now clarifies that the 'relatedNode' is the **outermost** 'svg'
>element, which means clientX/clientY are values in the initial coordinate
>system."
>
>I can't find any discussion of this topic on the public WWW SVG list. Has
>there been any discussion on this topic? Am I wrong in thinking that mouse
>events should be delivered to target objects in co-ordinates they can use
>directly, without further compuation? Are there implementation issues that
>make this difficult or impossible? 

Yes. The routines that field the events have no concept of coordinate
system transformations or rendering order or any other SVG-specific event
handling logic. Typically, you get an (x,y) location relative to some
window, where the units are (typically) screen units. There are various
problems that make this messy.

But in recognition that scripters want to work in local user units, there
is a method call on every element that contains a 'transform' attribute:

getTransformToElement
 
Returns the transformation matrix from the user coordinate system on the
current element (after application of the transform attribute) to the
user coordinate system on element (after application of its transform
attribute). 
  Parameters 
    in SVGElement element 
      The target element. 

  Return value 
    SVGMatrix 
      An SVGMatrix object that defines the transformation. 

  Exceptions 
    SVGException 
      SVG_WRONG_TYPE_ERR: Raised if the target element is of an invalid type. 
      SVG_MATRIX_NOT_INVERTABLE: Raised if the currently defined
transformation matrices make it impossible
      to compute the given matrix (e.g., because one of the transformations
is singular). 


>
>I think that if the standard is not changed to deliver co-ordinates in the
>local co-ordinate space, then every programmer will be forced to write a
>piece of code that calculates what the event co-ordinates should be in the
>local space. And the code is far from trivial. And since everyone will have
>done it differently, and potentially wrongly, existing code bases may be a
>barrier to further evolution of the SVG spec.
>
>But I have to say that I think SVG is the best thing since sliced bread, and
>will revolutionize the web, particularly in the areas of data visualization
>and user interfacing. Keep up the great work.

Thanks.

Jon Ferraiolo
SVG Editor
Adobe Systems Incorporated

>
>Alan Kennedy.
>
>-----Original Message-----
>From:	Alan Kennedy [SMTP:Alank@Widelearning.com]
>Sent:	Monday, March 13, 2000 1:10 PM
>To:	'xml-dev@xml.org'
>Subject:	SVG: Retrieving mouse event co-ordinates in transformed
>co-ordina te space.
>
>Hi,
>
>Is this something missing from SVG? Or something missing from DOM2?
>
>Hope this explanation isn't too long.
>
>All pixel-addressable display screens have a maximum width (max-width) and
>height (max-height), and I can address pixels on such displays using a
>co-ordinate system where the x value ranges from 0 to max-width and the y
>value ranges from 0 to max-height. Let's call this co-ordinate space SYSTEM.
>
>When I define a SVG document, if I don't define any co-ordinate system, I
>get the "initial user co-ordinate system", which is set by the user agent.
>Let's call this co-ordinate space S.
>
><svg width="640px" height="480px">
>	<!-- This rectangle will fill the visible portion of S.	-->
>	<rect x="0" y="0" width="640" height="480" style="fill:red;"/>
></svg>
>
>However, I can also define a transformation on S, using the "viewBox"
>attribute, to change the mapping of co-ordinates into a new co-ordinate
>space more suitable for my purposes. Let's call this transformed co-ordinate
>space ST.
>
><svg width="640" height="480" viewBox="0 0 100 100"
>preserveAspectRatio="none">
>	<!-- This rectangle will fill the visible portion of ST.	-->
>	<rect x="0" y="0" width="100" height="100" style="fill:red;"
>onmouse="handleSTevents(event)"/>
></svg>
>
>Next, I register event listeners on an object in ST, listening for all mouse
>events, e.g. mouseover, mouseup, mousedown, etc. I do this in order to be
>able to make the objects interactive, e.g. draggable.
>
>When the event (a DOM2 UIEvent) is received by my event handler
>(handleSTevents), it has four attributes on it to tell me the location of
>the mouse at the time the event occurred. They are, along with definitions
>given in the DOM2 spec
>(http://www.w3.org/TR/DOM-Level-2/events.html#Events-UIEvent), 
>
>screenX - The horizontal coordinate at which the event occurred relative to
>the origin of the screen coordinate system.
>screenY- The vertical coordinate at which the event occurred relative to the
>origin of the screen coordinate system.
>clientX - The horizontal coordinate at which the event occurred relative to
>the DOM implementation's client area.
>clientY- The vertical coordinate at which the event occurred relative to the
>DOM implementation's client area.
>
>The problem is that there seems to be no way of determining what were the
>co-ordinates of the mouse event in the transformed space ST. If I want to
>find out where in my graphical object the event occurred, or if I want to
>change the location of my object to a new location *in space ST*, then I
>cannot do so, since I can't find the location of the event in space ST.
>
>The "screenX" and "screenY" attributes tell me the co-ordinates of the event
>in the SYSTEM co-ordinate space, and the "clientX" and "clientY" attributes
>tell me the co-ordinates of the event in the user agent's S co-ordinate
>space.
>
>If I want to work out the co-ordinates of the event in the space ST, then I
>have to calculate them by finding all co-ordinate system transformations
>that result in the formation of ST, by searching the ancestors of the
>element in the document, and process "clientX" and "clientY" through them.
>
>Or am I missing something?
>
>Alan Kennedy.
>
>
>***************************************************************************
>This is xml-dev, the mailing list for XML developers.
>To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
>List archives are available at http://xml.org/archives/xml-dev/
>***************************************************************************
>

Received on Friday, 17 March 2000 18:03:12 UTC