inconsistent decimal precision

[Christina Palmer]

Under Document Properties, with grid units set to Inches, grid spacing precision is limited to 4 decimal places, which makes working with designs for small parts difficult, as grids of 1/32" (.03125") or smaller fractional powers of 2 require more than 4 decimal places of precision. Grid spacing can be entered with higher precision via the XML editor, but the Document Properties UI should use the precision specified in "SVG output numeric precision", or some other defined constant, rather than being limited to 4 decimal places. This precision should apply to all objects, guides, grids, etc.

Forcing trailing zeros on decimal numbers makes for more tedious editing, as the zeros have to be deleted to make room for other digits. Numbers should be represented without trailing zeros. (eg 0.5 vs 0.5000 or 0.50000000) This ties into the decimal place precision limitation. Perhaps the numeric entry fields could behave differently, and accept values of any precision, to be reduced to the precision specified in the constant as suggested in the previous paragraph.

[su_v (suv-lp)]

Christina Palmer wrote:
> the Document Properties UI should use the precision specified
> in "SVG output numeric precision"

This is a misunderstanding of the 'Numeric precision' setting for SVG Output: it defines the numbers of significant digits, not the number of decimal places (as is described in the tooltip of the setting) [1]. The numeric precision used for storing SVG data is not related to the number of decimal places in the GUI entry fields. Otherwise the workaround I showed you in the related Inkscape forum topic (using the XML Editor to enter more precise numbers for the grid spacing) would not work.

Related earlier requests (due to which the number of decimal places in the grid GUI was raised from 2 to current 4):
Bug #168574 “Grid setup truncate significant figures”
Bug #168689 “Grid and Guide precision”

Christina Palmer wrote:
> grid spacing precision is limited to 4 decimal places, which makes
> working with designs for small parts difficult

Basically what is happening here is precisely what a lead developer predicted in
Bug #166474 “4 digits precision for grid offset not enough?” (comment #1 ff)

<quote>
Why do you need the 5-digit precision for this? As you
understand we have to put a limit somewhere. If I make it 5
digits someone will complain that it's not 6, etc :)
</quote>

[1] <http://en.wikipedia.org/wiki/Significant_figures>
    <http://en.wikipedia.org/wiki/Arithmetic_precision>

[su_v (suv-lp)]

Testing and comparing current stable (0.48.1) and the development branch of Inkscape:

The new spinboxes in the development version which include a basic expression evaluator (see bug #171282) apparently allow to enter a larger number of decimal places e.g. for the grid spacing, and store the entered value as is in the SVG source as long as the input is confirmed with <Enter>. Tabbing through the spinboxes/entry fields however will still truncate the the numbers in the SVG source to the 4 decimal places used in the GUI (as described in the discussion of previously mentioned bug #166474).

[Christina Palmer (morsel-elvencraft)]

OK, so the limitation is in the input UI. Why can't we have our cake, and eat it, too? The notion of too many digits hurting usability is wrong. As long as trailing zeros are not displayed, and the user is allowed to choose how many digits they desire to see, there should be no problem with permitting more digits to be input.

When drawing tiny objects on a scale of small fractions of an inch, many decimal places are necessary to represent the size accurately. A 1/256" object requires 8 digits: .00390625"

Perhaps SVG output numeric precision is not the right constant, in which case there should be another constant which controls how many decimal places of precision all input values are displayed as, but it should not restrict how many decimal places may be typed in, regardless of what is displayed. Show users a conveniently rounded off value per their specified preference, but don't prevent them from entering accurate values in the UI.

Alain-knaff in Bug 166474 wrote: "My problem is not so much that it doesn't _display_ the full range, but that it doesn't allow to _enter_ the full range. Entering precise numbers should always be possible."

[Christina Palmer (morsel-elvencraft)]

Post 3 was typed before seeing post 2.