Re: Numerical Limits in SVG coordinates?

The guidance in the specs is here:

SVG 1.1: http://www.w3.org/TR/SVG11/types.html#Precision
SVG 2 Editor's Draft: https://svgwg.org/svg2-draft/types.html#Precision

In short, most numbers should be maintained at single-float precision.
However, Firefox on many platforms uses the Cairo library, which uses
fixed-point decimals for coordinates, and therefore can't handle very large
or very small numbers, which is why it wasn't displaying your file.  See
this Q&A on Stack Overflow, particularly Robert Longson's comments re
Firefox:
http://stackoverflow.com/q/27161079/3128209

There has been some talk about upgrading the requirement to double-float
precision, in order to better support the direct conversion of coordinates
from other formats, particularly longitude/latitude in mapping.

See  comments in meeting minutes from Nov 2013:
http://www.w3.org/2013/11/14-svg-minutes.html#item01

The current requirements are that  "High Quality viewers" should use
double-precision for transformation calculations.  At that meeting, it was
resolved that the distinction between regular and high-quality viewers
should be re-examined.  One option would be to require "high quality
viewers" to use doubles for regular coordinates.  However, I think there
has been push-back because many GPUs only use floats; using doubles would
limit hardware acceleration possibilities.

Regardless, the particular example you're using would work with floats,
just not with Firefox's fixed point numbers.  For now, your best bet is to
add an extra normalization step to your conversion process, that scales the
number to a range more in keeping with the final pixel distances.

ABR

On 28 January 2015 at 12:25, Smailus, Thomas O <Thomas.O.Smailus@boeing.com>
wrote:

>  Working with some diagrams that come by way of CAD systems, when
> translated to SVG produces some very large coordinate’s space usage.
>
> The resulting diagram draws in some browsers (IE11) but not others
> (Firefox 33), and I’m wondering if there is any specification guidance on
> numerical extents.
>
> It may not even be a numerical extents problem for all I know.
>
>
>
>
>
> The diagram, which should render a polygon drawn oval shape in the upper
> left quadrant of the display:
>
>  *[clipped]*
>