[SciPy-user] Re: [Scipy-chaco] TeX/LaTeX and Chaco

Andrea Riciputi ariciputi at pito.com
Thu Oct 16 04:54:41 EDT 2003


Hi,
I tried PyX too after your post last week. It looks very promising and  
I'm doing some experiments with it.

Under MacOS X it compiles without problems and all the examples worked  
(except minimal.py and bar.py because corresponding .dat files are  
missing, but the author told me he had already fixed this in CVS),  
'import pyx' gives the same problem here.

I've looked at the output of pattern.py example (both mine and yours)  
and as far as I can see it looks like the one on the website. Are you  
sure your output is different from the one on the site?

For further discussion about PyX I've subscribed PyX-Users mailing  
list. Hope to see your posts there soon. ;-)

For those interested in PyX and running MacOS X I've prepared and  
submitted a Fink's package. I hope it will be available to all the  
Fink's users very soon.

Cheers,
	Andrea.

On Thursday, Oct 16, 2003, at 00:31 Europe/Rome, Fernando Perez wrote:

> Chris Barker wrote:
>
>> Anyway, PyX is a pretty neat project, that seems to have a lot in  
>> common
>> with Chaco/Kiva. I wanted to make sure you all knew about it.
>
> Just a few days ago I mentioned it on the scipy-* (not chaco) lists,  
> after finding out about it myself.  Something's in the air ;-)
>
> Anyway, even more coincidence, I spent a good chunk of time today  
> getting it to work, which unfortunately isn't totally trivial on a  
> RedHat box, mainly because of some path issues.  I was this very  
> minute about to send my notes to the developers so they perhaps can  
> include the fixes in the future.  But since you brought it up here, I  
> figured I'd put my notes on these lists.  Once you have the  
> instructions, the fixes are trivial to implement.  But knowing what to  
> do may save people quite a bit of time.
>
> Hopefully these instructions will be unnecessary in the near future.   
> In the meantime, I hope some find them useful.
>
> Best,
>
> f.
> PyX NOTES
> =========
>
> PyX http://pyx.sourceforge.net is an extremely interesting tool for
> manipulating PostScript files in python, with full access to LaTeX  
> commands.
> In particular, it is capable of reading in an existing eps file, and  
> 'overlay'
> additional elements (graphical or text, including arbitrary mathematics
> defined in LaTeX).  Since it is a python library, all changes are done
> programatically and can be automated.
>
> In conjunction with (I)Python's support for Gnuplot, it becomes very  
> easy to
> generate the basic part of a plot using Gnuplot, and then use PyX to  
> add any
> elements which may be difficult or impossible to control with Gnuplot.
>
> However, the current (0.4.1) version of PyX as distributed presents a  
> few
> hurdles, at least on a RedHat system.
>
> Below is a list of the problems I encountered, along with their  
> solution.
> They can all be fixed within a few minutes, and hopefully these fixes  
> will be
> implemented in the mainline distribution for future versions.
>
>
> PROBLEM
> -------
>
> 'import pyx' doesn't provide access to pyx's modules.  The examples  
> provided
> all use 'from pyx import *', which is bad form for larger scripts,  
> where this
> kind of blanket import is bound to cause nasty name collisions.
>
> FIX: trivial.  In __init__.py, add after __all__ is defined:
>
> # Load __all__ in pyx namespace so that a simple 'import pyx' gives
> # access to them via pyx.<name>
> for name in __all__:
>     __import__(name,globals(),locals(),[])
>
>
> - PROBLEM: setup.py doesn't put things in the proper place if --home  
> is given
> different from the default.  I used --home=~/usr/local, and while pyx  
> itself
> went into ~/usr/local/lib/python/pyx, its .lfs files went to
> ~/usr/local/share/pyx.  But the pyx program itself expects to find them
> somewhere else, because trying to run hello.py produces:
>
> planck[examples]> python hello.py
> Traceback (most recent call last):
>   File "hello.py", line 4, in ?
>     c.text(0, 0, "Hello, world!")
>   File "/home/fperez/usr/local/lib/python/pyx/canvas.py", line 767, in  
> text
>     return self.insert(self.texrunner.text(x, y, atext, *args))
>   File "/home/fperez/usr/local/lib/python/pyx/text.py", line 2283, in  
> text
>     return self._text(unit.topt(x), unit.topt(y), expr, *args)
>   File "/home/fperez/usr/local/lib/python/pyx/text.py", line 2271, in  
> _text
>     self.execute(expr, *helper.getattrs(args, texmessage,  
> default=self.texmessagedefaultrun))
>   File "/home/fperez/usr/local/lib/python/pyx/text.py", line 1994, in  
> execute
>     raise IOError("file '%s' not found. Available latex font sizes:  
> %s" % (lfsname, lfsnames))
> IOError: file '10pt.lfs' not found. Available latex font sizes: []
>
> This may be a bug in setup.py, or in pyx itself (pyx may need to  
> adjust its
> search paths according to where it got installed).  I don't know for  
> sure.
>
> Putting some print statements in text.py gave the following:
>
> *** file 10pt.lfs not found!
> *** file /usr/share/pyx/10pt.lfs not found!
> *** file /home/fperez/usr/local/lib/python/pyx/lfs/10pt.lfs not found!
>
> So the problem is in how pyx builds its search path (lines 1980-93 in
> text.py).  It needs to pick up the correct installation path, or  
> setup.py
> needs to make sure that the lfs files end up underneath the pyx  
> directory
> (instead of above it, in ../../share).
>
> FIX: For now I can fix it manually, by moving the .lfs files to a  
> directory
> (which must be created first) called
> /home/fperez/usr/local/lib/python/pyx/lfs.  But this needs to be done
> permanently in the code.  I'm not exactly sure what the correct fix is.
>
>
> PROBLEM
> -------
>
> After fixing the previous one manually, I still can't run hello.py.
> Note that I've also seen this error on a machine where pyx was  
> 'setup.py
> install'ed to a default directory.
>
> Here's the traceback:
>
> planck[examples]> python hello.py
> Traceback (most recent call last):
>   File "hello.py", line 6, in ?
>     c.writetofile("hello")
>
> ... [snip]
>
> RuntimeError: no information for font 'cmr10' found in font mapping  
> file, aborting
>
> This problem is discussed in:
>
> http://sourceforge.net/mailarchive/ 
> forum.php?thread_id=3225190&forum_id=23700
>
> FIX: change around line 504 of text.py, from:
>
> fontmap = readfontmap(["psfonts.map"])
>
> to:
>
> fontmap = readfontmap(["psfonts.map","psfonts.cmz","psfonts.amz"])
>
> It might be worth doing this in the mainline sources.  Even if it is  
> not the
> ideal default for some latex-related reasons I don't understand, the  
> truth is
> that distributions as popular as RedHat choke on the current  
> configuration.
> If this simple change makes pyx work out of the box for many users, it  
> is that
> much more likely to become popular.
>
>
> PROBLEM
> -------
>
> Trying to run the latex.py example:
>
> planck[examples]> python latex.py
> Traceback (most recent call last):
>    File "latex.py", line 9, in ?
>      c.text(0, 0, r"This is \LaTeX.")
>
> .... [snip]
>
> pyx.text.TexResultError: TeX didn't respond as expected within the  
> timeout
> period (5 seconds).
> The expression passed to TeX was:
>    \documentclass{article}%
>    \PyXInput{3}%
> After parsing the return message from TeX, the following was left:
>    *
>
>
> The problem is that on a system where ~ is NFS mounted, a 5 second  
> timeout may
> be just too short.  We serve /home from an old Solaris box, and  
> latex'ing a
> file typically is a bit of a slow process with lots of network  
> read/write
> activity.  I wouldn't be surprised if this was a rather common  
> situation in
> typical unix shops.
>
> FIX: I'd advocate for a much longer timeout, perhaps 30 seconds at  
> least.  I
> changed it to 30 (line 1848 of text.py), and it works fine even on our
> sluggish network.  While this timeout is a bit long, it makes pyx a  
> much more
> robust system in the face of 'real world' network environments.
>
>
> PROBLEM
> -------
>
> After fixing the above, I can run most of the included examples.  The  
> only
> remaining issues are:
>
> - The pattern.eps file looks very different from the one on the  
> website.  The
> global figure is indeed the PyX logo, but instead of being made out of  
> little
> copies of PyX, it's made out of text blocks.  This may or may not be  
> an issue
> with my system, I don't know.
>
> I've put up what I get (temporarily) in
> http://windom.colorado.edu/~fperez/tmp/pattern.eps
> in case the developers find it useful.
>
> - bar.py and minimal.py don't run because the corresponding .dat files  
> are not
> included in the distribution.
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user
>
---
Andrea Riciputi

"Science is like sex: sometimes something useful comes out,
   but that is not the reason we are doing it" -- (Richard Feynman)



More information about the SciPy-User mailing list