Ok, that's another vote for using double precision everywhere. That gets us 14-15 digits, which should be enough for anybody.
njh
On Thu, Sep 11, 2014 at 09:43:03AM -0700, mathog wrote:
On 11-Sep-2014 07:50, LucaDC wrote:
Let's say that, at least, I expect all input integers to be stored as integers in the file.
Unfortunately that often turns to be impossible. Any transform in the object path can change a "10" into a float like "4.2452... , which has no exact binary representation. The transform math is with floats, so on a 32 bit system there are only ~7 digits of precision. Every time the value is transformed, a little more precision is lost. However, there are transforms, and then there are transforms. If the initial coordinates entered into an object for some length never change, then the final coordinate is just the result of multiplying all the transforms above it and then applying the final combined transform to those coordinates. If the pixel (internal unit) to units (external units) conversion is accomplished by a single transform at the viewbox stage, then changing the units from mm to inches, and back, need not degrade the precision of the internals of the drawing. Just that transform is modified, and the internal coordinates never change. Doing it that way, it would be possible to change from pixels, to pixels->mm, to pixels->in, then back to just pixels, and end up with exactly the same document as when you started. That is not the case with Inkscape at present though, because at each change code runs through the entire document modifying all of the coordinates and lengths, and this degrades the precision at each conversion.
As an aside in some very special instances it is possible to check for this sort of precision problem and snap the units back to what they should be. For instance, in EMF import clipping there is an "exclude clip operation". SVG doesn't have an exact equivalent, so the clip is emulated by drawing a huge square with the four corners at {+-faraway,+-faraway}, where "faraway" is a very large integer which should be outside any sane drawing, and then the actual clip path in the opposite direction within it. This makes a subtractive clipping object. At present "faraway" is 10000000 - pixels. Later in the import process the entire image is scaled to produce an SVG drawing in mm, and this slightly reduces the precision of the "faraway" corners. If the image is then emitted back to EMF the output driver sees coordinates like 9999823 (made up number, something like that). In this case though the code looks for coordinates that are within a rounding error of {+-faraway,+-faraway} and snaps them to that exact value. This allows clipped drawings to be read in and written out by inkscape from/to EMF without the values wandering.
In general though, there is no way of knowing what any coordinate {x,y} is supposed to be with absolute precision, so no way to correct back to those exact values. This is why Inkscape should do everything it can to NOT change the base lengths and coordinates within the document when it changes the document units. Instead it does exactly the opposite.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel