Hi Friends,
I've been using the Paint Bucket tool a lot lately, and notice a really annoying, and imo inappropriate pattern in the type and placement of nodes on paths created with this tool . I recently posted a similar and related topic (how is the type of node determined). This one is specifically about nodes/paths created by the paint bucket tool, and sufficiently different that I think a new topic is needed. Also though, I'm thinking of making a bug report, if there is any agreement that it is needed.
And I'll start right off by saying that I suspect the reason these nodes are as they are, is a natural result of the innate nature of the paint bucket tool, and I may well learn here that nothing can be done about it. But I think it might be worth documenting, in any case.
In some cases, I find the nodes created by the paint bucket tool to be entirely appropriate -- especially when the area to be filled is straight-forward and uncomplicated, something resembling a square, for example. But in most cases I find myself needing to use this tool for oddly shaped areas. I guess I can't really say the node type and placement seems entirely randomly determined, because I do see patterns. It's just that the type and/or placement of the nodes, often is entirely inappropriate. I have several sample images to illustrate this.
As you may notice, these samples are from a Spirograph Effect project I've been working on. (In case it matters.)
1. In the corners of the red-filled area, with purple and blue circle indicators, and even in the corner with no additional indicators, please notice how the corners have been assigned smooth nodes. I would estimate at least 75% of the shapes I've filled in this project, with the PB tool, have smooth nodes assigned to corner positions (maybe more). I would suggest that while assigning nodes to the corner positions is appropriate, the use of smooth nodes in corners is inappropriate.
2. In the corner where I've circled 3 nodes in green, you can see that they are all cusp or corner nodes. This shows that sometimes, both the type and placement of nodes is appropriate, as in this corner node. Although I would estimate this happens in 10% or less of the paths.
3. Also in the green circle, please notice how the 2 nodes closest to the corner are also cusp. Since the segments defining that corner are smooth and gently curving, I would suggest that those nodes should be smooth. In this particular project, cusp nodes have been assigned to smoothly curving paths, I would estimate, in about 20% of the paths I've created with the PB tool.
In these next samples, you'll see additional examples of the above, plus the following additional details.
4. Please notice here that a corner, albeit quite an obtuse angle, still a corner, has not been assigned a node at all. I estimate that there are no nodes placed in corner positions in about 30% of paths I've made with the PB tool, in this project. Although I don't have an example to show, it's not just obtuse angles which are denied nodes. Often as not, very acute angles don't get a node either.
5. Also please notice, along the path and just to the left of where the missing node should be (in the selected path), there's a small gray dot. (It's very hard to see.) This is what one normally sees in Inkscape, where there is one node directly on top of another node. In this project, every time there are 2 nodes sharing the exact same space, they are always cusp nodes. Also in every case, each cusp node has one handle retracted -- one has the left handle retracted, and the other the right handle is retracted. Most of the time I see this in paths similar to the image below, in acutely angled corners, rather than in this obtusely angled corner or in paths with less severely angled corners (like the red one in the 1st example).
6. In the above image is another example of a smooth node with a corner placement. Also it shows another gray dot indicating 2 nodes are there. In the image from which I've taken these examples, it's quite common to see this arrangement of nodes, in this particular shape of path. Typically there is an acutely angled corner (almost always with a smooth node) with a pair of overlapping nodes near the corner.
And I'm not sure which is more interesting -- that the PB tool creates paths with 2 overlapping nodes, each with a handle retracted, rather than just one node with no handles retracted; OR that this pair of overlapping nodes typically appears on a smooth, gently curving segment, near an acute corner (althought not always near an acute corner).
And in this final example (below) almost every issue I've reported here appears in one small area. The only issue it doesn't show is a cusp node assigned to a smooth, gently curving segment. There's nothing new to see here, just to reinforce the issues I've described, in another part of this spirogram project.
So I guess my questions are:
-- Is this behavior by the Paint Bucket tool ( ) of assigning (what I think are) inappropriate node types and placements, normal or expected?
-- Or is it a bug?
-- Can this be fixed, or is it unavoidable innate behavior of the PB tool?
-- Should it be reported, or is this just the current state of development, and fixing these problems is already on the "to do list"? Or maybe even already fixed -- I'm using 0.46, the last stable release.
Thanks for listening!
All comments welcome, and certainly appreciated
If an SVG is needed, please let me know.
nodes created by the paint bucket tool
nodes created by the paint bucket tool
Basics - Help menu > Tutorials
Manual - Inkscape: Guide to a Vector Drawing Program
Inkscape Community - Inkscape FAQ - Gallery
Inkscape for Cutting Design
Manual - Inkscape: Guide to a Vector Drawing Program
Inkscape Community - Inkscape FAQ - Gallery
Inkscape for Cutting Design
Re: nodes created by the paint bucket tool
The paint bucket tool works by taking a bitmap copy of the drawing, filling the area with colour (just like any raster program) and then running the "Trace Bitmap" function on it. Technically, what ever issues you have with the placement of the nodes are due to "Trace Bitmap".
Remember, it's dealling with a bitmap, not a vector--it can't be perfect. It has to make assumptions and guesses. VectorMagick charges a lot of money for a algorithm that does it as well as I've seen, but still not perfect.
It's best to think of like a freehand tool such as . It's not designed to be precise. But when it comes to working with organic shapes it's a blessing.
Remember, it's dealling with a bitmap, not a vector--it can't be perfect. It has to make assumptions and guesses. VectorMagick charges a lot of money for a algorithm that does it as well as I've seen, but still not perfect.
It's best to think of like a freehand tool such as . It's not designed to be precise. But when it comes to working with organic shapes it's a blessing.