matplotlib-users Mailing List for matplotlib

Greetings
I am trying to install matplotlib 0.98.1 on python 2.5.1 on Mac OS X 
10.5.3. The install breaks at the required dependancy numpy 1.1 
because it thinks it has v 1.0.1. I have, in fact, installed numpy 1.1 
and I can't figure out why the matplotlib installer is not seeing it. 
I am not entirely familiar with installing python tools on Macs. Can 
anyone point out a build parameter or a common newbie error or any 
other info so I can resolve the dependancy?
Thanks
Mike

Hello,
I tried to do a stem plot on an Axes with logarithmic scale, experiencing that the stemlines were not drawn...
====axes.py (svn trunk, 2008年07月08日):
def stem(self, x, y, linefmt='b-', markerfmt='bo', basefmt='r-'):
[...]
 stemlines = []
 for thisx, thisy in zip(x, y):
 l, = self.plot([thisx,thisx], [0, thisy], linefmt)
 stemlines.append(l)
After Axes.set_yscale('log'), Axes.stem() no longer draws the stemlines because it tries to draw from y=0, thereby apparently triggering some guard which prevents plotting log(0), hence suppressing the complete stemline.
Dirty hacking, I replace [0, thisy] with [1, thisy] in case yscale=='log' and it works for my plots, but for sure there is more to do to make it robust...
Please give me a heads-up if I just oversaw the Right Way to do a stem plot with logarithmic yscale.
Cheers,
Dirk

Yves Revaz wrote:
> Hi all,
> 
> Is there a way to define logarithmic axes when using axes3d ?
> 
> lines like
> ax = axes3d.Axes3D(fig)
> 
> ax.semilogx()
> or
> ax.set_xscale('log')
> 
> fail !
> 
> Thanks,
> 
> yves
> 
You are on your own with axes3d. It has been unmaintained for a long 
time, and therefore it has been removed from the svn trunk.
Eric

Thanks for the report. It's a bit convoluted, but it is automatable, at 
least, and I'm glad to see it works for you.
I'd like to see a Cairo expert take on the task of upgrading our Cairo 
backend to use Pango. That would make this a little cleaner and 
theoretically fix the text alignment problem with your method (i.e. the 
titles are not exactly centered since its width is based on a naive 
rendering of the text). I have no concept of how much work that would 
be. Though it's also possible that that would just run up against other 
assumptions that matplotlib makes about text.
Cheers,
Mike
Mathieu Leplatre wrote:
> Thank you Michael and Darren.
>
> I'll keep your information for further polishing :
>
> So far, I am not having problems with my two-steps solution :
>
> 1) SVG backend
> 2) rsvg + Cairo, code snippet :
>
> svg = rsvg.Handle( filesvg )
> width = svg.props.width
> height = svg.props.height
> surface = cairo.ImageSurface (cairo.FORMAT_ARGB32, width, height)
> cr = cairo.Context (surface)
> svg.render_cairo (cr)
> surface.write_to_png (filepng)
>
> Thanks again for your assistance ! Long live sub-cultures and their
> exotic writings !
>
>
> 2008年6月25日 Mathieu Leplatre <lep...@gm...>:
> 
>> Well, I'll give a try towards another possibility :
>> 1 - use SVG output with rc setting : svg.embed_char_paths" to False
>> 2 - use cairo to export to PNG/JPG etc..
>>
>> Step 1 works great natively with Arabic (at least viewing it with Inkscape).
>> Let's see if I have problems with step 2.
>>
>> 2008年6月25日 Darren Dale <dsd...@gm...>:
>> 
>>> Hi Mathieu,
>>>
>>> Are there perhaps some latex packages you could load using the
>>> text.latex.preamble rc setting? This setting is officially unsupported, but
>>> it would be much easier than adding an option to use the xetex executable
>>> (which would probably not be officially supported by mpl).
>>>
>>> Darren
>>>
>>> On Wednesday 25 June 2008 09:02:41 am Mathieu Leplatre wrote:
>>> 
>>>> Hi all,
>>>>
>>>> I have been trying to follow your tips regarding matplotlib and arabic
>>>> support.
>>>>
>>>> Indeed matplotlib with Latex and unicode work great together :
>>>>
>>>> #-*- coding: utf-8 -*-
>>>> from pylab import *
>>>> from matplotlib import rcParams
>>>> rcParams['text.usetex']=True
>>>> rcParams['text.latex.unicode']=True
>>>> figure(1)
>>>> plot([1,2,3])
>>>> title(unicode(r'\textit{éèê}','utf8'))
>>>> show()
>>>>
>>>> But then I came to the conclusion that Latex did not support Arabic.
>>>> This few lines generate a "missing def" error.
>>>>
>>>> \documentclass{article}
>>>> \usepackage{ucs}
>>>> \usepackage[utf8x]{inputenc}
>>>> \title{éèê هه}
>>>> \begin{document}
>>>> \maketitle
>>>> \end{document}
>>>>
>>>> Is it related to my installation ? (Ubuntu with package
>>>> texlive-latex-recommended)
>>>> I asked here : http://ubuntuforums.org/showthread.php?p=5258457
>>>>
>>>> Somebody pointed me out XeTeX, which has wider support for Unicode.
>>>> www.tug.org/TUGboat/Articles/tb27-2/tb87kew.pdf
>>>>
>>>> I was wondering if there could be a way to get matplotlib work with XeTeX.
>>>>
>>>> What do you think ? Is it the right track ? Should I switch to
>>>> grandpa's gnuplot :) ?
>>>>
>>>> Thank you all,
>>>>
>>>> Mathieu.
>>>>
>>>> Michael Droettboom wrote:
>>>> 
>>>>> Unfortunately, I believe this is a fundamental incompatibility within
>>>>> matplotlib. matplotlib uses a very simple algorithm for layout out a
>>>>> line of characters which assumes ltr order and all kinds of other things.
>>>>>
>>>>> That said, there is something you could try. Matplotlib has a "usetex"
>>>>> mode which will do all text rendering using LaTeX. Assuming you can get
>>>>> LaTeX to handle Arabic correctly, you can set the following in your
>>>>> .matplotlibrc file:
>>>>>
>>>>> text.usetex : True
>>>>> text.latex.unicode : True
>>>>>
>>>>> You'll need to install the LaTeX Unicode extension "ucs" (Ubuntu
>>>>> probably has packages for that.) If you need to load any LaTeX packages
>>>>> to get arabic support, you can tell matplotlib about them in your
>>>>> matplotlibrc like so:
>>>>>
>>>>> text.latex.preamble: \usepackage{foo}
>>>>>
>>>>> If Arabic-encoded-as-Unicode doesn't work, you could try setting
>>>>> "text.latex.unicode" to False, and then typing your Arabic strings using
>>>>> one of the other Arabic encodings that LaTeX understands.
>>>>>
>>>>> Please let us know if you have success or hit another roadblock.
>>>>>
>>>>> Cheers,
>>>>> Mike
>>>>>
>>>>> Burhan Khalid wrote:
>>>>> 
>>>>>> Hello All:
>>>>>>
>>>>>> Having an issue with Arabic font support using matplotlib. When using
>>>>>> the correct font, Arabic characters are displayed, but are not joined
>>>>>> together
>>>>>> properly; and they are also not in the correct order (the font rendered
>>>>>> is ltr, but Arabic is a rtl language). Is this an issue with the render
>>>>>> I am using, or some incompatibility within matplotlib? Sample source
>>>>>> code used (please note, your email client should support utf8 to display
>>>>>> the code correctly).
>>>>>>
>>>>>> #-*- coding: utf-8 -*-
>>>>>> from pylab import *
>>>>>> figure(1) # the first figure
>>>>>> plot([1,2,3])
>>>>>> figure(1) # figure 1 current
>>>>>> title(u'برهان',name='Times New Roman') # figure 1 title
>>>>>> savefig('test.png')
>>>>>> savefig('test.eps')
>>>>>> show()
>>>>>>
>>>>>> Output when run from the command line:
>>>>>>
>>>>>> matplotlib data path /usr/share/matplotlib/mpl-data
>>>>>> $HOME=/home/burhan
>>>>>> CONFIGDIR=/home/burhan/.matplotlib
>>>>>> loaded rc file /etc/matplotlibrc
>>>>>> matplotlib version 0.90.1
>>>>>> verbose.level helpful
>>>>>> interactive is False
>>>>>> units is True
>>>>>> platform is linux2
>>>>>> numerix numpy 1.0.3
>>>>>> font search path ['/usr/share/matplotlib/mpl-data/fonts/ttf',
>>>>>> '/usr/share/matplotlib/mpl-data/fonts/afm']
>>>>>> loaded ttfcache file /home/burhan/.matplotlib/ttffont.cache
>>>>>> backend TkAgg version 8.4
>>>>>> Could not match Bitstream Vera Serif, New Century Schoolbook, Century
>>>>>> Schoolbook L, Utopia, ITC Bookman, Bookman, Nimbus Roman No9 L, Times
>>>>>> New Roman, Times, Palatino, Charter, serif, normal, normal. Returning
>>>>>> /usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf
>>>>>>
>>>>>> This is on a clean Ubuntu Gutsy install, using python 2.5.1.
>>>>>>
>>>>>> Thanks,
>>>>>> Burhan
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>> - This SF.net email is sponsored by: Splunk Inc.
>>>>>> Still grepping through log files to find problems? Stop.
>>>>>> Now Search log events and configuration files using AJAX and a browser.
>>>>>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>>
>>>>>> _______________________________________________
>>>>>> Matplotlib-users mailing list
>>>>>> Mat...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>>> 
>>>>> --
>>>>> Michael Droettboom
>>>>> Science Software Branch
>>>>> Operations and Engineering Division
>>>>> Space Telescope Science Institute
>>>>> Operated by AURA for NASA
>>>>>
>>>>> -------------------------------------------------------------------------
>>>>> This SF.net email is sponsored by: Splunk Inc.
>>>>> Still grepping through log files to find problems? Stop.
>>>>> Now Search log events and configuration files using AJAX and a browser.
>>>>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>>>>> _______________________________________________
>>>>> Matplotlib-users mailing list
>>>>> Mat...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>> 
>>>> -------------------------------------------------------------------------
>>>> Check out the new SourceForge.net Marketplace.
>>>> It's the best place to buy or sell services for
>>>> just about anything Open Source.
>>>> http://sourceforge.net/services/buy/index.php
>>>> _______________________________________________
>>>> Matplotlib-users mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>> 
>>>
>>> 
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Thank you Michael and Darren.
I'll keep your information for further polishing :
So far, I am not having problems with my two-steps solution :
1) SVG backend
2) rsvg + Cairo, code snippet :
svg = rsvg.Handle( filesvg )
width = svg.props.width
height = svg.props.height
surface = cairo.ImageSurface (cairo.FORMAT_ARGB32, width, height)
cr = cairo.Context (surface)
svg.render_cairo (cr)
surface.write_to_png (filepng)
Thanks again for your assistance ! Long live sub-cultures and their
exotic writings !
2008年6月25日 Mathieu Leplatre <lep...@gm...>:
> Well, I'll give a try towards another possibility :
> 1 - use SVG output with rc setting : svg.embed_char_paths" to False
> 2 - use cairo to export to PNG/JPG etc..
>
> Step 1 works great natively with Arabic (at least viewing it with Inkscape).
> Let's see if I have problems with step 2.
>
> 2008年6月25日 Darren Dale <dsd...@gm...>:
>> Hi Mathieu,
>>
>> Are there perhaps some latex packages you could load using the
>> text.latex.preamble rc setting? This setting is officially unsupported, but
>> it would be much easier than adding an option to use the xetex executable
>> (which would probably not be officially supported by mpl).
>>
>> Darren
>>
>> On Wednesday 25 June 2008 09:02:41 am Mathieu Leplatre wrote:
>>> Hi all,
>>>
>>> I have been trying to follow your tips regarding matplotlib and arabic
>>> support.
>>>
>>> Indeed matplotlib with Latex and unicode work great together :
>>>
>>> #-*- coding: utf-8 -*-
>>> from pylab import *
>>> from matplotlib import rcParams
>>> rcParams['text.usetex']=True
>>> rcParams['text.latex.unicode']=True
>>> figure(1)
>>> plot([1,2,3])
>>> title(unicode(r'\textit{éèê}','utf8'))
>>> show()
>>>
>>> But then I came to the conclusion that Latex did not support Arabic.
>>> This few lines generate a "missing def" error.
>>>
>>> \documentclass{article}
>>> \usepackage{ucs}
>>> \usepackage[utf8x]{inputenc}
>>> \title{éèê هه}
>>> \begin{document}
>>> \maketitle
>>> \end{document}
>>>
>>> Is it related to my installation ? (Ubuntu with package
>>> texlive-latex-recommended)
>>> I asked here : http://ubuntuforums.org/showthread.php?p=5258457
>>>
>>> Somebody pointed me out XeTeX, which has wider support for Unicode.
>>> www.tug.org/TUGboat/Articles/tb27-2/tb87kew.pdf
>>>
>>> I was wondering if there could be a way to get matplotlib work with XeTeX.
>>>
>>> What do you think ? Is it the right track ? Should I switch to
>>> grandpa's gnuplot :) ?
>>>
>>> Thank you all,
>>>
>>> Mathieu.
>>>
>>> Michael Droettboom wrote:
>>> > Unfortunately, I believe this is a fundamental incompatibility within
>>> > matplotlib. matplotlib uses a very simple algorithm for layout out a
>>> > line of characters which assumes ltr order and all kinds of other things.
>>> >
>>> > That said, there is something you could try. Matplotlib has a "usetex"
>>> > mode which will do all text rendering using LaTeX. Assuming you can get
>>> > LaTeX to handle Arabic correctly, you can set the following in your
>>> > .matplotlibrc file:
>>> >
>>> > text.usetex : True
>>> > text.latex.unicode : True
>>> >
>>> > You'll need to install the LaTeX Unicode extension "ucs" (Ubuntu
>>> > probably has packages for that.) If you need to load any LaTeX packages
>>> > to get arabic support, you can tell matplotlib about them in your
>>> > matplotlibrc like so:
>>> >
>>> > text.latex.preamble: \usepackage{foo}
>>> >
>>> > If Arabic-encoded-as-Unicode doesn't work, you could try setting
>>> > "text.latex.unicode" to False, and then typing your Arabic strings using
>>> > one of the other Arabic encodings that LaTeX understands.
>>> >
>>> > Please let us know if you have success or hit another roadblock.
>>> >
>>> > Cheers,
>>> > Mike
>>> >
>>> > Burhan Khalid wrote:
>>> >> Hello All:
>>> >>
>>> >> Having an issue with Arabic font support using matplotlib. When using
>>> >> the correct font, Arabic characters are displayed, but are not joined
>>> >> together
>>> >> properly; and they are also not in the correct order (the font rendered
>>> >> is ltr, but Arabic is a rtl language). Is this an issue with the render
>>> >> I am using, or some incompatibility within matplotlib? Sample source
>>> >> code used (please note, your email client should support utf8 to display
>>> >> the code correctly).
>>> >>
>>> >> #-*- coding: utf-8 -*-
>>> >> from pylab import *
>>> >> figure(1) # the first figure
>>> >> plot([1,2,3])
>>> >> figure(1) # figure 1 current
>>> >> title(u'برهان',name='Times New Roman') # figure 1 title
>>> >> savefig('test.png')
>>> >> savefig('test.eps')
>>> >> show()
>>> >>
>>> >> Output when run from the command line:
>>> >>
>>> >> matplotlib data path /usr/share/matplotlib/mpl-data
>>> >> $HOME=/home/burhan
>>> >> CONFIGDIR=/home/burhan/.matplotlib
>>> >> loaded rc file /etc/matplotlibrc
>>> >> matplotlib version 0.90.1
>>> >> verbose.level helpful
>>> >> interactive is False
>>> >> units is True
>>> >> platform is linux2
>>> >> numerix numpy 1.0.3
>>> >> font search path ['/usr/share/matplotlib/mpl-data/fonts/ttf',
>>> >> '/usr/share/matplotlib/mpl-data/fonts/afm']
>>> >> loaded ttfcache file /home/burhan/.matplotlib/ttffont.cache
>>> >> backend TkAgg version 8.4
>>> >> Could not match Bitstream Vera Serif, New Century Schoolbook, Century
>>> >> Schoolbook L, Utopia, ITC Bookman, Bookman, Nimbus Roman No9 L, Times
>>> >> New Roman, Times, Palatino, Charter, serif, normal, normal. Returning
>>> >> /usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf
>>> >>
>>> >> This is on a clean Ubuntu Gutsy install, using python 2.5.1.
>>> >>
>>> >> Thanks,
>>> >> Burhan
>>> >>
>>> >>
>>> >>
>>> >> ------------------------------------------------------------------------
>>> >>
>>> >> ------------------------------------------------------------------------
>>> >>- This SF.net email is sponsored by: Splunk Inc.
>>> >> Still grepping through log files to find problems? Stop.
>>> >> Now Search log events and configuration files using AJAX and a browser.
>>> >> Download your FREE copy of Splunk now >> http://get.splunk.com/
>>> >>
>>> >>
>>> >> ------------------------------------------------------------------------
>>> >>
>>> >> _______________________________________________
>>> >> Matplotlib-users mailing list
>>> >> Mat...@li...
>>> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>> >
>>> > --
>>> > Michael Droettboom
>>> > Science Software Branch
>>> > Operations and Engineering Division
>>> > Space Telescope Science Institute
>>> > Operated by AURA for NASA
>>> >
>>> > -------------------------------------------------------------------------
>>> > This SF.net email is sponsored by: Splunk Inc.
>>> > Still grepping through log files to find problems? Stop.
>>> > Now Search log events and configuration files using AJAX and a browser.
>>> > Download your FREE copy of Splunk now >> http://get.splunk.com/
>>> > _______________________________________________
>>> > Matplotlib-users mailing list
>>> > Mat...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>
>>> -------------------------------------------------------------------------
>>> Check out the new SourceForge.net Marketplace.
>>> It's the best place to buy or sell services for
>>> just about anything Open Source.
>>> http://sourceforge.net/services/buy/index.php
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>>
>>
>

Have a look here for some information about memory leaks:
http://matplotlib.sourceforge.net/faq.html#LEAKS
Can you provide a small standalone script that reproduces the error? It 
is possible that the figures are not being destroyed correctly because 
an extra reference is being held to them or something of that sort.
Cheers,
Mike
Maxime Bois wrote:
> Hi all,
>
> I have a problem of free memory for image buffer when I use Matplotlib 
> (the last version on linux).
> What i'm doing is that I create 4 figures in the same time, I save my 
> plots and I close them. After that, I create 4 new figures, save them 
> and close them... I do that many times and after a moment, a problem occurs.
> I obtain this message : "<class '_tkinter.TclError'>: not enough free 
> memory for image buffer" and my program stops.
>
> Does anyone have a solution for this problem ?
> Thanks a lot
> M.
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi all,
I have a problem of free memory for image buffer when I use Matplotlib 
(the last version on linux).
What i'm doing is that I create 4 figures in the same time, I save my 
plots and I close them. After that, I create 4 new figures, save them 
and close them... I do that many times and after a moment, a problem occurs.
I obtain this message : "<class '_tkinter.TclError'>: not enough free 
memory for image buffer" and my program stops.
Does anyone have a solution for this problem ?
Thanks a lot
M.

2008年7月8日 <mat...@li...>:
> On Thursday 03 July 2008 02:28:47 pm Michael Droettboom wrote:
>> Friedrich Hagedorn wrote:
>> > Hello,
>> >
>> > 2. Does anybody know a good python dirstibution including mpl?
>>
>> Enthought has one, but I have no experience with it.
>
> It might be worth keeping an eye on Python(x,y). It doesn't have a linux
> installer yet, but it looks like Pierre is working on it.
>
> Darren
That is correct, thank you Darren.
Actually *we* are working on it. And, honestly, I didn't and won't do
much on the linux version because I'm already too busy with the
Windows distribution (especially with the forthcoming 2.0 release):
one of my colleague is working on it. After a lot of public
(http://groups.google.com/group/pythonxy/browse_thread/thread/e5c707a1ac8bd4a4)
and private discussions on this, we have decided to distribute the
linux version as a metapackage. The first public release will
hopefully be available before the end of summer.
Pierre

On Thursday 03 July 2008 02:28:47 pm Michael Droettboom wrote:
> Friedrich Hagedorn wrote:
> > Hello,
> >
> > today I tried to install mpl in my local home directory at work. This
> > debian distribution is very old and I had to compile for my own.
> >
> > But I failed to compile pygtk (special cairo and pango) as a dependency
> > for mpl. So I have two questions:
> >
> > 1. Does you have an advice to compile mpl with minimal dependencies?
>
> You can copy "setup.cfg.template" to "setup.cfg" and then edit the [gui]
> section to disable certain GUIs. You will need at least one GUI --
> TkAgg is probably going to be the easiest to get working on an older
> system. You will need to have Tkinter and the Tcl/Tk development
> headers installed, however.
>
> > 2. Does anybody know a good python dirstibution including mpl?
>
> Enthought has one, but I have no experience with it.
It might be worth keeping an eye on Python(x,y). It doesn't have a linux 
installer yet, but it looks like Pierre is working on it.
Darren

Hi all,
Is there a way to define logarithmic axes when using axes3d ?
lines like
ax = axes3d.Axes3D(fig)
ax.semilogx()
or
ax.set_xscale('log')
fail !
Thanks,
yves
-- 
 (o o)
--------------------------------------------oOO--(_)--OOo-------
 Yves Revaz
 Laboratory of Astrophysics EPFL
 Observatoire de Sauverny Tel : ++ 41 22 379 24 28
 51. Ch. des Maillettes Fax : ++ 41 22 379 22 05
 1290 Sauverny e-mail : Yve...@ep...
 SWITZERLAND Web : http://www.lunix.ch/revaz/
----------------------------------------------------------------