bulia byak wrote:
What you describe is similar to one of the 2 proposed approaches, using boolops. So I don't think it's much of a "temporary fix" - it's almost the real thing, in fact :)
I don't think forcing the user to draw a rect is a good idea. Bucket fill works without it in raster editors, and it should work the same in vector.
And personally, I'm much more in favor of the other approach, using bitmap fill algorithm over the rasterized image and then tracing the result. This way may sound more contrived, but it's actually more natural and universal. See this RFE for details:
http://sourceforge.net/tracker/index.php?func=detail&aid=1123138&gro...
As long as we're discussing this, I'd like to suggest that a vector bucket-fill, if implemented, might be designed to be a little smarter than its bitmap cousin:
It would be nice to be able to control the "viscosity" of the paint, so that it won't spill through an infinitesimally small hole. One of the classic problems with the bucket fill in bitmap work is that you have to be very very careful about making sure that the region is completely sealed-up, to avoid the fill algorithm "leaking" and filling the whole page. This can take a lot of time.
I can think of two mathematical constraints that could be used for this:
1) A "brush size" -- if it can't fit through, it doesn't spill.
2) A constraint on the curvature of the perimeter (no extremely sharp turns as would occur at the spill point). Or possibly, the constraint is on the narrowness of the curve at that point.
#1 is probably the way to go for a bitmap-based fill. #2 might be easier to implement if the algorithm is curve-based. (?)
Another useful thing to control would be an "overfill" parameter -- the fill should actually be very slightly larger than the area it fills. This may seem unnecessary, but it's very useful in practice. Typically the "ink" layer will have thick enough lines to obscure errors in the "paint" layer. This would reduce the possibility of gaps and allow the user to manipulate the paint layer and put it back without having to be pixel-accurate.
This is actually an exact analog for how manual ink and paint is (or was) done on cels -- the front is inked, and the back painted to match, so that brush stroke errors are hidden by the thickness of the ink lines.
Cheers, Terry