RE: Numerical Limits in SVG coordinates?

Scaling all of the necessary documents by a consistent scale factor may not be a easily implemented option.
Not all the documents are necessarily known/available at one time, when a scale needs to be applied (as this scaling would need to happen downstream from the authoring process in a CAD system, and well after additional business processes have produced additional data files that reference content in the drawings by coordinates).  It is certainly an option, that if scaled, we store some XML metadata in the SVG to indicate the scale factor applied to the SVG diagram coordinates, and then any user of such a document can ensure that all related documents are scaled such that all documents under consideration are at the same scale factor.  That is a work-around I’d have to consider if need be.

For the polygon data – that is the point definitions of the polygon as it comes out of a CGM file.  That the polygon definition explicitly adds the starting point as the ending point, making a final edge 0 length is the way the polygon was defined in the CGM which presumably is the result of some major CAD system exporting its data in that way.

Thomas
--
Thomas Smailus, Ph.D.  P.E.
Boeing Information Technology
thomas.o.smailus@boeing.com

From: Paul LeBeau [mailto:paul.lebeau@gmail.com]
Sent: Monday, February 02, 2015 19:17
To: www-svg
Subject: 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<mailto: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<mailto: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.