[IPython-dev] SVG figures status report

Bob McElrath bob+ipython@mcelrath....
Tue Jun 26 05:54:24 CDT 2012


Zoltán Vörös [zvoros@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.

Sorry that I did not see that mail previously.  :-/

But just a couple of comments.

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

1. There's a lot of good code in mplh5canvas:
        http://code.google.com/p/mplh5canvas/
   I think it may be possible to extract their matplotlib backend and adapt it
   to IPython.  This could be relatively quick to do, and behaves exactly like
   the other matplotlib GUI's.

2. I'm using my SVG branch daily and I will continue to beat on SVG.  I'm not
    entirely convinced that the bugs I see are not due to some bad
    jQuery/CodeMirror interaction.  I have one example in which the CodeMirror
    updateDisplay() is using a ton of CPU when output cells with a lot of SVG
    figures are focused.  Other profiling I've done indicates it's style
    recalculations that are eating a ton of CPU.  A PNG or Canvas image cache
    rendering is really a hack, and the long-term future is in SVG.

3. I'd say that computationally-oriented tasks, such as coordinate reporting,
    changing to log axes, should be a top priority for interactive figures.
    Secondary to that is massaging a figure into a final form, such as changing
    ticks/labels etc, and importantly, *saving* it in a convenient form.
    Switching to SVG or Canvas for figures will obscure one's ability to save
    the figure and move it into your LaTeX document.  (can't just right
    click->save as anymore).

4. WRT Latex in worksheets and exporting: yet another major failing of
    Maple/Mathematica was their slow evolution into horrible hackish document
    processing systems.  Mathematica made a bizarre Frankenstein beast in which
    you could create entire documents, user interfaces, and unrelated garbage
    with Mathematica commands.  Maple added "2d math input" which is just a
    nightmare of figuring out where it's going to put the cursor next, so you
    can reposition it with the arrow keys.  These things are just hacks, and no
    one uses them to write papers, and never will.  IPython should not have
    delusions of grandeur, and I suggest focusing on computation is more useful.
    The only elements of these "document processing systems" that I ever used
    was annotation text around calculations, and folding blocks of code for
    organization.  IPython already has the former, I expect the latter will come
    soon.  Latex packages are very, very far from the realm of things I want to
    worry about in a worksheet.

5. I'm far more concerned about the repeatability of calculations due to the
    worksheet/kernel separation, and the general organization of a calculation
    in a worksheet, than exporting in a "presentation" form.  I think the
    "worksheet" as a computing paradigm is weak and has many flaws, and I would
    love to see some new and innovative ideas on this front.  I'm not interested
    in a reimplementation of Mathematica's interface.

I'll scratch my itch when it comes to IPython, and I hope it's helpful, but I
don't have the time or resources to implement much this.  So, for the
maintainers, please don't depend on me in this regard.

--
Cheers, Bob McElrath

"The individual has always had to struggle to keep from being overwhelmed by
the tribe.  If you try it, you will be lonely often, and sometimes frightened.
But no price is too high to pay for the privilege of owning yourself." 
    -- Friedrich Nietzsche


More information about the IPython-dev mailing list