On Fri, 2015-05-08 at 07:17 +0200, Krzysztof Kosiński wrote:
The 2Geom sync is almost done. So far I have identified two problem areas.
2Geom is now a lot more strict about what it considers a degenerate closing segment - it requires exact equality of endpoints, not just nearness to some arbitrary precision. This is of particular importance in paths where the last segment is curved. Because Inkscape loses precision when storing paths, bug #515237 now manifests on every closed path with a non-linear last segment.
https://bugs.launchpad.net/inkscape/+bug/515237
I intend to fix this in the following way: first, modify SVGPathParser so that it knows whether the last segment before 'z' was relative, and if it is, snap it to the final node with a precision set by another function call, 1e-6 by default; second, by making Inkscape output paths with the double-conversion library now integrated in 2Geom and always using absolute coordinates, so that there is perfect roundtrip between XML and internal representation. This will mean the removal of the Output Precision setting and a moderate increase in file sizes. The proper place for such functionality is in a separate export filter. As a bonus, setting the document unit to metres will no longer cause a variety of issues.
We discussed output precision briefly on the hackfest. Moving to full precision output with perfect roundtrip is the only correct solution and will enable us to avoid excessive recomputation of attributes in the SP tree, which is a performance win. If someone wants to get rid of extra precision - use an export filter. However, if anyone has a different opinion please speak up now.
It's not clear to me what the plan is for enabling an export filter. We definitely need to offer our users the ability to limit the precision of the output so before we store double precision numbers we need to have this output filter in place. In addition, the ability to save as relative coordinates is important (I use it all the time and it has been requested by others; on the other hand, saving mixed absolute and relative coordinates to save a few bytes is probably not very useful).
Recall, the SVG 2 spec now allows 'z' to fill in missing points at the end of the path with the value of the first point so there is no need to create a 'zero' length line segment to close a path due to rounding errors. We should be able to parse this right away. Writing out this way should probably wait until the other renderers have caught up.
Tav