Re: Numerical Limits in SVG coordinates?

Hi,

The cases which surely needs the effective digit number (8 or more) exceeding a short precision floating point number are in a map or large-scale CAD data.

As Amelia showed, on F2F of the past, we discussed about it.
> http://www.w3.org/2013/11/14-svg-minutes.html#item01

However, since I still recognized the issue on that conclusion, I investigated how to solve it, considering restrictions of GPU or graphics libraries.  And we discussed about it on TPAC F2F last year.

The following is wiki which described that method.
https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Better_CTM_Computation
It is like tiling or segmentation. The proposal for realizing this, tests and polyfills are also included.

The minutes are this.
http://www.w3.org/2014/10/31-svg-minutes.html#item02

Regars,

Satoru Takagi

> On Mon, Feb 2, 2015 at 5:41 PM, Amelia Bellamy-Royds <
> amelia.bellamy.royds@gmail.com> wrote:
> 
> > Ooops!  That's what I get for whipping up an answer without actually
> > testing anything...  Thanks for checking Rik.
> >
> > I didn't look closely to see how small the deltas were compared to the
> > magnitude in the shape coordinates.   I looked at the viewBox, and thought
> > the overall coordinate system dimensions to absolute value was still
> > reasonable enough that the lower-precision digits wouldn't be significant.
> > I didn't factor in the transform on the shape.
> >
> 
> There's actually enough of a delta that it should still display.
> I suspect that the problem is somewhere in the logic that deals with the
> viewbox.
> 
> 
> > For Thomas, this clearly wasn't the answer you wanted to hear, but a
> > normalization process is definitely going to be necessary.  You'll need to
> > figure out a way to store the information about that conversion process
> > (and the original coordinates) in metadata, and access it when necessary to
> > align multiple drawings.
> >
> 
> This issue was also noticed by the engineers at KDDI who were using SVG to
> draw maps. When they didn't normalize the paths and expressed them in
> "world" coordinates, graphics were drawn with low precision.
> 
> FWIW in PDF we work around this issue by emitting a translate to the first
> coordinate of a path. Then the path coordinates become smaller and the
> shape is high precision.
> 
> 
> > On 2 February 2015 at 18:12, Rik Cabanier <cabanier@gmail.com> wrote:
> >>
> >>
> >> 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.
> >>
> >>
> >
> 
> 
> 
>

Received on Tuesday, 3 February 2015 09:44:33 UTC