Impreciseness when rewriting an SVG file with `usvg`.

[Doublonmousse]

There is a difference between the svg before and after the simplification (some paths are longer, some elements are slightly larger). It's probably not the most beautiful svg out there, but I'm not sure where the problem is (clip-path="url(#clip-0)" attributes ? ClipPath element ? The very numerous use elements ?)

Comparison in firefox (left is original, right is after usvg)

Options used for the call are here :

https://github.com/flxzt/rnote/blob/2ef66c5000c8ab4577ee2c2a73d2c6b5c3316d06/crates/rnote-engine/src/strokes/vectorimage.rs#L148-L164

After:

Before:

[LaurenzV]

Seems like your coordinates/transform precision is too low. I tried with 3 and 4 like you do and get the same, if I up both to 8 (like in the usvg CLI) it looks fine. I guess your SVG has some weird transforms or coordinates that are really small where each decimal place matters.

[Doublonmousse]

Mh ... Is this expected ? From the doc it is (smaller precision => malformed output possible)

So the precision is set on the coordinates and transforms separately but it's not "normalized" (meaning you can't have a "I want a precision to the i-th decimal on the final coordinate" option).

I feel like the SVG being weird is probably the answer there, though I'm kinda surprised the transform/coordinates could be so unbalanced numerically. If you think it's worth having something in usvg to re balance things like that (or have a precision on the end coordinate), maybe I can turn this issue into a feature request.

Otherwise, we can close this

[LaurenzV]

Yeah, I'm not entirely sure either, perhaps there is something we can do about it. We would have to investigate the root cause. But in any case, at least there is an easy way to work around it. :)

Thought I should mention that the usvg simplification part isn't well-tested at all, we usually just use it as a debugging tool to understand how usvg interprets a certain SVG.

But we can leave the issue open for now.