Joining non-end nodes in Inkscape (both through GUI and LPE)
![](https://secure.gravatar.com/avatar/c9deb1c23208b72209fefc58f7c85f5e.jpg?s=120&d=mm&r=g)
Hello,
I am looking for a way to join two (potentially non-end) nodes from different paths into one, so when I move the node both paths are modified accordingly.
I read the manual and I realize that the “Join” feature on Inkscape GUI will only join two end nodes. Is it possible to join two non-end nodes on GUI (to make an “X” with joined intersection node, for example?)
More importantly, I would also like to do this in code, through LPE. For example, if I use Construct Grid LPE, it would be really nice if the output paths join all the intersection together, like what I demonstrate on the right of the following image:
I also noticed that there was a similar idea being proposed a few years back and to my best knowledge I don’t think this feature exists yet. Put it simply, I’d like to know if there is a way to output paths from LPE so that some non-end nodes across different curves are joined. Thank you for your answers.
Regards, _______________________ Papoj "Hua" Thamjaroenporn pt2277@...3110...
![](https://secure.gravatar.com/avatar/b47d036b8f12e712f4960ba78404c3b2.jpg?s=120&d=mm&r=g)
2014-04-28 9:08 GMT+02:00 Papoj Thamjaroenporn <pt2277@...3110...>:
Hello,
I am looking for a way to join two (potentially non-end) nodes from different paths into one, so when I move the node both paths are modified accordingly.
This is currently impossible to represent in SVG without elaborate hacks.
Regards, Krzysztof
![](https://secure.gravatar.com/avatar/516640127f084752aaf5f23c7119f1be.jpg?s=120&d=mm&r=g)
On Tue, 2014-04-29 at 13:47 +0200, Krzysztof Kosiński wrote:
I am looking for a way to join two (potentially non-end) nodes from
different paths into one, so when I move the node both paths are modified accordingly.
This is currently impossible to represent in SVG without elaborate hacks.
I've thought about this issue too since I've had artworks that would have been easier with it. But looking at the svg specification, it's just not built to think of nodes as objects, even storing an index, the nodes last-known position or both, it would get very fiddly to store.
That said, there might be a design that could work in the UI but not reflect in the svg itself.
At the moment when using the node-tool on a group, we ignore the group an automatically drill down to the object under focus. What if when it did this it checked other paths in that same group layer for nodes at that exact point?
The user would do this: select two paths, group them, select one node (currently not possible) from each path and use the align tool to put them in the same place. Or perhaps a button to do that.
The code would do this: selected->path's->group is not selected group. loop through objects in the group and check for nodes that have the exact coordinates of the selected node in the selected path. Moving them all at the same time.
Complications: Move computation time for moving nodes in groups.
Thoughts?
Best Regards, Martin Owens
![](https://secure.gravatar.com/avatar/b47d036b8f12e712f4960ba78404c3b2.jpg?s=120&d=mm&r=g)
2014-04-29 15:26 GMT+02:00 Martin Owens <doctormo@...400...>:
On Tue, 2014-04-29 at 13:47 +0200, Krzysztof Kosiński wrote:
I am looking for a way to join two (potentially non-end) nodes from
different paths into one, so when I move the node both paths are modified accordingly.
This is currently impossible to represent in SVG without elaborate hacks.
I've thought about this issue too since I've had artworks that would have been easier with it. But looking at the svg specification, it's just not built to think of nodes as objects, even storing an index, the nodes last-known position or both, it would get very fiddly to store.
That said, there might be a design that could work in the UI but not reflect in the svg itself.
I think some sort of XML representation is necessary. I'm not really against providing this feature - I'm more worried about the overhead of keeping this inherently node-based information in sync with the path data. Every operation that moves any node in the path or changes the number of nodes would need special handling for those joined nodes.
We already store some index-based information in the sodipodi:nodetypes attribute, but it is strictly local to the path - it only needs to change if the d attribute on the same path changes.
At the moment when using the node-tool on a group, we ignore the group an automatically drill down to the object under focus. What if when it did this it checked other paths in that same group layer for nodes at that exact point?
What about the result of the break nodes operation? It creates two nodes at the exact same point. If the initial subpath is open, the resulting nodes are in different subpaths (though in the same path).
Moreover, in order for this feature to be reasonably general, it should allow you to define arbitrary sets of nodes that move together - not necessarily nodes that lie at the exact same point. I would think of this as "node grouping", with grouping two nodes at the same point being just a special case.
This bug is also relevant. The relative path commands we use by default will cause an accumulation of numerical errors in some cases, which will lead to the nodes no longer being at the exact same point. I'm not even getting into issues with different transformation matrices in effect for different paths... https://bugs.launchpad.net/inkscape/+bug/515237
The user would do this: select two paths, group them, select one node (currently not possible) from each path and use the align tool to put them in the same place. Or perhaps a button to do that.
The existing "join nodes" button would be more suitable I think, if we ever introduce that, or the existing "Group" action. I'm not sure how to represent grouped nodes in the UI though.
The code would do this: selected->path's->group is not selected group. loop through objects in the group and check for nodes that have the exact coordinates of the selected node in the selected path. Moving them all at the same time.
This requires converting each path in the group to node representation at least once during each motion event. This would be prohibitively expensive for groups that contain several large paths (e.g. 5000 nodes). We could work around that by caching the node representation in the relevant SPObject though.
Regards, Krzysztof
participants (3)
-
Krzysztof Kosiński
-
Martin Owens
-
Papoj Thamjaroenporn