The IDL folks already give you this capability. You can do that directly from VG/VGL plots themselves

That's just part of vega-embed - in fact, this directly supports svg, png, opening in vega/vega-lite editor and getting the final source

@U0525KG62 Are you specifically looking for batch/server-side rendering? @U06C63VL4 is right that when you load up a Vega visualization in the browser with vega-embed (which Oz uses), it provides a little drop down menu from which you can export static svg/png files. If however you want "batch"/"server-side" rendering, we have an issue on this, and folks have been expressing interest there: https://github.com/metasoarous/oz/issues/5.

I've thought about rendering static html as an option (button) for Saite. As it is, I've started giving presentations with it since you can have tabs for 'chapters' and all your plots can have annotations, not just hiccup, but active components - nifty things like modal panels, info buttons, popovers, etc. This is actually very nice since you keep VG/VGL interactions active and so can directly explore during presentation. But, the idea of pushing the whole notebook out as static html has an appeal to it. Altair does this with selenium and headless Chrome or Firefox. I'm not really sure about this though. Making the thing static sort of defeats the entire point of VG/VGL. Plus Saite has named sessions so that many users (browser pages) can see the same notebook at the same time. Yeah, not sure - but if I went this route, I would probably take what Altair does and use that.

A much more interesting issue is saving notebooks as 'live' documents that can be simply loaded and rendered in a Saite session. I have given rather more thought to that as it is much more useful.

most of the problem is calling out to R (in how we're currently doing it)

I'd quite like to be able to do a unified look and feel across pdf/presentation charts and online ones too (which I'm sure can be done with both vega and ggplot2 but I'd prefer to have one code base)

Calling out to R: been fairly routine for us. The main server code and many services are written in Clj, Services are basically nodes in a job flow. And services can be written in R, Python, and Perl. Other stuff could be accommodated but that's what there now. Calling out to R for some modeling and plot generation in this context has been rather straight forward. ¯\(ツ)/¯