matplotlib-users Mailing List for matplotlib

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
>

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
>
> Dan Karipides wrote:
> > Thanks John.
> >
> > I did this test:
> >
> > 	python simple_plot.py -dTkAgg
> >
> > and it worked just fine. (The GTK backend won't compile for me, but that
>
> is
>
> > a topic for another email.)
> >
> > So you are correct, it seems to be a qt4 problem or a pyqt4 problem, I
> > guess.
> >
> > At least I know where to look now.
> >
> > -Dan
> >
> > -----Original Message-----
> > From: John Hunter [mailto:jd...@gm...]
> > Sent: Wednesday, January 09, 2008 11:40 AM
> > To: Dan Karipides
> > Cc: Matplotlib Users
> > Subject: Re: [Matplotlib-users] screen colors invert with matplotlib
> >
> > On Jan 9, 2008 10:14 AM, Dan Karipides <ka...@tx...> wrote:
> >> OS: Fedora Core 8
> >>
> >> Video Card: Nvidia GeForce 8800 Ultra
> >>
> >> Driver: Latest Unix driver from Nvidia (169.07, release date: Dec 20,
> >
> > 2007)
> >
> >> Matplotlib version: matplotlib-0.91.2.tar.gz (built from source)
> >>
> >> Backend chosen: qt4agg
> >
> > Hi Dan,
> >
> > No one has ever reported anything like this before as far as I know.
> > Could you try running a simple test script with a different GUI
> > backend, eg tkagg or gtkagg
> >
> > > python simple_plot.py -dTkAgg #or GTKAgg
> >
> > I assume this is a qt4 problem, but I'd just like to confirm before we
> > proceed. Do you see it with qtagg or just qt4agg?
> >
> >
> > -------------------------------------------------------------------------
> > 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/marketplac
>e
>
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
-- 
Darren S. Dale, Ph.D.
Staff Scientist
Cornell High Energy Synchrotron Source
Cornell University
275 Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853
dar...@co...
office: (607) 255-3819
fax: (607) 255-9001
http://www.chess.cornell.edu

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
Dan Karipides wrote:
> Thanks John.
> 
> I did this test:
> 
> 	python simple_plot.py -dTkAgg 
> 
> and it worked just fine. (The GTK backend won't compile for me, but that
is
> a topic for another email.)
> 
> So you are correct, it seems to be a qt4 problem or a pyqt4 problem, I
> guess.
> 
> At least I know where to look now.
> 
> -Dan
> 
> -----Original Message-----
> From: John Hunter [mailto:jd...@gm...] 
> Sent: Wednesday, January 09, 2008 11:40 AM
> To: Dan Karipides
> Cc: Matplotlib Users
> Subject: Re: [Matplotlib-users] screen colors invert with matplotlib
> 
> On Jan 9, 2008 10:14 AM, Dan Karipides <ka...@tx...> wrote:
> 
>> OS: Fedora Core 8
>>
>> Video Card: Nvidia GeForce 8800 Ultra
>>
>> Driver: Latest Unix driver from Nvidia (169.07, release date: Dec 20,
> 2007)
>> Matplotlib version: matplotlib-0.91.2.tar.gz (built from source)
>>
>> Backend chosen: qt4agg
>>
> 
> Hi Dan,
> 
> No one has ever reported anything like this before as far as I know.
> Could you try running a simple test script with a different GUI
> backend, eg tkagg or gtkagg
> 
> > python simple_plot.py -dTkAgg #or GTKAgg
> 
> I assume this is a qt4 problem, but I'd just like to confirm before we
> proceed. Do you see it with qtagg or just qt4agg?
> 
> 
> -------------------------------------------------------------------------
> 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
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I don't have pyqt installed, just pyqt4, so I'm afraid I can't do that test
for you at the moment. Though I suppose I could install pyqt as one method
of testing this.
Thanks,
-Dan
-----Original Message-----
From: John Hunter [mailto:jd...@gm...] 
Sent: Wednesday, January 09, 2008 2:32 PM
To: Dan Karipides; Matplotlib Users
Subject: Re: [Matplotlib-users] screen colors invert with matplotlib
On Jan 9, 2008 1:32 PM, Dan Karipides <ka...@tx...> wrote:
> Thanks John.
>
> I did this test:
>
> python simple_plot.py -dTkAgg
>
> and it worked just fine. (The GTK backend won't compile for me, but that
is
> a topic for another email.)
>
> So you are correct, it seems to be a qt4 problem or a pyqt4 problem, I
> guess.
>
> At least I know where to look now.
What about qtagg vs qt4agg? It would be interesting to know if it is
qt4 specific, or qt specific.
Please keep the responses on list because there are other developers
more knowledgeable than I about qt.
JDH

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
Dan Karipides wrote:
> Thanks John.
> 
> I did this test:
> 
> 	python simple_plot.py -dTkAgg 
> 
> and it worked just fine. (The GTK backend won't compile for me, but that is
> a topic for another email.)
> 
> So you are correct, it seems to be a qt4 problem or a pyqt4 problem, I
> guess.
> 
> At least I know where to look now.
> 
> -Dan
> 
> -----Original Message-----
> From: John Hunter [mailto:jd...@gm...] 
> Sent: Wednesday, January 09, 2008 11:40 AM
> To: Dan Karipides
> Cc: Matplotlib Users
> Subject: Re: [Matplotlib-users] screen colors invert with matplotlib
> 
> On Jan 9, 2008 10:14 AM, Dan Karipides <ka...@tx...> wrote:
> 
>> OS: Fedora Core 8
>>
>> Video Card: Nvidia GeForce 8800 Ultra
>>
>> Driver: Latest Unix driver from Nvidia (169.07, release date: Dec 20,
> 2007)
>> Matplotlib version: matplotlib-0.91.2.tar.gz (built from source)
>>
>> Backend chosen: qt4agg
>>
> 
> Hi Dan,
> 
> No one has ever reported anything like this before as far as I know.
> Could you try running a simple test script with a different GUI
> backend, eg tkagg or gtkagg
> 
> > python simple_plot.py -dTkAgg #or GTKAgg
> 
> I assume this is a qt4 problem, but I'd just like to confirm before we
> proceed. Do you see it with qtagg or just qt4agg?
> 
> 
> -------------------------------------------------------------------------
> 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
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Jan 9, 2008 1:32 PM, Dan Karipides <ka...@tx...> wrote:
> Thanks John.
>
> I did this test:
>
> python simple_plot.py -dTkAgg
>
> and it worked just fine. (The GTK backend won't compile for me, but that is
> a topic for another email.)
>
> So you are correct, it seems to be a qt4 problem or a pyqt4 problem, I
> guess.
>
> At least I know where to look now.
What about qtagg vs qt4agg? It would be interesting to know if it is
qt4 specific, or qt specific.
Please keep the responses on list because there are other developers
more knowledgeable than I about qt.
JDH

Thanks John.
I did this test:
	python simple_plot.py -dTkAgg 
and it worked just fine. (The GTK backend won't compile for me, but that is
a topic for another email.)
So you are correct, it seems to be a qt4 problem or a pyqt4 problem, I
guess.
At least I know where to look now.
-Dan
-----Original Message-----
From: John Hunter [mailto:jd...@gm...] 
Sent: Wednesday, January 09, 2008 11:40 AM
To: Dan Karipides
Cc: Matplotlib Users
Subject: Re: [Matplotlib-users] screen colors invert with matplotlib
On Jan 9, 2008 10:14 AM, Dan Karipides <ka...@tx...> wrote:
> OS: Fedora Core 8
>
> Video Card: Nvidia GeForce 8800 Ultra
>
> Driver: Latest Unix driver from Nvidia (169.07, release date: Dec 20,
2007)
>
> Matplotlib version: matplotlib-0.91.2.tar.gz (built from source)
>
> Backend chosen: qt4agg
>
Hi Dan,
No one has ever reported anything like this before as far as I know.
Could you try running a simple test script with a different GUI
backend, eg tkagg or gtkagg
 > python simple_plot.py -dTkAgg #or GTKAgg
I assume this is a qt4 problem, but I'd just like to confirm before we
proceed. Do you see it with qtagg or just qt4agg?

Included below is an updated patch fixing the legend with numpoints=1. 
The patch has been made against SVN and works for Line2D, 
LineCollection, Patch, and RegularPolyCollection. The patch could be merged.
I also think the patch could be improved. Currently, handle._marker is 
examined to determine if the legend should contain lines or symbols, but 
this is done in the _get_handles function. It would be better if that 
could be moved into the Legend class definition, however, I do not know 
how to examine handle._marker in the Legend class definition.
Again, I would appreciate any comments or improvements.
Thanks,
Paul
diff -u a/lib/matplotlib/legend.py b/lib/matplotlib/legend.py
--- a/lib/matplotlib/legend.py	2008年01月09日 13:11:00.000000000 -0600
+++ b/lib/matplotlib/legend.py	2008年01月09日 13:08:36.000000000 -0600
@@ -175,9 +175,7 @@
 # make a trial box in the middle of the axes. relocate it
 # based on it's bbox
 left, top = 0.5, 0.5
- if self.numpoints == 1:
- self._xdata = npy.array([left + self.handlelen*0.5])
- else:
+ if self.numpoints > 1:
 self._xdata = npy.linspace(left, left + self.handlelen, 
self.numpoints)
 textleft = left+ self.handlelen+self.handletextsep
 self.texts = self._get_texts(labels, textleft, top)
@@ -236,6 +234,7 @@
 def _get_handles(self, handles, texts):
 HEIGHT = self._approx_text_height()
+ left = 0.5
 ret = [] # the returned legend lines
@@ -243,6 +242,10 @@
 x, y = label.get_position()
 x -= self.handlelen + self.handletextsep
 if isinstance(handle, Line2D):
+ if self.numpoints == 1 and handle._marker == 'None':
+ self._xdata = npy.linspace(left, left + 
self.handlelen, 2)
+ elif self.numpoints == 1:
+ self._xdata = npy.array([left + self.handlelen*0.5])
 ydata = (y-HEIGHT/2)*npy.ones(self._xdata.shape, float)
 legline = Line2D(self._xdata, ydata)
 legline.update_from(handle)
@@ -253,7 +256,8 @@
 ret.append(legline)
 elif isinstance(handle, Patch):
-
+ if self.numpoints == 1:
+ self._xdata = npy.linspace(left, left + 
self.handlelen, 2)
 p = Rectangle(xy=(min(self._xdata), y-3/4*HEIGHT),
 width = self.handlelen, height=HEIGHT/2,
 )
@@ -263,6 +267,8 @@
 p.set_clip_path(None)
 ret.append(p)
 elif isinstance(handle, LineCollection):
+ if self.numpoints == 1:
+ self._xdata = npy.linspace(left, left + 
self.handlelen, 2)
 ydata = (y-HEIGHT/2)*npy.ones(self._xdata.shape, float)
 legline = Line2D(self._xdata, ydata)
 self._set_artist_props(legline)
@@ -277,6 +283,8 @@
 ret.append(legline)
 elif isinstance(handle, RegularPolyCollection):
+ if self.numpoints == 1:
+ self._xdata = npy.array([left])
 p = Rectangle(xy=(min(self._xdata), y-3/4*HEIGHT),
 width = self.handlelen, height=HEIGHT/2,
 )
Michael Droettboom wrote:
> I'm sure the radio silence to your question is just due to holidays.
> 
> Thanks for looking into this. I'd be happy to incorporate your patch 
> when it is ready.
> 
> As for your question about plots that can include patches -- patches are 
> virtually anything plotted that aren't lines or images. This includes 
> rectangles, polygons and ellipses, for instance. See something like 
> ellipse_demo.py for an example. Patches are always drawn as rectangles 
> in the legend.
> 
> Cheers,
> Mike
> 

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

On Jan 9, 2008 10:14 AM, Dan Karipides <ka...@tx...> wrote:
> OS: Fedora Core 8
>
> Video Card: Nvidia GeForce 8800 Ultra
>
> Driver: Latest Unix driver from Nvidia (169.07, release date: Dec 20, 2007)
>
> Matplotlib version: matplotlib-0.91.2.tar.gz (built from source)
>
> Backend chosen: qt4agg
>
Hi Dan,
No one has ever reported anything like this before as far as I know.
Could you try running a simple test script with a different GUI
backend, eg tkagg or gtkagg
 > python simple_plot.py -dTkAgg #or GTKAgg
I assume this is a qt4 problem, but I'd just like to confirm before we
proceed. Do you see it with qtagg or just qt4agg?

I've recently started using matplotlib on new unix box and I'm running in to
an odd problem. I'm not sure what the root cause is (my linux installation,
graphics drivers, matplotlib, or something else) but I thought I would ask
here to see if anyone else had experienced this.
 
OS: Fedora Core 8
Video Card: Nvidia GeForce 8800 Ultra
Driver: Latest Unix driver from Nvidia (169.07, release date: Dec 20, 2007)
Matplotlib version: matplotlib-0.91.2.tar.gz (built from source)
Backend chosen: qt4agg
Qt4 version: 4.3.3
 
The problem: If a matplotlib plot window ever has focus, the screen colors
on the whole screen invert themselves. White becomes black, etc. I can
probably post a link to a screenshot if that will help, but it looks like a
simple color inversion to me. If the plot window doesn't have focus,
everything is drawn correctly.
 
My simple test was:
 
$ ipython -pylab
 
In [1]: plot(range(10))
 
With older versions of matplotlib, the colors did not invert-the screen went
totally black when the plot window had focus. When it doesn't, everything
looks fine.
 
I'm not seeing this behavior with any other application so far. If
upgrading to the SVN trunk version would help, I'm willing to give that a
try. But I wanted to get some feedback before updating anything else.
 
Thanks,
 
-Dan
-----
Dan Karipides
Tech-X Corporation
ka...@tx...

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. 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.
> 
> 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
Mike,
I agree that this problem needs to be solved. I was looking at it a 
year or so ago, with the idea of putting in simple options rather than 
full internationalization, but I never followed up on it. Until your 
message I had never looked at the documentation for the locale module. 
It *might* be possible to fix the formatters by replacing a few 
"somestring % variables" constructs with calls to 
locale.format_string(somestring, variables)--but this is new in python 
2.5. Without this it looks like it might be much harder. The formatter 
code is already a bit convoluted because of all the variations--latex, 
mathtex, plain, with or without scientific notation.
Actually, I think the option I was looking at a year ago was what is 
handled by the "grouping" arg in locale.format_string--the ability to 
use commas or dots to break up triplets of digits.
Eric

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. 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.
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/marketplace
> _______________________________________________
> 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/marketplace
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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

Norman,
There is code (in 0.91, going back before my time) that rounds the 
vertices of polygons (which arrows in effect are) to the center of 
pixels. You can see it here inside RendererAgg::draw_polygon() in 
_backend_agg.cpp:
 agg::path_storage path;
 for (size_t j=0; j<Npoints; j++) {
 double x = xs[j];
 double y = ys[j];
 //snapto pixel centers
 x = (int)x + 0.5;
 y = (int)y + 0.5;
 if (j==0) path.move_to(x,y);
 else path.line_to(x,y);
 }
 path.close_polygon();
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.
Now to veer away from your question a little bit -->
On the transforms branch (which is now in SVN head, and not in any 
release), this behavior has changed. The new heuristic is that if a 
path (which includes everything including lines and polygons) includes 
only straight and axis-aligned segments, it is rounded. If it includes 
any curves or non-axis-aligned segments it is not rounded. This 
heuristic seems to work quite well in practice, since it includes grid 
lines, non-rotated rectangles etc., but I am interested in getting 
feedback from other users if that heuristic fails in any special 
circumstances.
Cheers,
Mike
Norman Davis wrote:
> Hi all,
> I' ve been using matplotlib to create some animations and it seems
> that the endpoints for arrow polygon lines are being rounded off to
> the nearest pixel. At least thats my guess. When viewing an animation
> the arrow changes shape and distorts as it moves around. The code
> below shows it on my Windows XP system where I'm using Matplotlib
> 0.91.1, SciPy 0.6.0, Numpy 1.0.4, Python 2.4. (The code is adapted
> from examples/animation_blit_tk.py) I've also seen this on my Linux
> setup when producing .png's for animation. I think I also remember
> noticing circle patches having discrete movements, so it may be more
> general than arrows.
> I'm wondering if other's find this to be a problem. Its
> distracting in my particular case. What can I do to help change this?
> I've been enjoying matplotlib along with basemap for the past two
> years and would like to help out if I can.
> Norm.
> 
> - - - - - -
> import matplotlib
> matplotlib.use('TkAgg')
> 
> import sys
> import pylab as p
> from matplotlib.patches import Arrow
> 
> ax = p.subplot(111)
> canvas = ax.figure.canvas
> 
> def run(*args):
> background = canvas.copy_from_bbox(ax.bbox)
> 
> while 1:
> canvas.restore_region(background)
> 
> ells = [Arrow(x = i/20.+ (run.cnt+1)/16000.,
> y = 0.4+ (run.cnt+1)/30000.,
> dx = 0.04 + 1/200.,
> dy = 0.06,
> width=0.03)
> for i in xrange(10)]
> for e in ells:
> ax.add_artist(e)
> for e in ells:
> ax.draw_artist(e)
> 
> canvas.blit(ax.bbox)
> 
> for e in ells:
> e.remove()
> 
> if run.cnt==1000:
> sys.exit()
> 
> run.cnt += 1
> run.cnt = 0
> 
> p.subplots_adjust(left=0.3, bottom=0.3)
> p.grid()
> manager = p.get_current_fig_manager()
> manager.window.after(100, run)
> p.show()
> - - - - - -
> 
> -------------------------------------------------------------------------
> 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
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

The default mathtext font should have the "times" symbol. Are you 
making any other changes that would affect the selection of mathtext 
fonts? (Can you please attach a copy of your matplotlibrc file?) If 
that looks ok, perhaps it isn't finding the math fonts correctly. There 
are a multitude of reasons that could be happening. It is sometimes 
helpful to set "verbose.level" to "debug-annoying" and then look at the 
logs to see what might be going on. Also, you could try deleting the 
fonts cache in ~/.matplotlib/fontManager.cache to force it to regenerate.
Cheers,
Mike
Matthias Michler wrote:
> Hello list,
> 
> the little example below seems to fail, can anybody help me? 
> I'm on Debian using the release 0.91.2.
> 
> best regards and thanks in advance for any hints,
> Matthias
> 
> -------------------------------------------------------------------------------------------
> from matplotlib.ticker import ScalarFormatter
> from matplotlib.pyplot import *
> 
> ax = axes()
> axis([0.0, 10**-7, 0, 10**-7])
> 
> ax.yaxis.set_major_formatter(ScalarFormatter(useMathText=True))
> 
> show()
> ------------------------------------------------------------------------------------------------
> error message:
> /scratch/michler/SOFT/lib/python2.4/site-packages/matplotlib/mathtext.py:722: 
> MathTextWarning: Unrecognized symbol '\times'. Substituting with a dummy 
> symbol. 
> % sym.encode('ascii', 'backslashreplace'), MathTextWarning)
> 
> 
> the string '\times' is due to line 
> sciNotStr = r'{\times}'+self.format_data(10**self.orderOfMagnitude)
> in function ScalarFormatter.get_offset
> 
> -------------------------------------------------------------------------
> 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
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi all,
 I' ve been using matplotlib to create some animations and it seems
that the endpoints for arrow polygon lines are being rounded off to
the nearest pixel. At least thats my guess. When viewing an animation
the arrow changes shape and distorts as it moves around. The code
below shows it on my Windows XP system where I'm using Matplotlib
0.91.1, SciPy 0.6.0, Numpy 1.0.4, Python 2.4. (The code is adapted
from examples/animation_blit_tk.py) I've also seen this on my Linux
setup when producing .png's for animation. I think I also remember
noticing circle patches having discrete movements, so it may be more
general than arrows.
 I'm wondering if other's find this to be a problem. Its
distracting in my particular case. What can I do to help change this?
I've been enjoying matplotlib along with basemap for the past two
years and would like to help out if I can.
Norm.
 - - - - - -
 import matplotlib
matplotlib.use('TkAgg')
import sys
import pylab as p
from matplotlib.patches import Arrow
ax = p.subplot(111)
canvas = ax.figure.canvas
def run(*args):
 background = canvas.copy_from_bbox(ax.bbox)
 while 1:
 canvas.restore_region(background)
 ells = [Arrow(x = i/20.+ (run.cnt+1)/16000.,
 y = 0.4+ (run.cnt+1)/30000.,
 dx = 0.04 + 1/200.,
 dy = 0.06,
 width=0.03)
 for i in xrange(10)]
 for e in ells:
 ax.add_artist(e)
 for e in ells:
 ax.draw_artist(e)
 canvas.blit(ax.bbox)
 for e in ells:
 e.remove()
 if run.cnt==1000:
 sys.exit()
 run.cnt += 1
run.cnt = 0
p.subplots_adjust(left=0.3, bottom=0.3)
p.grid()
manager = p.get_current_fig_manager()
manager.window.after(100, run)
p.show()
- - - - - -

On Wednesday 09 January 2008 10:15:54 am Francesco Pretto wrote:
> 2008年1月9日, Darren Dale <dar...@co...>:
> > setup.py attempts to select the appropriate backend for you, based on
> > what backends were available at build time. That selection is written
> > into the default matplotlibrc file, which resides in
> > site-packages/matplotlib/mpl-data. If matplotlib finds another
> > matplotlibrc file (for example, in the current working directory, in
> > $HOME/.matplotlib, etc), then it will use those settings instead. I would
> > guess that is the source of the problem.
>
> No, the problem is the default installed matplotlibrc, that is not
> different from the one present in the source tree and has the default
> selection:
>
> backend : TkAgg
>
> Now, i don't know if the build script is trying to modify it according
> user selection or compile-time backend detection, but I'm wondering
> why the same problem wasn't happening on linux, where I tipically
> never install Tk runtime.
>
> However, for me the problem is solved, but if there's a matplotlib
> windows dev listening, here is my experience; first, i removed the
> already installed "lib/site-packages/matplotlib/mpl-data/matplotlibrc"
> . Afer, I went for clean compiling with a setup.cfg with these
> configurations:
>
> gtk = True
> gtkagg = False
> tkagg = False
> wxagg = False
> backend = GTK
>
> Eventually, "python setup.py install" write again a
> "site-packages/matplotlib/mpl-data/matplotlibrc" which still have:
>
> backend : TkAgg
>
> If this shouldn't happen, well, consider this a bug report :D
Oh, I see. Look at line 238 in setup.py. Maybe we don't need that check for 
sys.platform anymore, now that we have setup.cfg. I think that check was in 
there for the benefit of building the windows installers, which we wanted to 
default to tkagg.
I think it would be best to use a setup.cfg to set the numerix and backends 
when building the windows installers. Charlie, does that sound alright?
Darren

2008年1月9日, Darren Dale <dar...@co...>:
>
> setup.py attempts to select the appropriate backend for you, based on what
> backends were available at build time. That selection is written into the
> default matplotlibrc file, which resides in
> site-packages/matplotlib/mpl-data. If matplotlib finds another matplotlibrc
> file (for example, in the current working directory, in $HOME/.matplotlib,
> etc), then it will use those settings instead. I would guess that is the
> source of the problem.
>
No, the problem is the default installed matplotlibrc, that is not
different from the one present in the source tree and has the default
selection:
backend : TkAgg
Now, i don't know if the build script is trying to modify it according
user selection or compile-time backend detection, but I'm wondering
why the same problem wasn't happening on linux, where I tipically
never install Tk runtime.
However, for me the problem is solved, but if there's a matplotlib
windows dev listening, here is my experience; first, i removed the
already installed "lib/site-packages/matplotlib/mpl-data/matplotlibrc"
. Afer, I went for clean compiling with a setup.cfg with these
configurations:
gtk = True
gtkagg = False
tkagg = False
wxagg = False
backend = GTK
Eventually, "python setup.py install" write again a
"site-packages/matplotlib/mpl-data/matplotlibrc" which still have:
backend : TkAgg
If this shouldn't happen, well, consider this a bug report :D
Greetings,
Francesco Pretto

On Wednesday 09 January 2008 09:27:39 am Francesco Pretto wrote:
> 2008年1月9日, Charlie Moad <cw...@gm...>:
> > You need to set a different backend in your matplotlibrc or specify it
> > first.
> >
> > import matplotlib
> > matplotlib.use('Agg')
> >
> > You can also run scripts passing the backend:
> >
> > python lab1_ex2.py -dAgg
>
> Oh, thanks. That really seems a RTFM...
>
> However, in linux i hadn't to select the backend, i just configure
> "setup.cfg" to exclude backends and, after compiling, matplotlib was
> running just fine choosing the right backend (gtk or gtkagg). Isn't
> this a sign that matplotlib isn't able to detect the correct default
> backend at compile time (at least on windows)?
>
> However, thanks again. As promised, now I'll try to be more autonomous ;-)
setup.py attempts to select the appropriate backend for you, based on what 
backends were available at build time. That selection is written into the 
default matplotlibrc file, which resides in 
site-packages/matplotlib/mpl-data. If matplotlib finds another matplotlibrc 
file (for example, in the current working directory, in $HOME/.matplotlib, 
etc), then it will use those settings instead. I would guess that is the 
source of the problem.
Darren

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...>:
>
> 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/marketplace
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
>

2008年1月9日, Charlie Moad <cw...@gm...>:
> You need to set a different backend in your matplotlibrc or specify it first.
>
> import matplotlib
> matplotlib.use('Agg')
>
> You can also run scripts passing the backend:
>
> python lab1_ex2.py -dAgg
>
Oh, thanks. That really seems a RTFM...
However, in linux i hadn't to select the backend, i just configure
"setup.cfg" to exclude backends and, after compiling, matplotlib was
running just fine choosing the right backend (gtk or gtkagg). Isn't
this a sign that matplotlib isn't able to detect the correct default
backend at compile time (at least on windows)?
However, thanks again. As promised, now I'll try to be more autonomous ;-)
Greetins,
Francesco

You need to set a different backend in your matplotlibrc or specify it first.
import matplotlib
matplotlib.use('Agg')
You can also run scripts passing the backend:
python lab1_ex2.py -dAgg
On Jan 9, 2008 8:41 AM, Francesco Pretto <cez...@gm...> wrote:
> Hi, after having correctly compiled matplotlib, now is time to test
> something (I need at least to get it something working before I can
> start hack it autonomously =). Unfortunately, it's not usable: it
> complains about not being able to load "_tkagg" module. The fact is I
> don't want "tkagg" backend at all! Here is the backends dependencies
> detect log:
>
> OPTIONAL BACKEND DEPENDENCIES
> libpng: found, but unknown version (no pkg-config)
> Tkinter: no
> * Tkinter present, but header files are not found.
> * You may need to install development packages.
> wxPython: no
> * wxPython not found
> Gtk+: gtk+: 2.10.11, glib: 2.12.11, pygtk: 2.10.6,
> pygobject: 2.12.3
> Qt: no
> Qt4: no
> Cairo: 1.2.6
>
> As it should be clear, I want to use the a gtk+ aware backend, and
> initially in fact I used a customized "setup.cfg"; seeing the error I
> tryed deleting the customized "setup.cfg", but without results. Is
> there some problems with backend selection on windows platform?
> I hope gtk+ backends are supported. Follows 2 traces of the error
> running an ipython shell and a test python program (it works on
> linux).
>
> Any help is appreciated.
>
> Thanks,
> Francesco
>
> ---------------------------------------------------------------------------
>
> Here is the trace in ipython trying to run sample test program:
>
> In [3]: run lab1_ex2.py
>
> ImportError Traceback (most recent call last)
>
> C:\Documents and Settings\Public\desktop\lab1_ex2.py in <module>()
> 1 from numpy import *
> 2 from scipy import *
> ----> 3 from pylab import *
> 4
> 5 n=100
>
> c:\python25\Lib\site-packages\pylab.py in <module>()
> ----> 1
> 2
> 3 from matplotlib.pylab import *
> 4 import matplotlib.pylab
> 5 __doc__ = matplotlib.pylab.__doc__
>
> c:\python25\Lib\site-packages\matplotlib\pylab.py in <module>()
> 290
> 291
> --> 292 from matplotlib.pyplot import *
> 293
> 294
>
> c:\python25\Lib\site-packages\matplotlib\pyplot.py in <module>()
> 35
> 36 from matplotlib.backends import pylab_setup
> ---> 37 new_figure_manager, draw_if_interactive, show = pylab_setup()
> 38
> 39 def switch_backend(newbackend):
>
> c:\python25\Lib\site-packages\matplotlib\backends\__init__.py in pylab_setup()
> 22 backend_name = 'backend_'+backend.lower()
> 23 backend_mod = __import__('matplotlib.backends.'+backend_name,
> ---> 24 globals(),locals(),[backend_name])
> 25
> 26 # Things we pull in from all backends
>
> c:\python25\Lib\site-packages\matplotlib\backends\backend_tkagg.py in <module>()
>
> 6
> 7 import Tkinter as Tk, FileDialog
> ----> 8 import tkagg # Paint image to Tk photo blitter extension
>
> 9 from backend_agg import FigureCanvasAgg
> 10
>
> c:\python25\Lib\site-packages\matplotlib\backends\tkagg.py in <module>()
> ----> 1
> 2
> 3 import _tkagg
> 4 import Tkinter as Tk
> 5
> 6 def blit(photoimage, aggimage, bbox=None, colormode=1):
> 7 tk = photoimage.tk
>
> ImportError: No module named _tkagg
> WARNING: Failure executing file: <lab1_ex2.py>
>
> ---------------------------------------------------------------------------
>
> Here is another trace trying to run ipython with "--pylab" switch:
>
> Traceback (most recent call last):
> File "C:\Python25\scripts\ipython", line 27, in <module>
> IPython.Shell.start().mainloop()
> File "C:\Python25\lib\site-packages\IPython\Shell.py", line 1152, in start
> return shell(user_ns = user_ns)
> File "C:\Python25\lib\site-packages\IPython\Shell.py", line 1049, in __init__
> shell_class=MatplotlibShell)
> File "C:\Python25\lib\site-packages\IPython\Shell.py", line 74, in __init__
> debug=debug,shell_class=shell_class)
> File "C:\Python25\Lib\site-packages\IPython\ipmaker.py", line 95, in make_IPyt
> hon
> embedded=embedded,**kw)
> File "C:\Python25\lib\site-packages\IPython\Shell.py", line 589, in __init__
> user_ns,b2 = self._matplotlib_config(name,user_ns)
> File "C:\Python25\lib\site-packages\IPython\Shell.py", line 530, in _matplotli
> b_config
> import matplotlib.pylab as pylab
> File "c:\python25\Lib\site-packages\matplotlib\pylab.py", line 292, in <module
> >
> from matplotlib.pyplot import *
> File "c:\python25\Lib\site-packages\matplotlib\pyplot.py", line 37, in <module
> >
> new_figure_manager, draw_if_interactive, show = pylab_setup()
> File "c:\python25\Lib\site-packages\matplotlib\backends\__init__.py", line 24,
> in pylab_setup
> globals(),locals(),[backend_name])
> File "c:\python25\Lib\site-packages\matplotlib\backends\backend_tkagg.py", lin
> e 8, in <module>
> import tkagg # Paint image to Tk photo blitter extension
> File "c:\python25\Lib\site-packages\matplotlib\backends\tkagg.py", line 1, in
> <module>
> import _tkagg
> ImportError: No module named _tkagg
>
> -------------------------------------------------------------------------
> 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
>

Hi, after having correctly compiled matplotlib, now is time to test
something (I need at least to get it something working before I can
start hack it autonomously =). Unfortunately, it's not usable: it
complains about not being able to load "_tkagg" module. The fact is I
don't want "tkagg" backend at all! Here is the backends dependencies
detect log:
OPTIONAL BACKEND DEPENDENCIES
 libpng: found, but unknown version (no pkg-config)
 Tkinter: no
 * Tkinter present, but header files are not found.
 * You may need to install development packages.
 wxPython: no
 * wxPython not found
 Gtk+: gtk+: 2.10.11, glib: 2.12.11, pygtk: 2.10.6,
 pygobject: 2.12.3
 Qt: no
 Qt4: no
 Cairo: 1.2.6
As it should be clear, I want to use the a gtk+ aware backend, and
initially in fact I used a customized "setup.cfg"; seeing the error I
tryed deleting the customized "setup.cfg", but without results. Is
there some problems with backend selection on windows platform?
I hope gtk+ backends are supported. Follows 2 traces of the error
running an ipython shell and a test python program (it works on
linux).
Any help is appreciated.
Thanks,
Francesco
---------------------------------------------------------------------------
Here is the trace in ipython trying to run sample test program:
In [3]: run lab1_ex2.py
ImportError Traceback (most recent call last)
C:\Documents and Settings\Public\desktop\lab1_ex2.py in <module>()
 1 from numpy import *
 2 from scipy import *
----> 3 from pylab import *
 4
 5 n=100
c:\python25\Lib\site-packages\pylab.py in <module>()
----> 1
 2
 3 from matplotlib.pylab import *
 4 import matplotlib.pylab
 5 __doc__ = matplotlib.pylab.__doc__
c:\python25\Lib\site-packages\matplotlib\pylab.py in <module>()
 290
 291
--> 292 from matplotlib.pyplot import *
 293
 294
c:\python25\Lib\site-packages\matplotlib\pyplot.py in <module>()
 35
 36 from matplotlib.backends import pylab_setup
---> 37 new_figure_manager, draw_if_interactive, show = pylab_setup()
 38
 39 def switch_backend(newbackend):
c:\python25\Lib\site-packages\matplotlib\backends\__init__.py in pylab_setup()
 22 backend_name = 'backend_'+backend.lower()
 23 backend_mod = __import__('matplotlib.backends.'+backend_name,
---> 24 globals(),locals(),[backend_name])
 25
 26 # Things we pull in from all backends
c:\python25\Lib\site-packages\matplotlib\backends\backend_tkagg.py in <module>()
 6
 7 import Tkinter as Tk, FileDialog
----> 8 import tkagg # Paint image to Tk photo blitter extension
 9 from backend_agg import FigureCanvasAgg
 10
c:\python25\Lib\site-packages\matplotlib\backends\tkagg.py in <module>()
----> 1
 2
 3 import _tkagg
 4 import Tkinter as Tk
 5
 6 def blit(photoimage, aggimage, bbox=None, colormode=1):
 7 tk = photoimage.tk
ImportError: No module named _tkagg
WARNING: Failure executing file: <lab1_ex2.py>
---------------------------------------------------------------------------
Here is another trace trying to run ipython with "--pylab" switch:
Traceback (most recent call last):
 File "C:\Python25\scripts\ipython", line 27, in <module>
 IPython.Shell.start().mainloop()
 File "C:\Python25\lib\site-packages\IPython\Shell.py", line 1152, in start
 return shell(user_ns = user_ns)
 File "C:\Python25\lib\site-packages\IPython\Shell.py", line 1049, in __init__
 shell_class=MatplotlibShell)
 File "C:\Python25\lib\site-packages\IPython\Shell.py", line 74, in __init__
 debug=debug,shell_class=shell_class)
 File "C:\Python25\Lib\site-packages\IPython\ipmaker.py", line 95, in make_IPyt
hon
 embedded=embedded,**kw)
 File "C:\Python25\lib\site-packages\IPython\Shell.py", line 589, in __init__
 user_ns,b2 = self._matplotlib_config(name,user_ns)
 File "C:\Python25\lib\site-packages\IPython\Shell.py", line 530, in _matplotli
b_config
 import matplotlib.pylab as pylab
 File "c:\python25\Lib\site-packages\matplotlib\pylab.py", line 292, in <module
>
 from matplotlib.pyplot import *
 File "c:\python25\Lib\site-packages\matplotlib\pyplot.py", line 37, in <module
>
 new_figure_manager, draw_if_interactive, show = pylab_setup()
 File "c:\python25\Lib\site-packages\matplotlib\backends\__init__.py", line 24,
 in pylab_setup
 globals(),locals(),[backend_name])
 File "c:\python25\Lib\site-packages\matplotlib\backends\backend_tkagg.py", lin
e 8, in <module>
 import tkagg # Paint image to Tk photo blitter extension
 File "c:\python25\Lib\site-packages\matplotlib\backends\tkagg.py", line 1, in
<module>
 import _tkagg
ImportError: No module named _tkagg

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

Hello list,
the little example below seems to fail, can anybody help me? 
I'm on Debian using the release 0.91.2.
best regards and thanks in advance for any hints,
Matthias
-------------------------------------------------------------------------------------------
from matplotlib.ticker import ScalarFormatter
from matplotlib.pyplot import *
ax = axes()
axis([0.0, 10**-7, 0, 10**-7])
ax.yaxis.set_major_formatter(ScalarFormatter(useMathText=True))
show()
------------------------------------------------------------------------------------------------
error message:
/scratch/michler/SOFT/lib/python2.4/site-packages/matplotlib/mathtext.py:722: 
MathTextWarning: Unrecognized symbol '\times'. Substituting with a dummy 
symbol. 
 % sym.encode('ascii', 'backslashreplace'), MathTextWarning)
the string '\times' is due to line 
 sciNotStr = r'{\times}'+self.format_data(10**self.orderOfMagnitude)
in function ScalarFormatter.get_offset