You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(33) |
Dec
(20) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(7) |
Feb
(44) |
Mar
(51) |
Apr
(43) |
May
(43) |
Jun
(36) |
Jul
(61) |
Aug
(44) |
Sep
(25) |
Oct
(82) |
Nov
(97) |
Dec
(47) |
2005 |
Jan
(77) |
Feb
(143) |
Mar
(42) |
Apr
(31) |
May
(93) |
Jun
(93) |
Jul
(35) |
Aug
(78) |
Sep
(56) |
Oct
(44) |
Nov
(72) |
Dec
(75) |
2006 |
Jan
(116) |
Feb
(99) |
Mar
(181) |
Apr
(171) |
May
(112) |
Jun
(86) |
Jul
(91) |
Aug
(111) |
Sep
(77) |
Oct
(72) |
Nov
(57) |
Dec
(51) |
2007 |
Jan
(64) |
Feb
(116) |
Mar
(70) |
Apr
(74) |
May
(53) |
Jun
(40) |
Jul
(519) |
Aug
(151) |
Sep
(132) |
Oct
(74) |
Nov
(282) |
Dec
(190) |
2008 |
Jan
(141) |
Feb
(67) |
Mar
(69) |
Apr
(96) |
May
(227) |
Jun
(404) |
Jul
(399) |
Aug
(96) |
Sep
(120) |
Oct
(205) |
Nov
(126) |
Dec
(261) |
2009 |
Jan
(136) |
Feb
(136) |
Mar
(119) |
Apr
(124) |
May
(155) |
Jun
(98) |
Jul
(136) |
Aug
(292) |
Sep
(174) |
Oct
(126) |
Nov
(126) |
Dec
(79) |
2010 |
Jan
(109) |
Feb
(83) |
Mar
(139) |
Apr
(91) |
May
(79) |
Jun
(164) |
Jul
(184) |
Aug
(146) |
Sep
(163) |
Oct
(128) |
Nov
(70) |
Dec
(73) |
2011 |
Jan
(235) |
Feb
(165) |
Mar
(147) |
Apr
(86) |
May
(74) |
Jun
(118) |
Jul
(65) |
Aug
(75) |
Sep
(162) |
Oct
(94) |
Nov
(48) |
Dec
(44) |
2012 |
Jan
(49) |
Feb
(40) |
Mar
(88) |
Apr
(35) |
May
(52) |
Jun
(69) |
Jul
(90) |
Aug
(123) |
Sep
(112) |
Oct
(120) |
Nov
(105) |
Dec
(116) |
2013 |
Jan
(76) |
Feb
(26) |
Mar
(78) |
Apr
(43) |
May
(61) |
Jun
(53) |
Jul
(147) |
Aug
(85) |
Sep
(83) |
Oct
(122) |
Nov
(18) |
Dec
(27) |
2014 |
Jan
(58) |
Feb
(25) |
Mar
(49) |
Apr
(17) |
May
(29) |
Jun
(39) |
Jul
(53) |
Aug
(52) |
Sep
(35) |
Oct
(47) |
Nov
(110) |
Dec
(27) |
2015 |
Jan
(50) |
Feb
(93) |
Mar
(96) |
Apr
(30) |
May
(55) |
Jun
(83) |
Jul
(44) |
Aug
(8) |
Sep
(5) |
Oct
|
Nov
(1) |
Dec
(1) |
2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(3) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
|
2017 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(7) |
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
|
|
1
(13) |
2
(16) |
3
(5) |
4
(6) |
5
(4) |
6
|
7
(8) |
8
(4) |
9
(8) |
10
(14) |
11
(20) |
12
(3) |
13
(7) |
14
(1) |
15
(1) |
16
(5) |
17
(9) |
18
(5) |
19
|
20
|
21
(5) |
22
(7) |
23
(4) |
24
|
25
|
26
|
27
(3) |
28
(2) |
29
(8) |
30
(6) |
|
|
|
From: Eric F. <ef...@ha...> - 2010-06-09 22:22:48
|
On 06/09/2010 10:53 AM, Jae-Joon Lee wrote: > On Wed, Jun 9, 2010 at 4:18 PM, Eric Firing<ef...@ha...> wrote: >> My sense is that box-forced lets you shoot yourself in the foot with >> shared axes, box doesn't. The reason I prohibited sharing x and y axes >> with adjustable as box is that it is not clear what should happen, or >> will happen--fundamental inconsistencies can arise. Suppose you have >> two axes sharing x and y. You set aspect to 1 for the first and 2 for >> the second. The first axes is drawn, executing apply_aspect and setting >> the box dimensions accordingly. Then the second is drawn, also >> executing apply_aspect. It is inconsistent with the first. There is no >> solution that satisfies all constraints. The basic point is that when >> using apply_aspect with adjustable as box, you have to have freedom to >> change one of the axes, and this is not in general consistent with >> sharing both axes--though it may be in particular cases. >> >> Very likely there is a way of refining the logic, but beware: getting >> aspect ratio control to work under a wide range of conditions, including >> all sorts of zooming and resizing, is tricky and laborious. It is much >> easier to break it than to fix it, and the breakage can be hard to spot. >> >> Eric >> > > "box-forced" must be only used in a very limited cases when axes > sharing is okay. > For example, when both x and y axis are shared and both axes have same > aspect ratio and the original axes position of both axes have same > width and height. > > Hm, maybe it is better to limit the visibility of the "box-forced" > option from normal users. > > For the issue of the Basemap using > > ax.set_aspect('equal',adjustable='box',anchor=self.anchor) > > I think (adjustable="box") is not necessary here. Simply using > > ax.set_aspect('equal',anchor=self.anchor) > > should work and it will also resolve the compatibility issue with > axes_grid toolkit. > > But this issue should be addressed by Jeff. I'm not quite familiar with Basemap. Jeff can correct me if I am wrong, but I think adjustable='box' is essential for basemap because the maximum data limits are set when the Basemap instance is created. In some cases the characteristics of the projection, and in all cases the extraction of coastlines, is set at instantiation time. You can zoom in to show smaller regions, but you don't want apply_aspect to expand the data limits beyond their initial values. Eric > > Regards, > > -JJ > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel |
From: Jae-Joon L. <lee...@gm...> - 2010-06-09 21:05:37
|
I'm not very kin to implement every possible options for every possible cases. If you need customization beyond what the current "legend" class provide, I recommend you to use proxy artists. http://matplotlib.sourceforge.net/users/legend_guide.html#using-proxy-artist I personally think that the drawing of the legend handle should be delegated to the associated artist (but fall back to the default behavior when not provided). Regards, -JJ On Wed, Jun 9, 2010 at 4:32 PM, Benjamin Root <ben...@ou...> wrote: > I was trying the patch and I realized a possible use-case that might not > have been thought of before. Consider the situation where a user does a > scatter plot with markers of two different sizes. Then, it isn't that > far-fetched that the user might also want to control the markerscale for > each marker in the legend. > > A particular example would be that a user selected a smaller markersize for > the second scatterplot so that one could see the markers from the first > scatterplot if they share the same coordinates. However, they may wish to > display the markers in the legend so that they have the same size. > > Currently, the markerscale argument accepts only a scalar, and not a list. > I don't know how difficult it would be to modify it do that, but it is a > thought. > > Ben Root > > On Wed, Jun 9, 2010 at 2:23 PM, Jae-Joon Lee <lee...@gm...> wrote: >> >> Thanks for reporting these. >> I took a look at your patch and slight revised it (see the attached). >> While I believe that my patch is compatible to yours, it'll be great >> if you check my patch to see if I missed anything. >> I'll commit the change soon. >> >> Regards, >> >> -JJ >> >> >> On Tue, Jun 8, 2010 at 3:16 PM, Erik Tollerud <eri...@gm...> >> wrote: >> > I noticed some odd behavior in the legend and managed to track down >> > the source of the problem and make a fix (a diff against the current >> > svn is attached). Specifically, two things were fixed: >> > >> > *The "markerscale" argument for the legend seems to do nothing... The >> > attached diff properly applies the markerscale scaling for >> > polygon/circle collections and the markers for lines with markers (but >> > NOT patches or the width of lines elements in the legend). >> > >> > *If the "scatterpoints" argument was >3, all points beyond 3 >> > disappeared. This was because the default scatteryoffset only had 3 >> > entries, so if you didn't specifically overwrite this, the points >> > beyond 3 didn't appear. I've re-worked this so that now the default >> > properly deals with a number of points other than 3. >> > >> > >> > ------------------------------------------------------------------------------ >> > ThinkGeek and WIRED's GeekDad team up for the Ultimate >> > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the >> > lucky parental unit. See the prize list and enter to win: >> > http://p.sf.net/sfu/thinkgeek-promo >> > _______________________________________________ >> > Matplotlib-devel mailing list >> > Mat...@li... >> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > >> > >> >> >> ------------------------------------------------------------------------------ >> ThinkGeek and WIRED's GeekDad team up for the Ultimate >> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the >> lucky parental unit. See the prize list and enter to win: >> http://p.sf.net/sfu/thinkgeek-promo >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > > |
From: Jae-Joon L. <lee...@gm...> - 2010-06-09 20:54:18
|
On Wed, Jun 9, 2010 at 4:18 PM, Eric Firing <ef...@ha...> wrote: > My sense is that box-forced lets you shoot yourself in the foot with > shared axes, box doesn't. The reason I prohibited sharing x and y axes > with adjustable as box is that it is not clear what should happen, or > will happen--fundamental inconsistencies can arise. Suppose you have > two axes sharing x and y. You set aspect to 1 for the first and 2 for > the second. The first axes is drawn, executing apply_aspect and setting > the box dimensions accordingly. Then the second is drawn, also > executing apply_aspect. It is inconsistent with the first. There is no > solution that satisfies all constraints. The basic point is that when > using apply_aspect with adjustable as box, you have to have freedom to > change one of the axes, and this is not in general consistent with > sharing both axes--though it may be in particular cases. > > Very likely there is a way of refining the logic, but beware: getting > aspect ratio control to work under a wide range of conditions, including > all sorts of zooming and resizing, is tricky and laborious. It is much > easier to break it than to fix it, and the breakage can be hard to spot. > > Eric > "box-forced" must be only used in a very limited cases when axes sharing is okay. For example, when both x and y axis are shared and both axes have same aspect ratio and the original axes position of both axes have same width and height. Hm, maybe it is better to limit the visibility of the "box-forced" option from normal users. For the issue of the Basemap using ax.set_aspect('equal',adjustable='box',anchor=self.anchor) I think (adjustable="box") is not necessary here. Simply using ax.set_aspect('equal',anchor=self.anchor) should work and it will also resolve the compatibility issue with axes_grid toolkit. But this issue should be addressed by Jeff. I'm not quite familiar with Basemap. Regards, -JJ |
From: Benjamin R. <ben...@ou...> - 2010-06-09 20:32:42
|
I was trying the patch and I realized a possible use-case that might not have been thought of before. Consider the situation where a user does a scatter plot with markers of two different sizes. Then, it isn't that far-fetched that the user might also want to control the markerscale for each marker in the legend. A particular example would be that a user selected a smaller markersize for the second scatterplot so that one could see the markers from the first scatterplot if they share the same coordinates. However, they may wish to display the markers in the legend so that they have the same size. Currently, the markerscale argument accepts only a scalar, and not a list. I don't know how difficult it would be to modify it do that, but it is a thought. Ben Root On Wed, Jun 9, 2010 at 2:23 PM, Jae-Joon Lee <lee...@gm...> wrote: > Thanks for reporting these. > I took a look at your patch and slight revised it (see the attached). > While I believe that my patch is compatible to yours, it'll be great > if you check my patch to see if I missed anything. > I'll commit the change soon. > > Regards, > > -JJ > > > On Tue, Jun 8, 2010 at 3:16 PM, Erik Tollerud <eri...@gm...> > wrote: > > I noticed some odd behavior in the legend and managed to track down > > the source of the problem and make a fix (a diff against the current > > svn is attached). Specifically, two things were fixed: > > > > *The "markerscale" argument for the legend seems to do nothing... The > > attached diff properly applies the markerscale scaling for > > polygon/circle collections and the markers for lines with markers (but > > NOT patches or the width of lines elements in the legend). > > > > *If the "scatterpoints" argument was >3, all points beyond 3 > > disappeared. This was because the default scatteryoffset only had 3 > > entries, so if you didn't specifically overwrite this, the points > > beyond 3 didn't appear. I've re-worked this so that now the default > > properly deals with a number of points other than 3. > > > > > ------------------------------------------------------------------------------ > > ThinkGeek and WIRED's GeekDad team up for the Ultimate > > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > > lucky parental unit. See the prize list and enter to win: > > http://p.sf.net/sfu/thinkgeek-promo > > _______________________________________________ > > Matplotlib-devel mailing list > > Mat...@li... > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > > > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > |
From: Eric F. <ef...@ha...> - 2010-06-09 20:19:09
|
On 06/09/2010 09:58 AM, Benjamin Root wrote: > Has anybody given any further thought to the implication of having > Basemap set adjustable as "box-forced" instead of "box"? So far, it has > been working just fine for me, but I have no clue if there are any > unintended side-effects. My sense is that box-forced lets you shoot yourself in the foot with shared axes, box doesn't. The reason I prohibited sharing x and y axes with adjustable as box is that it is not clear what should happen, or will happen--fundamental inconsistencies can arise. Suppose you have two axes sharing x and y. You set aspect to 1 for the first and 2 for the second. The first axes is drawn, executing apply_aspect and setting the box dimensions accordingly. Then the second is drawn, also executing apply_aspect. It is inconsistent with the first. There is no solution that satisfies all constraints. The basic point is that when using apply_aspect with adjustable as box, you have to have freedom to change one of the axes, and this is not in general consistent with sharing both axes--though it may be in particular cases. Very likely there is a way of refining the logic, but beware: getting aspect ratio control to work under a wide range of conditions, including all sorts of zooming and resizing, is tricky and laborious. It is much easier to break it than to fix it, and the breakage can be hard to spot. Eric > > Ben Root > > > On Tue, Jun 1, 2010 at 6:00 PM, Benjamin Root <ben...@ou... > <mailto:ben...@ou...>> wrote: > > 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 what sort of repricussions that > has for other use cases. > > So far, this has worked just fine for me, but I hardly represent the > normal use cases of Basemap and AxesGrid. > > Ben Root > > > On Tue, Jun 1, 2010 at 5:20 PM, Jae-Joon Lee <lee...@gm... > <mailto:lee...@gm...>> wrote: > > 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 > > > On Tue, Jun 1, 2010 at 2:45 PM, Benjamin Root <ben...@ou... > <mailto:ben...@ou...>> wrote: > > > > 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 of > > 'box' in Basemap? > > > > Ben Root > > > > On Thu, May 27, 2010 at 1:59 PM, Jae-Joon Lee > <lee...@gm... <mailto:lee...@gm...>> wrote: > >> > >> ax1 = subplot(121) > >> ax2 = subplot(122, sharex=ax1, sharey=ax1) > >> > >> ax1.set_adjustable("box-forced") > >> ax2.set_adjustable("box-forced") > >> > >> arr1 = np.arange(100).reshape((10, 10)) > >> ax1.imshow(arr1) > >> > >> arr2 = np.arange(100, 0, -1).reshape((10, 10)) > >> ax2.imshow(arr2) > >> > >> Note the use of set_adjustable("box-forced"). > >> sharex and sharey does not get along with axes of aspect=1 & > >> adjustable="box". > >> > >> -JJ > >> > >> > >> > >> On Thu, May 27, 2010 at 2:10 PM, <PH...@ge... > <mailto:PH...@ge...>> wrote: > >> > Do the “sharex” and “sharey” kwargs help? > >> > > >> > > >> > > http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.axes > >> > > >> > > >> > > http://matplotlib.sourceforge.net/examples/pylab_examples/shared_axis_demo.html > >> > > >> > -paul > >> > > >> > > >> > > >> > From: Adam Fraser [mailto:ada...@gm... > <mailto:ada...@gm...>] > >> > Sent: Thursday, May 27, 2010 10:44 AM > >> > To: matplotlib-users > >> > Subject: [Matplotlib-users] Is there a way to link axes of > imshow plots? > >> > > >> > > >> > > >> > Suppose I have a figure canvas with 3 plots... 2 are > images of the same > >> > dimensions plotted with imshow, and the other is a > scatterplot. I'd like > >> > to > >> > be able to link the x and y axes of the imshow plots so > that when I zoom > >> > in > >> > one, the other zooms to the same coordinates, and when I > pan in one, the > >> > other pans as well. > >> > > >> > > >> > > >> > I started hacking my way around this by > >> > subclassing NavigationToolbar2WxAgg > >> > (shown below)... but there are several problems here. > >> > > >> > 1) This will link the axes of all plots in a canvas since > all I've done > >> > is > >> > get rid of the checks for a.in_axes() > >> > > >> > 2) This worked well for panning, but zooming caused all > subplots to zoom > >> > from the same global point, rather than from the same > point in each of > >> > their > >> > respective axes. > >> > > >> > > >> > > >> > Can anyone suggest a workaround? > >> > > >> > > >> > > >> > Much thanks! > >> > > >> > -Adam > >> > > >> > > >> > > >> > from matplotlib.backends.backend_wxagg import > NavigationToolbar2WxAgg as > >> > NavigationToolbar > >> > > >> > class MyNavToolbar(NavigationToolbar): > >> > > >> > def __init__(self, canvas, cpfig): > >> > > >> > NavigationToolbar.__init__(self, canvas) > >> > > >> > > >> > > >> > # override > >> > > >> > def press_pan(self, event): > >> > > >> > 'the press mouse button in pan/zoom mode callback' > >> > > >> > > >> > > >> > if event.button == 1: > >> > > >> > self._button_pressed=1 > >> > > >> > elif event.button == 3: > >> > > >> > self._button_pressed=3 > >> > > >> > else: > >> > > >> > self._button_pressed=None > >> > > >> > return > >> > > >> > > >> > > >> > x, y = event.x, event.y > >> > > >> > > >> > > >> > # push the current view to define home if stack is > empty > >> > > >> > if self._views.empty(): self.push_current() > >> > > >> > > >> > > >> > self._xypress=[] > >> > > >> > for i, a in enumerate(self.canvas.figure.get_axes()): > >> > > >> > # only difference from overridden method is > that this one > >> > doesn't > >> > > >> > # check a.in_axes(event) > >> > > >> > if x is not None and y is not None and > a.get_navigate(): > >> > > >> > a.start_pan(x, y, event.button) > >> > > >> > self._xypress.append((a, i)) > >> > > >> > self.canvas.mpl_disconnect(self._idDrag) > >> > > >> > > >> > self._idDrag=self.canvas.mpl_connect('motion_notify_event', > >> > self.drag_pan) > >> > > >> > > >> > > >> > def press_zoom(self, event): > >> > > >> > 'the press mouse button in zoom to rect mode callback' > >> > > >> > if event.button == 1: > >> > > >> > self._button_pressed=1 > >> > > >> > elif event.button == 3: > >> > > >> > self._button_pressed=3 > >> > > >> > else: > >> > > >> > self._button_pressed=None > >> > > >> > return > >> > > >> > > >> > > >> > x, y = event.x, event.y > >> > > >> > > >> > > >> > # push the current view to define home if stack is > empty > >> > > >> > if self._views.empty(): self.push_current() > >> > > >> > > >> > > >> > self._xypress=[] > >> > > >> > for i, a in enumerate(self.canvas.figure.get_axes()): > >> > > >> > # only difference from overridden method is > that this one > >> > doesn't > >> > > >> > # check a.in_axes(event) > >> > > >> > if x is not None and y is not None and > a.get_navigate() and > >> > a.can_zoom(): > >> > > >> > self._xypress.append(( x, y, a, i, > a.viewLim.frozen(), > >> > a.transData.frozen())) > >> > > >> > > >> > > >> > self.press(event) > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > ------------------------------------------------------------------------------ > >> > > >> > > >> > _______________________________________________ > >> > Matplotlib-users mailing list > >> > Mat...@li... > <mailto:Mat...@li...> > >> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > >> > > >> > > >> > >> > >> > ------------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> Matplotlib-users mailing list > >> Mat...@li... > <mailto:Mat...@li...> > >> https://lists.sourceforge.net/lists/listinfo/matplotlib-users > > > > > > > ------------------------------------------------------------------------------ > > > > > > _______________________________________________ > > Matplotlib-devel mailing list > > Mat...@li... > <mailto:Mat...@li...> > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > <mailto:Mat...@li...> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > > > > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel |
From: Benjamin R. <ben...@ou...> - 2010-06-09 19:58:44
|
Has anybody given any further thought to the implication of having Basemap set adjustable as "box-forced" instead of "box"? So far, it has been working just fine for me, but I have no clue if there are any unintended side-effects. Ben Root On Tue, Jun 1, 2010 at 6:00 PM, Benjamin Root <ben...@ou...> wrote: > 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 > what sort of repricussions that has for other use cases. > > So far, this has worked just fine for me, but I hardly represent the normal > use cases of Basemap and AxesGrid. > > Ben Root > > > On Tue, Jun 1, 2010 at 5:20 PM, Jae-Joon Lee <lee...@gm...> wrote: > >> 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 >> >> >> On Tue, Jun 1, 2010 at 2:45 PM, Benjamin Root <ben...@ou...> wrote: >> > >> > 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 >> of >> > 'box' in Basemap? >> > >> > Ben Root >> > >> > On Thu, May 27, 2010 at 1:59 PM, Jae-Joon Lee <lee...@gm...> >> wrote: >> >> >> >> ax1 = subplot(121) >> >> ax2 = subplot(122, sharex=ax1, sharey=ax1) >> >> >> >> ax1.set_adjustable("box-forced") >> >> ax2.set_adjustable("box-forced") >> >> >> >> arr1 = np.arange(100).reshape((10, 10)) >> >> ax1.imshow(arr1) >> >> >> >> arr2 = np.arange(100, 0, -1).reshape((10, 10)) >> >> ax2.imshow(arr2) >> >> >> >> Note the use of set_adjustable("box-forced"). >> >> sharex and sharey does not get along with axes of aspect=1 & >> >> adjustable="box". >> >> >> >> -JJ >> >> >> >> >> >> >> >> On Thu, May 27, 2010 at 2:10 PM, <PH...@ge...> wrote: >> >> > Do the “sharex” and “sharey” kwargs help? >> >> > >> >> > >> >> > >> http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.axes >> >> > >> >> > >> >> > >> http://matplotlib.sourceforge.net/examples/pylab_examples/shared_axis_demo.html >> >> > >> >> > -paul >> >> > >> >> > >> >> > >> >> > From: Adam Fraser [mailto:ada...@gm...] >> >> > Sent: Thursday, May 27, 2010 10:44 AM >> >> > To: matplotlib-users >> >> > Subject: [Matplotlib-users] Is there a way to link axes of imshow >> plots? >> >> > >> >> > >> >> > >> >> > Suppose I have a figure canvas with 3 plots... 2 are images of the >> same >> >> > dimensions plotted with imshow, and the other is a scatterplot. I'd >> like >> >> > to >> >> > be able to link the x and y axes of the imshow plots so that when I >> zoom >> >> > in >> >> > one, the other zooms to the same coordinates, and when I pan in one, >> the >> >> > other pans as well. >> >> > >> >> > >> >> > >> >> > I started hacking my way around this by >> >> > subclassing NavigationToolbar2WxAgg >> >> > (shown below)... but there are several problems here. >> >> > >> >> > 1) This will link the axes of all plots in a canvas since all I've >> done >> >> > is >> >> > get rid of the checks for a.in_axes() >> >> > >> >> > 2) This worked well for panning, but zooming caused all subplots to >> zoom >> >> > from the same global point, rather than from the same point in each >> of >> >> > their >> >> > respective axes. >> >> > >> >> > >> >> > >> >> > Can anyone suggest a workaround? >> >> > >> >> > >> >> > >> >> > Much thanks! >> >> > >> >> > -Adam >> >> > >> >> > >> >> > >> >> > from matplotlib.backends.backend_wxagg import NavigationToolbar2WxAgg >> as >> >> > NavigationToolbar >> >> > >> >> > class MyNavToolbar(NavigationToolbar): >> >> > >> >> > def __init__(self, canvas, cpfig): >> >> > >> >> > NavigationToolbar.__init__(self, canvas) >> >> > >> >> > >> >> > >> >> > # override >> >> > >> >> > def press_pan(self, event): >> >> > >> >> > 'the press mouse button in pan/zoom mode callback' >> >> > >> >> > >> >> > >> >> > if event.button == 1: >> >> > >> >> > self._button_pressed=1 >> >> > >> >> > elif event.button == 3: >> >> > >> >> > self._button_pressed=3 >> >> > >> >> > else: >> >> > >> >> > self._button_pressed=None >> >> > >> >> > return >> >> > >> >> > >> >> > >> >> > x, y = event.x, event.y >> >> > >> >> > >> >> > >> >> > # push the current view to define home if stack is empty >> >> > >> >> > if self._views.empty(): self.push_current() >> >> > >> >> > >> >> > >> >> > self._xypress=[] >> >> > >> >> > for i, a in enumerate(self.canvas.figure.get_axes()): >> >> > >> >> > # only difference from overridden method is that this one >> >> > doesn't >> >> > >> >> > # check a.in_axes(event) >> >> > >> >> > if x is not None and y is not None and a.get_navigate(): >> >> > >> >> > a.start_pan(x, y, event.button) >> >> > >> >> > self._xypress.append((a, i)) >> >> > >> >> > self.canvas.mpl_disconnect(self._idDrag) >> >> > >> >> > >> >> > self._idDrag=self.canvas.mpl_connect('motion_notify_event', >> >> > self.drag_pan) >> >> > >> >> > >> >> > >> >> > def press_zoom(self, event): >> >> > >> >> > 'the press mouse button in zoom to rect mode callback' >> >> > >> >> > if event.button == 1: >> >> > >> >> > self._button_pressed=1 >> >> > >> >> > elif event.button == 3: >> >> > >> >> > self._button_pressed=3 >> >> > >> >> > else: >> >> > >> >> > self._button_pressed=None >> >> > >> >> > return >> >> > >> >> > >> >> > >> >> > x, y = event.x, event.y >> >> > >> >> > >> >> > >> >> > # push the current view to define home if stack is empty >> >> > >> >> > if self._views.empty(): self.push_current() >> >> > >> >> > >> >> > >> >> > self._xypress=[] >> >> > >> >> > for i, a in enumerate(self.canvas.figure.get_axes()): >> >> > >> >> > # only difference from overridden method is that this one >> >> > doesn't >> >> > >> >> > # check a.in_axes(event) >> >> > >> >> > if x is not None and y is not None and a.get_navigate() >> and >> >> > a.can_zoom(): >> >> > >> >> > self._xypress.append(( x, y, a, i, >> a.viewLim.frozen(), >> >> > a.transData.frozen())) >> >> > >> >> > >> >> > >> >> > self.press(event) >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> ------------------------------------------------------------------------------ >> >> > >> >> > >> >> > _______________________________________________ >> >> > Matplotlib-users mailing list >> >> > Mat...@li... >> >> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users >> >> > >> >> > >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> >> >> _______________________________________________ >> >> Matplotlib-users mailing list >> >> Mat...@li... >> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-users >> > >> > >> > >> ------------------------------------------------------------------------------ >> > >> > >> > _______________________________________________ >> > Matplotlib-devel mailing list >> > Mat...@li... >> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > >> > >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > > |
From: Jae-Joon L. <lee...@gm...> - 2010-06-09 19:24:01
|
Thanks for reporting these. I took a look at your patch and slight revised it (see the attached). While I believe that my patch is compatible to yours, it'll be great if you check my patch to see if I missed anything. I'll commit the change soon. Regards, -JJ On Tue, Jun 8, 2010 at 3:16 PM, Erik Tollerud <eri...@gm...> wrote: > I noticed some odd behavior in the legend and managed to track down > the source of the problem and make a fix (a diff against the current > svn is attached). Specifically, two things were fixed: > > *The "markerscale" argument for the legend seems to do nothing... The > attached diff properly applies the markerscale scaling for > polygon/circle collections and the markers for lines with markers (but > NOT patches or the width of lines elements in the legend). > > *If the "scatterpoints" argument was >3, all points beyond 3 > disappeared. This was because the default scatteryoffset only had 3 > entries, so if you didn't specifically overwrite this, the points > beyond 3 didn't appear. I've re-worked this so that now the default > properly deals with a number of points other than 3. > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > |
From: John H. <jd...@gm...> - 2010-06-08 20:12:39
|
On Tue, Jun 8, 2010 at 2:49 PM, Friedrich Romstedt <fri...@gm...> wrote: > Hi Michael, > > may it be that you used different compilers for compiling your > FreeType2 and your matplotlib? [CC=gcc-4.2] It's nearly impossible > to tell afterwards from the libraries. > > I was able to compile matplotlib (not the svn though) on OS X Snow > Leopard /without/ using the make.osx script. One has to apply some > changes, but not large ones. > > John, I have the slight impression that you constantly try to ignore > me, can you give a good reason, then I will be satisfied. Fixing the > _png.cpp issue for libpng 1.4 would be a good start to make matplotlib > compilable without the effort of make.osx. Sorry, I wasn't intentionally ignoring you. I don't have as much time as I'd like on the mpl mailing list so I sometimes dart in and out. If there is some thread or two or three where you would like me to comment or have some patches that need attention, please point me to them. Frequently, threads and contributions get left behind. Usually, the slight is not intentional but just due to bandwidth constraints. It happens enough that we have a FAQ :-) http://matplotlib.sourceforge.net/faq/howto_faq.html#contributing-howto JDH |
From: Friedrich R. <fri...@gm...> - 2010-06-08 19:49:41
|
Hi Michael, may it be that you used different compilers for compiling your FreeType2 and your matplotlib? [CC=gcc-4.2] It's nearly impossible to tell afterwards from the libraries. I was able to compile matplotlib (not the svn though) on OS X Snow Leopard /without/ using the make.osx script. One has to apply some changes, but not large ones. John, I have the slight impression that you constantly try to ignore me, can you give a good reason, then I will be satisfied. Fixing the _png.cpp issue for libpng 1.4 would be a good start to make matplotlib compilable without the effort of make.osx. I want to add that I'm not an expert and used just standard approaches. But they worked (for me). Especially I have way to little knowledge of the implications of 64bit. Best, Friedrich |
From: Benjamin R. <ben...@ou...> - 2010-06-08 19:42:57
|
Erik, Thanks for addressing this. I actually ran into this problem once a while back, but just figured that I was doing something wrong. I will check out your patch to see how well it works. Ben Root On Tue, Jun 8, 2010 at 2:16 PM, Erik Tollerud <eri...@gm...>wrote: > I noticed some odd behavior in the legend and managed to track down > the source of the problem and make a fix (a diff against the current > svn is attached). Specifically, two things were fixed: > > *The "markerscale" argument for the legend seems to do nothing... The > attached diff properly applies the markerscale scaling for > polygon/circle collections and the markers for lines with markers (but > NOT patches or the width of lines elements in the legend). > > *If the "scatterpoints" argument was >3, all points beyond 3 > disappeared. This was because the default scatteryoffset only had 3 > entries, so if you didn't specifically overwrite this, the points > beyond 3 didn't appear. I've re-worked this so that now the default > properly deals with a number of points other than 3. > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > |
From: Erik T. <eri...@gm...> - 2010-06-08 19:17:22
|
I noticed some odd behavior in the legend and managed to track down the source of the problem and make a fix (a diff against the current svn is attached). Specifically, two things were fixed: *The "markerscale" argument for the legend seems to do nothing... The attached diff properly applies the markerscale scaling for polygon/circle collections and the markers for lines with markers (but NOT patches or the width of lines elements in the legend). *If the "scatterpoints" argument was >3, all points beyond 3 disappeared. This was because the default scatteryoffset only had 3 entries, so if you didn't specifically overwrite this, the points beyond 3 didn't appear. I've re-worked this so that now the default properly deals with a number of points other than 3. |
From: John H. <jd...@gm...> - 2010-06-07 21:47:15
|
On Mon, Jun 7, 2010 at 4:13 PM, Michael Hearne <mh...@us...> wrote: > John - I followed your advice, and tried the build/install step again after downloading a completely fresh svn copy of the source: > > svn co https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib matplotlib > cd matplotlib > sudo PREFIX=/Library/Frameworks/EPD64.framework/Versions/Current/ make -f make.osx fetch deps mpl_install > > It successfully compiled and installed matplotlib in my site-packages directory. However, I still see this in ipython: > >>>from matplotlib import ft2font > --------------------------------------------------------------------------- > ImportError Traceback (most recent call last) > > /Users/mhearne/<ipython console> in <module>() > > ImportError: dlopen(/Library/Frameworks/EPD64.framework/Versions/6.0.0/lib/python2.6/site-packages/matplotlib/ft2font.so, 2): Symbol not found: _FT_Attach_File > Referenced from: /Library/Frameworks/EPD64.framework/Versions/6.0.0/lib/python2.6/site-packages/matplotlib/ft2font.so > Expected in: flat namespace > in /Library/Frameworks/EPD64.framework/Versions/6.0.0/lib/python2.6/site-packages/matplotlib/ft2font.so > > Am I missing some other step? One possibility is that the path from the traceback /Library/Frameworks/EPD64.framework/Versions/6.0.0/lib/python2.6/site-packages is not the same as your PREFIX "PREFIX=/Library/Frameworks/EPD64.framework/Versions/Current/" unless "Current" is a symlink to 6.0.0 which it very well may be. Can you confirm? If you are getting different versions, you'll need to set your PYTHONPATH. Alternatively, we may need to set your LD_LIBRARY_PATH or similar to find the libs we built. They should be in $PREFIX/lib. You can use otool to see what the linker is finding in your current environment > otool -L /Library/Frameworks/EPD64.framework/Versions/Current/lib/python2.6/site-packages/matplotlib/ft2font.so There may be another way -- you can set your prefix to something like PREFIX=~/tmpbuild and then build as before but do 'make binaries' rather than 'make mpl_install'. Then use the binary installer to do the system install. This may get you a build with the support libs statically linked in, though I am not sure about this. Sorry this is such a pain -- I keep trying to make a build script that works for people but it obviously isn't there yet. JDH |
From: Michael H. <mh...@us...> - 2010-06-07 21:13:27
|
John - I followed your advice, and tried the build/install step again after downloading a completely fresh svn copy of the source: svn co https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib matplotlib cd matplotlib sudo PREFIX=/Library/Frameworks/EPD64.framework/Versions/Current/ make -f make.osx fetch deps mpl_install It successfully compiled and installed matplotlib in my site-packages directory. However, I still see this in ipython: >>from matplotlib import ft2font --------------------------------------------------------------------------- ImportError Traceback (most recent call last) /Users/mhearne/<ipython console> in <module>() ImportError: dlopen(/Library/Frameworks/EPD64.framework/Versions/6.0.0/lib/python2.6/site-packages/matplotlib/ft2font.so, 2): Symbol not found: _FT_Attach_File Referenced from: /Library/Frameworks/EPD64.framework/Versions/6.0.0/lib/python2.6/site-packages/matplotlib/ft2font.so Expected in: flat namespace in /Library/Frameworks/EPD64.framework/Versions/6.0.0/lib/python2.6/site-packages/matplotlib/ft2font.so Am I missing some other step? Thanks, Mike On Jun 7, 2010, at 9:52 AM, John Hunter wrote: > On Mon, Jun 7, 2010 at 10:26 AM, Michael Hearne <mh...@us...> wrote: >> I've had several problems with building on OS X in the past, and was just notified that a bug I opened about it has closed. Eric Firing suggested that I re-open the bug if it is still a problem. It is still a problem, but I can't seem to figure out how to re-open my bug report, so I'll report it again here with an update on the procedures I followed. >> >> First, I downloaded a fresh copy of matplotlib source: >> >> svn co https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib matplotlib >> >> Then, following the instructions I found in README.osx: >> PREFIX=/Users/mhearne/build make -f make.osx fetch deps mpl_install >> >> I then moved my current matplotlib (one from Enthought) aside: >> cd /Library/Frameworks/EPD64.framework/Versions/Current/lib/python2.6/site-packages >> sudo mv matplotlib matplotlib.old >> >> I then used setup.py to install matplotlib: >> sudo /Library/Frameworks/EPD64.framework/Versions/Current/bin/python setup.py install > > > You do not want to do this last step. The mpl_install in the make > command will handle the install. This last step may be building > against different libs, which is probably why you are seeing the > ft2font import link problem. > > Note that the install will be put into > $PREFIX/lib/python.6/site-packages so the PREFIX should be your > installation target, not your build target. Ie, it looks like you are > not setting the PREFIX according to the intent. > > I suggest something like > >> sudo PREFIX=/Library/Frameworks/EPD64.framework/Versions/Current/ > make -f deps mpl_install > > for your current file hierarchy. Alternatively, you can do > >> PREFIX=/Users/mhearne/build make -f make binaries > > and then use the binary installers that are built to do the site wide install. > > > JDH |
From: Eric F. <ef...@ha...> - 2010-06-07 18:30:40
|
On 06/07/2010 03:04 AM, Bob wrote: > Here is an example which generates both a png and svg file. > The png edge alpha levels are displayed correctly, while the svg edges > have an alpha value of 1.0 > I tested this with a fresh build of matplotlib-1.0.svn r8391 > Thanks for your help. And thank you for the report. I have fixed this in 8394. Eric > > #!/usr/bin/python > import sys > import matplotlib > matplotlib.use('Agg') > import matplotlib.pyplot as plt > import numpy as N > import networkx as nx > > def main(): > G = nx.Graph() > G.add_nodes_from([0,1,2]) > G.add_edges_from([(0,1),(0,2),(1,2)]) > pos = nx.spring_layout(G) > nx.draw_networkx_nodes(G, pos, node_size=1500, > node_color=['c','m','y'], alpha=0.3) > nx.draw_networkx_edges(G, pos, width=45, edge_color=['r','g','b'], alpha=0.3) > nx.draw_networkx_labels(G, pos) > plt.savefig('test.png') > plt.savefig('test.svg') > return 0 > > if __name__ == "__main__": > sys.exit(main()) > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel |
From: John H. <jd...@gm...> - 2010-06-07 15:52:35
|
On Mon, Jun 7, 2010 at 10:26 AM, Michael Hearne <mh...@us...> wrote: > I've had several problems with building on OS X in the past, and was just notified that a bug I opened about it has closed. Eric Firing suggested that I re-open the bug if it is still a problem. It is still a problem, but I can't seem to figure out how to re-open my bug report, so I'll report it again here with an update on the procedures I followed. > > First, I downloaded a fresh copy of matplotlib source: > > svn co https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib matplotlib > > Then, following the instructions I found in README.osx: > PREFIX=/Users/mhearne/build make -f make.osx fetch deps mpl_install > > I then moved my current matplotlib (one from Enthought) aside: > cd /Library/Frameworks/EPD64.framework/Versions/Current/lib/python2.6/site-packages > sudo mv matplotlib matplotlib.old > > I then used setup.py to install matplotlib: > sudo /Library/Frameworks/EPD64.framework/Versions/Current/bin/python setup.py install You do not want to do this last step. The mpl_install in the make command will handle the install. This last step may be building against different libs, which is probably why you are seeing the ft2font import link problem. Note that the install will be put into $PREFIX/lib/python.6/site-packages so the PREFIX should be your installation target, not your build target. Ie, it looks like you are not setting the PREFIX according to the intent. I suggest something like > sudo PREFIX=/Library/Frameworks/EPD64.framework/Versions/Current/ make -f deps mpl_install for your current file hierarchy. Alternatively, you can do > PREFIX=/Users/mhearne/build make -f make binaries and then use the binary installers that are built to do the site wide install. JDH |
From: Michael H. <mh...@us...> - 2010-06-07 15:41:13
|
I've had several problems with building on OS X in the past, and was just notified that a bug I opened about it has closed. Eric Firing suggested that I re-open the bug if it is still a problem. It is still a problem, but I can't seem to figure out how to re-open my bug report, so I'll report it again here with an update on the procedures I followed. First, I downloaded a fresh copy of matplotlib source: svn co https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib matplotlib Then, following the instructions I found in README.osx: PREFIX=/Users/mhearne/build make -f make.osx fetch deps mpl_install I then moved my current matplotlib (one from Enthought) aside: cd /Library/Frameworks/EPD64.framework/Versions/Current/lib/python2.6/site-packages sudo mv matplotlib matplotlib.old I then used setup.py to install matplotlib: sudo /Library/Frameworks/EPD64.framework/Versions/Current/bin/python setup.py install Then I tried to import ft2font from the ipython command line: from matplotlib import ft2font and got the following error: --------------------------------------------------------------------------- ImportError Traceback (most recent call last) /Users/mhearne/build/matplotlib/<ipython console> in <module>() ImportError: dlopen(/Library/Frameworks/EPD64.framework/Versions/6.0.0/lib/python2.6/site-packages/matplotlib/ft2font.so, 2): Symbol not found: _FT_Attach_File Referenced from: /Library/Frameworks/EPD64.framework/Versions/6.0.0/lib/python2.6/site-packages/matplotlib/ft2font.so Expected in: flat namespace in /Library/Frameworks/EPD64.framework/Versions/6.0.0/lib/python2.6/site-packages/matplotlib/ft2font.so |
From: Michael D. <md...@st...> - 2010-06-07 14:24:24
|
I think the better fix here might be to fix "baseline" to use the baseline of the bottom line of text, rather than the top. We are making a concerted effort to use "baseline" as much as possible, because it is generally the right choice. I have committed this fix to r8393. Mike On 06/07/2010 07:27 AM, Olle Engdegård wrote: > Hi, > > When "baseline" recently became the default for text(), it's no longer > possible to have two-line titles, title("First line\nSecond Line), > without adding va="bottom". It would be nice if title() somehow could > have "bottom" as default. > > Cheers, > Olle > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA |
From: Bob <rps...@gm...> - 2010-06-07 13:04:48
|
Here is an example which generates both a png and svg file. The png edge alpha levels are displayed correctly, while the svg edges have an alpha value of 1.0 I tested this with a fresh build of matplotlib-1.0.svn r8391 Thanks for your help. #!/usr/bin/python import sys import matplotlib matplotlib.use('Agg') import matplotlib.pyplot as plt import numpy as N import networkx as nx def main(): G = nx.Graph() G.add_nodes_from([0,1,2]) G.add_edges_from([(0,1),(0,2),(1,2)]) pos = nx.spring_layout(G) nx.draw_networkx_nodes(G, pos, node_size=1500, node_color=['c','m','y'], alpha=0.3) nx.draw_networkx_edges(G, pos, width=45, edge_color=['r','g','b'], alpha=0.3) nx.draw_networkx_labels(G, pos) plt.savefig('test.png') plt.savefig('test.svg') return 0 if __name__ == "__main__": sys.exit(main()) |
From: Olle E. <oen...@gm...> - 2010-06-07 11:28:07
|
Hi, When "baseline" recently became the default for text(), it's no longer possible to have two-line titles, title("First line\nSecond Line), without adding va="bottom". It would be nice if title() somehow could have "bottom" as default. Cheers, Olle |
From: Jae-Joon L. <lee...@gm...> - 2010-06-05 17:55:20
|
The link to the trunk-version of the documentation http://matplotlib.sourceforge.net/trunk-docs/ has not been working for a few days. And this seems to be due to build failure on one of th build bot. http://mpl-buildbot.code.astraw.com/waterfall However, the the documentation build just fine in my local installation. Does anyone else has doc build failure? Andrew, can you take a look if you have a chance? Regards, -JJ |
From: Jae-Joon L. <lee...@gm...> - 2010-06-05 17:13:07
|
On Sat, Jun 5, 2010 at 12:24 AM, Eric Firing <ef...@ha...> wrote: >> No, they do work when decorated, I am not claiming that they don't. >> Maybe the CircleCollection and the EllipseCollection don't need the >> decorator, but the PolyCollector generates a warning if you set >> rasterized=True without the decorator. > > They all need the decorator because of the flag it adds. Having a > decorated draw call a decorated base draw doesn't hurt. > Ah, I didn't noticed the warning. > I added the missing Collection subclass draw decorators in svn 8381. Thanks Eric, -JJ > > Eric > |
From: Eric F. <ef...@ha...> - 2010-06-05 04:24:42
|
On 06/04/2010 02:50 PM, Benjamin Root wrote: > > > On Fri, Jun 4, 2010 at 4:53 PM, Jae-Joon Lee <lee...@gm... > <mailto:lee...@gm...>> wrote: > > On Wed, Jun 2, 2010 at 10:09 PM, Benjamin Root <ben...@ou... > <mailto:ben...@ou...>> wrote: > > I have noticed that the svn repo still does not have rasterization > > decorators for some of the collections (e.g., PolyCollection, > > EllipseCollection, CircleCollection if I remember correctly). > Don't know > > what are supposed to be the final list of Collection that are > eligible for > > that decorator, but it is incomplete at this point in the trunk. > > Did you actually test that the rasterization does not work for these > artist? > They are supposed to, and and they do in my installation. > > If you simply saying that the draw method of these artist are not > decorated, they don't need one because Collection.draw which is called > inside their draw method is already decorated. > > Regards, > > -JJ > > > No, they do work when decorated, I am not claiming that they don't. > Maybe the CircleCollection and the EllipseCollection don't need the > decorator, but the PolyCollector generates a warning if you set > rasterized=True without the decorator. They all need the decorator because of the flag it adds. Having a decorated draw call a decorated base draw doesn't hurt. I added the missing Collection subclass draw decorators in svn 8381. Eric > > Ben Root |
From: Benjamin R. <ben...@ou...> - 2010-06-05 00:50:48
|
On Fri, Jun 4, 2010 at 4:53 PM, Jae-Joon Lee <lee...@gm...> wrote: > On Wed, Jun 2, 2010 at 10:09 PM, Benjamin Root <ben...@ou...> wrote: > > I have noticed that the svn repo still does not have rasterization > > decorators for some of the collections (e.g., PolyCollection, > > EllipseCollection, CircleCollection if I remember correctly). Don't know > > what are supposed to be the final list of Collection that are eligible > for > > that decorator, but it is incomplete at this point in the trunk. > > Did you actually test that the rasterization does not work for these > artist? > They are supposed to, and and they do in my installation. > > If you simply saying that the draw method of these artist are not > decorated, they don't need one because Collection.draw which is called > inside their draw method is already decorated. > > Regards, > > -JJ > No, they do work when decorated, I am not claiming that they don't. Maybe the CircleCollection and the EllipseCollection don't need the decorator, but the PolyCollector generates a warning if you set rasterized=True without the decorator. Ben Root |
From: Eric F. <ef...@ha...> - 2010-06-04 23:40:06
|
See https://sourceforge.net/tracker/?func=detail&aid=2564093&group_id=80706&atid=560720 My guess is that the problem is the call to Printer_Init(). Based on a little code scanning and grepping, and on the default wxagg plot with toolbar, I don't see that any of the Print* stuff is being used by mpl--but I know very little about wx, and I have not looked deeply into backend_wx*. Can we simply remove Printer_Init() from FigureCanvasWx.__init__, or will that have dire consequences for someone? Is there a wx wizard who can provide a good solution? One way or another, I would like to get this ancient ticket closed. Eric |
From: Jae-Joon L. <lee...@gm...> - 2010-06-04 21:54:10
|
On Wed, Jun 2, 2010 at 10:09 PM, Benjamin Root <ben...@ou...> wrote: > I have noticed that the svn repo still does not have rasterization > decorators for some of the collections (e.g., PolyCollection, > EllipseCollection, CircleCollection if I remember correctly). Don't know > what are supposed to be the final list of Collection that are eligible for > that decorator, but it is incomplete at this point in the trunk. Did you actually test that the rasterization does not work for these artist? They are supposed to, and and they do in my installation. If you simply saying that the draw method of these artist are not decorated, they don't need one because Collection.draw which is called inside their draw method is already decorated. Regards, -JJ |