- From: Thomas DeWeese <Thomas.DeWeese@Kodak.com>
- Date: Wed, 20 Aug 2003 13:17:56 -0400
- 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 UTC