[IPython-dev] notebook plots via javascript

Zoltán Vörös zvoros at gmail.com
Fri Jun 8 08:07:28 EDT 2012

Hi All,

On 06/08/2012 01:58 AM, Bob McElrath wrote:
> In a nutshell, if you want to change the aspect ratio, you will have 
> to dig into the matplotlib code, and change the SVG it generates.
>>> While this isn't interactive javascript yet, we can begin attaching some
>>> javascript to the SVG DOM elements.
>> And the figure resizing in my branch above would be a good start.
> Yes...of course, what we *really* want in resize-able circumstances is to change
> the tick marks, axis/label fonts, etc to maintain a reasonable figure.  This is
> really beyond the scope of what we can do with matplotlib.  As far as I can see,
> matplotlib is really oriented to producing printable output.
> I don't know where you want to go with ipython's graphics, but I think adding
> axis labels, legends, modifying scaling and tick marks (etc) by typing a
> sequence of plt.*() calls is a horrible thing to do to a person.  What I would
> love to see is:
> 1. A new matplotlib backend that generates a blob of data wrapped in svg and
>      javascript.
> 2. Interactive ability to scale/rotate/label that data in the browser.
> 3. A reverse tie-in so that interactive modifications to the figure become
>      python commands in the corresponding code block.
I have the feeling that these goals are too ambitious. I think, there is 
a desire to keep plotting within the realm of matplotlib, but add some 
interactivity to it. We have already discussed that this approach has 
some limitations, and the number of things one can do with it is 
definitely finite.

But I just fail to see why plots should be resizable, and why plots 
should be able to emit python code for tracking the changes. The vision 
for ipython was, and I believe, still is, is to provide a tool for 
exploratory computing. What you described above goes far beyond 
exploration. I don't think that changing the plot labels or the legend 
would qualify for exploration. I see only two instances where 
interactivity beyond the scope of matplotlib would be useful in this 
context. One is zooming/panning, which cannot be done without having 
some sort of access to the data, and the other is rotation of surfaces 
(here, again, data access is necessary). However, one should keep in 
mind that this latter one will be awfully slow in javascript/svg, anyway.

My concern here is that by demanding too much of the new backend, we 
won't get anywhere, simply because these requirements are just too 
stringent. I have a javascript backend now that produces stand-alone 
javascript, and allows for grid toggling, and coordinate reporting + 
cross-hairs. I could release that soon, but that is basically all what 
can be done without upsetting the code base of matplotlib. If the 
matplotlib people are willing to provide some interface to the data and 
so on, we could pick it up from there. Brian's proposal would be a good 
starting point for that.

What could, perhaps, help for the time being is, if there was a way of 
switching backends on the fly. I think one could live with interactive 
plots, if limited in capabilities, and whenever needed, switching to a 
truly interactive backend, like gtk/qt4. I recall that Fernando 
mentioned it at one point that he was working on this, but I don't know 
whether this is still on his list.


More information about the IPython-dev mailing list