Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Fixes to the display system #370

Merged
merged 4 commits into from May 17, 2011

Conversation

Projects
None yet
5 participants
Owner

ellisonbg commented Apr 12, 2011

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

mdboom commented Apr 14, 2011

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.

Contributor

mdboom commented Apr 14, 2011

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?

Owner

ellisonbg commented Apr 15, 2011

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

Contributor

mdboom commented Apr 15, 2011

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/

Owner

ellisonbg commented Apr 15, 2011

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

Contributor

mdboom commented Apr 15, 2011

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.

Contributor

mdboom commented Apr 15, 2011

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.

Owner

fperez commented Apr 15, 2011

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.

Owner

minrk commented Apr 19, 2011

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

Owner

ellisonbg commented Apr 19, 2011

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.

Contributor

rkern commented Apr 19, 2011

Sure.

Owner

minrk commented Apr 19, 2011

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

Owner

ellisonbg commented Apr 19, 2011

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

ellisonbg added some commits Apr 11, 2011

@ellisonbg ellisonbg Renaming the special methods of the formatters.
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.
43a27cb
@ellisonbg ellisonbg Renamed __pretty__ to _repr_pretty_ and changed updated pretty.py
* Throughout the codebase, __pretty__ has been changed to
  _repr_pretty_ to match general convention for special method
  names.
* The logic in pretty.py now matches that in formatters.py in that
  formatters that are callables are tried first and then special
  methods are used.
4241df5
@ellisonbg ellisonbg Misc updates the display system.
* PNG base64 encoding is now done at the ZMQ level, not in the
  display formatter itself.
* All formatters are documented as to the exact nature of their
  return value. PNGs are not base64 encoded, LaTeX must include
  $/$$, Javascript should not have the <script> tags, etc.
* Updated the Circle display example in docs/examples/core.
* Renamed the sympy printing extension to sympyprinting.py.
e7df0ac
@ellisonbg ellisonbg Added mdboom's math_to_image from matplotlib. 290c0f4

@ellisonbg ellisonbg merged commit 290c0f4 into ipython:master May 17, 2011

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment