Are you subscribed to the inkscape-devel list? Let's move our discussion there, because many people will be interested in your code.

the code is "borrowed" from the sp_path_selected_combine(), and there's a check on the number of elements in the selection (looks like it, at least).

It only checks that there are at least two objects selected:

if (g_slist_length (il) < 2) return;

So we need to fix it for the case when there are more than two. If you can make intersect and union functions accept any number of objects in one go, that would be the best. And for difference functions, we need to check that there are exactly two objects selected, and complain if not (for now you can just print a g_warning and do nothing).

...

Inset and offset, although very very useful, are unfortunately more buggy. When you do them repeatedly, the number of nodes grows very fast, and soon

oops... yes the number will grow fast (exponentially). isn't there already a function to cleanup a path in sodipodi?

None that I know of.

i recall seing somewhere discussion on how

to simplify a path... besides it's just a lame approximation of the offset, there's probably wiser algorithms (that i do not konw about)

You can discuss this on the list with people who have much better knowledge of algorithms than I, such as Nathan Hurst.

well, the soutline/offset/inset algorithm is quite stupid: build an offset path, and treat it like a polygon. the "difficulty" lies in building the offset path. the code is still rough, and doesn't like null segments in the path, path with multiple subpath, closed paths, etc... i have to admit it hasn't been tested thoroughly; just outlining a path twice as you suggested brought up a number of serious problems i'll have to investigate. on top of that, the result of the offset is transformed in a svg path description (so if d="", it means the algorithm completely failed), and the precision used to store the coordinates in the d attribute seems insufficient.

We plan to increase it from 6 digits to at least 8. Do you think 8 will be enough for you?

technically, coordinates are rounded to a 1/32 grid by the code in livarot; dumping the path with less precision in the xml tree can cause ugly things. the cusps you mentioned are usually small segments making sharp turns because coordinates were rounded. using a round or bevel join "removes" them (btw, how do you set the miter limit in inkscape?)

I don't think setting meter limit is implemented. Anyone?

I think now the best course of action is this. I'll ask Bryce to give you access to the CVS so you could create a branch for testing and development of the new commands. You will store the entire Inkscape tree there, so that people would be able to checkout and test it without patching. To hook up your commands to the menu and as shortcuts, I did a simplistic patch, which I will now upload to the Inkscape tracker along with your updated patch; you can use my patch as a starting point.

_________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963