On Fri, 2015-05-08 at 19:45 +0200, Krzysztof Kosiński wrote:
2015-05-08 18:04 GMT+02:00 Tavmjong Bah <tavmjong@...8...>:
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).
I can do some more work on Geom::SVGPathWriter so that it can be configured to do these things.
Excellent
The export filter could be implemented as a visitor that creates a separate XML document and populates it by calling write() method on the SP tree. I'll look into this before changing over to full precision.
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.
Right now I 'snap' the final node to the initial node of the path when the initial moveto or the last segment before 'z' is given in relative coordinates. If both are given in absolute coordinates, they will maintain exact coincidence despite rounding and therefore no snapping is required.
Even when we move to extended 'z', the mandatory linear closing segment remains useful, because it ensures that the size of range begin(), end_closed() is equal to the number of nodes, i.e. there are as many nodes in the path as there are segments between begin(), end_closed(). I will probably exploit this when adding node-centric path operations to 2Geom. These operations are interactive, so they can be O(N) since rendering is also at the very least O(N).
OK, but we need to be careful about how markers are drawn. Having or not having a small closing segment can effect which markers are drawn where.
PS: should the path parser in 2Geom have SVG 1.1 and SVG 2 versions, or just a single version that accepts everything? Is it useful to report errors for SVG 2 commands that are not in SVG 1.1?
Just one version. It would be useful to report errors. There are a couple of new path commands 'r' and 'b' but I doubt anybody will implement them soon.
Tav