[IPython-dev] SVG figures status report

Tue Jun 26 12:08:57 EDT 2012

On Tue, Jun 26, 2012 at 12:43 AM, Zoltán Vörös <zvoros at gmail.com> wrote:
> Dear Fernando, and Bob,
>
> 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:
> http://mail.scipy.org/pipermail/ipython-dev/2012-June/009476.html which I
> will quote here.
>
> 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.
>
> First, here are a couple of use cases for the notebook (From Fernando's
> comments)
>
> On Fri, Jun 8, 2012 at 8:49 AM, Bob McElrath <bob+ipython at mcelrath.org>
> wrote:
>> Well I'll just say that IPython and matplotlib have quickly become my
>> primary
>> computational tool.  So I would not simply call it an "exploratory" tool.
>>  I
>> could already do exploratory computing with the (i)python command line.
>>  The
>> notebook allows me to save, repeat/reproduce, and communicate a
>> computation.  In
>> particular it allows me to record how I produced the final version of a
>> plot.
>
> 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*.
>
>
> 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...

As Min mentioned if you want full LaTeX support you would have to use
the notebook in a different mode.  You put all the LaTeX in raw text
cells and give up the nice MathJaX browser rendering.  You are right
that it would be difficult to support full LaTeX in Markdown cells
with MathJaX rendering.

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

I pretty much agree with this.  If we want the interactive plotting to
be integrated with matplotlib, we will have to have someone on the mpl
team basically leading the effort.  We would have to work closely with
them to make sure it all works together.

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

Again, I agree.  Full interactivity does conflict with reproducibility
and we have to have a way of going back and forth between different
representations.

Cheers,

Brian

> On 06/26/2012 06:26 AM, Fernando Perez wrote:
>
> Hi Bob,
>
> In this spirit, have you had a chance to play with tools like this?
>
> http://paperjs.org/about/
>
> 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.
>
> 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...
> Cheers,
> Zoltán
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>

-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu and ellisonbg at gmail.com