coordinatePrecison attribute proposal

[klaus Förster]

Doug Sheppers asked me to send a proposal that I've made at the SVGOpen
conference on this subject to the list - so here it is:

SVG code generated by Software often contains attributes, namespaces and
the like that increase file-size, make code unreadable for human eyes
and are in fact not needed when displayed on the web. Thus libraries
like Scour [1] have started to clean up bloated code and even try to
reduce precision of coordinates during this process. Due to the nature
of SVG, precision requirements may change within a single file. A
mapping user interface in pixel space gets along with integers just
fine, whereas the included map in real-world lat/lon coordinates needs
at least 3 to 7 decimal places to preserve geometry. Currently it is not
possible to semantically distinguish between the two, so I propose a new
attribute named "coordinatePrecision", "precision" or any other name,
that allows to specify the desired number of decimal places for content
of the following elements:

   - elements that establish viewPorts [2] - i.e. svg, symbol, image,
foreignObject
   - marker, pattern and view elements [3]

If it is not possible or desirable to add such an attribute, I encourage
the working group to consider other ways of giving hints to libraries on
how to cope with this situation. Maybe using HTML5s custom data-
attribute or any other way.

Klaus Förster

[1] http://www.codedread.com/scour/
[2] http://www.w3.org/TR/SVG/coords.html#ElementsThatEstablishViewports
[3] http://www.w3.org/TR/SVG/coords.html#ViewBoxAttribute

[Dr. Olaf Hoffmann]

Hello,


yes, I have such problems too.
Especially already years ago I created a PHP script
to clean up path data created by potrace+inkscape,
because I did not find a possibility to specify the number
of digits required for my application.
To reduce file size for some applications I do additionally
a combination of transform scale and an internal multiplication
of path data to get the data in a range with less required
digits and a range, where precision errors of viewers are
not so dominant (notwithstanding to specification the precision
of several viewers depend directly on the number range
of the path data).
I think, some programs do such (arbitrary?) scaling and
even metamorphoses from basic shapes to arbitrary path
data too, without understanding the purpose or importance
of the current appearance of data.

On the other hand it is annoying, if authoring tools
change already optimised code without any notification
or agreement from the current author.
 
For many authors might be important to have influence on such
changes too, just to avoid a loss of semantical meaning and
to avoid a 'pessimisation' by such scripts and programs.

Not simple to solve this maybe and more an issue for such
programs changing existing code to ask the user interactively
about the purpose of the code instead of changing everything
without knowing the purpose of the already existing code.
On the other side, if an author runs such an optimisation script
as mine for known content there are not many problems and
such an attribute including a hint is more useful to bring back
to mind, why things were done with such a result in the past.


As long as there is no such indication within current SVG versions,
there is more than one option to indicate this anyway:
1. An extension using its own namespace
2. Using information embedded in the metadata element.
3. Using RDFa attributes (as available already in SVG tiny 1.2)
referring to an external specification for some 'precision markup'.
Well, someone has to write such a specification or proposal -
as a first step maybe already useful to see what can be embedded
later into SVG directly?

Olaf