http://savas.ca/blog/wp-content/uploads/2015/01/awsnap1.png 771w" sizes="(max-width: 771px) 100vw, 771px" />
If you’ll remember back a couple of months back during my LastWave posts, I mentioned that one of the two big challenges with creating LastWave was being able to hand the user an SVG. At the time of writing that post, my best solution was to use the “Chrome SVG-crowbar”, which, while solving the problem, was obviously not a perfect fix and left me unsatisfied. I’ve since been mucking around with SVG conversion and file saving and happened to run into a neat trick that allowed me to (partially) overcome the issues I was having.
$(“#svg_dl”).html($(“<a title=”file.svg” href=”data:image/svg+xml;base64,\n’+graph_data.base64+'” download=”svg.svg”><button class=”btn btn-primary”>Download vectorized SVG</button></a>”));
This is definitely a bit of a hack. Essentially what you do is this:
1. Take your already created in browser SVG and convert it into base64 (I’m using Base64.encode() from http://www.webtoolkit.info/javascript-base64.html)
2. Now take that base64 text and insert it manually into an <a> tag while letting the browser know that you’ll be downloading a file from it named svg.svg
3. When you click this link, the browser will now take that base64 information and download it into a file named svg, thus providing the end user with an svg of the file.
Sneaky, right?
I know it also seems like the perfect solution. But unfortunately it has one big problem. Since all of this is done on the client side (as with everything else in LastWave), Chrome and other browsers crash or freeze if the image size is too big. Unfortunately, “too big” is even a graph of a year of listening history, which is one of the benchmarks I was trying to offer. I’m therefore currently looking into taking a step in the direction I didn’t originally want to go: handling the file download on server side.
I’ll make a post when and if I end up making progress on this.