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

On 11/11/05 3:18 PM, Chris Lilley wrote:
> 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.

Not sure I would use accessibility argument, as this seems like it's 
more of a user agent thing.  For example, an accessible browser 
implementing SVG would presumably have some way of panning/zooming 
individual images and/or pages, so SVG doesn't need to provide another 
magnification layer which could just confuse the user ("why is this 
image acting differently than the others?").

Taken to the extreme position, why does SVG require user agents to 
implement zoom&pan natively when such functionality can be scripted by 
content when necessary using the primitives SVG provides?

> 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.

Will these two items be treated as LC items and acted upon?

Another LC comment: 13.7 should mention rotate, why it's not required 
like translate/scale, and whether the zoomAndPan attribute should also 
enable/disable rotate.

>>>>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.

The W3C should be more concerned with clarity and interoperability of 
the SVG specification, not with content written for a particular domain.

> 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.

This isn't a good reason to continue including it, especially since it's 
a purely informative addition to the specification.

Received on Friday, 11 November 2005 22:27:56 UTC