Menu
▾
▴
matplotlib-users
|
From: Michael G. <mic...@gm...> - 2005-10-06 03:17:51
|
Hello all,
First of all, I would like to say thank you to the matplotlib developers fo=
r
implementing a nice hack that enables a free python environment to rival th=
e
functionality and power of matlab.
My question is whether it is possible to use the TeX backend to render font=
s
under the windows versions of matplotlib? I am interested in mixing standar=
d
text with math text as labels on plots. The standard matplotlib font backen=
d
can almost do this, but it is not robust, is hard to work with, and the
results don't look very professional. On the contrary, the TeX backend is
clean and conformant (but it only appears to work on UNIX systems with TeX
installed). For example, this code
import pylab
pylab.rc('text', usetex=3DTrue)
pylab.xlabel(r'normal text ($\alpha$)')
pylab.plot(range(0,5))
pylab.show()
will not work on the windows version of matplotlib, but produces beatiful
labels on the linux version. FYI, the above "rc" command is what requests
the TeX backend rather than the default.
Thanks for your thoughts, ideas, and candor.
Mike Gilbert
|
|
From: Alan G I. <ai...@am...> - 2005-10-06 05:58:09
|
On Wed, 5 Oct 2005, Michael Gilbert apparently wrote:
> import pylab
> pylab.rc('text', usetex=True)
> pylab.xlabel(r'normal text ($\alpha$)')
> pylab.plot(range(0,5))
> pylab.show()
> will not work on the windows version of matplotlib,
Not really an answer to your question, but:
it looks like a parse error on the parentheses.
Put them inside the math delimiters and it works.
Cheers,
Alan Isaac
|
|
From: Robert K. <rk...@uc...> - 2005-10-06 08:43:29
|
Michael Gilbert wrote: > Hello all, > > First of all, I would like to say thank you to the matplotlib developers > for implementing a nice hack that enables a free python environment to > rival the functionality and power of matlab. > > My question is whether it is possible to use the TeX backend to render > fonts under the windows versions of matplotlib? Probably. Do you have TeX installed on your Windows machine? -- Robert Kern rk...@uc... "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter |
|
From: Gary R. <gr...@bi...> - 2005-10-06 09:11:35
|
Hi Michael,
Your example works fine on my Win2k + MiKTeX setup with Matplotlib 0.83
Perhaps you should try deleting the contents of the .matplotlib cache
directory. If this doesn't work, what version of Windows & Matplotlib
are you running and are you using the MiKTeX distribution?
Gary R.
Michael Gilbert wrote:
> Hello all,
>
> First of all, I would like to say thank you to the matplotlib developers
> for implementing a nice hack that enables a free python environment to
> rival the functionality and power of matlab.
>
> My question is whether it is possible to use the TeX backend to render
> fonts under the windows versions of matplotlib? I am interested in
> mixing standard text with math text as labels on plots. The standard
> matplotlib font backend can almost do this, but it is not robust, is
> hard to work with, and the results don't look very professional. On the
> contrary, the TeX backend is clean and conformant (but it only appears
> to work on UNIX systems with TeX installed). For example, this code
>
> import pylab
> pylab.rc('text', usetex=True)
> pylab.xlabel(r'normal text ($\alpha$)')
> pylab.plot(range(0,5))
> pylab.show()
>
> will not work on the windows version of matplotlib, but produces
> beatiful labels on the linux version. FYI, the above "rc" command is
> what requests the TeX backend rather than the default.
>
> Thanks for your thoughts, ideas, and candor.
>
> Mike Gilbert
|
|
From: Alan G I. <ai...@am...> - 2005-10-06 13:11:57
|
On Thu, 06 Oct 2005, Gary Ruben apparently wrote:=20 > Your example works fine on my Win2k + MiKTeX setup with Matplotlib 0.83= =20 You see the \alpha in his example?? Alan Isaac Using Win2K + MiKTeX + Matplotlib 0.83.2 Cheers, Alan Isaac |
|
From: Alan G I. <ai...@am...> - 2005-10-06 13:16:39
|
> On Thu, 06 Oct 2005, Gary Ruben apparently wrote:=20 >> Your example works fine on my Win2k + MiKTeX setup with Matplotlib 0.83= =20 On Thu, 6 Oct 2005, Alan G Isaac apparently wrote:=20 > You see the \alpha in his example??=20 > Alan Isaac=20 > Using Win2K + MiKTeX + Matplotlib 0.83.2=20 Oops. Too hair trigger on the send button. Deleting the cache worked. But why? I saw the problem the first time I ran his example. What exactly is being cached? Thank you, Alan Isaac |
|
From: John H. <jdh...@ac...> - 2005-10-06 13:49:10
|
>>>>> "Alan" == Alan G Isaac <ai...@am...> writes:
Alan> Oops. Too hair trigger on the send button. Deleting the
Alan> cache worked. But why? I saw the problem the first time I
Alan> ran his example. What exactly is being cached?
We run a md5 hash on the tex string itself and use that for the base
filename of the cache. The tex , dvi and png files are cached. I am
not sure why you needed to delete the cache on this one. If you can
replicate the problem, perhaps you can take a look at texmanager.py
and see what is going wrong. The module is fairly straigtforward.
Thanks,
JDH
|
|
From: Gary R. <gr...@bi...> - 2005-10-06 13:49:28
|
Alan G Isaac wrote:
>> On Thu, 06 Oct 2005, Gary Ruben apparently wrote:
>>> Your example works fine on my Win2k + MiKTeX setup with Matplotlib 0.83
>
> On Thu, 6 Oct 2005, Alan G Isaac apparently wrote:
>> You see the \alpha in his example??
>> Alan Isaac
>> Using Win2K + MiKTeX + Matplotlib 0.83.2
>
>
> Oops. Too hair trigger on the send button.
> Deleting the cache worked.
> But why?
I don't know, but I had noticed in the past that this sometimes makes a
difference. Not that it explains anything, but I'd say that the cache
mechanism could do with some improvement.
I think it seemed to me to be the font cache rather than the TeX cache
which made the difference.
I will now relate, for the record, that if anyone is trying to get TeX
support to work with Windows 98, they will be unsuccessful for the
following reasons:
There is a problem with MPL's TeX and PS support under Windows 98 where
Win98 generates resource errors. This is related to Win98's awful pipes
support; popen2 and popen3 calls basically do not work properly.
I have tried adding close() calls to the pipe input handle following
each usage of a pipe. The idea is to force the pipes to be flushed. This
improves the situation, although it does not guarantee a 100% fix, since
I think the close() call requests that Windows flush and destroy the
pipes but this can take an indeterminate time to act on. I don't know of
a better way of doing this like any method of checking that a pipe has
finished all its I/O activities.
One day I may try changing the os.popen calls to os.spawnl instead,
since this approach should work.
The other small problem is something I suggested in a previous post
(dated July 10th) which was not implemented, to do with Win98 returning
"DVIPNG.EXE" instead of "dvipng" in response to
running "dvipng --version".
The fix here is to change the line:
if line.startswith('dvipng '):
to
if line.lower().startswith('dvipng'):
For now, I'll just use my Win2k machine.
Gary
|
