W3C home > Mailing lists > Public > www-svg@w3.org > November 2005

Re: [SVGMobile12] Comments: Coordinate Systems, Transformations and Units

From: Chris Lilley <chris@w3.org>
Date: Fri, 11 Nov 2005 22:18:35 +0100
Message-ID: <19189943.20051111221835@w3.org>
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 GMT

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