KevLinDev Blog

The core intersection algorithms are now complete. The Intersection object has been updated to include the following intersections: Quadratic Bezier-Quadratic Bezier, Quadratic Bezier-Cubic Bezier, and Cubic Bezier-Cubic Bezier. You can see examples of these intersections in the 2D Geometry section of this site.

I managed to get my head around an approach that seems to work well for the various Bezier-Bezier intersections; however, there seems to be at least one case with the Quadratic Bezier-Quadratic Bezier intersection that I’m not handling properly. The problem case is when a Bezier overlaps itself and has all controls in a straight line. I was not able to reproduce the problem with the other two intersections, but I would imagine that there is a problem there too. BTW, if you want a good laugh, then you might want to look at the intersectBezier3Bezier3 method in the Intersection object. That has to be one of the most riduculous functions I’ve ever built in any language .

There’s still plenty to do with the intersection algorithms. Mainly, I need to go back and revisit the code to see where I can optimize things a bit. For example, I know that I can add tests to see if two shapes have overlapping bounding boxes. This should speed up polygon and path intersections considerably. And I still need to take care of polylines, horizontal and vertical lines in paths, and probably more.

The conversion of my SVG files to Batik-compatibility has been completed. I found that I will need three additional features in Batik before I can get all of the examples to work. Those features are: support for gzipped external JavaScript files, key events, and the use of a JavaScript object as an event handler (the EventListener interface). The gzipped JavaScript file is not critical. It looks like key events will be added to Batik. The EventListener stuff is being discussed a bit on the Batik list right now.

A lot more of the SVG files ended up working than I had originally expected. I created parallel SVG files for each HTML file so that I can easily navigate the site’s SVG files. You can start your tour by pointing the Batik SVG browser to http://www.kevlindev.com/index.svg. The SVG files simply list the links and SVG files that are in the associated HTML document. I hope to improve these SVG files in the future.

I’ve tried to get the SVG plug-in for Konquerer to build, but I haven’t had any luck. I’m hoping to get SVG files to run in as many viewers as is possible. It has been quite educational for me and I recommend it as an exercise to potentially gain a better understanding and appreciation for SVG and XML.

The tutorials section of the site has been re-organized and updated to be compatible with Batik

Adding support for Batik means that it’s time for me to break some bad habits. When I first starting into SVG, I didn’t really understand the difference between DOM Level 1 and DOM Level 2 calls. I used the DOM Level 1 calls because they seemed easier and they worked in ASV.

Batik is not as forgiving as ASV (and that’s a good thing). As I convert my site to Batik compatibility, I will completely replace all createElement(), getAttribute(), and setAttribute() calls with createElementNS(), getAttributeNS(), and setAttributeNS(), respectively. This is in prepration for the time when multi-namespace documents become more common.

I am quite happy and impressed with the latest beta release of Batik. Many of the examples that I’ve converted run well in the SVG Browser. Of course, SMIL animation is not supported, but that doesn’t effect me too much since many of my examples rely solely on JavaScript. If you haven’t looked into Batik yet, then I would say that now is the time to give it try. It’s looking like Batik will be the most complete SVG viewer since we aren’t seeing any more development on ASV.