Thanks for the pull request.

I did change a few things today, so this will not merge anymore. But I feel the general change could make it into the library.

I think the difficulty here is moving the existing bits around in a sane way to make the final conversion to an HTML image object optional. This code could move "up" the call stack, so that render.js only deals with creating the svg.

I have changed the return value to also contain the internal SVG representation. See https://github.com/cburgmer/rasterizeHTML.js/wiki/API#return-value. Let me know if that works for you!

I did not want to provide another set of 3 functions for what I believe is a corner case (I have yet to understand in which situations the SVG can be helpful).

The solution I chose not only returns the svg though, but also makes sure to load it as an Img object. In case the SVG is invalid, some browsers will make rasterizehtml fail.

For the use cases that only need the SVG I hope the loading as an image does not pose a performance issue.

Why the need for SVG? Some browsers can't render an SVG to a canvas, so the idea was to produce the SVG and send it to the server for rendering.

Unfortunately we had other issues with this approach so we ended up in a different direction.

Thanks for letting me know!