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.

I would suggest Plot.ly which is now open source and can export to html (with a lot of JavaScript which generates the SVG)

Plot.ly looks better to me as well. Specially the 3D stuff.

But hey, you can save your work in a xkcd style:

    to_bokeh(fig=None, use_pandas=True, xkcd=False)

Taken from: http://bokeh.pydata.org/en/latest/docs/user_guide/compat.htm...

But hey, you can already do that with Matplotlib ;)

http://matplotlib.org/xkcd/examples/showcase/xkcd.html

If you're not wedded to Python, have a gander at Gnuplot. Despite its quirks, it's my favorite plotting tool.

+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.

They're working on it, probably in a month or two you'll be able to do it: https://groups.google.com/a/continuum.io/forum/#!searchin/bo...

At the current time you can export to png, or maybe export to svg in a roundabout manner, by turning html page into pdf, turning pdf into svg, etc.

A png isn't a vector format, so the important property of the SVG (or EPS, PDF) is lost. A vectorized bitmap is still a bitmap.

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.

That's true, in practical uses a sufficiently high res raster is indistinguishable from a vector image. Still, it would be nice to have that option.

Working on SVG? What about EPS instead? For scientific publishing EPS is much better unless your visualisation is pretty much an high entropy one.

Please explain why EPS is better.

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.

I've never submitted to a journal that took SVG, nearly everyone I submit to takes EPS.

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.