W3C home > Mailing lists > Public > www-svg@w3.org > August 2003

SVGLocatable.getScreenCTM() vs clientX/Y, screenX/Y

From: Thomas DeWeese <Thomas.DeWeese@Kodak.com>
Date: Wed, 20 Aug 2003 13:17:56 -0400
Message-ID: <3F43AD44.3090704@Kodak.com>
To: www-svg@w3.org

Hi SVG Working Group,

     It has recently become obvious to me that the SVG specification is
a bit ambiguous as to what coordinate system getScreenCTM transforms
to. Quoting from the relevant section of the specification:

getScreenCTM

    Returns the transformation matrix from current user units (i.e.,
    after application of the transform attribute, if any) to the parent
    user agent's notice [SIC] of a "pixel". For display devices,
    ideally this represents a physical screen pixel. For other devices
    or environments where physical pixel sizes are not known, then an
    algorithm similar to the CSS2 definition of a "pixel" can be used
    instead.

    DOM event specification effectively defines two coordinate systems
for the values stored in mouse events:

clientX of type long, readonly
     The horizontal coordinate at which the event occurred relative to
     the DOM implementation's client area.

clientY of type long, readonly
     The vertical coordinate at which the event occurred relative to
     the DOM implementation's client area.

screenX of type long, readonly
     The horizontal coordinate at which the event occurred relative to
     the origin of the screen coordinate system.

screenY of type long, readonly
     The vertical coordinate at which the event occurred relative to
     the origin of the screen coordinate system.

     The description of getScreenCTM seems to mix these two definitions
a bit.  It talks about the "user agent's notion of a 'pixel'" as well
as physical screen pixels.  Given the name similarity I would lean
towards getScreenCTM going to the 'screen' coordinate system, however
most of the interfaces in SVG (currentScale/Translate for example)
deal with the user agent's coordinate system.  I don't have a strong
preference however Batik currently returns the transform to the DOM
implementation's client area (giving weight to the user agent part).

     Can the WG please provide a clarification as to which coordinate
system is intended?

     Thanks!
Received on Friday, 22 August 2003 22:28:41 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:25 GMT