Rounding errors

[Martin Andersen]

Often when setting specific values in Inkscape, it actually stores them with some rounding error, eg 12 becomes 11.999994 in the file, or 0 becomes 3.0808689e-15.
If I manually enter 12, I expect it to store 12 in the file.

Transforms are changed into a Matrix, often with rounding errors. For instance:
patternTransform="translate(12,12) scale(0.3557,0.3557)"
becomes
patternTransform="matrix(0.3557,0,0,0.3557,12,11.999994)"
Although visually identical in most cases, with repeated patterns and scaling etc, along with multiple operations, accumulation of rounding errors will mount.
Also it would be more legible, if less compact in some circumstances, to retain the original Transform attributes rather than the difficult to read Matrix.

[Martin Andersen (msandersen)]

Related: Bug#168002

[Martin Andersen (msandersen)]

Also, sometimes entering values into the XML editor, like 40.6, it "corrects" the value to something like 40.599998, and 40.7 becomes 40.700001. Any attempt to enter certain values will always fail getting the exact value due to rounding error. But if I enter, say, 120.6, 120.7, or 120.8, no rounding error. But setting 400.6 gets 400.60001, 400.7 gets 400.70001, and 400.8 gets 400.79999.

[ScislaC (scislac)]

This is a long standing issue that really should be addressed. When you enter a number by hand, the value should not be changed due to a rounding error. Additionally, it end ups affecting precision and unnecessarily inflating file sizes.

[Diederik van Lierop (mail-diedenrezi)]

Hi Martin and Scislac,

Could you try increasing the precision as suggested in bug 168002?

Thanks,

Diederik

[Roanoke (alyosha-be-deactivatedaccount)]

Increasing precision does not work. Why does inkscape even have to round? When a value is written in an input box, it should be taken verbatim, and recorded to the file unadulterated.

[RoyK (roysk)]

Apparently, this is still unsolved, and is easily reproducable on Windows. Haven't managed to reproduce it on OS X or Linux, though.

[SlashDev (slashdev)]

This is really a deal breaker for using InkScape with any precision. I can very easily reproduce this in all Windows versions I've tried (0.48 to the current 0.91 on Windows8). A little searching reveals this has been a problem since 2008.

Most recently, I scaled a 2900x2300 image to fill most of an 8.5"x11" page. Then I tried to place InkScape clones of grouped lines and text, aligned to an original pixel. It acts like snapping, but it's actually a floating-point issue. (Yes, snapping is off. No, working at a larger scale and then scaling down, using smaller grids, or using optimized transforms does not help.)

To reproduce it, start with an empty document. Zoom in to 750% or more, create a line segment and/or text, duplicate it, offset it, group it. Then just move it around the screen. The offset or even length of the segments change. Clones may have different offsets and lengths (see attached). Exiting and re-opening introduces changes.

I am particularly amused by the description in related bug 399776: " a bonus round of inkScape pixel fighting." Scoot, d@^^i+!

[Jonathan Hofinger (jhofinger)]

Hi, someone has opened this issue at Inkscape's new bugtracker on GitLab:
https://gitlab.com/inkscape/inbox/issues/1454

Please direct all further comments there.

Closed by https://gitlab.com/jhofinger