Re: Numerical Limits in SVG coordinates?

Thomas, if all your source documents have the same scale, then scaling them
all by some consistent scale factor shouldn't be a problem should it?  I am
assuming the values in your original SVG are in the base units of your CAD
software? For example, if you use 10e-4 you would effectively keep your
original values and avoid any significant rounding errors.

Also, your converter seems to have a bug!  The oval polygon goes over the
same path twice, which is the reason the fill is not showing.

Cheers

Paul

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
                "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" xmlns="http://www.w3.org/2000/svg"
                xmlns:xlink="http://www.w3.org/1999/xlink"
                viewBox="-54750.2416 -8589.934592 274782.8928
231928.233984" preserveAspectRatio="xMidYMid" xml:space="preserve"
                zoomAndPan="magnify" onload="diagramOnLoad(evt)" >
<desc>

Test Diagram - testing SVG rendering in very large coordinate space

</desc>
<rect id='mouseCapRect' x='-5550408.0976' y='-4647154.614272'
width='11266098.6048' height='9509057.593344' fill='green' opacity='0' />

<g id="cgm-objects" transform="scale(1,-1) translate(0,-117177.3184)">


<polygon stroke-width="200" id="igA14" stroke="rgb(0,0,0)"
fill="rgb(0,0,0)"  points="31054.1760,51998.0416 30807.3568,52116.7104
30542.1696,52198.5888 30260.9472,52243.1136 29966.1152,52250.1280
29660.0416,52219.8240 29345.1040,52152.6720 29023.5904,52049.3664
28697.8880,51910.8512 28370.2976,51738.2432 28043.2032,51532.9216
27719.0752,51296.5248 27400.2048,51030.8128 27088.9472,50737.8016
26787.5904,50419.6928 26498.4128,50078.9312 26223.5568,49718.0672
25965.0032,49339.7248 25724.8496,48946.9856 25504.6832,48542.4544
25306.3344,48129.4880 25131.2240,47711.0176 24980.6704,47290.1792
24855.8400,46870.1504 24757.6864,46454.0768 24686.9856,46045.0880
24644.2944,45646.1088 24630.0000,45260.2240 24644.2896,44890.2080
24687.1600,44538.8192 24758.4144,44208.7488 24857.7120,43902.3648
24984.4720,43622.1376 25137.9488,43370.2720 25317.0736,43148.9920
25520.5840,42960.2080 25746.7264,42805.7728 25993.5392,42687.0912
26258.7344,42605.2096 26539.9472,42560.6752 26834.7744,42553.6544
27140.8512,42583.9488 27455.7856,42651.0944 27777.2928,42754.3968
28103.0080,42892.9088 28430.6336,43065.5296 28757.6384,43270.7904
29081.8144,43507.2128 29400.6848,43772.9184 29711.9456,44065.9232
30013.3024,44384.0320 30302.4928,44724.8000 30577.3280,45085.6288
30835.8720,45463.9584 31076.0960,45856.7904 31296.2080,46261.2160
31494.5728,46674.2208 31669.6928,47092.6816 31820.2496,47513.5264
31945.0880,47933.5488 32043.2416,48349.6000 32113.9520,48758.6336
32156.6496,49157.5968 32170.9472,49543.4784 32156.6624,49913.5040
32113.7952,50264.8928 32042.5472,50594.9728 31943.2544,50901.3600
31816.4960,51181.6032 31663.0496,51433.4304 31483.8880,51654.7744
31280.4224,51843.5232 31054.1760,51998.0416 "  />


</g>

<script type="text/ecmascript"><![CDATA[
// diagram specific initialization
function diagramOnLoad(evt) {

                // do nothing
}
]]></script>
</svg>


On 3 February 2015 at 14:41, 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.
>
> 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.
>
> ABR
>
> 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.
>>
>>
>