matplotlib-users Mailing List for matplotlib

===== Original message from Robert Hetland | 17 Mar 2006:
> I would check to make sure you installed freetype right..
a reinstall of freetype got things up and running again.
the freetype on my system probably had been corrupted.

Supplying S as an argument instead of a keyword worked for fixing the 
size, but I lost the arrow heads.
Any suggestions?
> quiver()'s argument handling is very fragile. You can't use keyword arguments.
> If you want to use the S argument you have to invoke quiver() like so:
> 
> quiver(X, Y, U, V, S)
> 
-- 
Ms. Carol A. Leger
SRI International			Phone: (650) 859-4114
333 Ravenswood Avenue G-273
Menlo Park, CA 94025 e-mail: le...@sr...

Daniel McQuillen <danmcquillen@...> writes:
A follow up note from my posting today:
Although the .exe was successfully created by py2exe, 
when I try to run it,I only get an "Errors Occurred" 
dialog window with the following written to the
log:
Traceback (most recent call last):
 File "VizTool.py", line 2, in ?
 File "VizTool\Controllers.pyo", line 4, in ?
 File "VizTool\GraphPanels.pyo", line 1, in ?
 File "wxmpl.pyo", line 32, in ?
 File "matplotlib\numerix\__init__.pyo", line 145, in ?
ImportError: No module named random_array
Here's my setup script. Note that I've included the 
line suggested by the py2exe wiki
(http://starship.python.net/crew/theller/moin.cgi/MatPlotLib)
to try to remedy this missing random_array module, 
but am still getting that error.
import os
from distutils.core import setup
import py2exe
import glob
import matplotlib
opts = {
 'py2exe': { 'includes': 'matplotlib.numerix.random_array',
 'excludes': ['_gtkagg', '_tkagg'],
 'dll_excludes': ['libgdk-win32-2.0-0.dll',
 'libgobject-2.0-0.dll']
 }
 }
 
setup( version = '0.0.1',
 windows = ['VizTool.py'], 
 data_files = [('data', ['data/CH2.csv']),
 ('conf',['conf/GraphStyles.ini']),
 ('',['matplotlibrc']),
 matplotlib.get_py2exe_datafiles()],
 options={"py2exe":{"optimize":2}},
)
This is the setup.py command at the DOST prompt:
C:>python.exe -OO setup.py py2exe -b 3 -c -p numarray,pytz -e numpy 
Thanks for any help anybody can provide!
Regards,
Daniel McQuillen
Oakland, CA

John Hunter wrote:
>>>>>>"Steve" == Steve Schmerler <el...@gm...> writes:
> 
> 
> Steve> sorry forgot to attach the files :)
> 
> OK< after a quick look here is a new approach to think about. After
> you install and run 0.82, and then build 0.87.x, you did not flush the
> font cache or tex cache dir, right? In this case the font caching
> mechanism may be picking up the old font dir look for 'font search
> path' in your logs. What happens if you first install 0.82, run it,
> then install 0.87, run it, then flush the font and tex cache. Does 87
> then fail as before. Ie is it the running of 0.82 and the
> preservation of the font cache information that is causing 0.87 to
> work? Arguing against this is that findfont seems to be returning
> Vera.ttf in both cases.
> 
> In any case, an important clue would be to know whether wiping out
> ~/.matplotlib/*.cache restores the bug in 0.87.x
> 
No. I removed
elcorto@ramrod:~$ rm -r .matplotlib/tex.cache/ .matplotlib/ttffont.cache 
.ttffont.cache
and ran the script. It doesn't fail. Note that I still had a 
.ttffont.cache (from 0.82) in my $HOME (because I did not remove 
*anything* related to 0.82 before building 0.87.2). But even removing 
this doesn't change anything.
Does mpl (0.87.2) maybe include 0.82 stuff during the build process?
cheers,
steve
ps: I always get your mails twice :)
-- 
Random number generation is the art of producing pure gibberish as 
quickly as possible.

Daniel McQuillen <daniel@...> writes:
> Charlie Moad <cwmoad <at> ...> writes:
> 
> > 
> > I just committed the changes to cvs and added a convenience function
> > for py2exe called get_py2exe_datafiles. 
> 
Charlie, 
Thanks for your help. I tried running your script and got an error originating
from the function you wrote within __init__.py. I tried the function by itself
within PyShell and got the same error...here's the error I received:
 File "setup.py", line 23, in ?
 data_files = [('', ['nlo.gif', '../vtkrotate/NMA.pdb']),
 File "C:\Python24\Lib\site-packages\matplotlib\__init__.py", line 367, in get_
py2exe_datafiles
 mplfiles = glob.glob(os.sep.join([matplotlib.get_data_path(), '*']))
NameError: global name 'matplotlib' is not defined
This seems to be the code that you added to the __init__.py file:
 def get_py2exe_datafiles():
 import glob
 
 mplfiles = glob.glob(os.sep.join([matplotlib.get_data_path(), '*']))
 # Need to explicitly remove cocoa_agg files or py2exe complains
 mplfiles.remove(os.sep.join([matplotlib.get_data_path(), 'Matplotlib.nib']))
 
 return ('matplotlibdata', mplfiles)
I removed the matplotlib references and the code then worked:
 def get_py2exe_datafiles():
 import glob
 
 mplfiles = glob.glob(os.sep.join([get_data_path(), '*']))
 # Need to explicitly remove cocoa_agg files or py2exe complains
 mplfiles.remove(os.sep.join([get_data_path(), 'Matplotlib.nib']))
 
 return ('matplotlibdata', mplfiles)
I can now create an .exe. I'll post soon as to how well the .exe actually works.
Thanks for your help.
Daniel
Oakland, CA

>>>>> "Steve" == Steve Schmerler <el...@gm...> writes:
 Steve> sorry forgot to attach the files :)
OK< after a quick look here is a new approach to think about. After
you install and run 0.82, and then build 0.87.x, you did not flush the
font cache or tex cache dir, right? In this case the font caching
mechanism may be picking up the old font dir look for 'font search
path' in your logs. What happens if you first install 0.82, run it,
then install 0.87, run it, then flush the font and tex cache. Does 87
then fail as before. Ie is it the running of 0.82 and the
preservation of the font cache information that is causing 0.87 to
work? Arguing against this is that findfont seems to be returning
Vera.ttf in both cases.
In any case, an important clue would be to know whether wiping out
~/.matplotlib/*.cache restores the bug in 0.87.x
JDH

>>>>> "Steve" == Steve Schmerler <el...@gm...> writes:
 Steve> here the test script:
Well, your tests certainly look exhaustive and repeatable and it looks
like you are doing everything right. From the diff you posted it
certainly doesn't look like my hypothesis is correct. I did not see
the attachments thought; could you send them along as well?
JDH

John Hunter wrote:
>>>>>>"Steve" == Steve Schmerler <el...@gm...> writes:
> 
> Steve> No. I posted several times about this issue but
> Steve> unfortunately nobody seems to have this problem and/or a
> Steve> solution. If you're also running Debian sagre stable then I
> Steve> guess one of the (many) libs that mpl is using is too
> Steve> old/buggy in stable.
> 
> Interesting also that both of you appear to have german as your
> default language. I wonder if one of the default fonts you are using
> is different and is providing bad font metrics. Could you run a
> script in the environment which produces the error with
> --verbose-debug, and then again in the environment which doesn't with
> the same flag and post the output of both cases. Maybe something
> about first installing 0.82 and then removing it makes a difference in
> which fonts are found. Just guessing. But verbose-debug will at
> least identify which font files are being loaded.
> 
sorry forgot to attach the files :)
here the test script:
----------------------------------------------
plot([1,2,3])
xlabel('x-label')
ylabel('y-label')
show()
----------------------------------------------
attached files:
mpl_svn0.87.2_bad_labels.txt
mpl_deb0.82_good_labels.txt
mpl_svn0.87.2_good_labels_run_1.txt
mpl_svn0.87.2_good_labels_run_2.txt
uninstall.sh
what I did:
1)
* no mpl stuff on the machine, removed .matplotlibrc/.tex.cache and
 .matplotlibrc/.ttffont.cache
* installed latest svn (0.87.2)
* the 1st run creates .matplotlib/.tex.cache and
 ./matplotlib/.ttffont.cache
* the --verbose-debug output of a normal run is in
 mpl_svn0.87.2_bad_labels.txt
* the x-axis starts at -1, not at 0, labels have the wrong position
2)
* uninstalled 0.87.2 with uninstall.sh
* istalled 0.82 debs
* labels OK, --verbose-debug output in mpl_deb0.82_good_labels.txt
3)
* removed 0.87.2 build folder, *not* $HOME/.tex.cache,
 $HOME/.ttffont.cache (which is 0.82 stuff)
* recompiled and installed 0.87.2
* labels OK
* the output of the 1st run where .matplotlibrc/.tex.cache and
 .matplotlibrc/.ttffont.cache are created is in
 mpl_svn0.87.2_good_labels_run_1.txt (copy-paste from shell)
* the normal-run output is in mpl_svn0.87.2_good_labels_run_2.txt
Now the outputs mpl_svn0.87.2_bad_labels.txt and
mpl_svn0.87.2_good_labels_run_2.txt should show some difference
regarding loaded font libs but they don't ....
----------------------------------------------------------------------
elcorto@ramrod:~$ diff -cbB mpl_svn0.87.2_bad_labels.txt
mpl_svn0.87.2_good_labels_run_2.txt
*** mpl_svn0.87.2_bad_labels.txt 2006年03月17日 20:39:53.000000000 +0100
--- mpl_svn0.87.2_good_labels_run_2.txt 2006年03月17日 21:10:11.000000000 +0100
***************
*** 1,3 ****
--- 1,6 ----
+ elcorto@ramrod:~$ python test.py --verbose-debug
+ /usr/lib/python2.3/site-packages/pylab.py:1: DeprecationWarning:
Non-ASCII character '\xc3' in file
/usr/lib/python2.3/site-packages/matplotlib/__init__.py on line 148, but
no encoding declared; see http://www.python.org/peps/pep-0263.html for
details
+ from matplotlib.pylab import *
 matplotlib data path /usr/lib/python2.3/site-packages/matplotlib/mpl-data
 $HOME=/home/elcorto
 CONFIGDIR=/home/elcorto/.matplotlib
----------------------------------------------------------------------
(The DeprecationWarning is caused because of the line
__date__ = '$Date: 2006年03月17日 20:21:28 +0100 (Fr, 17 Mär 2006) $'
where obviously the german date (output of date?) causes some little
trouble)
cheers,
steve
-- 
Random number generation is the art of producing pure gibberish as
quickly as possible.

John Hunter wrote:
>>>>>>"Steve" == Steve Schmerler <el...@gm...> writes:
> 
> Steve> No. I posted several times about this issue but
> Steve> unfortunately nobody seems to have this problem and/or a
> Steve> solution. If you're also running Debian sagre stable then I
> Steve> guess one of the (many) libs that mpl is using is too
> Steve> old/buggy in stable.
> 
> Interesting also that both of you appear to have german as your
> default language. I wonder if one of the default fonts you are using
> is different and is providing bad font metrics. Could you run a
> script in the environment which produces the error with
> --verbose-debug, and then again in the environment which doesn't with
> the same flag and post the output of both cases. Maybe something
> about first installing 0.82 and then removing it makes a difference in
> which fonts are found. Just guessing. But verbose-debug will at
> least identify which font files are being loaded.
> 
here the test script:
----------------------------------------------
plot([1,2,3])
xlabel('x-label')
ylabel('y-label')
show()
----------------------------------------------
attached files:
mpl_svn0.87.2_bad_labels.txt
mpl_deb0.82_good_labels.txt
mpl_svn0.87.2_good_labels_run_1.txt
mpl_svn0.87.2_good_labels_run_2.txt
uninstall.sh
what I did:
1)
* no mpl stuff on the machine, removed .matplotlibrc/.tex.cache and
 .matplotlibrc/.ttffont.cache
* installed latest svn (0.87.2)
* the 1st run creates .matplotlib/.tex.cache and
 ./matplotlib/.ttffont.cache
* the --verbose-debug output of a normal run is in
 mpl_svn0.87.2_bad_labels.txt
* the x-axis starts at -1, not at 0, labels have the wrong position
2)
* uninstalled 0.87.2 with uninstall.sh
* istalled 0.82 debs
* labels OK, --verbose-debug output in mpl_deb0.82_good_labels.txt
3)
* removed 0.87.2 build folder, *not* $HOME/.tex.cache,
 $HOME/.ttffont.cache (which is 0.82 stuff)
* recompiled and installed 0.87.2
* labels OK
* the output of the 1st run where .matplotlibrc/.tex.cache and
 .matplotlibrc/.ttffont.cache are created is in
 mpl_svn0.87.2_good_labels_run_1.txt (copy-paste from shell)
* the normal-run output is in mpl_svn0.87.2_good_labels_run_2.txt
Now the outputs mpl_svn0.87.2_bad_labels.txt and 
mpl_svn0.87.2_good_labels_run_2.txt should show some difference 
regarding loaded font libs but they don't ....
----------------------------------------------------------------------
elcorto@ramrod:~$ diff -cbB mpl_svn0.87.2_bad_labels.txt 
mpl_svn0.87.2_good_labels_run_2.txt
*** mpl_svn0.87.2_bad_labels.txt 2006年03月17日 20:39:53.000000000 +0100
--- mpl_svn0.87.2_good_labels_run_2.txt 2006年03月17日 21:10:11.000000000 +0100
***************
*** 1,3 ****
--- 1,6 ----
+ elcorto@ramrod:~$ python test.py --verbose-debug
+ /usr/lib/python2.3/site-packages/pylab.py:1: DeprecationWarning: 
Non-ASCII character '\xc3' in file 
/usr/lib/python2.3/site-packages/matplotlib/__init__.py on line 148, but 
no encoding declared; see http://www.python.org/peps/pep-0263.html for 
details
+ from matplotlib.pylab import *
 matplotlib data path /usr/lib/python2.3/site-packages/matplotlib/mpl-data
 $HOME=/home/elcorto
 CONFIGDIR=/home/elcorto/.matplotlib
----------------------------------------------------------------------
(The DeprecationWarning is caused because of the line
__date__ = '$Date: 2006年03月17日 20:21:28 +0100 (Fr, 17 Mär 2006) $'
where obviously the german date (output of date?) causes some little 
trouble)
cheers,
steve
-- 
Random number generation is the art of producing pure gibberish as 
quickly as possible.

I just changed texmanager.py and backend_ps.py in svn, so they do not use the 
subprocess module anymore. You can point your web browser to 
http://svn.sourceforge.net/viewcvs.cgi/matplotlib/trunk/matplotlib/lib/matplotlib/
to get the updated versions of these files. 
Darren
On Friday 17 March 2006 04:19, Randewijk P-J <pjr...@su...> wrote:
> Dear All,
>
> Using the new matplotlib-0.87.2 on Windows, I get the following error
> message:
>
> File "c:\Python\lib\site-packages\matplotlib\texmanager.py", line 245,
> in make_ps
> stdout=PIPE, close_fds=True)
> File "C:\Python\lib\subprocess.py", line 500, in __init__
> raise ValueError("close_fds is not supported on Windows "
> ValueError: close_fds is not supported on Windows platforms
>
> Changeing all the `close_fds=True' -> `close_fds=False', I get the
> following:
>
> File "c:\Python\lib\site-packages\matplotlib\texmanager.py", line 245,
> in make_ps
> stdout=PIPE, close_fds=False)
> File "C:\Python\lib\subprocess.py", line 533, in __init__
> (p2cread, p2cwrite,
> File "C:\Python\lib\subprocess.py", line 593, in _get_handles
> p2cread = self._make_inheritable(p2cread)
> File "C:\Python\lib\subprocess.py", line 634, in _make_inheritable
> DUPLICATE_SAME_ACCESS)
> TypeError: an integer is required
>
> Changed all the stdout=PIPES to stdout=STDOUT, but get the same error...
>
> I've read through PEP-324 and subprocess.html but these PIPES confuses
> me...
>
> I thought computers work with CPUs, chips, wires and PCBs etc. ... but
> not PIPES ... or at least not my win32 type computer, maybe Linux uses
> different hardware ... >:-)
>
> (At to that `file descriptors', `child process', `stdin', `stdout',
> `stderr'...)
>
>
> Would something like the following work?
>
> if sys.platform == 'win32':
> 	stdin, stdout, stderr = os.popen3(command)
> 	verbose.report(stdout.read(), 'debug-annoying')
> 	err = stderr.read
> 	if err: verbose.report(err, 'helpful'):
> 		...
> else:
> process = Popen(command, shell=True, stderr=STDOUT,
> stdout=PIPE, close_fds=True)
> exit_status = process.wait()
> if exit_status:
> 		...
>
> PJR
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live
> webcast and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid1720ドル&dat1642
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
-- 
Darren S. Dale, Ph.D.
Cornell High Energy Synchrotron Source
Cornell University
200L Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853
dd...@co...
office: (607) 255-9894
fax: (607) 255-9001

Carol Leger wrote:
> Hi folks,
> 
> I am trying to turn off the auto scaling in quiver.
> 
> In the form QUIVER( X, Y, U, V, S), I have made plots with S=0, S=5 and
> omitting S entirely. The plots look the same to me.
> 
> What effect does the S argument have on the plot?
> 
> What I want is to be able to generate multiple figures with a consistent
> scale. In other words, I want a vector of U=100,V=100 to be the same
> size on each figure no matter what the maximum vector is for the figure.
quiver()'s argument handling is very fragile. You can't use keyword arguments.
If you want to use the S argument you have to invoke quiver() like so:
 quiver(X, Y, U, V, S)
-- 
Robert Kern
rob...@gm...
"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
 -- Umberto Eco

Hi folks,
I am trying to turn off the auto scaling in quiver.
In the form QUIVER( X, Y, U, V, S), I have made plots with S=0, S=5 and 
omitting S entirely. The plots look the same to me.
What effect does the S argument have on the plot?
What I want is to be able to generate multiple figures with a consistent 
scale. In other words, I want a vector of U=100,V=100 to be the same 
size on each figure no matter what the maximum vector is for the figure.
Any hints?
I am using matplotlib 0.87.1 with numarray and GTKagg.
-- 
Ms. Carol A. Leger
SRI International			Phone: (650) 859-4114
333 Ravenswood Avenue G-273
Menlo Park, CA 94025 e-mail: le...@sr...

I've updated (and also re-renamed) subprocess.py to the latest Python
upstream version in svn. Unfortunately it looks like it still has this
comment about Windows specific code for close_fds, so I don't believe it
addresses this issue. I'm going to send another email to the
matplotlib-dev list regarding another issue...
Darren Dale wrote:
>On Friday 17 March 2006 04:19, Randewijk P-J <pjr...@su...> wrote:
> 
>
>>Dear All,
>>
>>Using the new matplotlib-0.87.2 on Windows, I get the following error
>>message:
>>
>> File "c:\Python\lib\site-packages\matplotlib\texmanager.py", line 245,
>>in make_ps
>> stdout=PIPE, close_fds=True)
>> File "C:\Python\lib\subprocess.py", line 500, in __init__
>> raise ValueError("close_fds is not supported on Windows "
>>ValueError: close_fds is not supported on Windows platforms
>> 
>>
>
>Does this work for you? 
>
>import subprocess
>process = subprocess.Popen(['dir'], shell=True, stdout=subprocess.PIPE, 
>stderr=subprocess.STDOUT)
>stat = process.wait()
>print process.stdout.read()
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by xPML, a groundbreaking scripting language
>that extends applications into web and mobile media. Attend the live webcast
>and join the prime developer group breaking into this new coding territory!
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>_______________________________________________
>Matplotlib-users mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
>

>>>>> "Steve" == Steve Schmerler <el...@gm...> writes:
 Steve> No. I posted several times about this issue but
 Steve> unfortunately nobody seems to have this problem and/or a
 Steve> solution. If you're also running Debian sagre stable then I
 Steve> guess one of the (many) libs that mpl is using is too
 Steve> old/buggy in stable.
Interesting also that both of you appear to have german as your
default language. I wonder if one of the default fonts you are using
is different and is providing bad font metrics. Could you run a
script in the environment which produces the error with
--verbose-debug, and then again in the environment which doesn't with
the same flag and post the output of both cases. Maybe something
about first installing 0.82 and then removing it makes a difference in
which fonts are found. Just guessing. But verbose-debug will at
least identify which font files are being loaded.
If you could do the same Willi, we might be able to triangulate on the
common cause for this problem.
JDH 

On Friday 17 March 2006 04:19, Randewijk P-J <pjr...@su...> wrote:
> Dear All,
>
> Using the new matplotlib-0.87.2 on Windows, I get the following error
> message:
>
> File "c:\Python\lib\site-packages\matplotlib\texmanager.py", line 245,
> in make_ps
> stdout=PIPE, close_fds=True)
> File "C:\Python\lib\subprocess.py", line 500, in __init__
> raise ValueError("close_fds is not supported on Windows "
> ValueError: close_fds is not supported on Windows platforms
Does this work for you? 
import subprocess
process = subprocess.Popen(['dir'], shell=True, stdout=subprocess.PIPE, 
stderr=subprocess.STDOUT)
stat = process.wait()
print process.stdout.read()

On Friday 17 March 2006 04:19, Randewijk P-J <pjr...@su...> wrote:
> Dear All,
>
> Using the new matplotlib-0.87.2 on Windows, I get the following error
> message:
>
> File "c:\Python\lib\site-packages\matplotlib\texmanager.py", line 245,
> in make_ps
> stdout=PIPE, close_fds=True)
> File "C:\Python\lib\subprocess.py", line 500, in __init__
> raise ValueError("close_fds is not supported on Windows "
> ValueError: close_fds is not supported on Windows platforms
Does this work on windows?

Hi,
When using an imshow command whose extent is larger than the axes
limits, the axes are partially hidden by the image. That is, one half
of the axis line is hidden and the other appears fine. I made sure
that ax.set_axisbelow is False.
I attached a screenshot of the png file, look at the top axis.
Using version 0.86.2
Thanks,
David

Chris,
 IE doesn't render transparent PNGs correctly. One can wrap them 
in javascript to invoke the renderer that will fix this however it is 
an ugly hack.
see:
http://homepage.ntlworld.com/bobosola/
for details.
Ian
On Mar 10, 2006, at 11:09 PM, matplotlib-users- 
re...@li... wrote:
> made my plot PNGs transparent. For some reason this works
> in Firefox but not in Internet Explorer.
>
> Anyone know why?
>
> chris

Make sure your matplotlibrc says Numeric.
On 3/17/06, Vineet Jain <vi...@al...> wrote:
> I just upgraded to matplotlib 0.87.2 from 0.85. I've been using Numeric
> and have not moved over to numpy yet. I'm getting the following error:
>
> from matplotlib.pylab import *
> File
> "/usr/lib/python2.4/site-packages/matplotlib-0.87.2-py2.4-linux-i686.egg/
> matplotlib/pylab.py", line 196, in ?
> import cm
> File
> "/usr/lib/python2.4/site-packages/matplotlib-0.87.2-py2.4-linux-i686.egg/
> matplotlib/cm.py", line 5, in ?
> import colors
> File
> "/usr/lib/python2.4/site-packages/matplotlib-0.87.2-py2.4-linux-i686.egg/
> matplotlib/colors.py", line 33, in ?
> from numerix import array, arange, take, put, Float, Int, where, \
> File
> "/usr/lib/python2.4/site-packages/matplotlib-0.87.2-py2.4-linux-i686.egg/
> matplotlib/numerix/__init__.py", line 66, in ?
> import numpy
> ImportError: No module named numpy
>
> The egg support is great!!
>
> Thanks for your help.
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting langua=
ge
> that extends applications into web and mobile media. Attend the live webc=
ast
> and join the prime developer group breaking into this new coding territor=
y!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D121642
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

I've just tried the latest version (87.2) and still have the same problem. =
The=20
install worked just fine (attached). The problem:
Text alignment with text() works, as I can test with
text(3, -4, r'l', fontsize=3D20, horizontalalignment=3D'left')
text(3, -4, r'c', fontsize=3D20, horizontalalignment=3D'center')
text(3, -4, r'r', fontsize=3D20, horizontalalignment=3D'right')
However the xlabel/ylabel commands position the labels at the lower left=20
corner, which looks just ugly. Also the title is positioned at the upper le=
ft=20
corner.
Any further hint?
I use Fedora Core 3
Am Freitag, 17. M=E4rz 2006 11:34 schrieb Steve Schmerler:
> Willi Richert wrote:
> > Am Montag, 16. Januar 2006 17:14 schrieb Steve Schmerler:
> >>Hi
> >>
> >>With MPL 0.86 and 0.86.1 I found that the axes labels aren't centered
> >>(i.e. the xlabel is on the left side of the x-axis, the ylabel on the
> >>"bottom" of the y-axis). What's up?
> >>
> >>cheers,
> >>steve
> >
> > I have exactly the same problem. I've posted it some months ago on this
> > list and the solution (delete ttfonts file) did not work for me. Is the=
re
> > some news regarding this error?
>
> No. I posted several times about this issue but unfortunately nobody
> seems to have this problem and/or a solution. If you're also running
> Debian sagre stable then I guess one of the (many) libs that mpl is
> using is too old/buggy in stable.
>
> On the other hand, my "workarround" (installing 0.82 debs first) shows
> that newer versions probably read some lib files written from 0.82. I
> didn't have time to fiddle out the details. At least a hint from a
> developer would help a lot here.
>
> I must have missed this "solution" (delete ttfonts file). Do you have a
> link to the thread or do you remember the discussion subject?
>
> cheers,
> steve

I just upgraded to matplotlib 0.87.2 from 0.85. I've been using Numeric 
and have not moved over to numpy yet. I'm getting the following error:
 from matplotlib.pylab import *
 File 
"/usr/lib/python2.4/site-packages/matplotlib-0.87.2-py2.4-linux-i686.egg/ 
matplotlib/pylab.py", line 196, in ?
 import cm
 File 
"/usr/lib/python2.4/site-packages/matplotlib-0.87.2-py2.4-linux-i686.egg/ 
matplotlib/cm.py", line 5, in ?
 import colors
 File 
"/usr/lib/python2.4/site-packages/matplotlib-0.87.2-py2.4-linux-i686.egg/ 
matplotlib/colors.py", line 33, in ?
 from numerix import array, arange, take, put, Float, Int, where, \
 File 
"/usr/lib/python2.4/site-packages/matplotlib-0.87.2-py2.4-linux-i686.egg/ 
matplotlib/numerix/__init__.py", line 66, in ?
 import numpy
ImportError: No module named numpy
The egg support is great!!
Thanks for your help.

On Friday 17 March 2006 08:25, Darren Dale wrote:
> On Friday 17 March 2006 04:19, Randewijk P-J <pjr...@su...> wrote:
> > Dear All,
> >
> > Using the new matplotlib-0.87.2 on Windows, I get the following error
> > message:
> >
> > File "c:\Python\lib\site-packages\matplotlib\texmanager.py", line 245,
> > in make_ps
> > stdout=PIPE, close_fds=True)
> > File "C:\Python\lib\subprocess.py", line 500, in __init__
> > raise ValueError("close_fds is not supported on Windows "
> > ValueError: close_fds is not supported on Windows platforms
>
> This is frustrating. subprocess is listed under the Generic Operating
> System Services in the Python Reference Manual, and there is no mention of
> incompatibility in the module's doc string.
>
> I suggest that usetex users on windows continue to use mpl-0.87.1 for now.
> I'll work on fixing this today.
Can anyone tell me if the popen2 module is compatible with MacOS? From the 
docs: "This module allows you to spawn processes and connect their i/o/err 
pipes and obtain return codes under Unix and Windows."

On Friday 17 March 2006 04:19, Randewijk P-J <pjr...@su...> wrote:
> Dear All,
>
> Using the new matplotlib-0.87.2 on Windows, I get the following error
> message:
>
> File "c:\Python\lib\site-packages\matplotlib\texmanager.py", line 245,
> in make_ps
> stdout=PIPE, close_fds=True)
> File "C:\Python\lib\subprocess.py", line 500, in __init__
> raise ValueError("close_fds is not supported on Windows "
> ValueError: close_fds is not supported on Windows platforms
This is frustrating. subprocess is listed under the Generic Operating System 
Services in the Python Reference Manual, and there is no mention of 
incompatibility in the module's doc string.
I suggest that usetex users on windows continue to use mpl-0.87.1 for now. 
I'll work on fixing this today.

Hubert Fitch wrote
> If not, is there somewhre a list definitely compatible components,
> and a list of steps to follow, that will definitely result
> in a working marriage of Python and Matplotlib?
>
> Yes I have been trying to read doccumentation, FAQ, etc.
> but I can't quite put it all together.
>
> Thanks for any help.that anyone can give.
Do note that if you are using IDLE, the only backend you can reliably use is
TkAgg (and this is noted in the documentation). Also note that it requires
starting IDLE with a special switch (-n). See
http://matplotlib.sourceforge.net/backends.html
Under tht Tkinter GUI backend heading.
Note that generally use of an application that uses a GUI toolkit (i.e.
IDLE) generally will not work in the same process with a different GUI
toolkit. Since IDLE uses Tkinter, you need to use the TkAgg backend only.
This is not a Python issue but a GUI issue.
Perry Greenfield

Willi Richert wrote:
> Am Montag, 16. Januar 2006 17:14 schrieb Steve Schmerler:
> 
>>Hi
>>
>>With MPL 0.86 and 0.86.1 I found that the axes labels aren't centered
>>(i.e. the xlabel is on the left side of the x-axis, the ylabel on the
>>"bottom" of the y-axis). What's up?
>>
>>cheers,
>>steve
> 
> 
> I have exactly the same problem. I've posted it some months ago on this list 
> and the solution (delete ttfonts file) did not work for me. Is there some 
> news regarding this error?
> 
No. I posted several times about this issue but unfortunately nobody 
seems to have this problem and/or a solution. If you're also running 
Debian sagre stable then I guess one of the (many) libs that mpl is 
using is too old/buggy in stable.
On the other hand, my "workarround" (installing 0.82 debs first) shows 
that newer versions probably read some lib files written from 0.82. I 
didn't have time to fiddle out the details. At least a hint from a 
developer would help a lot here.
I must have missed this "solution" (delete ttfonts file). Do you have a 
link to the thread or do you remember the discussion subject?
cheers,
steve
-- 
Random number generation is the art of producing pure gibberish as 
quickly as possible.