Intersection Algorithm Dispatcher
When I started to setup the intersection examples to include the Bezier-Bezier intersections, I realized that I had a bit of a design problem. Basically, I was going to end up with all sorts of methods to support all combinations of intersections. This wasn’t really a problem until I added all of the path commands. I think I would have ended up with something like 200 methods to support all combinations. Anyway, I rewrote the intersection handling.
The Intersection object is now responsible for dispatching to the appropriate intersection method based on the shapes that are passed to it. To support this, I added a getIntersectionParams() method to all shapes (including path commands). Now each shape returns it’s base type (circle, ellipse, bezier3, etc.) and the parameters needed for intersection. The Intersection object’s intersectShapes() method determines which intersection method to call based on the returned information. This has reduced the size of the code considerably (don’t have exact numbers) and, I think, the code is much easier to follow.
As usual, I updated all of the intersection examples. I added a custom namespace and custom attribute to the examples so that I can start to get a feel for the direction in which I’m trying to go.
I would like for this code to run under Batik, so I started some tests. The Quadratic Bezier-Circle intersection example shows what’s needed to setup everything so that Batik will successfully validate the SVG file and at the same time make ASV use it’s internal scripting engine. I had to add ATTLIST’s for all of the custom namespace related stuff (for Adobe and for me). This all looks promising, but it appears that I will need to wait for Batik 1.5b2 before I can create dynamic elements on the <svg> element.
