The problem with canvas is that our users need to be able to zoom very deep and still have crisp rendering. We wouldn't get that with canvas unless we rendered to a really huge canvas, right?

Yeah, the machine is definitely going to make a difference, though as I say a) most our documents are smaller than this and b) we have ways of speeding up bigger documents where required.

Sure, SVG isn't made for this, but it works. Going to canvas would mean a load of extra work and you can be sure there would be other tradeoffs and issues to work around. Additionally, SVG is super hackable. You can work with it easily front and back end. You can read it and understand what's going on.

And hey, if your users are happy.... :-)

http://www.capterra.com/takeoff-software/spotlight/144811/Co...

i think you can redraw the canvas when zooming in. So even if the canvas dimension is finite, you can redraw it with infinitely higher resolutions of data.

I get the idea, but then I'll be doing the work that the SVG engine is currently doing. So really, here you're trying to get canvas to do something that it wasn't designed to do - which is weird, because that was your argument against svg in the first place. A quick google reveals the general solution of "sounds like you should be using svg." [0]

Given that svg 100% works for my usecase, I don't have any reason to attempt anything else at the moment. People give svg a hard time about performance and I think that's counterproductive. My suggestion is that everyone should give it more of an honest shot and I suspect they'll find that there are plenty of cases when it becomes the first tool they reach for.

[0] http://stackoverflow.com/questions/19284304/how-redraw-on-ca...