Re: Numerical Limits in SVG coordinates?

On Wed, Jan 28, 2015 at 11:54 AM, Amelia Bellamy-Royds <
amelia.bellamy.royds@gmail.com> wrote:

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

Actually not :-)
Single precision floats have 6 to 9 digits of precision [1] depending how
you convert, so Thomas' example might be losing details even on conforming
readers.
I saved his example to a fiddle and only IE is able to display it:
http://jsfiddle.net/d31nv0sy/1/
Chrome, Safari and Firefox all show a blank page.

Theoretically, you can work around the issue by adding a
'transform=translate(x,y)' to the polygon. Since the intermediate
calculations are supposed to be in double precision, it should work around
the single precision issue. However, it doesn't seem to make a difference.

Thomas, can you control how the SVG is generated? I think you will get more
stable results if you can normalize the coordinate system



1:
http://en.wikipedia.org/wiki/Single-precision_floating-point_format#IEEE_754_single-precision_binary_floating-point_format:_binary32


> 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]*
>>
>