...

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

coordinates?

Changing the source and rebuilding. Actually it shouldn't be that hard to force Inkscape to always choose relative coordinates, but why would you want to? The current behaviour is that Inkscape minimizes the length of the path data.

As for why you would want to - I can give at least one answer to that. I was recently using Inkscape to create SVG images for use in a little shoot-em-up game I was writing. Ultimately I didn't want the complete Inkscape file, I just wanted to extract the SVG for each sprite then move or position them manually.

Relative coordinates mean that it's just the initial move (m) command that needs to change, and everything else moves with it. It makes manually consuming fragments of an SVG file in another context (an HTML5 page in my case) a lot easier.

Mark

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.

...

...

Especially the -113.000006 has me worried a bit,

This was most probably caused by the accumulation of rounding errors when I alternately moved the image with the mouse and by editing the first coordinate in the xml editor.

P.A.

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 - 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.

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.

Forgot to mention that I use Inkscape 0.48.0 r9654, under Kubuntu 10.1, and (not related to this topic), trying to select the File/Document Properties menu crashes my Inkscape).

Thanks again, best wishes, Adrian

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?

...

What you can do is to force Inkscape to use absolute coordinates and convert those to relative coordinates yourself when processing them.

Alright then, if this is the only way then this is it, we'll have to live with this.

The workaround with translating the layer does not work for you? I have added to the layer transform="translate(-1000,-1000)" and increased the preference "Numeric precision" and the coordinates are now allways relative and well rounded.

P.A.

On 22-06-11 21:32, Adrian Dusa wrote:

On Wed, Jun 22, 2011 at 18:01, Jasper van de Gronde <th.v.d.gronde@...226...> wrote:

...

...

...

• 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.

Oh, that's very simple: in my case, I get these values when snapping to grid. Simply, I take a path away from its fixed coordinates, then move it back with snap to grid... my impression was that snapping makes the coordinates exact, but I might not understand very well how it works.

This is interesting. I just did a quick test, and you might be on to something here. I'll take a closer look asap, but you may want to file a bug, including the steps you use to reproduce it at: http://bugs.launchpad.net/inkscape/ That way it won't be forgotten and we can easily track what's happening with this particular bug.

The reason for which I need the shortest possible string is to use it in a webpage via Javascript code. As the number of objects tends to increase as the webpage gets more and more complicated, I am concerned with loading time.

Then in your case I would recommend NOT forcing all coordinates to be relative, and I would definitely not force it to repeat commands, as both (can) make the path data longer. In principle Inkscape's output should be optimal, if it isn't it's a bug. That is, given a certain path Inkscape will give the smallest path string representing that path upto the specified numerical precision (without resorting to some tricks that make the output extremely hard to read).

perhaps we should at one point revisit how we handle dragging with the mouse (and/or zooming). It might make sense to "snap" to more logical values while dragging and/or constraining zoom levels so that the coordinates don't get too weird.

Now I increased the preference "Numeric precision" to value 10 and everything is in most cases OK even if I move the path using the mouse: only the first pair of coorditnates has 10 ciphers, whereas all the following relative coordinates remains integer pixels. But the coordinates *.000001 or *.999999 still occur (even if the coordinates remain relative) if some part of the path is moved outside the left or top edge of the page, although the origin of the layer is translated to (-1000 -1000). But otherwise the workaround with forcing relative coordinates by translating the layer now works fine. (BTW, the entry "Numeric precision" has a misleading tooltip "How many digits to write after the decimal dot", whereas the value evidetly means the total number of valid digits.)