You can clone with
HTTPS or Subversion.
Pros of PNG:
Cons of PNG:
My suggestion would be for to make SVG the default from now on, but for the qt console to manually set kernels it starts to use png to avoid the clipping bug. If users do want SVG in the qt console, they can configure it themselves (which means that the qt console would need to set it to PNG only if the user hasn't set it)
@minrk, we can pick up here the format discussion from #923.
PNG is also generally more predictable - SVG renderers in browsers are definitely better than Qt's (which is quite bad), but they are not perfect, nor are they reliably identical to each other.
There is also the option of sending multiple versions at the same time. This is obviously duplication of data, and increased network traffic, but it would allow better embedding of figures, especially in the notebook, where the right answer could be any of PNG/PDF/SVG/etc. for export, while the display format should be something else. This is already true for Qt, where PNG is definitely the right display format, but having SVG around as well would mean that the XHTML export would still work.
Sending multiple copies is a good idea, as long as it's completely optional: the added overhead can be truly significant, as it's not just sending more data, it's also calling two completely separate rendering passes in MPL, which can be expensive.
I remember at some point there was discussion about some way of having interactive, zoomable & slidable versions of graphs embedded. I take it that's still something for the future?
Most certainly!!! The two 'big things' on the notebook plans are full/clean reST/sphinx integration and interactive widgets. In fact, we'd like to go beyond plots and have something akin to Sage's @interact but with a model more closely based on Traits and our own display protocols. But that's a larger job, so it's quite likely that someone will add as an intermediate step support for matplotlib pan/zoom interactivity and basic event handling, with a full architecture for arbitrary widgets in the future.
The html5 matplotlib backend would be perfect for this, @takluyver. Would it be too hard to have integrated with the notebook?
Yes, that would indeed be very cool. We would need to figure some things out, because, for instance, it cannot be guaranteed that the browser can have a direct connection to the kernel, so we would have to relay the websocket connection through the notebook server.
I've made some tests with more complex figures (large networkx directed graphs visualized with FancyArrow patches) and I'm finding that the SVG quality isn't really up to par. So it seems to me the best course of action would be to just leave PNG as our default, the way it is now.
Given the new %config magic makes it so easy to change this for users on a per-notebook basis, by simply putting
%config InlineBackend.figure_format = 'svg'
I don't think we need to do anything else.
If nobody disagrees in a day or so, I'll close this issue leaving PNG as our default the way it is now.
Closing this as resolved, as suggested by @fperez above. PNG is more reliable and better behaved, and switching to SVG is easy enough with the new %config magic.