<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Dear Fernando, and Bob,<br>
    <br>
    I didn't want to bring up this issue before the new release, given
    that that has the higher priority, but since a new thread was opened
    along the same lines, I would like to respond to a couple of points
    raised here, and here:
    <a class="moz-txt-link-freetext" href="http://mail.scipy.org/pipermail/ipython-dev/2012-June/009476.html">http://mail.scipy.org/pipermail/ipython-dev/2012-June/009476.html</a>
    which I will quote here.<br>
    <br>
    Based on these two threads, I have the feeling that the views on
    what an interactive plot should do are somewhat diverging, and we
    should first come to some consensus as to what we exactly want. <br>
    <br>
    First, here are a couple of use cases for the notebook (From
    Fernando's comments)<br>
    <br>
    <blockquote type="cite">
      <pre>On Fri, Jun 8, 2012 at 8:49 AM, Bob McElrath &lt;<a href="http://mail.scipy.org/mailman/listinfo/ipython-dev">bob+ipython@mcelrath.org</a>&gt; wrote:
&gt;<i> Well I'll just say that IPython and matplotlib have quickly become my primary
</i>&gt;<i> computational tool. &nbsp;So I would not simply call it an "exploratory" tool. &nbsp;I
</i>&gt;<i> could already do exploratory computing with the (i)python command line. &nbsp;The
</i>&gt;<i> notebook allows me to save, repeat/reproduce, and communicate a computation. &nbsp;In
</i>&gt;<i> particular it allows me to record how I produced the final version of a plot.
</i>
1. Individual exploratory work: play with some code, some data, ...
2. Collaboration with colleagues.  ... 
3. Parallel production work: ...

 ... if your results do pan out, you'll want to publish them!...

4. The same notebook can then be exported to latex or html for
publication.  We're not really at the point of the notebook being what
you send to a journal, but the notebooks right now are perfect as
supplementary materials that remain *executable*.  
</pre>
    </blockquote>
    <br>
    I think, implementing all of these in a single tool is too
    ambitious, and unrealistic, and the requirements are even
    conflicting. This would mean, e.g., that the notebook should be
    aware of LaTeX packages. But since at this point, it uses MathJaX,
    and since MathJaX does not implement the full LaTeX command set, I
    don't see how this could be pulled off. Even worse, many journals
    require the use of a specific stylesheet, and figures have to be
    submitted as separate files. So, one would have to implement at
    least two separate backends, one for interactive work, and one for
    PDFs...<br>
    <br>
    Also, if executability is a requirement (I think, it is a reasonable
    one), then for plots we are left with js or SVG, that can work as a
    stand-alone figure, without relying on the ipython kernel. Another
    reason for decoupling the plot from the kernel is that in this way,
    one could explore plots in the notebook, while another calculation
    is running in the kernel. <br>
    <br>
    I would like to quote Brian's comments "I would love to see that
    emerge out of matplotlib, rather than YAPL
    (yet another plotting library).". I couldn't agree more. But if this
    is the case, then there are some major modifications to be
    implemented in matplotlib itself. I think, we have already realised
    that we would have to have access to not only the canvas elements,
    but the underlying data. At this point, there is no easy way of
    exposing those in matplotlib. So, the bottom line is that, if this
    plotting tool is to emerge from matplotlib, then we have to work
    with the matplotlib developers, and we can't just piggyback on what
    is already there. In such a case, however, we would have to have a
    very clear idea as to what is needed, for otherwise, it will be
    quite hard to convince the matplotlib developers.<br>
    <br>
    As I said earlier, after having played with the javascript backend,
    I could implement coordinate reporting, cross-hairs, and grid
    toggling in a standalone file, and more would most probably be not
    possible. If this is enough, then we should just go with that. If
    not, then the javascript backend is not an option, and SVG would not
    offer significantly more.<br>
    <blockquote type="cite">
      <pre>5. ... With the traditional approaches we've mostly used so far, each of the
steps above typically required shifting tools completely.  That hurts
productivity, kills reproducibility, and fundamentally impairs your
ability to *iterate* on an idea...</pre>
    </blockquote>
    <pre>In my view, this point is perhaps the most problematic: if the user 
is capable of changing a figure significantly, then there's got to be 
a mechanism for tracing those changes, otherwise, reproducibility will 
be severely compromised, if at a different level. However, implementing 
such a tracking mechanism is most certainly a huge undertaking.

</pre>
    On 06/26/2012 06:26 AM, Fernando Perez wrote:
    <blockquote
cite="mid:CAHAreOr2_DfwJBoF1UskayXhVdWPykZ2z2zPjJ0Dvaj1CW6Hog@mail.gmail.com"
      type="cite">
      <pre wrap="">Hi Bob,

In this spirit, have you had a chance to play with tools like this?

<a class="moz-txt-link-freetext" href="http://paperjs.org/about/">http://paperjs.org/about/</a>

Since it goes directly to the canvas element and is not SVG, I wonder
if interactive figures built upon it would fare any better than the
SVG ones.
</pre>
    </blockquote>
    I have looked at quite a few of the examples, and it seems to me
    that this library is rather CPU-hungry. But it might just be an
    issue with firefox... However, this might be a problem, even if we
    start from matplotlib, and implement a javascript backend from
    scratch. Static plots certainly have the advantage that once
    produced, they don't require CPU resources anymore... <br>
    Cheers,<br>
    Zolt&aacute;n<br>
    <br>
  </body>
</html>