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
|
2
(1) |
3
(7) |
4
|
|
5
(9) |
6
(7) |
7
(10) |
8
(5) |
9
(2) |
10
(5) |
11
(6) |
|
12
(1) |
13
(6) |
14
(1) |
15
(15) |
16
(1) |
17
(2) |
18
(1) |
|
19
(1) |
20
|
21
|
22
(1) |
23
(2) |
24
(4) |
25
(2) |
|
26
(2) |
27
(1) |
28
(11) |
29
(14) |
30
(7) |
|
|
On Tue, Apr 28, 2009 at 10:59 AM, Olivier Feys <oli...@gm...>wrote: > 0.98.5.2 > I also am not seeing it on the 0.98 branch, so the good news is that if we can ever get this release out as planned it should be fixed on the next release. Or if you are happy with svn and a compiler, you can upgrade from svn http://matplotlib.sourceforge.net/faq/installing_faq.html#install-svn JDH
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#666666">
0.98.5.2<br>
<br>
John Hunter wrote:
<blockquote
cite="mid:88e...@ma..."
type="cite"><br>
<br>
<div class="gmail_quote">On Tue, Apr 28, 2009 at 3:18 AM, Olivier
Feys <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:oli...@gm...">oli...@gm...</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#666666"><font
face="Helvetica, Arial, sans-serif">Hi,<br>
<br>
I found a bug with the grid after passing by a log scale.<br>
Here is the sample code reproducing the bug : <br>
<br>
</font>
<blockquote><tt>from pylab import *<br>
<br>
plot(range(50),range(50))<br>
draw()<br>
gca().set_yscale('log')<br>
draw()<br>
gca().xaxis.grid()<br>
draw()<br>
gca().set_yscale('linear')<br>
draw()<br>
show()</tt><br>
</blockquote>
<br>
<font face="Helvetica, Arial, sans-serif">The grid on the xaxis
disappears after setting back the yaxis to linear.</font><br>
<font face="Helvetica, Arial, sans-serif">Please let me know i</font></div>
</blockquote>
</div>
<br>
<br>
I am not seeing this with svn matplotlib -- what version are you using?<br>
<br>
<a moz-do-not-send="true"
href="http://matplotlib.sourceforge.net/faq/troubleshooting_faq.html#report-a-problem">http://matplotlib.sourceforge.net/faq/troubleshooting_faq.html#report-a-problem</a><br>
<a moz-do-not-send="true"
href="http://matplotlib.sourceforge.net/faq/troubleshooting_faq.html#obtaining-matplotlib-version">http://matplotlib.sourceforge.net/faq/troubleshooting_faq.html#obtaining-matplotlib-version</a><br>
<br>
JDH<br>
</blockquote>
<br>
</body>
</html>
On Tue, Apr 28, 2009 at 3:18 AM, Olivier Feys <oli...@gm...>wrote:
> Hi,
>
> I found a bug with the grid after passing by a log scale.
> Here is the sample code reproducing the bug :
>
> from pylab import *
>
> plot(range(50),range(50))
> draw()
> gca().set_yscale('log')
> draw()
> gca().xaxis.grid()
> draw()
> gca().set_yscale('linear')
> draw()
> show()
>
>
> The grid on the xaxis disappears after setting back the yaxis to linear.
> Please let me know i
>
I am not seeing this with svn matplotlib -- what version are you using?
http://matplotlib.sourceforge.net/faq/troubleshooting_faq.html#report-a-problem
http://matplotlib.sourceforge.net/faq/troubleshooting_faq.html#obtaining-matplotlib-version
JDH
On Tue, Apr 28, 2009 at 8:18 AM, Pierre Raybaut <co...@py...>wrote: > Hi all, > > I would like to contribute to matplotlib with this enhancement for the > PyQt4 backend: the idea is to add a toolbar button to configure figure > options (axes, curves, ...). > > It's based on a tiny module called formlayout to generate PyQt4 form > dialog automatically. > > Some screenshots: > http://code.google.com/p/formlayout/ > > So, if you're interested (all the following is GPL2): > > *matplotlib patch* > > In FigureManagerQT.__init__, added: > self.canvas.axes = self.canvas.figure.add_subplot(111) > > In NavigationToolbar2QT._init_toolbar, added: > a = self.addAction(self._icon("customize.png"), 'Customize', > self.edit_parameters) > a.setToolTip('Edit curves line and axes parameters') > > Added the following method in NavigationToolbar2QT: > def edit_parameters(self): > from figureoptions import figure_edit > figure_edit(self.canvas, self) > > *additionnal modules and data* > > formlayout.py (http://code.google.com/p/formlayout/) > figureoptions.py (http://code.google.com/p/PyQtShell/) > customize.png (http://code.google.com/p/PyQtShell/) Hi Pierre -- this looks very nice (the last link is broken though , I get a 404 error). We would be happy to include this in matplotlib or as a toolkit. To contribute it to to mpl, the license needs to be matplotlib compatible ( http://matplotlib.sourceforge.net/devel/coding_guide.html#licenses) but we have more licensing flexibility in a toolkit, though we prefer to keep everything BSD compatible where possible. And of course you would need to agree to maintain it :-) but I think many users would appreciate a GUI plot configuration dialog. JDH
Hi all, I would like to contribute to matplotlib with this enhancement for the PyQt4 backend: the idea is to add a toolbar button to configure figure options (axes, curves, ...). It's based on a tiny module called formlayout to generate PyQt4 form dialog automatically. Some screenshots: http://code.google.com/p/formlayout/ So, if you're interested (all the following is GPL2): *matplotlib patch* In FigureManagerQT.__init__, added: self.canvas.axes = self.canvas.figure.add_subplot(111) In NavigationToolbar2QT._init_toolbar, added: a = self.addAction(self._icon("customize.png"), 'Customize', self.edit_parameters) a.setToolTip('Edit curves line and axes parameters') Added the following method in NavigationToolbar2QT: def edit_parameters(self): from figureoptions import figure_edit figure_edit(self.canvas, self) *additionnal modules and data* formlayout.py (http://code.google.com/p/formlayout/) figureoptions.py (http://code.google.com/p/PyQtShell/) customize.png (http://code.google.com/p/PyQtShell/) cheers, Pierre
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#666666">
<font face="Helvetica, Arial, sans-serif">Hi,<br>
<br>
I found a bug with the grid after passing by a log scale.<br>
Here is the sample code reproducing the bug : <br>
<br>
</font>
<blockquote><tt>from pylab import *<br>
<br>
plot(range(50),range(50))<br>
draw()<br>
gca().set_yscale('log')<br>
draw()<br>
gca().xaxis.grid()<br>
draw()<br>
gca().set_yscale('linear')<br>
draw()<br>
show()</tt><br>
</blockquote>
<br>
<font face="Helvetica, Arial, sans-serif">The grid on the xaxis
disappears after setting back the yaxis to linear.</font><br>
<font face="Helvetica, Arial, sans-serif">Please let me know if this is
the right place for posting this kind of message. If not, where can I
do that ?<br>
<br>
Thanks <br>
<br>
Olivier<br>
</font>
</body>
</html>
On Sun, Apr 26, 2009 at 18:08, John Hunter <jd...@gm...> wrote: > On Sun, Apr 26, 2009 at 9:05 AM, Sandro Tosi <mo...@de...> wrote: >> >> Hi! >> some days ago there was a thread about new matplotlib release, but it >> seems there is some problem about windows binary pacakges preparation. >> >> Is this situation evolved a bit? Would it be considerable to do a >> source-only release (there are a lot of changes in the svn that our >> users would like to see), and then work on binary packages? > > Yes, we had problems with both the OSX and win32 builds, which we have not > resolved yet unfortunately. The problem with a "source only" release is > that on the sf download site, users will be directed to the latest release, > and there will be no binaries available there. I suppose we could reupload > the old binaries there, but I would prefer to et these issues resolved. I Ah, I see. > have had a crazy few weeks (first vacation, then my mom broke both her arms > on vavation with me requiring surgery on both sides, and I've been spending > time with her helping her recover), and I am just starting to get back into > normal life here (meaning I'm behind on non-mpl things as well) Ohh, sorry to hear that! take your time. Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi
>> The discussion about what to do with my patch fizzled. I created a >> decorator that made mixed-mode switching a one-line change per artist >> type. I also added get/set_rasterized and an _rasterized attribute to >> the Artist base class. I've used it on and off for a few months now >> with no noted bugs. >> >> If we don't like the decorator, we can just make a helper function >> that is called at the beginning of every artist.draw() method. It's >> not a very complicated modification. >> > Would there be a case that draw methods of some Artists do not need to > be decorated? Not that I can think of, if rasterization defaults to off and it's a user setting to turn it on (except perhaps some future modification where we auto-detect egregious poly counts in a mesh, for instance). > If not, I guess some metaclass black magic might be not harmful. What > do you think? I'm attaching modified version of your patch which > utilize metaclass for decoration. I like that this solution doesn't litter every call to draw with rasterize checks. But it means that the rasterization support had better be robust, since Artist authors might not know they're interacting with the rasterization code. It has the downside of being implicit rather than explicit. > > I personally want that rasterization is also supported in the ps > backend. I guess the missing support of alpha composition would be a > problem. But, in most of the my use case, I want rasterization for > artist with z lower than some specified value (i.e., background images > using pcolormesh), so it is not a problem for me. I'm not too familiar with the PS backend, but I think that's separate from the issue of how to tell the renderer when to rasterize. Thanks, Eric >>> >>> Are you planning to commit your patch to the trunk? I'll be glad to >>> help you if there are any issues. >> >> >> I'd love to get the patch in trunk, if only so that more people can >> try it out and find things to improve (or re-implement). >> >> Thanks, >> Eric >> >
On Sun, Apr 26, 2009 at 9:05 AM, Sandro Tosi <mo...@de...> wrote: > Hi! > some days ago there was a thread about new matplotlib release, but it > seems there is some problem about windows binary pacakges preparation. > > Is this situation evolved a bit? Would it be considerable to do a > source-only release (there are a lot of changes in the svn that our > users would like to see), and then work on binary packages? > Yes, we had problems with both the OSX and win32 builds, which we have not resolved yet unfortunately. The problem with a "source only" release is that on the sf download site, users will be directed to the latest release, and there will be no binaries available there. I suppose we could reupload the old binaries there, but I would prefer to et these issues resolved. I have had a crazy few weeks (first vacation, then my mom broke both her arms on vavation with me requiring surgery on both sides, and I've been spending time with her helping her recover), and I am just starting to get back into normal life here (meaning I'm behind on non-mpl things as well) JDH
Hi! some days ago there was a thread about new matplotlib release, but it seems there is some problem about windows binary pacakges preparation. Is this situation evolved a bit? Would it be considerable to do a source-only release (there are a lot of changes in the svn that our users would like to see), and then work on binary packages? Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi
Yeah, that seems to work! thanks a lot,
Ken
On Fri, Apr 24, 2009 at 5:21 PM, Jae-Joon Lee <lee...@gm...> wrote:
> ps backend, when usetex=True, uses latex with psfrag package to
> generate the output (with some extra steps).
> It seems that the bounding box information is not correctly recovered
> during this process.
> I first thought that it would be quite difficult to get this correct,
> however the attached (relatively simple) patch seems to work fine.
>
> Ken, can you try the patch and see if it works?
>
> -JJ
>
>
>
>
> On Thu, Apr 23, 2009 at 2:25 PM, Ken Schutte <kts...@gm...> wrote:
>> I've been trying to track down some strange behavior I was getting,
>> and I think narrowed it down to some code that I'll paste below.
>>
>> I'm trying to write to .eps files, and when I have usetex=True,
>> something is screwed up with the padding on the left, and eventually
>> the whole image is just white.
>>
>> If I run this script, the 'testA-*.eps' look good, but 'testB-*' does
>> not. The same problem happens even if I remove the ticklabels.
>>
>> Any tips would be appreciated.
>> thanks,
>> Ken
>>
>>
>>
>> ------------------------------------------------
>> import matplotlib.pyplot as plt
>> import numpy as np
>> from matplotlib import rc
>>
>> fig = plt.figure()
>> ax = fig.add_axes([0,0,1,1],frameon=False)
>>
>> X = np.tile(np.arange(500),(10,1)) # (10,500) shape
>>
>> ax.imshow(X,interpolation='nearest',aspect='auto')
>>
>> def go(name):
>>
>> for d in (1,2,3,4):
>>
>> w = d*5
>> h = d
>>
>> fig.set_size_inches(w,h)
>> fig.savefig("%s-%d.eps" % (name,d))
>>
>> rc('text', usetex=False)
>> go("testA")
>>
>> rc('text', usetex=True)
>> go("testB")
>>
>> ------------------------------------------------------------------------------
>> Crystal Reports - New Free Runtime and 30 Day Trial
>> Check out the new simplified licensign option that enables unlimited
>> royalty-free distribution of the report engine for externally facing
>> server and web deployment.
>> http://p.sf.net/sfu/businessobjects
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
Hi Eric, > > Sorry about the broken links. I've attached a diff made against trunk > from a few days ago. Thanks! > > The discussion about what to do with my patch fizzled. I created a > decorator that made mixed-mode switching a one-line change per artist > type. I also added get/set_rasterized and an _rasterized attribute to > the Artist base class. I've used it on and off for a few months now > with no noted bugs. > > If we don't like the decorator, we can just make a helper function > that is called at the beginning of every artist.draw() method. It's > not a very complicated modification. > > Would there be a case that draw methods of some Artists do not need to be decorated? If not, I guess some metaclass black magic might be not harmful. What do you think? I'm attaching modified version of your patch which utilize metaclass for decoration. I personally want that rasterization is also supported in the ps backend. I guess the missing support of alpha composition would be a problem. But, in most of the my use case, I want rasterization for artist with z lower than some specified value (i.e., background images using pcolormesh), so it is not a problem for me. Regards, -JJ >> >> Are you planning to commit your patch to the trunk? I'll be glad to >> help you if there are any issues. > > > I'd love to get the patch in trunk, if only so that more people can > try it out and find things to improve (or re-implement). > > Thanks, > Eric >
ps backend, when usetex=True, uses latex with psfrag package to
generate the output (with some extra steps).
It seems that the bounding box information is not correctly recovered
during this process.
I first thought that it would be quite difficult to get this correct,
however the attached (relatively simple) patch seems to work fine.
Ken, can you try the patch and see if it works?
-JJ
On Thu, Apr 23, 2009 at 2:25 PM, Ken Schutte <kts...@gm...> wrote:
> I've been trying to track down some strange behavior I was getting,
> and I think narrowed it down to some code that I'll paste below.
>
> I'm trying to write to .eps files, and when I have usetex=True,
> something is screwed up with the padding on the left, and eventually
> the whole image is just white.
>
> If I run this script, the 'testA-*.eps' look good, but 'testB-*' does
> not. The same problem happens even if I remove the ticklabels.
>
> Any tips would be appreciated.
> thanks,
> Ken
>
>
>
> ------------------------------------------------
> import matplotlib.pyplot as plt
> import numpy as np
> from matplotlib import rc
>
> fig = plt.figure()
> ax = fig.add_axes([0,0,1,1],frameon=False)
>
> X = np.tile(np.arange(500),(10,1)) # (10,500) shape
>
> ax.imshow(X,interpolation='nearest',aspect='auto')
>
> def go(name):
>
> for d in (1,2,3,4):
>
> w = d*5
> h = d
>
> fig.set_size_inches(w,h)
> fig.savefig("%s-%d.eps" % (name,d))
>
> rc('text', usetex=False)
> go("testA")
>
> rc('text', usetex=True)
> go("testB")
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensign option that enables unlimited
> royalty-free distribution of the report engine for externally facing
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
On Thu, Apr 9, 2009 at 8:18 PM, Adam Mercer <ram...@gm...> wrote:
> On Thu, Apr 9, 2009 at 13:46, Michael Droettboom <md...@st...> wrote:
> > I did a lot of the initial fixes for Python 2.6 within the first week of
> the
> > 2.6.0 release -- they were mostly of the warning/style nature. I've been
> > running it on 2.6 on and off ever since, so it should be ok. But let us
> > know if you find anything.
>
> The only things I've seen so far are some deprecation warnings of the form:
>
>
> /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/matplotlib/texmanager.py:55:
> DeprecationWarning: os.popen4 is deprecated. Use the subprocess
> module.
> stdin, stdout = os.popen4('dvipng -version')
>
I fixed this in r7063. It works for me on Linux, but the windows users
might want to double check that there isn't some weird subprocess
incompatibility. (tex_demo.py exercises this code.)
I also fixed the use of os.popen in cbook.report_memory(). Again, it works
for me here, but I'd love for others to check. There is no code for windows
with this one, but there is code for Macs.
Ryan
--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from Norman, Oklahoma, United States
On Thu, Apr 23, 2009 at 9:54 PM, Eric Bruning <eri...@gm...>wrote: > On Thu, Apr 23, 2009 at 3:06 PM, Jae-Joon Lee <lee...@gm...> > wrote: > > The discussion about what to do with my patch fizzled. I created a > decorator that made mixed-mode switching a one-line change per artist > type. I also added get/set_rasterized and an _rasterized attribute to > the Artist base class. I've used it on and off for a few months now > with no noted bugs. > > If we don't like the decorator, we can just make a helper function > that is called at the beginning of every artist.draw() method. It's > not a very complicated modification. I think part of the problem with decorators before was that they came around in 2.4. I think we only support >=2.4 now, so this is no longer an issue. IMO, decorators seem like a sensible way to go. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma
On Thu, Apr 23, 2009 at 3:06 PM, Jae-Joon Lee <lee...@gm...> wrote: > On Tue, Apr 21, 2009 at 10:42 PM, Eric Bruning <eri...@gm...> wrote: >> On a somewhat related note, how are you turning rasterization on and >> off? Are you using my per-artist patch (which last I knew wasn't in >> trunk) or some other solution? > > I remember that I tried to use your patch, but all the links that I > found were broken. So I wrote a few lines for monkey patching. It was > straight forward as I only needed a rasterization of the QuadMesh > class. Sorry about the broken links. I've attached a diff made against trunk from a few days ago. The discussion about what to do with my patch fizzled. I created a decorator that made mixed-mode switching a one-line change per artist type. I also added get/set_rasterized and an _rasterized attribute to the Artist base class. I've used it on and off for a few months now with no noted bugs. If we don't like the decorator, we can just make a helper function that is called at the beginning of every artist.draw() method. It's not a very complicated modification. > > Are you planning to commit your patch to the trunk? I'll be glad to > help you if there are any issues. I'd love to get the patch in trunk, if only so that more people can try it out and find things to improve (or re-implement). Thanks, Eric
On Tue, Apr 21, 2009 at 10:42 PM, Eric Bruning <eri...@gm...> wrote: > On a somewhat related note, how are you turning rasterization on and > off? Are you using my per-artist patch (which last I knew wasn't in > trunk) or some other solution? I remember that I tried to use your patch, but all the links that I found were broken. So I wrote a few lines for monkey patching. It was straight forward as I only needed a rasterization of the QuadMesh class. Are you planning to commit your patch to the trunk? I'll be glad to help you if there are any issues. Regards, -JJ
I've been trying to track down some strange behavior I was getting,
and I think narrowed it down to some code that I'll paste below.
I'm trying to write to .eps files, and when I have usetex=True,
something is screwed up with the padding on the left, and eventually
the whole image is just white.
If I run this script, the 'testA-*.eps' look good, but 'testB-*' does
not. The same problem happens even if I remove the ticklabels.
Any tips would be appreciated.
thanks,
Ken
------------------------------------------------
import matplotlib.pyplot as plt
import numpy as np
from matplotlib import rc
fig = plt.figure()
ax = fig.add_axes([0,0,1,1],frameon=False)
X = np.tile(np.arange(500),(10,1)) # (10,500) shape
ax.imshow(X,interpolation='nearest',aspect='auto')
def go(name):
for d in (1,2,3,4):
w = d*5
h = d
fig.set_size_inches(w,h)
fig.savefig("%s-%d.eps" % (name,d))
rc('text', usetex=False)
go("testA")
rc('text', usetex=True)
go("testB")
On Thu, Apr 16, 2009 at 1:38 PM, Jae-Joon Lee <lee...@gm...> wrote: > Eric and others, > > I just committed the fix for this problem to the trunk. > It should also work with the svg backend. Thanks, that's fantastic. I'm glad to have the fix in place. On a somewhat related note, how are you turning rasterization on and off? Are you using my per-artist patch (which last I knew wasn't in trunk) or some other solution? >> From a design perspective, is it appropriate for the renderer to store >> a reference to a figure? Many (all?) of the renderers seem entirely >> decoupled from the figure. >> > > I acknowledge this issue but I couldn't find a better solution, so > I hope someone else come up with a better idea. It's easy for me to critique, but you actually wrote some code :) Thanks, Eric
It seems that the colormaps are now modifying inplace the input arguments: resting ~ $ ipython -pylab Python 2.5.2 (r252:60911, Oct 5 2008, 19:24:49) Type "copyright", "credits" or "license" for more information. IPython 0.9.1 -- An enhanced Interactive Python. ? -> Introduction and overview of IPython's features. %quickref -> Quick reference. help -> Python's own help system. object? -> Details about 'object'. ?object also works, ?? prints more. Welcome to pylab, a matplotlib-based Python environment. For more information, type 'help(pylab)'. In [1]: import numpy as np In [2]: from pylab import cm In [3]: values = np.linspace(0., 1., 3) In [4]: values Out[4]: array([ 0. , 0.5, 1. ]) In [5]: _ = cm.summer(values) In [6]: values Out[6]: array([ 0. , 128. , 255.9999744]) I think this is very bad. I don't see where it is mentionned in the docstring, but even if it were, I still would disapprove. My 2 cents, Ga
On Sat, Apr 19, 2008 at 7:13 PM, Eric Firing <ef...@ha...> wrote: > > > > 2.12.1) on an OSX machine. Btw, matplotlib does not build on OSX > > currently -- a person needs to upgrade gcc first (from 4.0.1 to 4.2). > > I saw John posted a compiler error (resulting from this problem) on > > some other list, so it's something to keep in mind. > > Yes, my colleague, Jules, and I ran into this yesterday. Very > frustrating. We also ran into some sort of problem involving, > apparently, a mixture of libraries and/or object modules with and > without dual ppc/intel code, but from the error messages it was > impossible for us to track down beyond that. It might have been obvious > to an OSX wizard. Jules was trying to follow John's instructions > carefully. Numpy went in flawlessly. Scipy went in OK, we think, but > the test needed nosetest, and then when that was installed, it failed. > We gave up on the matplotlib installation. > On a new machine without the proper depdendencies, you might want to try first the makefile in release/osx, which will wget the depenencies, build them with the right flag, and link them in statically. There is a README in that directory with instructions, but here is a crib sheet from the command history I just executed (which still works on my box):: # build the dependencies cd release/osx/ unset PKG_CONFIG_PATH make fetch_deps cd bdist_mpkg-0.4.3 sudo python setup.py install cd .. make dependencies # build the mpl sdist cd ../.. python setup.py sdist mv dist/matplotlib-0.98.6svn.tar.gz release/osx/ # set the version number in the Makefile to 0.98.6svn and build the # installers cd release/osx/ make installers On a machine that does have the dependencies properly buily and installed, I use > make build_osx105 with the Makefile that lives alongside setup.py. This still works for me with the native gcc 4.0.1 on my 10.5 machine and then you can do a normal python setup.py install.
I was getting a similar bug, mac os x, enthought python distribution. They weren't lines per se, but ugly seperations between filled contours. I tried a number of things, to no avail. Ultimately, the solution was just to replot the contourf multiple times. It took care of all the ugliness. Cheers! -tf -- View this message in context: http://www.nabble.com/Contourf-draws-contour-lines-tp16766750p23103326.html Sent from the matplotlib - devel mailing list archive at Nabble.com.
Reinier Heeres <reinier@...> writes: > This is a known issue, and I hope to resolve it soon... > > Thanks for reporting though; if you notice any other problems, please > let me know! > > Regards, > Reinier > The 3d plotting is great, thanks for updating it! Another small bug: the plot_surface routine reveals bits that should be hidden behind foreground surfaces. You can see this in the test_surface() plot in demo.py Neil
Eric and others, I just committed the fix for this problem to the trunk. It should also work with the svg backend. > > From a design perspective, is it appropriate for the renderer to store > a reference to a figure? Many (all?) of the renderers seem entirely > decoupled from the figure. > I acknowledge this issue but I couldn't find a better solution, so I hope someone else come up with a better idea. Regards, -JJ
On Wed, Apr 15, 2009 at 2:04 PM, Reinier Heeres <re...@he...> wrote: > Hi Fernando, > > This is a known issue, and I hope to resolve it soon... > > Thanks for reporting though; if you notice any other problems, please > let me know! Will do, and I'll be happy to test as needed. f