SVG snap-to-grid, part one

Last night, I was thinking I’d really like to have a JavaScript-based SVG editor. There are some really freaking sweet examples out there. But there’s something missing from all of these, which surprises me in retrospect: SVG snap-to-grid support.

Freehand drawing is nice… unless you want precision. Sadly, the human hand (mine, at least) isn’t that accurate with distilling individual pixels. If I can get close enough with the mouse on a zoomed-in view, though, and I can see a grid indicating pixel coordinates, maybe the application can round off my mouse position to the nearest real point, and give me a visual indicator. Like this snap to grid example, which I put together in about two hours.

Right now, if you load the example, you can place a point by hitting a key on the keyboard. This is in keeping with the idea that controls should be accessible without the mouse. Unfortunately, I haven’t gotten into maneuvering points with key strokes. Nor have I factored in any kind of zoom & pan capabilities – linear algebra is not one of my strengths.

Over the next few days, I hope to turn this code into an actual class, similar to a Dojo-style library. I might even make it a XBL binding. Ultimately, by being able to precisely identify coordinates, I could plug coordinates directly into shapes such as SVG paths (Bezier curves made simple), rectangles, ellipses, etc. I could even build interfaces to create classes of polygons. (I want my <svg:triangle/>!)

You might wonder why I’d work on yet another SVG editor, when there are so many out there. There are two reasons. First I didn’t see any examples that would really be compatible with running inside a Mozilla framework, besides the ones above. They’re usually stand-alone apps. The examples above are exceptions to that rule, but (this is the second reason), the first two are not explicitly licensed under an open-source software license (no explicit license, and Creative Commons, respectively). Mark Finkle’s work is under the MIT License, but it’s HTML based. Nothing wrong with that. It just strikes me as unnecessary if the only platform you’re targeting is Mozilla. Mark’s targeting IE, too. My use case is simply different.

On the other hand, if I keep it as a JS-based constructor (instead of XBL), that would make it easier to port to other platforms, such as RichDraw.

Food for thought.