In response to the original question (forcing Inkscape to use relative coordinates): if anyone wants to change Inkscape's behaviour, the relevant code is in src/svg/path-string.cpp, if you need help changing it, just mail me. (Otherwise, I *may* get around to adding an option myself, but it could take quite a while.)

On 21-06-11 13:13, A. da Mek wrote:

...

...

What would be the best way of forcing the path to (always) relative coordinates?

...

The current behaviour is that Inkscape minimizes the length of the path data.

How can the choice of absolute or relative coordinates affect the length of the path data?

Suppose you have a line from 10,10 to 12,13 then "M 10,10 L 12,13" is longer than "m 10,10 l 2,3". When you have very complex paths this can matter quite a bit. In addition Inkscape leaves out the commands whenever it can, to save even more. It could save still more by doing things like removing white space where possible and such, but that makes the path data really a lot less "readable" and offers relatively little in terms of size reduction.

It is so that the absolute coordinates are used when the node is nearer to the origin than to the previous node?

It is actually a bit more complicated. It uses a technique called dynamic programming to decide on a GLOBALLY optimal strategy. So it can pick the longer alternative locally if that means the complete string will get smaller.

Then maybe translate the layer at least of one page width to left and page height to top, and all coordinates should be relative. But when I tried to test this idea, I found that the coordinates are allways relative if the preference"allow relative coordinates" is checked. I thought that this behavior maybe changed in a newer version, so I upgraded from 0.47 to 0.48.1, but still all coordinates are allways relative.

I'm not entirely sure what you mean. If you think you have found a case where Inkscape makes the "wrong" decision (that is, it outputs a longer string than necessary), that would be a bug and I'd love to hear about it. If you're seeing it mostly choose relative coordinates, that is because it favors relative coordinates when all things are equal (this tends to avoid switching between the two, as relative coordinates are hardly ever worse than absolute coordinates).

(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)

If you see things like that there can be a number of things going on. One problem is that Inkscape (currently) has to write out values in the decimal number system while internally it uses binary numbers (of course). This leads to a whole host of problems, not the least of which is cases like the ones you give (although generally integers aren't a big problem, so that's a bit weird).

Then there is the problem that as you move things around (or even place things) Inkscape works with limited precision and errors might accumulate. When the error gets large enough you can get numbers like the ones you give. Inkscape does round the numbers it writes out though, and you can control that through the preferences. Making numbers "snap" to integers when they deviate from an integer by more than the allowed tolerance is problematic at best.

Now, unfortunately you do not give the full path in which you see these numbers appearing, but if these are from relative coordinates then there is a good chance that it is a bug. Suppose that you have set Inkscape to use only 4 digits, and you have a line from 1200.2,0 to 1210.4,0. Using absolute coordinates this would be "M 1200,0 L 1210,0". Using relative coordinates this SHOULD become "m 1200,0 l 10,0", and NOT "m 1200,0 l 10.4,0", and Inkscape does have code to deal with this. So if it does not act like this, then you have found a bug and I'd love to know about it.

Especially the -113.000006 has me worried a bit, is it from an actual path? If so, can you please send me the full path data? There is a chance that it is legitimate (again, Inkscape can make a locally suboptimal choice if that ultimately leads to a smaller string), but it does not happen that often, so I'd like to see what happened here.