matplotlib-users Mailing List for matplotlib

I have replaced the binary with a working version.
Thanks again for the catch,
 Charlie
On Jan 11, 2008 2:15 PM, Charlie Moad <cw...@gm...> wrote:
> Apparently a dynamic link snuck into the build. Typically everything
> is statically included. You can see this by running the following
> command:
>
> uaternion:matplotlib cmoad$ otool -L ft2font.so
> ft2font.so:
> /usr/local/lib/libfreetype.6.dylib (compatibility version 10.0.0,
> current version 10.16.0)
> /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
> /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 88.3.6)
> /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
>
> I will created and post a new build asap.
>
> Thanks,
> Charlie
>
> On Jan 11, 2008 1:50 PM, Michele Vallisneri
>
> <Mic...@jp...> wrote:
> > Hello all,
> >
> > after installing matplotlib 0.91.2 from the sourceforge egg on OS X
> > 10.4.11 (Python 2.5.1), I get the following error:
> >
> > >>> import pylab
> > Traceback (most recent call last):
> > File "<stdin>", line 1, in <module>
> > File "/Users/vallis/lib/python2.5/site-packages/matplotlib-0.91.2-
> > py2.5-macosx-10.3-fat.egg/matplotlib/pylab.py", line 208, in <module>
> > from matplotlib import mpl # pulls in most modules
> > File "/Users/vallis/lib/python2.5/site-packages/matplotlib-0.91.2-
> > py2.5-macosx-10.3-fat.egg/matplotlib/mpl.py", line 3, in <module>
> > from matplotlib import axis
> > File "/Users/vallis/lib/python2.5/site-packages/matplotlib-0.91.2-
> > py2.5-macosx-10.3-fat.egg/matplotlib/axis.py", line 20, in <module>
> > from font_manager import FontProperties
> > File "/Users/vallis/lib/python2.5/site-packages/matplotlib-0.91.2-
> > py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", line 40, in
> > <module>
> > from matplotlib import ft2font
> > ImportError: dlopen(/Users/vallis/lib/python2.5/site-packages/
> > matplotlib-0.91.2-py2.5-macosx-10.3-fat.egg/matplotlib/ft2font.so,
> > 2): Symbol not found: _FT_Attach_File
> > Referenced from: /Users/vallis/lib/python2.5/site-packages/
> > matplotlib-0.91.2-py2.5-macosx-10.3-fat.egg/matplotlib/ft2font.so
> > Expected in: dynamic lookup
> >
> > It seems there's something wrong with ft2font.so, since CDing to the
> > egg directory and importing only that extension yields
> >
> > >>> import ft2font.so
> > Traceback (most recent call last):
> > File "<stdin>", line 1, in <module>
> > ImportError: dlopen(./ft2font.so, 2): Symbol not found: _FT_Attach_File
> > Referenced from: /Users/vallis/lib/python2.5/site-packages/
> > matplotlib-0.91.2-py2.5-macosx-10.3-fat.egg/matplotlib/ft2font.so
> > Expected in: dynamic lookup
> >
> > Any ideas?
> >
> > Cheers,
> >
> > Michele
> >
> >
> > -------------------------------------------------------------------------
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to buy or sell services for
> > just about anything Open Source.
> > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >
>

Apparently a dynamic link snuck into the build. Typically everything
is statically included. You can see this by running the following
command:
uaternion:matplotlib cmoad$ otool -L ft2font.so
ft2font.so:
	/usr/local/lib/libfreetype.6.dylib (compatibility version 10.0.0,
current version 10.16.0)
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
	/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 88.3.6)
	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
I will created and post a new build asap.
Thanks,
 Charlie
On Jan 11, 2008 1:50 PM, Michele Vallisneri
<Mic...@jp...> wrote:
> Hello all,
>
> after installing matplotlib 0.91.2 from the sourceforge egg on OS X
> 10.4.11 (Python 2.5.1), I get the following error:
>
> >>> import pylab
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> File "/Users/vallis/lib/python2.5/site-packages/matplotlib-0.91.2-
> py2.5-macosx-10.3-fat.egg/matplotlib/pylab.py", line 208, in <module>
> from matplotlib import mpl # pulls in most modules
> File "/Users/vallis/lib/python2.5/site-packages/matplotlib-0.91.2-
> py2.5-macosx-10.3-fat.egg/matplotlib/mpl.py", line 3, in <module>
> from matplotlib import axis
> File "/Users/vallis/lib/python2.5/site-packages/matplotlib-0.91.2-
> py2.5-macosx-10.3-fat.egg/matplotlib/axis.py", line 20, in <module>
> from font_manager import FontProperties
> File "/Users/vallis/lib/python2.5/site-packages/matplotlib-0.91.2-
> py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", line 40, in
> <module>
> from matplotlib import ft2font
> ImportError: dlopen(/Users/vallis/lib/python2.5/site-packages/
> matplotlib-0.91.2-py2.5-macosx-10.3-fat.egg/matplotlib/ft2font.so,
> 2): Symbol not found: _FT_Attach_File
> Referenced from: /Users/vallis/lib/python2.5/site-packages/
> matplotlib-0.91.2-py2.5-macosx-10.3-fat.egg/matplotlib/ft2font.so
> Expected in: dynamic lookup
>
> It seems there's something wrong with ft2font.so, since CDing to the
> egg directory and importing only that extension yields
>
> >>> import ft2font.so
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> ImportError: dlopen(./ft2font.so, 2): Symbol not found: _FT_Attach_File
> Referenced from: /Users/vallis/lib/python2.5/site-packages/
> matplotlib-0.91.2-py2.5-macosx-10.3-fat.egg/matplotlib/ft2font.so
> Expected in: dynamic lookup
>
> Any ideas?
>
> Cheers,
>
> Michele
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Hello all,
after installing matplotlib 0.91.2 from the sourceforge egg on OS X 
10.4.11 (Python 2.5.1), I get the following error:
 >>> import pylab
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File "/Users/vallis/lib/python2.5/site-packages/matplotlib-0.91.2- 
py2.5-macosx-10.3-fat.egg/matplotlib/pylab.py", line 208, in <module>
 from matplotlib import mpl # pulls in most modules
 File "/Users/vallis/lib/python2.5/site-packages/matplotlib-0.91.2- 
py2.5-macosx-10.3-fat.egg/matplotlib/mpl.py", line 3, in <module>
 from matplotlib import axis
 File "/Users/vallis/lib/python2.5/site-packages/matplotlib-0.91.2- 
py2.5-macosx-10.3-fat.egg/matplotlib/axis.py", line 20, in <module>
 from font_manager import FontProperties
 File "/Users/vallis/lib/python2.5/site-packages/matplotlib-0.91.2- 
py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", line 40, in 
<module>
 from matplotlib import ft2font
ImportError: dlopen(/Users/vallis/lib/python2.5/site-packages/ 
matplotlib-0.91.2-py2.5-macosx-10.3-fat.egg/matplotlib/ft2font.so, 
2): Symbol not found: _FT_Attach_File
 Referenced from: /Users/vallis/lib/python2.5/site-packages/ 
matplotlib-0.91.2-py2.5-macosx-10.3-fat.egg/matplotlib/ft2font.so
 Expected in: dynamic lookup
It seems there's something wrong with ft2font.so, since CDing to the 
egg directory and importing only that extension yields
 >>> import ft2font.so
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
ImportError: dlopen(./ft2font.so, 2): Symbol not found: _FT_Attach_File
 Referenced from: /Users/vallis/lib/python2.5/site-packages/ 
matplotlib-0.91.2-py2.5-macosx-10.3-fat.egg/matplotlib/ft2font.so
 Expected in: dynamic lookup
Any ideas?
Cheers,
Michele

Hi Thorsten,
On Wednesday 09 January 2008 15:35, Thorsten Kranz wrote:
> Hi list, Hi Matthias,
>
> I found another way to deal with this problem. when defining the colorbar,
> one can give an additional kwarg "format", so by defining the kwarg
> "format=formatter", we solved the problem.
I'm happy that your problem disappeared, but I still have a question. On my 
system the problem still exist, if I use "format=formatter" in colorbar and 
after that use 
cb.ax.yaxis.set_major_formatter(formatter)
in the example-code of my last email. 
Can anybody confirm this behaviour (data range 0.0 ... 0.54 -> 0.0 ... 0.95)? 
And if so: Is this the expected behaviour?
best regards,
Matthias
> Anyway, I think an option as Matthias implemented would be very handy for
> all those users like us here in Germany who might want to have the numbers
> formatted with commata.
>
> Greetings,
> Thorsten
>
> 2008年1月9日, Matthias Michler <Mat...@gm...>:
> > Hello list,
> > Hello Thorsten,
> >
> > On Wednesday 09 January 2008 11:38, Thorsten Kranz wrote:
> > > I have a question concerning reformatting of axis-ticks via the
> > > FuncFormatter-class. In german, it's common to use a comma as separator
> >
> > for
> >
> > > decimal numbers instead of a dot. To realize it in matplotlib, I do
> > > something like
> > >
> > > >from matplotlib.ticker import FuncFormatter
> > >
> > > import pylab
> > > pylab.figure()
> > > formatter = FuncFormatter(lambda x,pos: ("%.2f"%x).replace(".",","))
> > > ax = pylab.axes()
> > > ax.xaxis.set_major_formatter(formatter)
> > > ax.yaxis.set_major_formatter(formatter)
> > > ax.plot(pylab.arange(0,1,0.1),pylab.arange(0,1,0.1))
> > > This works fine for me,
> >
> > I had the same idea ;-). The problem is that you have a fixed number of
> > digits
> > behind the comma, which is not the desirable behaviour during zoom.
> > I changed the ticker.py/ axes.py files to circumwait this disadvantage. I
> > attached a patch showing my changes and maybe somebody can test it.
> > You can activate it using:
> > ax.ticklabel_format(style='comma')
> > for an ScalarFormatter
> >
> > > but I encounter a problem when I do an
> > > imshow-command with a colorbar. In the imshow-axes, it's o.k., but for
> >
> > the
> >
> > > colorbar it doesn't really work. I do
> > >
> > > cb = pylab.colorbar()
> > > cb.ax.yaxis.set_major_formatter(formatter)
> > >
> > > and, actually, all dots are replaced by com9mata, but the values are
> >
> > also
> >
> > > changed! E.g. instead of the old values (without formatter) from
> > > 0-0.54, the
> > >
> > > values are increased to 0-0.95.
> >
> > [...]
> >
> > > Can anyone explain why it doesn't work out as I expect it to work?
> >
> > I don't know were the problem comes from. I attached your example in a
> > slitly
> > modified version and this shows that the problem is not due to your
> > special
> > formatting. It occurs with matplotlib.ticker.ScalarFormatter, too.
> >
> > best regards,
> > Matthias
> >
> > > Or is there a better, more standard way to substitute the dots by
> >
> > commata?
> >
> > > Thanks,
> > > Thorsten
> >
> > -------------------------------------------------------------------------
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to buy or sell services for
> > just about anything Open Source.
> >
> > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketpl
> >ace _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Hello Mike, 
Hello list,
On Wednesday 09 January 2008 18:21, Michael Droettboom wrote:
> Thanks for the patch. However, perhaps a more general solution would be
> to use the Python locale module to format numbers according to different
> locales. 
I agree with you, but it seems to be hard to do. 
I'm not familiar with the Python locale module and don't know how much effort 
would be needed to fully internationalize the formatting.
> And expose a kwarg select between the user's preferred locale, 
> the current U.S. English-centric defaults as they are now, or an
> arbitrary locale using an ISO language code. That seems like it could
> be a better long-term solution, since there are different number formats
> all over, not just in Germany.
You're again right. These three possible formaters should be possible, because 
the default-locale is not always the corresponding country and for scientific 
publications English is needed.
My hope while sending the patch was that it could be useful to more than 
German people and I didn't know about the whole problem of different 
seperators.
A problem with the Python locale module might be the difference between plain 
and tex-text, because for the comma as decimal seperator '{,}' is used in 
tex-text and I'm not sure if the locale module take care of that.
best regards,
Matthias
> All that said, internationalization is hard -- especially for us
> sheltered people in the U.S. where the defaults are most often correct.
> I may be missing an important detail here.
>
> Cheers,
> Mike
>
> Thorsten Kranz wrote:
> > Hi list, Hi Matthias,
> >
> > I found another way to deal with this problem. when defining the
> > colorbar, one can give an additional kwarg "format", so by defining the
> > kwarg "format=formatter", we solved the problem.
> >
> > Anyway, I think an option as Matthias implemented would be very handy
> > for all those users like us here in Germany who might want to have the
> > numbers formatted with commata.
> >
> > Greetings,
> > Thorsten
> >
> > 2008年1月9日, Matthias Michler <Mat...@gm...
> > <mailto:Mat...@gm...>>:
> >
> > Hello list,
> > Hello Thorsten,
> >
> > On Wednesday 09 January 2008 11:38, Thorsten Kranz wrote:
> > > I have a question concerning reformatting of axis-ticks via the
> > > FuncFormatter-class. In german, it's common to use a comma as
> >
> > separator for
> >
> > > decimal numbers instead of a dot. To realize it in matplotlib, I
> > > do something like
> > >
> > > >from matplotlib.ticker import FuncFormatter
> > >
> > > import pylab
> > > pylab.figure()
> > > formatter = FuncFormatter(lambda x,pos:
> > > ("%.2f"%x).replace(".",",")) ax = pylab.axes()
> > > ax.xaxis.set_major_formatter(formatter)
> > > ax.yaxis.set_major_formatter(formatter)
> > > ax.plot(pylab.arange(0,1,0.1),pylab.arange(0,1,0.1))
> > > This works fine for me,
> >
> > I had the same idea ;-). The problem is that you have a fixed number
> > of digits
> > behind the comma, which is not the desirable behaviour during zoom.
> > I changed the ticker.py/ axes.py files to circumwait this
> > disadvantage. I
> > attached a patch showing my changes and maybe somebody can test it.
> > You can activate it using:
> > ax.ticklabel_format(style='comma')
> > for an ScalarFormatter
> >
> > > but I encounter a problem when I do an
> > > imshow-command with a colorbar. In the imshow-axes, it's o.k.,
> >
> > but for the
> >
> > > colorbar it doesn't really work. I do
> > >
> > > cb = pylab.colorbar()
> > > cb.ax.yaxis.set_major_formatter(formatter)
> > >
> > > and, actually, all dots are replaced by com9mata, but the values
> >
> > are also
> >
> > > changed! E.g. instead of the old values (without formatter) from
> >
> > 0-0.54,
> >
> > > the
> > >
> > > values are increased to 0-0.95.
> >
> > [...]
> >
> > > Can anyone explain why it doesn't work out as I expect it to work?
> >
> > I don't know were the problem comes from. I attached your example in
> > a slitly
> > modified version and this shows that the problem is not due to your
> > special
> > formatting. It occurs with matplotlib.ticker.ScalarFormatter, too.
> >
> > best regards,
> > Matthias
> >
> > > Or is there a better, more standard way to substitute the dots by
> >
> > commata?
> >
> > > Thanks,
> > > Thorsten
> >
> > 
> > -------------------------------------------------------------------------
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to buy or sell services for
> > just about anything Open Source.
> > 
> > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketpl
> >ace _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > <mailto:Mat...@li...>
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> > <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://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketpl
> >ace
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Replying to myself...
Erik Cederstrand wrote:
> Hi!
> 
> I'm trying to make a clickable plot_date() plot (using the Pylons 
> framework). What I need is the pixel coordinates of the data points I 
> give to plot_date(), but the trans.seq_x_y() function doesn't like 
> Datetime:
> 
> >> xcoords, ycoords = trans.seq_x_y(x, y)
> float() argument must be a string or a number
> 
> How can I get the pixel coordinates?
> 
> Here are the relevant parts of my code (x is Datetime, y is float):
> 
> figure = pylab.figure(figsize=(6,4), dpi=100, frameon=False)
> ax = figure.add_subplot(111)
> 
> # quick simple scatter plot
> ax.plot_date(x, y, 'ro')
> 
> # Convert the data set points into screen space coordinates
> trans = ax.get_transform()
> xcoords, ycoords = trans.seq_x_y(x, y)
Thanks to the excellent documentation, I solved this by using 
dates.date2num():
	xcoords, ycoords = trans.seq_x_y(dates2num(x), y)
Erik

Now this is a totally shot in the dark, but I remember similar
'features' from good old unix times, where the X display was palette
instead of true-color, and you'd start some other app that forced its
own colors to the X display, thus changing the palette of other windows.
No idea though why it would happen with qt4, but not with other gui
libraries...
Cheers,
Vincent Schut.
Dan Karipides wrote:
> Darren,
> 
> This is interesting. I tried to get a screenshot of the bad behavior for
> you. My first attempt was to just hit "print screen". Under Fedora Core 8,
> KDE window manager this brings up the application KSnapshot. When KSnapshot
> gets focus, the bad behavior goes away and it was not captured in the
> screenshot.
> 
> I did notice the KSnapshot app has a snapshot delay feature. I set it to 2
> seconds, and clicked new snapshot. The KSnapshot window disappeared for 2
> seconds; the bad behavior was back for that period of time. However, even
> in this case, the behavior doesn't show up in the screenshot.
> 
> This makes me wonder if maybe it is a video driver problem. Linux has the
> right colors in memory (which is I assume the level at which the snap shot
> is taken), but the driver is wigging out when communicating the info to the
> actual video card.
> 
> If I manage to get a SS I will post it.
> 
> -Dan
> 
> -----Original Message-----
> From: Darren Dale [mailto:dar...@co...] 
> Sent: Wednesday, January 09, 2008 3:08 PM
> To: mat...@li...
> Cc: Dan Karipides
> Subject: Re: [Matplotlib-users] screen colors invert with matplotlib
> 
> Could you please post a screenshot of the bad behavior? I don't see anything
> 
> strange here, and I'm using qt-4.3.3, pyqt-4.3.3, and an nvidia GeForce
> 6600.
> 
> Darren
> 
> On Wednesday 09 January 2008 05:00:28 pm Dan Karipides wrote:
>> Do the demo apps come with the standard qt4/pyqt4 install? I just used
> the
>> Fedora Core 8 package manager to install both of these packages.
>>
>> I apologize that my knowledge of qt is limited. I'll do some
> investigation
>> of qt4 / pyqt4 on my own before bothering the list further.
>>
>> Thanks for the suggestion,
>>
>> -Dan
>>
>> -----Original Message-----
>> From: Michael Droettboom [mailto:md...@st...]
>> Sent: Wednesday, January 09, 2008 2:35 PM
>> To: Dan Karipides
>> Cc: 'Matplotlib Users'
>> Subject: Re: [Matplotlib-users] screen colors invert with matplotlib
>>
>> I wonder if the problem exhibits itself in any other pyqt4 apps (such as
>> the demo apps)... In that case, I would take your question to the pyqt
>> list. Otherwise, we'll want to track down what specifically matplotlib
>> is doing that causes this.
>>
>> Cheers,
>> Mike
>>
> 
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

On Jan 9, 2008 11:53 AM, John Hunter <jd...@gm...> wrote:
> On Jan 9, 2008 9:11 AM, Michael Droettboom <md...@st...> wrote:
>
> > You could comment out these two lines:
> >
> > x = (int)x + 0.5;
> > y = (int)y + 0.5;
> >
> > and see if that corrects your wiggliness problem, just to confirm that
> > as the source.
> >
> > The bigger question is -- there was probably a good reason that this
> > code was put in there in the first place, so it probably isn't a good
> > idea to remove it en masse. It may need to be exposed as an argument so
> > some things get this behavior and others don't. I know that dashed
> > lines that are perpendicular to the edges of the figure (e.g. grid
> > lines) look much worse if they aren't rounded to pixel centers. But in
> > general for polygons, I don't know if that's true.
>
> For subpixel accuracy in rendering, agg antialiasing causes different
> line segments to appear different in their thicknesses if they do not
> have the same subpixel values. Maxim wrote the following essay on the
> subject:
>
> http://antigrain.com/tips/line_alignment/line_alignment.agdoc.html#PAGE_LINE_ALIGNMENT
>
>
> For this reason, to preserve visible consistency of the segments, I
> have several parts in the agg code which snaps the vertices ot the
> pixel centers. I have never found a solution that seems to work in
> all cases, since removing the snapto code will cause the
> inconsistencies referred to above. I think should probably be a
> graphics context property (which could get the information from an
> artist property) so at least the user could control it when needed.
>
>
> JDH
>
Hi John, Hi Mike,
I commented out the two lines in draw_polygon() and am now getting
very smooth arrow movement in my animations. It looks GREAT!
I've got my system here now set up so I can easily turn the rounding
on and off, by switching the PATH, and will watch the results so I can
understand more about this issue. The more I understand, the harder it
looks.
Being able to control this as a property of an artist would definitely
work easily enough for my scenario.
I'll also give the new hueristic in SVN a try and see how it works for me.
Thanks for all the help!