Add option for rounding to set number of decimals

[mrmeszaros]

Fixes #141

[Ede123]

I'm still mulling over this. In general I'm not opposed, but it has the potential to break images if used wrongly (which the existing precision option usually does not!) and on top of that it will be confusing for people to have two separate options to control numeric precision.

I might consider accepting it as an "interim solution" until we can come up with something that ticks all checkboxes, i.e. is user-friendly, ensures image quality and achieves smallest file size.

A "proper" fix likely would be what I suggested in https://github.com/scour-project/scour/issues/141#issuecomment-282844930, as I ensures precision matches the size of objects, but it will be a bit more work to implement (also as absolute coordinates would probably need to be treated differently from relative coordinates).

In any case the MR can't be accepted as-is, as it's currently rounding the numbers on import. That means numeric errors will be "amplified" while processing the file (and doing things like applying transforms, etc.). Instead any rounding needs to be done at the very end of all processing when writing out the numbers as a string.

[mrmeszaros]

Hey, thanks for the review!

I totally agree, rounding / precision should be done on output, and not on import.

I will try to look into how it can be implemented. If you have any ideas, please share :)

[codeling]

I would really like such an "absolute precision" mode (i.e. being able to determine how many digits after the comma the result has). For me it makes more sense than the current mode, which I would call "relative precision".

For positions in the current, "relative" precision mode it depends where in the image a coordinate is to determine its actual precision in the output. Let me give an example of what I mean:

• "precision" set to 3
• some object a at position 100.123, 100.123 -> shortened to 100, 100 (meaning also that some object b at 100.4, 100.4 would be "shifted" to be at exactly the same position as a)
• another box at position 0.123, 0.123 -> remains at 0.123, 0.123 (and in contrast to the case above, an object at 0.4, 0.4, so with the same offset as b has to a above, would remain at its distinct position and not be "shifted" to the same position) So in the current mode, positions closer to the origin (with less digits before the comma) are stored with much higher overall precision in the output!

As this examples below show, this has the potential to introduce different look of regions in the resulting images depending on where in the image objects are positioned!.

Example .svg file:

<svg version="1.1" viewBox="0 0 101 101" xmlns="http://www.w3.org/2000/svg">
 <g fill="#444">
  <rect x=".123" y=".123" width=".2" height=".2"/>
  <rect x=".4" y=".4" width=".2" height=".2"/>
  <rect x="100.123" y="100.123" width=".2" height=".2"/>
  <rect x="100.4" y="100.4" width=".2" height=".2"/>
 </g>
</svg>

Output (produced using Inkscape 1.2.2 with Scour "0.31+", as far as I understand the settings regarding precision haven't changed since?):

<svg version="1.1" viewBox="0 0 101 101" xmlns="http://www.w3.org/2000/svg">
 <g fill="#444">
  <rect x=".123" y=".123" width=".2" height=".2"/>
  <rect x=".4" y=".4" width=".2" height=".2"/>
  <rect x="100" y="100" width=".2" height=".2"/>
  <rect x="100" y="100" width=".2" height=".2"/>
 </g>
</svg>

As you can see, the two rects close to the origin are really well-preserved; but the two rects at 100.x are moved over one another!

In contrast, if there was an option for a fixed number of decimal points, the output would look like this (for e.g. 1 digits after comma):

<svg version="1.1" viewBox="0 0 101 101" xmlns="http://www.w3.org/2000/svg">
 <g fill="#444">
  <rect x=".1" y=".1" width=".2" height=".2"/>
  <rect x=".4" y=".4" width=".2" height=".2"/>
  <rect x="100.1" y="100.1" width=".2" height=".2"/>
  <rect x="100.4" y="100.4" width=".2" height=".2"/>
 </g>
</svg>

Which would use a little more space than above of course, but would be much more consistent: The distance between to rect 1 and 2 would be the same as the distance between rect 3 and 4, instead of 3 and 4 being moved to exactly the same coordinates!

Where it could make sense in my opinion to use a "relative precision" (i.e. significant digits overall) is for encoding length; but even then the "environment" has to be taken into account; for example:

• If you show two bars, one of length 100.1 and 110.2, then the .1 and .2 don't matter in how the relative lengths of these two bars are perceived by viewers, even more so if they are placed apart or are not starting at the same position in the direction in which they have these lengths.
• If in contrast they are again of length 100.1 and 100.2, are starting at the same position, and are positioned right next to one another, then viewers can just notice this slight difference, and removing it would cause the "meaning" of the figure to change.

EDIT: Just saw that somebody else has made the same point over in that issue already!