Re: First Drafts of SVG 1.1 and SVG Mobile; new Test Suite release

Elliotte,

On Wed, 31 Oct 2001, Elliotte Rusty Harold wrote:

> Section 10.1 of the new spec looks promising:
> 
> In order to achieve interoperability between SVG content generators and SVG user agents, the next draft of the SVG 1.1 specification may describe a technique for defining the reference coordinate system used by an SVG document fragment that contains positional information (e.g. that path segment data is in WGS84 latitude/longitude). The SVG Working Group will not invent any metadata standards for this data; it will use existing metadata elements for the task and define how they should be included in an SVG fragment. 
> 
> Does this indeed mean that it would be possible to say that a rectangle is two meters by three meters and otherwise use actual units?

You can already say a rectangle is two metres by three metres using
CSS units, but I don't think that is what you meant, right?

Maybe it is better to explain the usage scenario. Suppose you
have two file that both contain geometric data with coordinates
that are actually represented by latitude/longitude values in
WGS/84. Using the specified metadata technique, a user agent can
see that in this case that one file could be overlayed on the
other.

Now jumping ahead to answer your question on the next paragraph,
if one file is lat/long using WGS/84 and the other is lat/long
using some other datum, then the user agent is not required to
transform the data. Of course, a smart user agent could do it
but seeing as there are a lot of different world coordinate systems
out there, and the transformations are quite complicated, this
is not required for SVG conformance. By simply describing the coordinate
system that the file uses, we help a large number of positioning
applications.

> However, the next paragraph is disturbing:
> 
> This should simplify overlaying SVG document fragments and including live global positioning data. It will not require that the SVG user agent provide any transformation of the data above that described in SVG 1.0. 
> 
> It seems to me essential to be able to set a scale from real-world units like meters to onscreen units and expect the browser to obey that scale factor. This is essential for CAD and other technical drawing systems. The lack of it is a major flaw in SVG 1.0. 

I think you can do this to some extent now by setting your viewBox
and width/height on the outermost svg element. I agree that it 
doesn't work in every situation.

> Perhaps my confusion is about parsing the word "It" in the above sentence. Does "It" refer to the specification or the new functionality? I.e. does this mean that the working group thinks that adding this functionality will not require user agents to  "provide any transformation of the data above that described in SVG 1.0." or does it mean that the working group thinks that such transformation is required, but that the spec is not going to require user agents to add it? Or am I just confused about what section 10.1 is talking about in the first place? 

I'll note this as feedback that the spec is unclear :)

This feature of SVG 1.1 will not require a user agent to transform
data between global coordinate systems. Some user agents might
do it, but the majority will not. This type of transformation is
much more complicated than the affine transformations specified
by the "transform" and "viewBox" attributes.

The SVG working group spent a fair amount of time discussing this.
The resolution was that SVG should specify where metadata describing
the coordinate system of the document should go, and what format it
should be. SVG will not define the format, that will probably come
from somewhere like the OpenGIS consortium.

Dean

Received on Wednesday, 31 October 2001 09:20:22 UTC