I have finally managed to test against TkAgg, and the faint white lines do
not appear to occur. So, as far as I can tell (no clue about Macs), the
GTKCairo, pdf and svg backends have this display bug. Shall I file a bug
report for this and another for the misaligned title?
Ben Root
On Tue, Jun
On Tue, Jun 1, 2010 at 4:35 PM, Eric Firing wrote:
> it seems to me that the solution is for
> bar to take a kwarg, say "errorkw", which is a dict that will be passed
> to errorbar via **errorkw, and that can have any valid errorbar kwargs
> in it. There is some precedent for this sort of thing,
I just took a look at bar() and errorbar(). bar() has linewidth and uses it
properly (I believe), except in the case where one specifies yerr/xerr (it
doesn't pass on kwargs nor does it apply the linewidth parameter).
Then looking at errorbar(), there is a kwarg called 'elinewidth' which
supercee
On 06/01/2010 01:17 PM, Fernando Perez wrote:
> Hi all,
>
> I just spent some time digging through the matplotlib code, and I see
> that the errorbar line width argument isn't passed through to the
> underlying call. In axis.bar, we have this code:
>
> if xerr is not None or yerr is not N
Hi all,
I just spent some time digging through the matplotlib code, and I see
that the errorbar line width argument isn't passed through to the
underlying call. In axis.bar, we have this code:
if xerr is not None or yerr is not None:
if orientation == 'vertical':
Right, that is sort of what I am asking. My thinking is that Basemap could
use 'box-forced' instead of 'box' for the adjustable parameter in order to
make it and AxesGrid compatible. Usually, if one wants to use AxesGrid,
they all should have the same domain and aspect ratio. I just have no clue
If Basemap explicitly sets aspect=1 and adjustable="box" at the same
time, you cannot use this with any axes that shares its axis with
others (including the axes created by the AxesGrid).
You need to somehow avoid the set_aspect call with adjustable"box"
(you can set box-forced in stead).
-JJ
O
On a related note, I have noticed an incompatibility between AxesGrid and
Basemap. It appears that Basemap will explicitly set adjustable='box' when
it calls ax.set_aspect(), but AxesGrid will error out, saying that it has to
be 'datalim'. What are the implications of using 'box-forced' instead o
Correction -- the problem with pcolormesh and the faint white lines are
occurring for pdf and svg files, *not* eps files as I originally stated. I
am also checking a number of display backends and found that the problem
occurs for GTKCairo. I am sure it also happens for TkAgg, but I can not
confi
I have since switched over to the svn checkout of basemap, and this issue
appears to be 'fixed'. While readshapefile() does still load all of the
data, it appears that .set_axes_limits() automatically turns off
autoscaling. This should cut down on much of the "odd" behaviors users
would encounter
Confirmed. This might also explain some other behaviors I have noticed with
pcolormesh and rasterized=True.
Ben Root
On Tue, Jun 1, 2010 at 11:18 AM, Jae-Joon Lee wrote:
> It seems that pcolormesh silently ignores some of the keyword
> parameters, and "rasterized" is one of them. And I'm not s
It seems that pcolormesh silently ignores some of the keyword
parameters, and "rasterized" is one of them. And I'm not sure this is
intended behavior or not and I hope other developers step in.
In the meantime, use a member method explicitly.
p2 = pcolormesh(arr)
p2.set_rasterized(True)
Regards,
On Tue, Jun 1, 2010 at 9:39 AM, Ryan May wrote:
> On Mon, May 31, 2010 at 11:28 AM, Benjamin Root wrote:
> > Markus,
> >
> > That is good to know that it has been fixed. As for the difference in
> > pcolor and pcolormesh, I think it has to do with the fact that pcolormesh
> is
> > composed of m
On Mon, May 31, 2010 at 11:28 AM, Benjamin Root wrote:
> Markus,
>
> That is good to know that it has been fixed. As for the difference in
> pcolor and pcolormesh, I think it has to do with the fact that pcolormesh is
> composed of many lines while pcolor is composed of many polygons. It is
> pr
Hi,
Pressing tab, the "Windows" key or the right click key (and maybe
others) on a plot with the GTKAgg or GTK backend causes the following
traceback:
Traceback (most recent call last):
File
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtk.py",
line 264, in key_press_event
15 matches
Mail list logo
