Since I have never really liked Matplotlib I would really like to learn Bokeh, but unfortunately its inability to export its visualizations in SVG or similar formats makes it kind of useless for me as a scientist wanting to publish my results.
Try my Veusz plotting app and library - http://home.gna.org/veusz - it has a nice interactive GUI, is python scriptable and extensible via plugins. It's based around Python, Qt and numpy. It can export to PDF, EPS, SVG and bitmap formats.
+1 for gnuplot. Amazingly powerful and flexible, and exports to png, pdf, eps, latex, etc. Possibly outdated in some aspects but still unbeatable AFAIK.
That being said, this sounds nice for adding interactivity (sliders to vary parameters, that sort of stuff). Useful in presentations and the sort.
I severely dislike Gnuplot, but then again, I am wedded to Python. I'm not sure how versatile it is, at least from the slightly acquainted position I am.
FYI it's really dead simple to write new "bokeh" command line tools as Bokeh apps now. We already have several ("bokeh html" and "bokeh json") but we are definitely interested in make a gnuplot-like bokeh command line tool that you can just point at a CSV or log file and get a visualization right out. E.g. something like "bokeh graph foo.log -x time -y connections --tail" would create an automatically updating visualization of a growing log file. Or if anyone is interested in this functionality and wants to help speed along the development, please let us know!
I definitely empathize. It's a technically challenging problem, there are lots of competing important priorities, and we are a small team that can only humanly accomplish so much work at once. Our vision for Bokeh was to be able to create and share interactive data applications with a minimum of python and little-to-no JS and "web tech" required. We are closing in on that vision, so it is my fervent hope (and intention) that we'll be able to turn to this important priority soon as well.
What resolution are you looking for in print? If you export your raster at 300 dpi, and enable lossless PNG compression, shouldn't it suffice for most print purposes?
Often, it's not about print. People sometimes take vector images of plots and squeeze a bunch of them on a single page, with the idea that whoever views the paper online can zoom in if they're interested enough.
It still has limited resolution and a much higher storage footprint. Plotting charts is the vector graphics use case par excellence. Having svg support is a no brainer.
Of course you're right that we do need to support SVG and vector formats, but it's also not entirely true that "vector >> raster" in all cases.
Raster does have limited resolution, but so does your screen or most output devices (yes, even scientific plotters).
It's also not necessarily true that it has a higher storage footprint; it depends on the complexity and number of glyphs, the fonts you need to embed for the LaTeX formulae, etc. etc. In large-data cases, raster can be a much more viable visualization transfer medium.
Most imaging for offset printing is done in PostScript, which can render EPS directly, so there's no format conversion. For web publishing that's not the case, and either is probably fine depending on the workflow.
Reason is quite simple. EPS is based on PostScript. PDF specification contains a subset of PostScript. Embedding EPS into PDF is trivial and yields high quality results. For a printing publication workflow having EPS files at hand saves a lot of time and problems.
SVG is nice too, just needs few more intermediate steps.
This is just a throw, I've not tried. But Bokeh creates Canvas. There is a Canvas 2 SVG https://github.com/gliffy/canvas2svg JavaScript library already made.
