On 22-06-11 16:02, Adrian Dusa wrote:
Dear all,
Jasper van de Gronde wrote:
On 21-06-11 18:54, A. da Mek wrote:
...
(BTW, the the length of the path data would be better minimized were the coordinates smartly rounded instead of such values as -113.000006 or -12.99999)
Especially the -113.000006 has me worried a bit, is it from an actual path?
...
First, sorry for not responding sooner, I must have forgotten my deilvery to digest mode (so I only saw all your messages in a batch). Thanks for all the answers, it seems that both issues are important:
- no matter if I change the path with the mouse or with the keys, the XML
still gets relative and absolute coordinates
In principle this is to be expected, Inkscape decide on what to use no earlier than writing out the path data and can switch many times within a path. This is by design. I understand that in some cases it might be interesting to use relative coordinates everywhere, because of further processing, but at this point Inkscape doesn't have an option for this.
What you can do is to force Inkscape to use absolute coordinates and convert those to relative coordinates yourself when processing them. Also
- indeed, many times I get values like "113.000006" (in which case I am
manually editing my path -- counterproductive) or perhaps even more confusing values such as "4.35838e-5"... which is practically equal to zero.
Without knowing exactly how such values are produced it is hard to tell where the problem lies, but such values are not uncommon, nor unexpected. Basically there is no way for Inkscape to know that you did not actually mean to have such values.
Put differently, somehow these values arose by editing the SVG and when it becomes time to save them, how is Inkscape supposed to know you really meant 113 or 0 instead of 113.000006 and 4.35838e-5?
Of course Inkscape does round to the specified precision, which usually helps quite a bit, but in some cases this is simply not enough. Personally I think it might make sense to revisit Inkscape's default zoom levels, as it does make some "unfortunate" choices with regard to "strange" coordinates, and it might be possible to tweak its rounding just a bit, but fundamentally the problem will stay. If you have any ideas for making Inkscape "smarter" in this regard I'd love to hear them.
Setting the numerical precision to 4 seems to have solved the second (will keep you posted if otherwise), but the first I think remains a mistery for me. As specified before, relative coordinates almost always produce a shorter string than absolute coordinates, and I would be grateful if this could be solved.
I'm not entirely sure what should be "solved". Currently Inkscape's behaviour is optimal from a size-reduction point-of-view, and that is by design. The value of 113.000006 may look odd, but without knowing exactly how it arose it could very well be "legitimate" (in the sense that that value actually did arise during editing and Inkscape properly encoded in the path data). So how would you like Inkscape's behaviour to be changed?