matplotlib-devel Mailing List for matplotlib

>>>>> "Jordan" == Jordan Dawe <fre...@oc...> writes:
 Jordan> Sweet, will do. I am using the CVS version currently; I
 Jordan> just submitted a patch to the sourceforge page to make it
 Jordan> easier for me to compile, since I am running under cygwin
 Jordan> most of the time. I have a couple of other patches I
 Jordan> intend to submit when I have a spare moment; is the
 Jordan> sourceforge page the proper place to do that?
Yes -- just send a note here describing what is in them so we can be
sure to include them. Bunch them together where possible to save
work.
Thanks,
JDH

>
> It looks like there is no problem with simply turning off the 
> chunking. I have made a bunch of changes in CVS, including turning 
> off the chunking by default, and allowing one to specify chunking, 
> antialiasing, and linewidth explicitly for contourf. So, I think you 
> will find that if you use the CVS version, the problems you reported 
> will go away. If you haven't done it before, you will find that 
> downloading and installing from CVS is very quick and easy; 
> instructions are given on the sourceforge download site. 
Sweet, will do. I am using the CVS version currently; I just submitted 
a patch to the sourceforge page to make it easier for me to compile, 
since I am running under cygwin most of the time. I have a couple of 
other patches I intend to submit when I have a spare moment; is the 
sourceforge page the proper place to do that?
Jordan

Jordan,
I have looked into various aspects of the problem you reported. It 
seems to be essentially a problem with antialiasing; all artifacts go 
away in the AGG backend with antialiasing turned off, regardless of the 
linewidth, right down to zero. With antialiasing on, however, it seems 
that a linewidth of about 0.5 with AGG (on my machine, with everything 
default) is needed to prevent the antialiasing from leaving light lines 
at polygon boundaries, regardless of whether they are the straight 
boundaries caused by chunking or the curved boundaries of the contours 
themselves. With Postscript, as rendered by ghostscript via gv, I see 
artifacts only with a much smaller linewidth, and only at some 
magnifications. Your ps viewers may be doing more antialiasing, and 
therefore showing artifacts over a larger range of linewidths. There is 
probably more going on, and more to be understood, but this got me far 
enough to manage the problem for now.
It looks like there is no problem with simply turning off the chunking. 
 I have made a bunch of changes in CVS, including turning off the 
chunking by default, and allowing one to specify chunking, antialiasing, 
and linewidth explicitly for contourf. So, I think you will find that 
if you use the CVS version, the problems you reported will go away. If 
you haven't done it before, you will find that downloading and 
installing from CVS is very quick and easy; instructions are given on 
the sourceforge download site. (As John notes, there may be a lag 
between developer CVS and the mirrors; make sure that what you download 
includes my changes, committed a few minutes ago.) Alternatively, if 
you simply want to turn off chunking in 0.84, you can do it by editing 
cntr.c, approximately line 1384, change
 long nchunk = 30; /* hardwired for now */
to
 long nchunk = 0; /* hardwired for now */
and recompile/reinstall.
If you use the CVS version (or the next mpl release, whenever that comes 
out), note that the APIs for contour, contourf, and clabel have changed 
as described in API_CHANGES and as illustrated in 
examples/contour_demo.py and contourf_demo.py.
Eric
Jordan Dawe wrote:
> Eric Firing wrote:
> 
>> Jordan,
>>
>> Thanks, now I see the problem and where it is coming from. In 
>> contour.py, near the bottom, in the contourf method, change the 
>> linewidth from 1 to 0.01, so the line reads:
>> col = PolyCollection(nlist, linewidths=(0.01,))
>>
>> I think this will be OK; based on the comment below the line, I think 
>> I found that using a linewidth of zero was problematic, so I probably 
>> simply used 1 thinking it was small enough not to matter.
>>
>> I will need to make a corresponding change in the CVS version so that 
>> it will get into the next release. I'll do that this evening.
>>
> Sorry about this, but that patch doesn't seem to work. When I open the 
> eps files generated with this change implimented, I get the artifact 
> problem mentioned in the comment; fine lines at the boundaries of the 
> contouring engine's subdomains. In fact, I get the artifacts at 
> linewidths as large as 0.5.
> 
> Jordan

On Friday 28 October 2005 9:57 am, Darren Dale wrote:
> I was wondering, has anyone looked into extending numerix to handle the new
> scipy? All scipy tests now pass on my 32bit system, but there is some
> incompatibility between new scipy and mpl. For example:
>
> from pylab import *
> from scipy import *
> plot(linspace(-1,1,100))
> show()
For those who are not on the scipy-dev list, Travis just informed me that 
upgrading to Numeric 24 will solve the problem I reported. I was working with 
23.8, the new version seems to have solved my problem.
Darren

Jordan,
Evidently the reason we see different things is because the result with 
linewidth < 1 is renderer-dependent; ghostview (which I am using) and 
Illustrator handle the same file differently.
To be sure we are agreeing on the phenomenon: Initially, with 
linewidth=1 in the contourf polygon generation, there was no problem 
with the subregion boundaries, but the polygons were a bit too large, so 
that thin line contours did not land exactly on the boundaries. Setting 
linewidth=0.01 fixes that problem, but introduces renderer-dependent 
artifacts at the subregion boundaries.
The real solution, or part of it, may be in the backend (ps at least, 
maybe others): I think that we want to be able to specify a polygon with 
a zero-width boundary, such that it is filled but not stroked. 
Alternatively, it may be that the problem is one of rounding in the 
conversion of floating point vertices to integers in the renderer, in 
which case removing the boundary line entirely won't help at all.
The division of the domain by cntr.c into subregions is controllable by 
a parameter; I can expose that parameter to the python level (this 
weekend, not this minute). Then setting it to a sufficiently large 
value will take care of the grid problem; and maybe it will have no bad 
side-effects. According to the comment in the contouring code, the 
reason for subdividing is that renderers bog down when filling polygons 
with too many vertices. It may be that this is no longer a problem; 
that comment may date from an earlier era.
Eric
Jordan Dawe wrote:
> Yeah, I see artifacts in the eps file you sent me. I'm looking at it in 
> Illustrator CS, and the artifacts show up in Adobe Acrobat 6.0 as well. 
> They also show up when I take the eps and do a 'convert example.eps 
> example.png' on it. The resulting png is attached.
> 
> The artifacts tend to change when I zoom in, so I'm guessing some of it 
> is related to the renderer in Illustrator, but I'm still worried they 
> will show up when they go to press. When the linewidth =1.0, the 
> artifacts don't show up at all, so I know it's possible to get rid of them.
> 
> I'm willing to hunt through and try to fix this problem, but where would 
> it show up? In the PS render code? In the polygon handers? I know a 
> fair bit of python, but I don't know my way around matplotlib very well...
> 
> Also, do you see any problems with me trying to make the cntr.c code 
> output one polygon per simply-connected region? Cause the current 
> "divide the fig up into 48 smaller areas" thing is annoying as hell when 
> you're working with eps. Matlab's renderer does this, why can't this one?
> 
> Jordan
> 
> ------------------------------------------------------------------------
> 

I was wondering, has anyone looked into extending numerix to handle the new 
scipy? All scipy tests now pass on my 32bit system, but there is some 
incompatibility between new scipy and mpl. For example:
from pylab import *
from scipy import *
plot(linspace(-1,1,100))
show()
Darren

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
 Eric> Jordan, Strange, I did test the change and it worked fine
 Eric> with your example on my system. I will email you the result
 Eric> in a separate message so as not to clog the list. Then you
 Eric> can tell me if you see the problem in that file. Maybe I am
 Eric> misunderstanding something.
Could be a CVS version problem -- make sure you are both working on
the same CVS file(s) and the same test script. Historically,
non-developer CVS tends to lag...
JDH

Jordan,
Strange, I did test the change and it worked fine with your example on 
my system. I will email you the result in a separate message so as not 
to clog the list. Then you can tell me if you see the problem in that 
file. Maybe I am misunderstanding something.
Eric
Jordan Dawe wrote:
> Eric Firing wrote:
> 
>> Jordan,
>>
>> Thanks, now I see the problem and where it is coming from. In 
>> contour.py, near the bottom, in the contourf method, change the 
>> linewidth from 1 to 0.01, so the line reads:
>> col = PolyCollection(nlist, linewidths=(0.01,))
>>
>> I think this will be OK; based on the comment below the line, I think 
>> I found that using a linewidth of zero was problematic, so I probably 
>> simply used 1 thinking it was small enough not to matter.
>>
>> I will need to make a corresponding change in the CVS version so that 
>> it will get into the next release. I'll do that this evening.
>>
> Sorry about this, but that patch doesn't seem to work. When I open the 
> eps files generated with this change implimented, I get the artifact 
> problem mentioned in the comment; fine lines at the boundaries of the 
> contouring engine's subdomains. In fact, I get the artifacts at 
> linewidths as large as 0.5.
> 
> Jordan
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Eric Firing wrote:
> Jordan,
>
> Thanks, now I see the problem and where it is coming from. In 
> contour.py, near the bottom, in the contourf method, change the 
> linewidth from 1 to 0.01, so the line reads:
> col = PolyCollection(nlist, linewidths=(0.01,))
>
> I think this will be OK; based on the comment below the line, I think 
> I found that using a linewidth of zero was problematic, so I probably 
> simply used 1 thinking it was small enough not to matter.
>
> I will need to make a corresponding change in the CVS version so that 
> it will get into the next release. I'll do that this evening.
>
Sorry about this, but that patch doesn't seem to work. When I open the 
eps files generated with this change implimented, I get the artifact 
problem mentioned in the comment; fine lines at the boundaries of the 
contouring engine's subdomains. In fact, I get the artifacts at 
linewidths as large as 0.5.
Jordan

Hi
I have found a problem when using external color information to color 
the arrows in a quiver-plot. I found that the norm-option does not 
affect the output. Here is the code I chanegd to fix this problem (3 
lines, marked with a #PI).
Pierre
--- fragment of file axes.py: ---
 def quiver(self, U, V, *args, **kwargs ):
 """
 QUIVER( X, Y, U, V )
 QUIVER( U, V )
 QUIVER( X, Y, U, V, S)
 QUIVER( U, V, S )
 QUIVER( ..., color=None, width=1.0, cmap=None,norm=None )
 Make a vector plot (U, V) with arrows on a grid (X, Y)
 The optional arguments color and width are used to specify the 
color and width
 of the arrow. color can be an array of colors in which case the 
arrows can be
 colored according to another dataset.
 If cm is specied and color is None, the colormap is used to give 
a color
 according to the vector's length.
 If color is a scalar field, the colormap is used to map the 
scalar to a color
 If a colormap is specified and color is an array of color 
triplets, then the
 colormap is ignored
 width is a scalar that controls the width of the arrows
 if S is specified it is used to scale the vectors. Use S=0 to 
disable automatic
 scaling.
 If S!=0, vectors are scaled to fit within the grid and then are 
multiplied by S.
 """
 if not self._hold: self.cla()
 do_scale = True
 S = 1.0
 if len(args)==0:
 # ( U, V )
 U = asarray(U)
 V = asarray(V)
 X,Y = meshgrid( arange(U.shape[1]), arange(U.shape[0]) )
 elif len(args)==1:
 # ( U, V, S )
 U = asarray(U)
 V = asarray(V)
 X,Y = meshgrid( arange(U.shape[1]), arange(U.shape[0]) )
 S = float(args[0])
 do_scale = ( S != 0.0 )
 elif len(args)==2:
 # ( X, Y, U, V )
 X = asarray(U)
 Y = asarray(V)
 U = asarray(args[0])
 V = asarray(args[1])
 elif len(args)==3:
 # ( X, Y, U, V )
 X = asarray(U)
 Y = asarray(V)
 U = asarray(args[0])
 V = asarray(args[1])
 S = float(args[2])
 do_scale = ( S != 0.0 )
 assert U.shape == V.shape
 assert X.shape == Y.shape
 assert U.shape == X.shape
 arrows = []
 N = sqrt( U**2+V**2 )
 if do_scale:
 Nmax = maximum.reduce(maximum.reduce(N))
 U *= (S/Nmax)
 V *= (S/Nmax)
 N /= Nmax
 alpha = kwargs.get('alpha', 1.0)
 width = kwargs.get('width', 0.25)
 norm = kwargs.get('norm', None)
 cmap = kwargs.get('cmap', None)
 vmin = kwargs.get('vmin', None)
 vmax = kwargs.get('vmax', None)
 color = kwargs.get('color', None)
 shading = kwargs.get('shading', 'faceted')
 C = None
 I,J = U.shape
 colorarrayflag = False #PI
 if color is not None and not looks_like_color(color):
 clr = asarray(color)
 if clr.shape==U.shape:
 C = array([ clr[i,j] for i in xrange(I) for j in 
xrange(J)])
 colorarrayflag = True #PI
 elif clr.shape == () and color:
 # a scalar (1, True,...)
 C = array([ N[i,j] for i in xrange(I) for j in xrange(J)])
 else:
 color = (0.,0.,0.,1.)
 elif color is None:
 color = (0.,0.,0.,1.)
 else:
 color = colorConverter.to_rgba( color, alpha )
 arrows = [ Arrow(X[i,j],Y[i,j],U[i,j],V[i,j],0.1*S ).get_verts()
 for i in xrange(I) for j in xrange(J) ]
 collection = PolyCollection(
 arrows,
 edgecolors = 'None',
 facecolors = (color,),
 antialiaseds = (0,),
 linewidths = (width,),
 )
 if C is not None:
 collection.set_array( C )
 else:
 collection.set_facecolor( (color,) )
 collection.set_cmap(cmap)
 collection.set_norm(norm)
 if norm is not None and colorarrayflag==False: # PI
 collection.set_clim( vmin, vmax )
 self.add_collection( collection )
 lims = asarray(arrows)
 _max = maximum.reduce( maximum.reduce( lims ))
 _min = minimum.reduce( minimum.reduce( lims ))
 self.update_datalim( [ tuple(_min), tuple(_max) ] )
 self.autoscale_view()
 return arrows

Jordan,
The correction--using a small linewidth for the patch boundary (which is 
the same color as the patch)--has been committed to CVS. Thanks for 
pointing out the problem.
Eric
Jordan Dawe wrote:
> Eric Firing wrote:
> 
>> Jordan,
>>
>> Would you send a simple example script and sample plot, please? If I 
>> understand correctly what you are trying to do, it should work.
> 
> 
> Ok, I stuck an example on my webserver. The script (heavily copied from 
> contour_demo.py):
> 
> http://freedryk.dyndns.org:8080/matplotlib/example.py
> 
> The eps output:
> 
> http://freedryk.dyndns.org:8080/matplotlib/example.eps
> 
> And, in case it's easier for you, the eps output converted into pdf:
> 
> http://freedryk.dyndns.org:8080/matplotlib/example.pdf
> 
> The problem can be seen by zooming into one of the contour lines. There 
> is about a .25 pica space between the contour lines and the filled 
> contours. This doesn't occur if you use a 1 pica line, but I don't like 
> thick lines...
> 
> Jordan
> 

Eric Firing wrote:
> Jordan,
>
> Would you send a simple example script and sample plot, please? If I 
> understand correctly what you are trying to do, it should work.
Ok, I stuck an example on my webserver. The script (heavily copied from 
contour_demo.py):
http://freedryk.dyndns.org:8080/matplotlib/example.py
The eps output:
http://freedryk.dyndns.org:8080/matplotlib/example.eps
And, in case it's easier for you, the eps output converted into pdf:
http://freedryk.dyndns.org:8080/matplotlib/example.pdf
The problem can be seen by zooming into one of the contour lines. There 
is about a .25 pica space between the contour lines and the filled 
contours. This doesn't occur if you use a 1 pica line, but I don't like 
thick lines...
Jordan

Jordan,
Would you send a simple example script and sample plot, please? If I 
understand correctly what you are trying to do, it should work.
Thanks.
Eric
Jordan Dawe wrote:
> Hi, I hope this is the proper place to send this message. I'm using 
> matplotlib to make contourf plots with contour overlays. My problem is 
> that I want to be able to use .25 pica lines for the overlaid contours, 
> but since contourf demands a linethickness of 1. to avoid artifacts (due 
> to the simply-connected domain contour algorhithm), the .25 contours 
> don't actually fit the contourf right; there will be a thin line of 
> color from the next contour around the contourf before the .25 pica line 
> appears. This annoys me to no end.
> 
> Currently I'm fixing it by plotting everything 4x larger than normal and 
> then shrinking the eps files down in Illustrator, but this is not an 
> ideal solution, since (for example) all the axis labels are in the wrong 
> position at this size. My question is, how hard would it be to fix the 
> contour code so that contourf's linethickness argument could be 
> changed? Where in the codebase would I look to start hacking? In the 
> contouring code? In the python code that accepts the contour algorithm 
> output? I don't want to spend hours hunting through the code for the 
> right place to start modifying things...
> 
> Jordan
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi, I hope this is the proper place to send this message. I'm using 
matplotlib to make contourf plots with contour overlays. My problem is 
that I want to be able to use .25 pica lines for the overlaid contours, 
but since contourf demands a linethickness of 1. to avoid artifacts (due 
to the simply-connected domain contour algorhithm), the .25 contours 
don't actually fit the contourf right; there will be a thin line of 
color from the next contour around the contourf before the .25 pica line 
appears. This annoys me to no end.
Currently I'm fixing it by plotting everything 4x larger than normal and 
then shrinking the eps files down in Illustrator, but this is not an 
ideal solution, since (for example) all the axis labels are in the wrong 
position at this size. My question is, how hard would it be to fix the 
contour code so that contourf's linethickness argument could be 
changed? Where in the codebase would I look to start hacking? In the 
contouring code? In the python code that accepts the contour algorithm 
output? I don't want to spend hours hunting through the code for the 
right place to start modifying things...
Jordan

On Oct 8, 2005, at 12:30 AM, Steve Chaplin wrote:
> I share Ted's concern. I think a 'well-behaved child widget' does not
> know anything about its parent (or grandparent). Its added to a
> container widget and expands/shrinks (depending on its resize policy) 
> to
> use the space that the container widget gives it. So the container
> widget dictates the size of the child widget, not the other way round.
I'm also concerned about the resizable-children approach, and not just 
because it sounds scary. The result is a FigureCanvas widget that is 
strongly coupled to its parent widget. This poses a thorny problem for 
me because my WxMPL library subclasses FigureCanvasWxAgg and encourages 
people to embed that class directly in their own Panels, Frames, and 
whatnot.
> If you use the GUI to resize the canvas, you resize the gtk.Window and
> the gtk.Window resizes the canvas. It seems reasonable to use the same
> process to resize from a script - resize the gtk.Window and let the
> Gtk.Window resize the canvas.
I agree that this is a much more reasonable approach, and feel that its 
also more robust. This brings me to the point of this email: is this 
now the officially blessed way of implementing interactive GUI figure 
resizing?
Ken

On Wed, 2005年10月19日 at 15:28 -0500, John Hunter wrote:
> It looks like I was a bit confused about how to best include the
> kerning information, and was experimenting by treating it as a
> fraction of the width of an "m". You may want to try some
> alternatives. But this is where you would start hacking.
I've made some improvements and I think the result looks as good as it's
going to using the Symbol font and without a suitable font for \cal; a
revised patch is attached. In the patch I've refactored the kerning in
mathtext.py and removed all kerning information from TrueType the font
classes (as it wasn't being used anyway) by renaming the relevant
get_kern functions.
Nick

>>>>> "Nicholas" == Nicholas Young <su...@su...> writes:
 Nicholas> On Wed, 2005年10月19日 at 12:08 -0500, John Hunter wrote:
 >> Hi this looks very nice! I have to run now but I'll give you a
 >> quick tip. kerning controls the inter-letter spacing, and your
 >> Fonts class has to override "get_kern"; the base class always
 >> returns 0
 Nicholas> I had missed this function - but as far as I can see it
 Nicholas> isn't actually called in the majority of cases (only
 Nicholas> where set_font is called on the parent GroupElement -
 Nicholas> which doesn't always happen in any of the common cases
 Nicholas> I've tried). Am I missing something?
The Group element is the only place kerning is set, but groups are the
right place. Eg \rm{hi mom} is a group. I just took a look and
noticed I commented out the place where the kern is set
 def advance(self):
 'get the horiz advance'
 return self.metrics.advance # how to handle cm units?+ self.kern*self.widthm
It looks like I was a bit confused about how to best include the
kerning information, and was experimenting by treating it as a
fraction of the width of an "m". You may want to try some
alternatives. But this is where you would start hacking.
JDH
 

On Wed, 2005年10月19日 at 12:08 -0500, John Hunter wrote:
> Hi this looks very nice! I have to run now but I'll give you a quick
> tip. kerning controls the inter-letter spacing, and your Fonts class
> has to override "get_kern"; the base class always returns 0
I had missed this function - but as far as I can see it isn't actually
called in the majority of cases (only where set_font is called on the
parent GroupElement - which doesn't always happen in any of the common
cases I've tried). Am I missing something?
Nick

>>>>> "Nicholas" == Nicholas Young <su...@su...> writes:
 Nicholas> Hi, I regularly use matplotlib on lots of systems I
 Nicholas> don't have root access to. On most of these
 Nicholas> installation of gs 8.15 is quite problematic (and buggy)
 Nicholas> and as I result using TeX with matplotlib is
 Nicholas> impractical. Additionally as all of the printers I have
 Nicholas> access to are HP made the use of embedded truetype fonts
 Nicholas> is also problematic. The combination of these two
 Nicholas> problems has made it difficult to use mpl for anything I
 Nicholas> need to print and for which I need mathtext.
Hi this looks very nice! I have to run now but I'll give you a quick
tip. kerning controls the inter-letter spacing, and your Fonts class
has to override "get_kern"; the base class always returns 0
 def get_kern(self, font, symleft, symright, fontsize, dpi):
 """
 Get the kerning distance for font between symleft and symright.
 font is one of tt, it, rm, cal or None
 sym is a single symbol(alphanum, punct) or a special symbol
 like \sigma.
 """
 return 0
For an afm class instance, you can call get_kern_distance to get the
kerning distance between two characters.
 >>> from afm import AFM
 >>> fh = file('ptmr8a.afm')
 >>> afm = AFM(fh)
 >>> afm.get_kern_dist('A', 'y')
 -92.0
and if I recall correctly this has to be corrected by a factor of
1000.
JDH

Hi,
I regularly use matplotlib on lots of systems I don't have root access
to. On most of these installation of gs 8.15 is quite problematic (and
buggy) and as I result using TeX with matplotlib is impractical.
Additionally as all of the printers I have access to are HP made the use
of embedded truetype fonts is also problematic. The combination of
these two problems has made it difficult to use mpl for anything I need
to print and for which I need mathtext.
As a solution I've patched the mathtext library and backend_ps in order
to support mathtext based upon the standard postscript Symbol font when
ps.usetex = True. A function patch to CVS is attached.
In addition to the expected limitations from using the standard fonts;
the character spacing in my output isn't perfect. As I'm not
particularly knowledgeable regarding fonts I'd appreciate some
assistance in fixing this problem. Once this problem is fixed I believe
that the result would be quite useful for those who want to produce
portable and small (in filesize) plots without the overhead of running
TeX.
Nick

>>>>> "Kilian" == Kilian Hagemann <hag...@eg...> writes:
 Kilian> Cool, I've rewritten my code with the suggested
 Kilian> simplification and style concerns you put forward.
Thanks...
 Kilian> tarball, but I guess using CVS is safer. Now, being a
 Kilian> newbie to open source *developing* and CVS, how do I
 Kilian> access and use mpl's CVS repository? Do you prefer my
 Kilian> patches to be sent to this list or should I commit my
 Kilian> changes to cvs?
See http://sourceforge.net/cvs/?group_id=80706. You should upload
your patches to the sourceforge patch system
 http://sourceforge.net/tracker/?group_id=80706&atid=560722
and send a notice to this list describing what is in them. After
you've gone through this a number of times and have a clear
understanding of matplotlib internals etc I can add you to the
developers list if that is preferable.
 Kilian> So, I thought just retrieve the dimensions of the current
 Kilian> subplot somehow, but to no avail. Is there a way to
 Kilian> retrieve the dimensions and/or position of the subplot,
 Kilian> not the axes it contains? Something like lbwh=(0,0,0.5,1)
 Kilian> for row 1, col 1 and lbwh=(0.5,0,0.5,1) for row 1, col 2
 Kilian> in the above example? That way I'd be able to calculate
 Kilian> how much space axes + outside legend is supposed to occupy
 Kilian> (my spaceNeeded variable).
 Kilian> Also, I see that this will only work when subplots are
 Kilian> used, as soon as custom axes positioning/sizing is used
 Kilian> such as that in examples/figlegend_demo.py, there seems to
 Kilian> be no way to calculate this required space. Any way to
 Kilian> check for this? Or should we leave it up to the user to
 Kilian> turn resizing off if it doesn't give the desired results?
From any Axes instance, you can get the position info with
 l,b,w,h = ax.get_position()
Take a look at fig.colorbar to see how it does it -- it looks like the
same idea.
JDH

On Friday 07 October 2005 16:30, John Hunter pondered:
> OK, I am happy to include this because I think the auto-resizing
> capability is useful (eg following the colorbar model). Now that you
> are aware of the figure legend, please take a look at your self.parent
> handling because parent can be an Axes or a Figure. You will want to
> check for isaxes before calling
>
> self.parent.get_position()
>
> and associated functions.
>
> Also, as a matter of style and efficiency, (snip)
Cool, I've rewritten my code with the suggested simplification and style 
concerns you put forward.
> Finally, I think your patch against your own tree, because it contains
> lines like
>
> - 'upper outside right' : 11,
> + 'upper outside right' : 11, # these only make sense with axes
> legends
>
>
> Eg, it is removing things that do not exist in matplotlib CVS -- make
> sure you apply diff against mpl CVS and not your own tree !
Oops, I diff'ed my most recent change against my first attempt instead of the 
original source, my bad. The original source tree I worked from was the 
mpl-0.84 tarball, but I guess using CVS is safer. Now, being a newbie to open 
source *developing* and CVS, how do I access and use mpl's CVS repository? Do 
you prefer my patches to be sent to this list or should I commit my changes 
to cvs?
More importantly though, after I made my changes I noticed that my axes 
resizing magic is based on the assumption that the plot the legend belongs to 
spans the width of the entire figure. This is not true in general and 
accordingly my new code, with resizing enabled, produces horrible results for 
e.g. subplot(121)/subplot(122), i.e. with multiple columns.
So, I thought just retrieve the dimensions of the current subplot somehow, but 
to no avail. Is there a way to retrieve the dimensions and/or position of the 
subplot, not the axes it contains? Something like lbwh=(0,0,0.5,1) for row 1, 
col 1 and lbwh=(0.5,0,0.5,1) for row 1, col 2 in the above example? That way 
I'd be able to calculate how much space axes + outside legend is supposed to 
occupy (my spaceNeeded variable).
Also, I see that this will only work when subplots are used, as soon as custom 
axes positioning/sizing is used such as that in examples/figlegend_demo.py, 
there seems to be no way to calculate this required space. Any way to check 
for this? Or should we leave it up to the user to turn resizing off if it 
doesn't give the desired results?
-- 
Kilian Hagemann
Climate Systems Analysis Group
University of Cape Town
Republic of South Africa
Tel(w): ++27 21 650 2748

On Tue, 2005年10月04日 at 09:00 -0500, John Hunter wrote:
> If I'm not mistaken, the complexity of the core matplotlib build has
> not changed in quite a while -- basically we've required zlib, png,
> freetype and C++ since 0.5. Yes, some backends require additional
> complexity (eg GTKAgg, the new WXAgg blit functionality) but you can
> simply turn these options off in setup.py if you don't need them; in
> the next few weeks I'm going to try and replace _gtkagg with pure
> python using python buffers. All of the changes to support blitting,
> widgets and so on have either been pure python or changes to existing
> extension code (eg _backend_agg.cpp and _gtkagg.cpp). Also, the size
> of the widgets module, which seems to bother you, is miniscule
> 
> > wc lib/matplotlib/widgets.py
> 985 3004 32510 lib/matplotlib/widgets.py
Once you have a GUI independent renderer and widget like
backend_bases.RendererBase and FigureCanvasBase then you have the
building blocks for writing a large GUI independent widget toolkit.
But just because its possible does not mean you should do it. I can see
that writing a small number of widgets is useful to mpl, but am
concerned that it could easily snowball into a project that is not
directly relevant to mpl.
Abraham was suggesting that we provide a way to override these mpl
widgets and use GTK widgets instead. I think that is unnecessary and
undermines matplotlib's idea of using a GUI independent renderer and
widget.
Steve
Send instant messages to your online friends http://au.messenger.yahoo.com 

On Fri, 2005年10月07日 at 20:04 -0700,
mat...@li... wrote:
> If you can sketch a cleaner implementation that makes more
> sense let
> me know. Since only GTK has an implementation currently and
> it is
> broken, and no mpl code is currently using the resize
> function, the
> field is wide open.
> 
> Thanks,
> JDH
I share Ted's concern. I think a 'well-behaved child widget' does not
know anything about its parent (or grandparent). Its added to a
container widget and expands/shrinks (depending on its resize policy) to
use the space that the container widget gives it. So the container
widget dictates the size of the child widget, not the other way round.
If you use the GUI to resize the canvas, you resize the gtk.Window and
the gtk.Window resizes the canvas. It seems reasonable to use the same
process to resize from a script - resize the gtk.Window and let the
Gtk.Window resize the canvas.
Or to put it another way - let the FigureManager manage the Figure!
I've updated backend_gtk.py to use this method, you can test it with:
$ ipython -gthread
In [1]: import pylab as p
In [2]: fig = p.figure()
In [3]: fm = p.get_current_fig_manager()
In [4]: fm.set_canvas_size(500, 600)
Steve
Send instant messages to your online friends http://au.messenger.yahoo.com 

>>>>> "Ted" == Ted Drain <ted...@jp...> writes:
 Ted> John, I had some questions about this resize work. Here is
 Ted> the code for resize from backend_gtk.py:
 Ted> def resize(self, w, h): 'set the drawing area size in
 Ted> pixels' winw, winh = self.parent.parent.get_size() tmp, tmp,
 Ted> myw, myh = self.allocation padw = winw-myw padh = winh-myh
 Ted> self.parent.parent.resize(w+padw, h+padh)
 Ted> I'm a little concerned about this implementation. It looks
 Ted> like the widget is telling it's parent's parent to resize.
 Ted> Doesn't this mean that the ability of the widget to be used
 Ted> as a modular component is reduced because this code requires
 Ted> a certain parent child relationship?
Oops, you're right. Good catch. This implementation will fail for
some widget packings, eg a canvas in a scrolled window...
 Ted> I think it's fairly important that a widget have only very
 Ted> minimum interactions with it's parent. Is there some way
 Ted> this could be implemented that doesn't require the child
 Ted> widget to be calling methods on the parent?
 Ted> If I understand the basic premise you've outlined below, you
 Ted> want a resize in the child (the drawing widget) to cause the
 Ted> parent window to resize. Only the parent can figure out what
 Ted> it's size needs to be (since it knows about it's margins,
 Ted> toolbars, etc). On the surface, it seems like there are two
 Ted> ways to handling this: 1) Tell the window to resize the
 Ted> canvas. The window can use it's own layout classes, etc and
 Ted> correctly resize itself and the canvas. 2) Tell the canvas
 Ted> to resize and have this trigger a window resize.
 Ted> I think the first option is much cleaner. However, if that
 Ted> isn't possible, I suggest that we do something like this:
Right, we don't need a resize method. As you suggest, all we need
is a way to tell the canvas and its parent(s) to auto_adjust itself to
accommodate the figure (using the width, height and dpi settings ....)
Then whenever fig.set_dpi or fig.set_figsize_inches or
fig.set_figsize_pixels (to be added) is called, we could call
 self.canvas.update_size()
if we can figure out the right way to propagate up containment chain.
The update_size method will have to send a signal to the parent, but
how this is done can be backend dependent. I think the logic in my
first implementation is still correct if we replace self.parent.parent
(which as you note makes certain parent/child assumptions) with the
gtk.Window the canvas resides in because it sets it computes the width
and height of all the other widgets in the canvas by subtracting the
canvas width/height from the window width/height.
 winw, winh = self.gtkwin.get_size()
 tmp, tmp, myw, myh = self.allocation
 padw = winw-myw
 padh = winh-myh
 self.gtkwin.resize(w+padw, h+padh)
Of course this would require that the canvas user sets gtkwin. Other
than for the philosophical reason that the child calls methods on the
parent, do you still think this implementation is problematic? I
personally don't find it problematic, but I'm willing to be corrected
:-) Of course, in QT you could handle it anyway you want, eg using
signals to the parent.
If you can sketch a cleaner implementation that makes more sense let
me know. Since only GTK has an implementation currently and it is
broken, and no mpl code is currently using the resize function, the
field is wide open.
Thanks,
JDH