Hello, When I tried out "python simple_plot.py" and tried to save it as a png file, python crashes. No problem with saving it to jpeg, though. My system: W2K SP4/Python2.3.2/matplotlib-0.31 Here's some traceback: <quote> python.exe caused an Access Violation at location 77f92373 in module ntdll.dll Writing to location 00000010. Registers: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=7803a710 edi=00000000 eip=77f92373 esp=0012e83c ebp=0012e89c iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000202 Call stack: 77F92373 ntdll.dll:77F92373 RtlpWaitForCriticalSection 77F922F8 ntdll.dll:77F922F8 RtlImageDirectoryEntryToData 03B5C06C libpng.dll:03B5C06C png_set_read_fn 01F5F480 00FA5192 libgdk_pixbuf-2.0-0.dll:00FA5192 gdk_pixbuf_new_from_xpm_data 00FA53FF libgdk_pixbuf-2.0-0.dll:00FA53FF gdk_pixbuf_savev 00E822DA _gtk.pyd:00E822DA init_gtk 1E0591AA python23.dll:1E0591AA PyCFunction_Call </quote> Regards, ST --
>>>>> "LUK" == LUK ShunTim <shu...@po...> writes: LUK> Hello, When I tried out "python simple_plot.py" and tried to LUK> save it as a png file, python crashes. No problem with saving LUK> it to jpeg, though. I haven't seen that before. It works fine on my system (Windows ME) and noone else has reported a win32 problem. The fact that it works with jpeg and not png suggests a lib PNG problem. What version of pygtk and GTK-Runtime are you using. If you are using pygtk-2.0.0 and GTK-Runtime-2.2.4.1, then you should be OK. Have you installed an earlier version of these libs, possibly creating a library conflict? When you search for libpng, what turns up? JDH
John Hunter wrote: >>>>>>"LUK" == LUK ShunTim <shu...@po...> writes: > > > LUK> Hello, When I tried out "python simple_plot.py" and tried to > LUK> save it as a png file, python crashes. No problem with saving > LUK> it to jpeg, though. > > I haven't seen that before. It works fine on my system (Windows ME) > and noone else has reported a win32 problem. The fact that it works > with jpeg and not png suggests a lib PNG problem. What version of > pygtk and GTK-Runtime are you using. If you are using pygtk-2.0.0 and > GTK-Runtime-2.2.4.1, then you should be OK. Have you installed an > earlier version of these libs, possibly creating a library conflict? > > When you search for libpng, what turns up? > > JDH > GTK 2.2.4 (Can't remember where I got it. There's been a few of these floating around.) Pygtk 2.0.0 from the link in matplotlib site. Somehow my GTK runtime don't have the png, jpeg etc images libraries and I got them from the gnuwin32 sf site. I followed the link in the matplotlib site and installed gtk 2.2.4.1 from the sf site and the problem goes away. This version has all the images libraries with them. I must bookmark it! Another question: I've set the environmental variable AFMPATH in the registry via the control panel but matplotlib complains that the .afm files are not there. <quote> H:00円work00円cvs\matplotlib\matplotlib\examples>python simple_plot.py -dPS Error: Could not find any AFM files; please set AFMPATH to point to some readable adobe font metric files H:00円work00円cvs\matplotlib\matplotlib\examples>echo %AFMPATH% E:\Py23e\share\matplotlib </quote> This is a W2K system. Thanks very much, ST --
>>>>> "LUK" == LUK ShunTim <shu...@po...> writes:
LUK> I followed the link in the matplotlib site and installed gtk
LUK> 2.2.4.1 from the sf site and the problem goes away. This
LUK> version has all the images libraries with them. I must
LUK> bookmark it!
Good news ...
LUK> Another question: I've set the environmental variable AFMPATH
LUK> in the registry via the control panel but matplotlib
LUK> complains that the .afm files are not there.
I cannot replicate this problem on my system. Are the *.afm files in
E:\Py23e\share\matplotlib? Are you sure you are running the right
version of python, ie, do you still get the error with
> E:\Py23e\python simple_plot.ps -dPS
You might want to add a diagnostic debug line to
backends/backend_ps.py to print the paths that it is searching. After
line 422 in that file, insert a new line that prints the paths, eg,
def _get_afm_filenames(self):
paths = [os.path.join(distutils.sysconfig.PREFIX, 'share', 'matplotlib')]
if os.environ.has_key('AFMPATH'):
afmpath = os.environ['AFMPATH']
if afmpath.find(';')>0: #win32 style
paths.extend(afmpath.split(';'))
elif afmpath.find(':')>0: # unix style
paths.extend(afmpath.split(':'))
else:
paths.append(afmpath)
*** print paths
fnames = []
And let me know what it reports. If you are using the fonts that ship
with matplotlib, you shouldn't even need to set the AFMPATH because it
automatically looks in the share/matplotlib subdir of your python
install dir.
You may also want to verify that matplotlib is finding your
environment variable by doing
> python
>>> import os
>>> print os.environ.has_key('AFMPATH')
If the *.afm fonts are in the share/matplotlib dir, and you are using
the right python, and the paths look correct from the diagnostic
information above, the only thing I can think of is that these files
are not readable by you (admin versus user thing?). To test this try
> python
>>> fh = file('E:\Py23e\\share\\matplotlib\\phvl8a.afm', 'r')
>>> s = fh.read()
>>> len(s)
Let me know....
JDH
John Hunter wrote:
>
> LUK> Another question: I've set the environmental variable AFMPATH
> LUK> in the registry via the control panel but matplotlib
> LUK> complains that the .afm files are not there.
>
> I cannot replicate this problem on my system. Are the *.afm files in
> E:\Py23e\share\matplotlib? Are you sure you are running the right
> version of python, ie, do you still get the error with
>
> > E:\Py23e\python simple_plot.ps -dPS
>
[snipped]
>
> And let me know what it reports. If you are using the fonts that ship
> with matplotlib, you shouldn't even need to set the AFMPATH because it
> automatically looks in the share/matplotlib subdir of your python
> install dir.
I can confirm that if the font files are installed in the default
location under the system python tree, it works. Setting AFMPATH also
works in linux.
>
> You may also want to verify that matplotlib is finding your
> environment variable by doing
>
>
>>python
>>
>>>>import os
>>>>print os.environ.has_key('AFMPATH')
>
>>> import os
>>> os.environ["AFMPATH"]
'E:\\Py23e\\share\\matplotlib'
>
> If the *.afm fonts are in the share/matplotlib dir, and you are using
> the right python, and the paths look correct from the diagnostic
> information above, the only thing I can think of is that these files
> are not readable by you (admin versus user thing?). To test this try
>
>
>>python
>>
>>>>fh = file('E:\Py23e\\share\\matplotlib\\phvl8a.afm', 'r')
>>>>s = fh.read()
>>>>len(s)
>
>>> fh = file('E:\Py23e\\share\\matplotlib\\afm\\phvl8a.afm', 'r')
>>> len(fh.read())
15627
>
> Let me know....
> JDH
>
Regards,
ST
--
> I can confirm that if the font files are installed in the default > location under the system python tree, it works. Setting AFMPATH also > works in linux. OK, so the font files exist and are readable. In order to figure out where the problem is, I'll need you to add a couple of lines to matplotlib/backends/backend_ps.py and tell me what the output is. In the function _get_afm_filenames on line 413, add these print lines before the return statement and let me know what they report print paths print fnames return fnames John Hunter
John Hunter wrote: > > I can confirm that if the font files are installed in the default > > location under the system python tree, it works. Setting AFMPATH also > > works in linux. > > OK, so the font files exist and are readable. In order to figure out > where the problem is, I'll need you to add a couple of lines to > matplotlib/backends/backend_ps.py and tell me what the output is. In > the function _get_afm_filenames on line 413, add these print lines > before the return statement and let me know what they report > > print paths > print fnames > return fnames > > John Hunter H:00円work00円cvs\matplotlib\matplotlib\examples>python subplot_demo.py -dPS ['E:\\Py23\\share\\matplotlib', 'E', '\\Py23e\\share\\matplotlib'] [] Error: Could not find any AFM files; please set AFMPATH to point to some readable adobe font metric files Regards, ST --
LUK ShunTim wrote:
> John Hunter wrote:
>
>> > I can confirm that if the font files are installed in the default
>> > location under the system python tree, it works. Setting AFMPATH also
>> > works in linux.
>>
>> OK, so the font files exist and are readable. In order to figure out
>> where the problem is, I'll need you to add a couple of lines to
>> matplotlib/backends/backend_ps.py and tell me what the output is. In
>> the function _get_afm_filenames on line 413, add these print lines
>> before the return statement and let me know what they report
>>
>> print paths
>> print fnames
>> return fnames
>>
>> John Hunter
>
>
> H:00円work00円cvs\matplotlib\matplotlib\examples>python subplot_demo.py -dPS
> ['E:\\Py23\\share\\matplotlib', 'E', '\\Py23e\\share\\matplotlib']
> []
> Error: Could not find any AFM files; please set AFMPATH to point to some
> readable adobe font metric files
>
> Regards,
> ST
> --
It appears that the following replacement of _get_afm_filenames
works. I'm a python learner so that may lead to other bugs. :-)
<quote>
def _get_afm_filenames(self):
paths = [os.path.join(distutils.sysconfig.PREFIX, 'share',
'matplotlib')]
if os.environ.has_key('AFMPATH'):
afmpath = os.environ['AFMPATH']
### if afmpath.find(';')>0: #win32 style
### paths.extend(afmpath.split(';'))
### elif afmpath.find(':')>0: # unix style
### paths.extend(afmpath.split(':'))
### else:
paths.append(afmpath)
fnames = []
fnames = [fname for fname in get_recursive_filelist(paths)
if fname.lower().find('.afm')>0 and
os.path.exists(fname)]
### start debug
#print paths
#print fnames
###raw_input("Hit enter to continue -->")
### end debug
return fnames
</quote>
I'm going to sleep now. :-)
Good day,
ST
--
>>>>> "LUK" == LUK ShunTim <shu...@po...> writes:
H:00円work00円cvs\matplotlib\matplotlib\examples>python subplot_demo.py -dPS
['E:\\Py23\\share\\matplotlib', 'E', '\\Py23e\\share\\matplotlib']
Oh, I see the bug. The reason the lines are there that you commented
out is to allow you to specify multiple font dirs in your path, as in
set AFMPATH = c:\somepath\fonts;e:\some\other\path\fonts
But I wasn't properly doing a platform independent path split.
The code should read
def _get_afm_filenames(self):
paths = [os.path.join(distutils.sysconfig.PREFIX, 'share', 'matplotlib')]
if os.environ.has_key('AFMPATH'):
afmpath = os.environ['AFMPATH']
paths.extend(afmpath.split(os.pathsep))
fnames = [fname for fname in get_recursive_filelist(paths)
if fname.lower().find('.afm')>0 and
os.path.exists(fname)]
return fnames
Thanks for helping me diagnose it. Please let me know if the above
works on your system!
John Hunter
John Hunter wrote:
>>>>>>"LUK" == LUK ShunTim <shu...@po...> writes:
>
>
> H:00円work00円cvs\matplotlib\matplotlib\examples>python subplot_demo.py -dPS
> ['E:\\Py23\\share\\matplotlib', 'E', '\\Py23e\\share\\matplotlib']
>
> Oh, I see the bug. The reason the lines are there that you commented
> out is to allow you to specify multiple font dirs in your path, as in
>
Yes, the previous version caught the ":" in the drive letter specification.
> set AFMPATH = c:\somepath\fonts;e:\some\other\path\fonts
>
> But I wasn't properly doing a platform independent path split.
>
> The code should read
>
> def _get_afm_filenames(self):
> paths = [os.path.join(distutils.sysconfig.PREFIX, 'share', 'matplotlib')]
> if os.environ.has_key('AFMPATH'):
> afmpath = os.environ['AFMPATH']
> paths.extend(afmpath.split(os.pathsep))
>
> fnames = [fname for fname in get_recursive_filelist(paths)
> if fname.lower().find('.afm')>0 and
> os.path.exists(fname)]
>
> return fnames
>
Yes, it works. I had thought of testing for "if OS == win" sort of stuff
instead of testing for the presence of ";" or ":". But it appears that
Python has the foresight to provide os.pathsep. I learnt a bit more and
love Python a bit more. :-)
>
> Thanks for helping me diagnose it. Please let me know if the above
> works on your system!
>
> John Hunter
>
You deserve much thanks for developing such a nice package.
An afterthought: perhaps an EPS backend instead of/additional to a PS
backend would be more convenient for inclusion into publications. I
know very little about postscript programming so I don't know what's the
effort involved, though.
Best regards,
ST
--
>>>>> "LUK" == LUK ShunTim <shu...@po...> writes: LUK> You deserve much thanks for developing such a nice package. Thanks! LUK> An afterthought: perhaps an EPS backend instead of/additional LUK> to a PS backend would be more convenient for inclusion into LUK> publications. I know very little about postscript programming LUK> so I don't know what's the effort involved, though. Not much at all. As far as I know, the only difference between eps and ps is a bounding box at the top of the document which gives the figure dimensions. It shouldn't be hard to check for an extension in the savefig command and add the bounding box if eps is requested. I use postscript (*.ps) directly in my LaTeX documents without trouble, however. Are you using LaTeX? JDH
John Hunter wrote: >>>>>>"LUK" == LUK ShunTim <shu...@po...> writes: > > > LUK> You deserve much thanks for developing such a nice package. > > Thanks! > > LUK> An afterthought: perhaps an EPS backend instead of/additional > LUK> to a PS backend would be more convenient for inclusion into > LUK> publications. I know very little about postscript programming > LUK> so I don't know what's the effort involved, though. > > Not much at all. As far as I know, the only difference between eps > and ps is a bounding box at the top of the document which gives the > figure dimensions. It shouldn't be hard to check for an extension in > the savefig command and add the bounding box if eps is requested. > > I use postscript (*.ps) directly in my LaTeX documents without > trouble, however. Are you using LaTeX? > Yes, but I think LaTeX requires the bounding box information. I can think of the quick and dirty way of calling the ps2eps script to do the conversion but it requires perl and ghostscript. Since the postscript backend is already there in matplotlib, it'd be nice to have the eps option directly. Regards, ST --
>>>>> "LUK" == LUK ShunTim <shu...@po...> writes:
LUK> Yes, but I think LaTeX requires the bounding box information.
Here is how I use PS (not eps) directly in LaTeX. The first arg to
difig specifies the figure size.
\usepackage[dvips]{graphics}
\newcommand{\dofig}[2]
{\center{\scalebox{#1}{\includegraphics*{#2}}}}
\begin{figure}[t]
\dofig{0.5}{somefile.ps}
\caption{\footnotesize Insert your figure caption here}
\label{fig:figref}
\end{figure}
LUK> I can think of the quick and dirty way of calling the ps2eps
LUK> script to do the conversion but it requires perl and
LUK> ghostscript. Since the postscript backend is already there in
LUK> matplotlib, it'd be nice to have the eps option directly.
Agreed.
JDH
John, I'd second the request for direct EPS. Sometimes you can get away without the bounding box, but not always. I've been using ps2epsi to convert my matplot .ps files into .eps files (.epsi is .eps with a preview, but I don't need the preview). It does a good job of finding bounding boxes. That's very important for running epstopdf on the images. That gives me pdf images so I can run pdflatex and generate a native PDF file from my LaTeX. -C -- Charles R. Twardy www.csse.monash.edu.au/~ctwardy Monash University sarbayes.org Computer Sci. & Software Eng. +61(3) 9905 5823 (w) 5146 (fax)
>>>>> "Charles" == Charles <ct...@cs...> writes: Charles> John, I'd second the request for direct EPS. Sometimes Charles> you can get away without the bounding box, but not Charles> always. I've been using ps2epsi to convert my matplot .ps Charles> files into .eps files (.epsi is .eps with a preview, but Charles> I don't need the preview). It does a good job of finding Charles> bounding boxes. That's very important for running Charles> epstopdf on the images. That gives me pdf images so I can Charles> run pdflatex and generate a native PDF file from my Charles> LaTeX. I'll see if I can get EPS into the ps backend in the near future. As far as I know, it should just be a matter of adding a bounding box. Note that you don't need to first convert your images to PDF to generate PDF from LaTeX (though a PDF backend is on the TODO list). I routinely generate PDF documents from LaTeX src with *.ps inputs as follows # With recent version of gv (7.x or later) do > dvips -Pcmz -Pamz -G1 -Ppdf -o final3.ps final3.dvi > ps2pdf final3.ps This will generate high quality PDF w/o the blurry appearance in acroread that you sometimes see with PDF generated by LaTeX. Hope this helps! John Hunter
Interesting. My experience is that pdflatex generates crisp and compact pdf, though I usually use xpdf to view. I hadn't had similar luck with ps2pdf but the -?mz may help. -C JH: > dvips -Pcmz -Pamz -G1 -Ppdf -o final3.ps final3.dvi JH: > ps2pdf final3.ps JH:This will generate high quality PDF w/o the blurry appearance in JH:acroread that you sometimes see with PDF generated by LaTeX.
John, Either sourceforge is behind or the change didn't fix the xticklabels([]). If you're around, can you email the file with the fix? In the meantime I'll try to make sure I'm not using a mirror. -C -- Charles R. Twardy www.csse.monash.edu.au/~ctwardy Monash University sarbayes.org Computer Sci. & Software Eng. +61(3) 9905 5823 (w) 5146 (fax)
Hmm. Current I seem to have to blank y and x axes separately. ax.set_yticklabels([]) # works fine ax.set_xticklabels([]) # nope # but... ax.set_xticklabels([ '' for x in blah ]) # yep Given that both call ticklabels, I'm not sure why. -C -- Charles R. Twardy www.csse.monash.edu.au/~ctwardy Monash University sarbayes.org Computer Sci. & Software Eng. +61(3) 9905 5823 (w) 5146 (fax)