I'm sure the lib2geom library will help a great deal. That will save me wondering how to implement cubic bezier curve equations for paths constructed from joined circles!
I agree with everything you say - a general solution is definitely preferred. Also, making the program select the objects within the boundary shouldn't be any more difficult than just counting them (assuming the extension interface or SVG spec offers hooks for defining selections).
You mention that it could also be useful to filter the object types, I agree with that.
You also raise the question, what does it mean for an object to lie inside the path? It can be interpreted many ways as you started to explore:
a) Does the centrepoint of each inner object lie within the zero-width boundary of the outer object? b) Do the inner object's boundary lines lie entirely within the outer object's boundary line? Or: c) You could conceivably even take into account stroke-width as well; a 5px diameter circle might really be a 1px diameter circle with a 4px stroke width. d) ...I'm sure there are more ways of deciding.
I imagine Drechsel has a fairly specific use case in mind.
I see the attraction of creating a very general purpose extension to solve this, but my aim for now would be to come up with a solution that will solve the problem at hand. Clearly, if there are features that would otherwise require substantial rewriting of code or other duplication of effort (i.e. code for searching *all* paths, not just circles, if that's within my abilities), then it makes sense to make the extension do those things the first time round.
However, if there are ideas for even more general features that are not needed for this problem, and, equally importantly, that can also easily be added later (when and if there's a need or desire; e.g. filtering by object type, finer-grained options about where the contained objects lie), then I might leave those for later or for others to implement. I suppose it will depend on my own free time and enthusiasm too. If I still have time and energy left after the main problem is solved, then I may well be interested in writing these extra features. I just don't want to set up expectations for extras at this stage.
Thanks, Craig
On 21 August 2010 10:49, Maximilian Albert <maximilian.albert@...1439...> wrote:
Hi Craig,
I'd be interested in producing a custom extension for this problem. My way of approaching the problem might be slightly different from yours though (depending on whether inkscape stores the circle centrepoints and radii for a collection of merged circles, if not it might require that the circles are not merged before the extension is installed).
If I understand you correctly the solution you have in mind would require the outline to be a composition of circles. However, I can imagine many other use cases for this kind of request in slightly different circumstances where the outline is a general path (and the items to be counted may be arbitrary objects). Even though he implementation seems easiest at first if you restrict yourself to circles, I would very much recommend not to make any assumptions to that effect and keep the functionality as generic as possible. Of course it would be overkill to implement a test whether an arbitrary path contains another in your extension code, but have a look at lib2geom [1], the geometry library underlying Inkscape. I haven't checked recently but it might contain functions to test wether one path lies with the boundaries of another (or at least whether a given point lies within a path, which might already be enough for your purposes if you only take the centers of the small red dots into account). If it doesn't, this should definitely be implemented anyway. :) The libary also has Python bindings.
On a different note, instead of counting the items within the outline path directly, it might be better (as in: give more flexibility for other use cases) to provide an easy way to *select* them. See my comments on the bug report: https://bugs.launchpad.net/inkscape/+bug/621627
Hope this helps, Max