Fixes to the display system

[ellisonbg]

The IPython formatters use special methods to compute the format
of objects. These special methods have names like __html__, but
with this commit these have been changed to _repr_html_.

I have also added a Javascript formatter and fixed a bug in
pylab tools in getfigs.

Some remaining questions:

• We are still using the old logic in pretty.py and the special name __pretty__. Do we want to update pretty.py as well and use _repr_pretty_?
• Are we happy with the special names in this branch?
• Should _repr_png_ return the raw png data or base64 encoded data (required for sending over json). Currently we base64 encode.
• Should the latex representation include the wrapping $ or $$?
• Should the javascript repr output the raw javascript or include it in a <script> tag pair.

[mdboom]

To answer your question: "Should the latex representation include the wrapping $ or $$?", meaning (I think), the result of repr_latex should include the dollar signs, I would advocate for "yes". The matplotlib mathtext parser supports text outside of math mode, eg.:

r"Result of expression: $\sqrt{x}$"

Also, if one ever wanted to use a "call out to the real LaTeX" approach to this, there's all kinds of text layout features in LaTeX outside of math mode that one might want to use.

[mdboom]

Quick sanity check also: Is the LaTeX inline display not yet working? I see how I can get it to display LaTeX for Sympy objects, but what about an arbitrary object with a repr_latex method?

[ellisonbg]

The repr_latex method does work, but the qtconsole does not have native latex rendering. The htmlnotebook we are working on does have native latex support, but it is not all wired up in the Javascript yet. Not sure how to get qt to handle latex (without rendering to png like we do for sympy currently).

[mdboom]

It still may be useful (if not perfect) to have LaTeX -> PNG supported in
the Qt for anything with a repr_latex. It may also be possible to write
out SVG snippets from math expressions with matplotlib -- let me look into
that.

Mike

On Fri, Apr 15, 2011 at 12:36 PM, ellisonbg <
reply@reply.github.com>wrote:

The repr_latex method does work, but the qtconsole does not have native
latex rendering. The htmlnotebook we are working on does have native latex
support, but it is not all wired up in the Javascript yet. Not sure how to
get qt to handle latex (without rendering to png like we do for sympy
currently).

Reply to this email directly or view it on GitHub:
#370 (comment)

Michael Droettboom
http://www.droettboom.com/

[ellisonbg]

At point point I started to look into latex->svg generation using
matplotlib, but I didn't get very far. That would be veyr nice to have. I
do like the idea of adding logic that looks to see if repr_latex is
present, and use that to generate a png/svg automatically. But, one thing
we are finding with the matplotlib latex engine is that it struggles with
many complex latex expressions. I don't have any examples right now, but
the best way to test this is to start messing with sympy. Some things I
remember:

• Lots of nesting with parens is not handled well.
• Things like matrices are not implemented.

But we would love to have better support for all of this and any ideas you
have are very welcome.

It still may be useful (if not perfect) to have LaTeX -> PNG supported in

the Qt for anything with a repr_latex. It may also be possible to write
out SVG snippets from math expressions with matplotlib -- let me look into
that.

Mike

On Fri, Apr 15, 2011 at 12:36 PM, ellisonbg <
reply@reply.github.com>wrote:

The repr_latex method does work, but the qtconsole does not have native
latex rendering. The htmlnotebook we are working on does have native
latex
support, but it is not all wired up in the Javascript yet. Not sure how
to
get qt to handle latex (without rendering to png like we do for sympy
currently).

Reply to this email directly or view it on GitHub:
#370 (comment)

Michael Droettboom
http://www.droettboom.com/

Reply to this email directly or view it on GitHub:
#370 (comment)

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

[mdboom]

Yeah -- the mathtext stuff in matplotlib is still a subset of what a standard LaTeX distribution has. It's reasonably complete wrt to TeX, on which it is based, but it's missing most of the macros that LaTeX layers on top.

You could use dvipng and real LaTeX to generate the equation images if LaTeX is available. It adds a really heavy dependency, but it's the only thing I'm aware of that is as complete as LaTeX (because it is!). The Sphinx mathpng extension is a good concise example of using dvipng to get a LaTeX image. There is dvi parsing code in matplotlib, but it is complicated by the fact that it deals with scalable fonts etc. -- something you wouldn't necessary want to do for an interactive console.

[mdboom]

I've added a function to matplotlib master that converts a math expression alone to any of the image formats that matplotlib supports. See this pull request:

matplotlib/matplotlib#84

Since that function won't exist in a released matplotlib for a while, you may want to copy it into IPython and use it when it isn't available in matplotlib -- it uses things that have been stable for quite some time.

[fperez]

On Mon, Apr 11, 2011 at 8:38 PM, ellisonbg
reply@reply.github.com
wrote:

• We are still using the old logic in pretty.py and the special name pretty.  Do we want to update pretty.py as well and use repr_pretty?

I'd like to hear @rkern's feedback on this one, seeing as much of our
pretty machinery has been driven by him.

• Are we happy with the special names in this branch?

We also had the alternative of _ipython_repr_foo_. Part of me
finds that really long and annoying, but another part sees the points
raised by @jasongrout. Ensuring that sage_repr_foo,
ipython_repr_foo don't collide is a good idea.

• Should repr_png return the raw png data or base64 encoded data (required for sending over json).  Currently we base64 encode.

I think encoding should be the responsibility of the zmq layer, not
the base repr method. Imagine an in-process call that is going to use
the data right away, there's no point in encoding just to have to
decode it again immediately.

• Should the latex representation include the wrapping $ or $$?

It should, because those are semantically meaningful (they indicate
the display intent, in-line or displayed).

• Should the javascript repr output the raw javascript or include it in a <script> tag pair.

Is there a valid usecase for the raw data? I just don't know... If
there is, then the data should be left alone and wrapped by the one
who will send it to a browser. But maybe that kind of data is only
meant to go to a browser-like device, case in which perhaps there's no
point in having the raw data other than making busywork for the
callers.

[minrk]

• Should the javascript repr output the raw javascript or include it in a <script> tag pair.

It should definitely exclude the script tag, because the tag is HTML, and it would no longer be a valid javascript representation if you include it.

The use case is javascript-based frontends. If the frontend wants to do any handling on the data, it would have to strip the tags before parsing. It's more trivial to add tags in frontends that just want to echo into HTML than it is to strip tags for frontends that want to look at the data.

[ellisonbg]

OK, I am going to make $/$$ required for latex output, the png/etc formats will not encode (zmq layer will do that) and the javascript will includes the <script> tags. Still waiting for @rkern to give us his thoughts on the pretty.py issues. Also, we will copy the new function @mdbloom wrote for generating svg output from latex and incorporate that into a default latex formatter.

[rkern]

Sure.

[minrk]

Please don't include <script> tags, for reasons described in my previous comment.

[ellisonbg]

@minrk: OK, I understand your logic here and I think I agree with you.