Preferences: numeric precision tooltip error.

[su_v]

previously reported in a comment to bug #399604:

Strange things happen when using these low precision values. First tests (numericprecision=1) show e.g.
- objects can not be placed at will on canvas
- dragging them snaps to seemingly random positions (all snap modes disabled)
- using the 'Align and Distribute…' dialog doesn't align the objects correctly or only after applying the command repeatedly
- Circles converted to path get deformed unevenly
- …

sample drawing attached to bug #399604:
<http://launchpadlibrarian.net/33321863/drawing-22435-precision1.svg>

What exactly is supposed to happen when using a lower numeric precision?

As a user I would assume that this setting doesn't influence the behavior of objects on canvas but only affects the SVG output - i.e. the precision (0.02 instead of 0.0198567) of coordinates and lengths written to the SVG file.

The current tooltip to the preference setting 'how many digits to write after the decimal dot' needs to be updated if this isn't unexpected but consequential behavior of operations translating or resizing objects when the numeric precision is lowered to its minimum.

Note: I have not systematically tested the consequences of using a lower SVG output precision value nor did I search the archives for known issues already reported or discussed on the inkscape-devel mailing list.

[jazzynico (jazzynico)]

Everything confirmed on Ubuntu 9.10, Inkscape bzr rev. 9401.

What about "Significant figures of the values written to the SVG file" for the tooltip?

[su_v (suv-lp)]

Do you have an example how defining the significant figures would be useful to merit its own preference? (/me has to admit partial failure in reading <http://en.wikipedia.org/wiki/Significant_figures> and trying to fully understand the meaning of 'significant figures' and the consequences of changing their number for SVG output).

> "Significant figures of the values written to the SVG file"
Much better - but maybe the tooltip could also mention explicitly that 'Numeric precision:' does not limit the number of decimal places (fractional digits)? The difference between rounding to significant digits or decimal places as laid out in <http://en.wikipedia.org/wiki/Arithmetic_precision> might be obvious to developers or mathematicians but not to the average user ;)

Another question: What happens if the user has chosen a different base unit for the document? I figure the setting is for SVG user units (px) as stored in the SVG file - without refreshing my basic math skills I wonder if the user-expected result when for example using 'm' as default units would be different?

[jazzynico (jazzynico)]

Even if you use a user defined unit, the value is converted to pixels in the SVG. And thus we have the same behavior.

[su_v (suv-lp)]

> Even if you use a user defined unit, the value is converted to pixels in the SVG.
I'm aware of that. My question is: would the range of values for units in meters (as used in the GUI and visible to the user) not differ (in precision) from the range of values using the same number of significant digits for 'px'? The conversion to px is not transparent and many users are not aware that it takes place regardless of the document default unit setting.

[su_v (suv-lp)]

Nevermind the question (if at all it should be discussed elsewhere I guess) - I'm fine with your proposed text: imho this bug can be closed if the tool tip is changed to "Significant figures of the values written to the SVG file".

[jazzynico (jazzynico)]

New tooltip text committed in bzr revision 9403.
But it doesn't fix the transform and align part of this report...

[su_v (suv-lp)]

> But it doesn't fix the transform and align part of this report...
AFAIU now that's to be expected because when reducing the number of significant digits to 1, the values of the new coordinates will deviate to a much greater degree from the original value before rounding the calculated new position to 1 significant figure - as opposed to rounding to 1 fractional digit. Hence my question in comment #2 about "how defining the significant figures would be useful to merit its own preference".

[jazzynico (jazzynico)]

Renaming and closing this bug "Fix committed".

The transform and align part is probably a normal behavior, and mainly depends on the object size and zoom level (I've reproduced this behavior with numericprecision=4, zoom=25600% and very tiny objects).