I overcommitted to a method without sufficient prototyping, and it’s causing me problems. At issue is – I think – some default choices that Inkscape makes when handling SVG. But it could also be a problem with how my original artwork got rendered into a PDF, or, it could just be a failure of understanding on my part.
Let me back up. I was assigned to read a book called Understanding the Four Rules of Simple Design, and create a presentation and blog post on it. This seemed like a good time to try something I’ve been wanting to try for at least a year: creating a sort of DIY Prezi.
The obvious question: why? What’s wrong with Prezi? Nothing’s wrong with Prezi! But SVG is an infinitely scaleable, very mathy format. I want to learn to use the format for data visualizations and for web art, not just presentations. What’s more, vinyl and laser cutters can take SVG as an input, as can printers, opening up a whole realm of possibility for doing off-the-screen graphics. I dream about making rubber stamps out of generative art, or taking a representation of some high-symmetry finite group, turning it into a mask, slapping it on a piece of glass or ceramic or metal, and sandblasting or acid-etching myself some tangible mathematical or math-inspired art. So, although yesterday I did d accuse myself of once again doing everything in the most complicated way possible, I still think it’s been a good experience for learning how to work with the format directly.
After a little bit of tinkering I discovered that objects in Inkscape can be assigned IDs. A-ha! A strategy emerged:
- Create a rectangle of a sensible-looking aspect ratio
- Move and scale it to surround the region that would be my first slide
- Assign it the id
- Copy it
- Move and scale the copy to surround the region that would be my next slide (thus maintaining the aspect ratio)
- Assign it the id
- Repeat until done
I got pretty into this. I also added a few rectangles labeled, e.g.,
#transition-3-4, on the theory that it might be useful to have some midpoints for the animations. Finally I had thirty-ish rectangles. What I expected to happen now was,
- Write a function
go(using Snap.svg or vanilla JS) mapping four numbers to the procedure to set the SVG
viewBoxattribute to the corresponding value
- Write another function
slideBoxfrom an integer between one and thirty-ish to four numbers, i.e., the numbers corresponding to the corners of a given
- Attach an
#slide-nthat would apply
n+1, thus advancing the viewport to the next viewing region
My theory was that this would get me the ability to advance to the next slide, instantaneously. If everything worked to this point, then I could spend any remaining time on animating the transition over time, and maybe even inserting transitions.
HOWEVER. After hacking on the thing for a while, I finally understood that Inkscape’s coordinate system diverges from the browser’s coordinate system! All the y-coordinates for my rectangles were negative. Also my rectangles had parent
<g> elements with a matrix transformation. I tried to write a function to try and do a change of coordinates, but I did not come up with the right one in time, and ended up giving my presentation by haphazardly sliding around the artboard in Inkscape itself. Not bueno.
Here is my final artboard (42 MB svg) as exported by Inkscape. (Note there are a few options for exporting, including “plain svg” and “optimized svg” — but they didn’t seem to be better.) These questions remain:
- Is there a way to get Inkscape to export something with a more web-standard coordinate system?
- If not, has someone written anything that will un-transform Inkscape SVG into something more web-standard?
- Why the heck is Inkscape exporting non-web-friendly coordinates in the first place?
- If later I try and export Inkscape SVG to a razor or laser cutter, how many fingers should I expect to lose?