- From: Chris Lilley <chris@w3.org>
- Date: Fri, 11 Nov 2005 22:18:35 +0100
- To: T Rowley <tor@cs.brown.edu>
- Cc: www-svg@w3.org
On Friday, November 11, 2005, 9:53:03 PM, T wrote: TR> On 11/11/05 2:01 PM, Chris Lilley wrote: >>>7.7.1 >>> >>>"UR = User Rotate (currentRotate on SVGSVGElement)" >>> >>>Where does this come from? The closest thing to it, pan and zoom >>>(13.7), doesn't mention rotation. >> >> True, although nor does it disallow it. Most user agents do not expose >> user rotation in the UI, but some do, so the equations cover that case >> as well. Its simply set to zero for those implementations that do not >> allow it. TR> So you're going to enforce implementation of magnification and panning TR> (13.7 paragraph 3), but not rotation? That was the plan, yes. Zooming is needed for accessibility and for scalability. Once you have zoom, you need pan otherwise zoom is only useful for the center portion. Rotation, on the other hand, while nice to have, and allowed, is not required. Lack of rotation does not prevent access to any part of the graphic at a size large enough to see it clearly. TR> Please specify either all must be supported, or make them all TR> optional. We can't make them all optional, because the Accessibility people will complain, and we can't really make rotation required because its not that big a use case and some argue that it makes navigation and user orientation more confusing. TR> Also 13.7 should indicate that TR> this user action modifies the SVGElement's TR> current{Scale,Translate,Rotate}. Yes, it should. TR> Currently the only hint in the SVG TR> specification that these two things are linked is the description of the TR> "scroll" and "zoom" events. Another thing - shouldn't there be a TR> "rotate" event to match? Yes, there should. >>>7.14 >>> >>>Domain specific authoring notes (GIS) do not belong in the specification >>>for a general purpose vector graphics format. >> >> Its just metadata. Furthermore, since there was scope for confusion how >> the two coordinate systems would be related, we felt that this >> description would be useful. And there are commercial services that use >> this. >> >> We added a note: >> >> Note that the presence of this metadata does not affect the rendering >> of the SVG in any way; it merely provides added semantic value for >> applications that use of combine maps. TR> This resolution does not resolve the comment to my satisfaction. What TR> makes the GIS userbase so special SVG deals with coordinate systems. Mapping deals with coordinate systems. This generated significant confusion, in a way that, for example, metadata on 'artist' or 'creation time' does not. TR> that they get what's essentially a TR> application note stuck in the official specification? Let the various TR> speciality users of SVG issue their own authoring recommendation TR> documents, and let the SVG specification be just about SVG. While sympathetic to that viewpoint in general, in this instance there is significant value in terms of clarity and multi-vendor interoperability which is after all, what W3C is all about. Note that this was also in the SVG 1.1 specification. Its copied here so that SVG Tiny 1.2 is a stand-alone spec. -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG
Received on Friday, 11 November 2005 21:18:38 UTC