Opened 6 years ago

Closed 3 years ago

#13543 closed defect (fixed)

Multi-character variables not supported in legend_labels

Reported by: mjo Owned by: jason, was
Priority: major Milestone: sage-6.10
Component: graphics Keywords:
Cc: kcrisman Merged in:
Authors: Michael Orlitzky Reviewers: Karl-Dieter Crisman
Report Upstream: N/A Work issues:
Branch: 0fb2fd4 (Commits) Commit: 0fb2fd4af09b39764464871834b0365bcca6db0b
Dependencies: #15870 Stopgaps:

Description

The simplest example I have is,

sage: hello = var('hello')
sage: latex(hello)
\mbox{hello}
sage: label = '$' + latex(hello) + '$'                    
sage: label
$ \mbox{hello} $
sage: plot(x, x, 0, 1, legend_label=label)
ERROR: An unexpected error occurred while tokenizing input
The following traceback may be corrupted or invalid
The error message is: ('EOF in multi-line statement', (409, 0))
...
ParseFatalException: Expected end of math '$'
$ \mbox{hello} $ (at char 0), (line:1, col:1)

It seems that matplotlib doesn't understand \mbox. If that's the bug to be fixed, we can simply replace \mbox with \rm when passing to matplotlib.

On the other hand, if I've declared hello to be a symbolic variable, shouldn't it be marked up as a symbolic variable (i.e. left in math mode)?

Change History (22)

comment:1 Changed 6 years ago by mjo

Ok, I finally got a chance to look at this. Matplotlib doesn't use a full TeX implementation by default. It has its own subset called mathtext that it uses unless you tell it to do otherwise via,

from matplotlib import rcParams
rcParams['text.usetex']=True

This requires you to have "TeX" available in your $PATH, whatever that means. I've done some experimenting and it's possible to set this globally via,

#text.usetex         : False # use latex for all text handling.

in local/lib/python2.7/site-packages/matplotlib/mpl-data/matplotlibrc.

However, I have a full, standalone LaTeX installed everywhere that I work, so I'm not sure if doing this would break a clean install.

comment:2 Changed 6 years ago by mjo

Ok, that doesn't work on a clean install (you can set an empty $PATH to convince it to crash). It requires ghostscript, dvipng (see #12276), and full tex installation. For a workaround, you can add,

from matplotlib import rcParams
rcParams['text.usetex'] = True

to ~/.sage/init.sage. The real fix would be one of the following:

  1. Get Matplotlib to support \mbox in their mathtext package.
  2. Replace all occurrences of \mbox in Sage with \mathrm. This might cause regressions.
  3. Ship tex, ghostscript, and dvipng with Sage.

comment:3 Changed 5 years ago by ppurka

Please check if #14664 fixes this ticket. If so, we can close this.

comment:4 follow-up: Changed 5 years ago by mjo

I don't know, because I can't plot anything thanks to #12276 =)

I'm guessing that it will work if I use typeset='latex' or typeset='type1' everywhere, but there are two problems:

  1. My example in the description will still crash.
  1. None of this works on a bare sage install, the user has to go find the missing ghostscript, latex, and dvipng dependencies and install them himself.

comment:5 in reply to: ↑ 4 ; follow-up: Changed 5 years ago by ppurka

Replying to mjo:

I don't know, because I can't plot anything thanks to #12276 =)

I'm guessing that it will work if I use typeset='latex' or typeset='type1' everywhere, but there are two problems:

  1. My example in the description will still crash.

Works for me. I have no problems with plotting with typeset='latex'. And my (external) dvipng is compiled with jpeg. My Sage's gd is not linked to jpeg, but the system gd is.

...5.10.rc0.sagenb/local/lib» ldd libgd.so | grep jpeg
...rc0.sagenb/local/lib [1] » ldd /usr/lib/libgd.so | grep jpeg
	libjpeg.so.8 => /usr/lib64/libjpeg.so.8 (0x00000030b4200000)
...5.10.rc0.sagenb/local/lib» sage -sh

Starting subshell with Sage environment variables set.  Don't forget
to exit when you are done.  Beware:
 * Do not do anything with other copies of Sage on your system.
 * Do not use this for installing Sage packages using "sage -i" or for
   running "make" at Sage's root directory.  These should be done
   outside the Sage shell.

Bypassing shell configuration files...

Note: SAGE_ROOT=/home/punarbasu/Installations/sage-5.10.rc0.sagenb
...5.10.rc0.sagenb/local/lib» which -a dvipng
/usr/bin/dvipng
...5.10.rc0.sagenb/local/lib»
  1. None of this works on a bare sage install, the user has to go find the missing ghostscript, latex, and dvipng dependencies and install them himself.

We can not expect to package latex with Sage. Latex packages are huge! We are better off asking the user to install them externally, especially since they are not an essential component of Sage.

comment:6 in reply to: ↑ 5 Changed 5 years ago by mjo

Replying to ppurka:

Replying to mjo:

I don't know, because I can't plot anything thanks to #12276 =)

I'm guessing that it will work if I use typeset='latex' or typeset='type1' everywhere, but there are two problems:

  1. My example in the description will still crash.

Works for me. I have no problems with plotting with typeset='latex'. And my (external) dvipng is compiled with jpeg. My Sage's gd is not linked to jpeg, but the system gd is.

Sorry, like I said, I was just guessing. Did you try running dvipng from within the sage shell? This is what I get:

gantu ~ $ dvipng foo.dvi 
This is dvipng 1.14 Copyright 2002-2010 Jan-Ake Larsson
[1] 
gantu ~ $ sage -sh

Starting subshell with Sage environment variables set.  Don't forget
to exit when you are done.  Beware:
 * Do not do anything with other copies of Sage on your system.
 * Do not use this for installing Sage packages using "sage -i" or for
   running "make" at Sage's root directory.  These should be done
   outside the Sage shell.

Bypassing shell configuration files...

Note: SAGE_ROOT=/home/mjo/src/sage-5.10.rc2
(sage-sh) mjo@gantu:~$ dvipng foo.dvi
dvipng: symbol lookup error: dvipng: undefined symbol: gdImageCreateFromJpegPtr
(sage-sh) mjo@gantu:~$

We can not expect to package latex with Sage. Latex packages are huge! We are better off asking the user to install them externally, especially since they are not an essential component of Sage.

There's a GSOC project that will hopefully go a long ways towards fixing the build system, but if you're going to decide to ship all of sage's dependencies, you've really got to ship all of them. Otherwise certain parts of the program will break, apparently at random.

comment:7 follow-up: Changed 5 years ago by ppurka

dvipng works from inside sage -sh for me.

/tmp/a» ls
a.dvi
/tmp/a» dvipng a.dvi
This is dvipng 1.14 Copyright 2002-2010 Jan-Ake Larsson
[1] 
/tmp/a» ls
a1.png	a.dvi
/tmp/a» sage -sh

Starting subshell with Sage environment variables set.  Don't forget
to exit when you are done.  Beware:
 * Do not do anything with other copies of Sage on your system.
 * Do not use this for installing Sage packages using "sage -i" or for
   running "make" at Sage's root directory.  These should be done
   outside the Sage shell.

Bypassing shell configuration files...

Note: SAGE_ROOT=/mnt/usb/Installations/sage-5.10.rc0
/tmp/a» rm a1.png
/tmp/a» dvipng a.dvi
This is dvipng 1.14 Copyright 2002-2010 Jan-Ake Larsson
[1] 
/tmp/a» ls
a1.png	a.dvi

comment:8 in reply to: ↑ 7 Changed 5 years ago by mjo

Replying to ppurka:

dvipng works from inside sage -sh for me.

Huh. And you use Gentoo, right? So we built dvipng the same way. Beats me.

comment:9 Changed 5 years ago by ppurka

Yes. Using pure (i.e. not one of the "forks" like Funtoo, Sabayon, etc) amd64 Gentoo here. :)

Edit: One thing that is different is my shell. I am using zsh.

Last edited 5 years ago by ppurka (previous) (diff)

comment:10 Changed 5 years ago by jdemeyer

  • Milestone changed from sage-5.11 to sage-5.12

comment:11 Changed 5 years ago by vbraun_spam

  • Milestone changed from sage-6.1 to sage-6.2

comment:12 Changed 5 years ago by dkrenn

  • Dependencies set to #15870

comment:13 Changed 5 years ago by novoselt

Works fine with 6.2.beta6

comment:14 Changed 5 years ago by mjo

Looks like it:

sage: hello = var('hello')
sage: latex(hello)
\mathit{hello}

The absence of \mbox probably makes a better unit test than the presence of \mathit.

comment:15 Changed 5 years ago by novoselt

I think the test for this ticket should be that plotting command works - what exactly is fed into it is not as relevant. Feel free to write the test and I'll review it ;-)

comment:16 Changed 5 years ago by mjo

Before the fix, the variable was math-escaped (as well as unplottable). A much lesser bug for sure, but now it's correctly marked up as a variable. I guess we should test that too but checking for \mbox or \mathrm is all I can think of.

comment:17 Changed 5 years ago by vbraun_spam

  • Milestone changed from sage-6.2 to sage-6.3

comment:18 Changed 4 years ago by vbraun_spam

  • Milestone changed from sage-6.3 to sage-6.4

comment:19 Changed 3 years ago by kcrisman

  • Cc kcrisman added

comment:20 Changed 3 years ago by mjo

  • Branch set to u/mjo/ticket/13543
  • Commit set to 0fb2fd4af09b39764464871834b0365bcca6db0b
  • Status changed from new to needs_review

I guess I shouldn't leave this open forever.


New commits:

0fb2fd4Trac #13543: Ensure that legends can contain weird variable names.

comment:21 Changed 3 years ago by kcrisman

  • Authors set to Michael Orlitzky
  • Milestone changed from sage-6.4 to sage-6.10
  • Reviewers set to Karl-Dieter Crisman
  • Status changed from needs_review to positive_review

comment:22 Changed 3 years ago by vbraun

  • Branch changed from u/mjo/ticket/13543 to 0fb2fd4af09b39764464871834b0365bcca6db0b
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.