matplotlib-devel Mailing List for matplotlib

>>>>> "Jochen" == Jochen Voss <vo...@se...> writes:
 Jochen> Hello, I found what I believe is bug in matplotlib. The
 Jochen> program
 Jochen> displays a graph, where the xlabel is shifted to much
 Jochen> down. Only the upper half of the xlabel is still visible,
 Jochen> the lower half is outside the visible area.
 Jochen> Is this a bug? Or do I need to somehow manually reserve
 Jochen> space for the display of the xlabel?
See http://matplotlib.sf.net/faq.html#TEXTOVERLAP
Basically the subplots are fixed sizes - they don't automatically
adjust in response to the items placed on or around them. One could
write a layout engine to do this, but there isn't one current. You
have to adjust parameters as described in the link above.
JDH

>>>>> "Jochen" == Jochen Voss <vo...@se...> writes:
 Jochen> Hello, I did some clean-up of the matplotlib PostScript
 Jochen> backend. Main changes:
 Jochen> - The generated Postscript output is now completely DSC
 Jochen> conformant (I hope).
Great - everyone should take this for a test drive with their favorite
PS viewers before the next release.
 Jochen> - All PostScript definitions go into a a PostScript
 Jochen> dictionary mpldict instead of the global one. This will
 Jochen> hopefully prevent problems (name clashes) when including
 Jochen> matplotlib generated eps files into other PostScript files
 Jochen> - I moved 1.5kb of comments about drawing ellipses from
 Jochen> the generated PostScript into a Python source code
 Jochen> comment. I think it does not make sense to ship the
 Jochen> comment in each and every genereated picture.
Makes sense to me...
 Jochen> Hopefully I did not cause any new problems. Comments
 Jochen> about the changes are most welcome.
One other PS quasi-bug you may want to be aware of is the way truetype
fonts are embedded. The basic problem is that Paul couldn't find a
way to access the individual glyph information so ended up having to
embed the entire font. For mathtext, with multiple fonts (which is
typical) this makes for large ps files. It would be nice to just
embed only the required glyphs. I believe this information is may be
available in face->glyph->outline - see also FT_Outline in the
freetype API abd agg22/font_freetype/agg_font_freetype.cpp which makes
use of this glyph info in decompose_ft_outline.
I haven't looked into this extensively, but I think it should be
possible. This would help on mathtext for SVG, for which I believe we
require the individual glyph information.
JDH

>>>>> "Jochen" == Jochen Voss <vo...@se...> writes:
 Jochen> Hello, currently I am having a closer look at the
 Jochen> PostScript backend. Some questions occurred to me:
 Jochen> 1) What is the meaning of 'backend_version'? When should
 Jochen> it be increased/changed?
Eg, for gtk this would be the version of pygtk, for wx the version of
wxpython. It is mainly used to provide us diagnositic information to
help when users post problems on the mailing list. If they run with
--debug-helpful, we get the version info. It is not the same as the
matplotlib version, which is reported separately. For PS, it seems
that it should be the PS level that is required (PS level I, level
II). But it could also be 'not applicable'. If you can think of
something that makes sense, use it.
 Jochen> 2) Is the following code the correct way to get the
 Jochen> matplotlib version for use in a backend file:
 Jochen> from matplotlib import __version__ version=__version__
Looks right to me; you could also do
from matplotlib import __version__ as version
 Jochen> 3) The draw_lines method checks whether the argument
 Jochen> arrays are of the same size as required. The other
 Jochen> functions do not do any sanity checks on the arguments.
 Jochen> Can the renderer methods assume that they are called with
 Jochen> semantically correct arguments? Is it ok to fail with an
 Jochen> Python exception otherwise?
Yes on both cases, me thinks.
 Jochen> 4) Can the PostScript code assume that each file contains
 Jochen> only one picture/page? Might this change in the future?
I say yes. I can't imagine changing this, but perhaps someelse who is
more imaginative than I could.
 Jochen> 5) Does matplotlib have the concept of a picture title
 Jochen> which could be written into the DSC "%%Title" comment? If
 Jochen> the answer is yes: how do I get this title?
Well, there is a figure title and an axes title. It would be easy to
add a renderer method called set_title which is called by figure.draw
and axes.draw. The problem here is that although there *is* a figure
title (see matplotlib.matlab.figtitle) the most common way to set
titles is via matplotlib.matlab.title which sets the title of the
current axes. Hence you could have multiple titles. One solution,
that will work in 95% of the cases, is just to use the first call to
set_title in the renderer and ignore subsequent calls. This will get
the figure title if there is one, and the first axes title if there
isn't.
 Jochen> Also I have some questions about the template backend in
 Jochen> backend_template.py:
 Jochen> 6) The template backend contains the line
 Jochen> from matplotlib.transforms import Bbox
 Jochen> Does this have any function or should it be removed?
It can be removed.
 Jochen> 7) The template backend uses
 Jochen> verbose.report('Error: %s'%msg)
 Jochen> Should this be 'verbose.report_error' instead?
Yes.
 Jochen> Sorry about having so many questions, Jochen --
Thanks!
JDH

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
 Steve> John, I think the doc string for points_to_pixels() in
 Steve> backend_bases.py and backend_template.py should be updated
 Steve> define its return type. Does points_to_pixels() return
 Steve> int, float, or float if the backend supports it (agg) else
 Steve> int (gtk)?
I think this should be a float return type, to leave issues of
rounding to the last minute when the backend renderer gets the coords
for drawing. Eg, lines.py uses this information to draw line with
lengths in points - you might imagine a situation where the backend
round one way or the other depending on the two end points of the
line. If the points were rounded first, this would not be possible.
If you agree with this, go ahead and update the doc string.
As I mentioned earlier, I'm looking into refactoring the backend
drawing model so that the transformations happen in the backend, which
would obviate some of these problems.
JDH

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
Hi Steve, 
 >> 7) The template backend uses=20
 >> 
 >> verbose.report('Error: %s'%msg)
 >> 
 >> Should this be 'verbose.report_error' instead?
Yes.
 Steve> No verbose() at all! But I agree I think it should be
 Steve> 'verbose.report_error'
Yes, it should. All printing should either go to verbose.report or
verbose.report_error, so that the user specified output handles are
used. This was just an oversight in backend_bases.error_msg.
Everyone should feel free to fix these as they find them.
Of course, GUI backends are an exception, where the error messages go
to the dialog box, as you noted.
 >> Also, there is a new PS backend now. I've been working on
 >> backend_cairo.py and today got it producing its own png and PS
 >> files.
Great - there have been a number of people who've been interested in a
cairo backend since the earliest days. When you get the thing so that
you're happy with it, you might want to search for cairo on the
mailing list and let these people know there is one.
Thanks!
JDH

Hello,
On Sun, Oct 31, 2004 at 10:09:55PM +0800, Steve Chaplin wrote:
> backend_bases has:
> def error_msg(msg, *args, **kwargs):
> """
> Alert an error condition with message
> """
> print >>sys.stderr, msg
> sys.exit()
>=20
> No verbose() at all! But I agree I think it should be
> 'verbose.report_error'=20
Yes, it seems that this makes sense in the non-interactive case.
We are aborting the program, so the message should be visible
in any case.
> Also, there is a new PS backend now. I've been working on
> backend_cairo.py and today got it producing its own png and PS files.
Cool!
All the best,
Jochen
--=20
http://seehuhn.de/

> 7) The template backend uses=20
> 
> verbose.report('Error: %s'%msg)
> 
> Should this be 'verbose.report_error' instead?
I was looking at this too, earlier today, because it was giving me a
problem - it was exiting without the error message being printed.
I looked to see how backend_agg handles errors and deleted it because I
don't think its even needed.
With a GUI backend you can popup an error message window.
With a non-GUI backend you can simply use
"from matplotlib.backend_bases import error_msg" as backend_agg does.
backend_bases has:
def error_msg(msg, *args, **kwargs):
 """
 Alert an error condition with message
 """
 print >>sys.stderr, msg
 sys.exit()
No verbose() at all! But I agree I think it should be
'verbose.report_error' 
Also, there is a new PS backend now. I've been working on
backend_cairo.py and today got it producing its own png and PS files.
Regards,
Steve

Hello,
I found what I believe is bug in matplotlib.
The program
 from matplotlib.matlab import *
 from math import sin
 t=3Darange(0,10,0.1)
 x=3Dmap(lambda tt:sin(tt), t)
 figure(figsize=3D(5,3))
 plot(t,x,"k-")
 xlabel("total time")
 ylabel("tatil tome")
 title("titol tame")
 show ()
displays a graph, where the xlabel is shifted to much down. Only the
upper half of the xlabel is still visible, the lower half is outside
the visible area.
Is this a bug? Or do I need to somehow manually reserve space for the
display of the xlabel?
All the best,
Jochen
--=20
http://seehuhn.de/

Hello,
I fixed the problem with the not-quite-correctly text in the PS
backend. The solution was to shift all the text up by the distance
between the lower edge of the bounding box and the text base line. I
added a new method to FT2Font, which calculates this distance.
Comments about this are most welcome.
All the best,
Jochen
--=20
http://seehuhn.de/

Hello,
I did some clean-up of the matplotlib PostScript backend.
Main changes:
 - The generated Postscript output is now completely DSC conformant
 (I hope).
 - All PostScript definitions go into a a PostScript dictionary
 mpldict instead of the global one. This will hopefully prevent
 problems (name clashes) when including matplotlib generated eps
 files into other PostScript files
 - I moved 1.5kb of comments about drawing ellipses from the generated
 PostScript into a Python source code comment. I think it does not
 make sense to ship the comment in each and every genereated picture.
Hopefully I did not cause any new problems. Comments about the
changes are most welcome.
All the best,
Jochen
--=20
http://seehuhn.de/

Hello,
currently I am having a closer look at the PostScript backend.
Some questions occurred to me:
1) What is the meaning of 'backend_version'? When should it
 be increased/changed?
2) Is the following code the correct way to get the
 matplotlib version for use in a backend file:
 from matplotlib import __version__
 version=3D__version__
3) The draw_lines method checks whether the argument arrays
 are of the same size as required. The other functions do not
 do any sanity checks on the arguments. Can the renderer methods
 assume that they are called with semantically correct arguments?
 Is it ok to fail with an Python exception otherwise?
4) Can the PostScript code assume that each file contains only one
 picture/page? Might this change in the future?
5) Does matplotlib have the concept of a picture title which could
 be written into the DSC "%%Title" comment? If the answer is yes:
 how do I get this title?
Also I have some questions about the template backend in
backend_template.py:
6) The template backend contains the line
 from matplotlib.transforms import Bbox
 Does this have any function or should it be removed?
7) The template backend uses=20
 verbose.report('Error: %s'%msg)
 Should this be 'verbose.report_error' instead?
Sorry about having so many questions,
Jochen
--=20
http://seehuhn.de/

John,
I think the doc string for points_to_pixels() in backend_bases.py and
backend_template.py should be updated define its return type.
Does points_to_pixels() return int, float, or float if the backend
supports it (agg) else int (gtk)?
Regards
Steve

gary ruben wrote:
> True, I didn't pay much attention to licencing. In light of it though, here
> are a couple more links to a couple of gentlemen who may be worth
> grovelling to should the need arise. No specific licencing is mentioned.
> 
> <http://mahi.ucsd.edu/parker/Software/>
Actually, having seen this code and the gist code, I'd recommend waiting 
 for the gist-derived prototype.
To muddy the waters a bit, the gist contouring algorithm looks to my eye 
like Paul Bourke's CONREC algorithm, which may or may not be patented.
O software patents, how I hate thee!
-- 
Robert Kern
rk...@uc...
"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
 -- Richard Harter

gary ruben wrote:
> True, I didn't pay much attention to licencing. In light of it though, here
> are a couple more links to a couple of gentlemen who may be worth
> grovelling to should the need arise. No specific licencing is mentioned.
> 
> <http://mahi.ucsd.edu/parker/Software/>
I know Bob. I'll ask him.
-- 
Robert Kern
rk...@uc...
"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
 -- Richard Harter

True, I didn't pay much attention to licencing. In light of it though, here
are a couple more links to a couple of gentlemen who may be worth
grovelling to should the need arise. No specific licencing is mentioned.
<http://mahi.ucsd.edu/parker/Software/>
The documentation says the contouring code was written by this guy who is
the director of the SETI@home project:
<http://setiweb.ssl.berkeley.edu/~davea/resume.html>
regards,
Gary
*********** REPLY SEPARATOR ***********
On 28/10/2004 at 09:25 John Hunter wrote:
> >>>>> "gary" == gary ruben <gr...@bi...> writes:
> 
> gary> Some more possible contour generating code links:
> 
> [1] http://www.geog.uni-hannover.de/grass/
> [2] http://www.triplexware.huckfinn.de/geogfix.html
> [3] http://www.triplexware.huckfinn.de/contweber.html
> [4] http://astronomy.swin.edu.au/~pbourke/projection/conrec/
> [5] http://members.bellatlantic.net/~vze2vrva/
> 
> Hi Gary, thanks for the tips. Note that [1] appears to be GPLd and
> we're looking for a routine with licenses as permissive as the
> PSF/matplotlib license. I believe [2] and [4] are both pointing to
> the same algorithm, by Paul Bourke - this one has a C++ implementation
> that includes the following license restriction
> 
> Additionally, the authors grant permission to modify this software
> and its documentation for any purpose, provided that such
> modifications are not distributed without the explicit consent of
> the authors and that existing copyright notices are retained in all
> copies. Some of the algorithms implemented by this software are
> patented, observe all applicable patent law.
> 
> Since this code implements the Bourke algorithm, I assume the other
> implementations have the same patent restrictions, but I haven't taken
> a close look. 
> 
> [3] is released under the MPL -
> http://www.mozilla.org/MPL/MPL-1.1.html, which as I understand has a
> complex licensing history - it certainly takes a lawyer to read
> through it - I'm not sure what the status is.
> 
> [5] is certainly as possibility, if as you say, we contact the author
> and see if he is willing to release it to us.
> 
> Hopefully, all of this is moot, as I understand that STSci has been
> working on a routine ripped from gist and Perry says they are close to
> having a prototype. I still think it's worthwhile investigating
> whether marching squares is patented or enforceable - Mr Horton's
> response was not terribly enlightening.
> 
> JDH
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
------------------------------------
Gary Ruben gr...@bi...
<http://users.bigpond.net.au/gazzar>

>>>>> "gary" == gary ruben <gr...@bi...> writes:
 gary> Some more possible contour generating code links:
 [1] http://www.geog.uni-hannover.de/grass/
 [2] http://www.triplexware.huckfinn.de/geogfix.html
 [3] http://www.triplexware.huckfinn.de/contweber.html
 [4] http://astronomy.swin.edu.au/~pbourke/projection/conrec/
 [5] http://members.bellatlantic.net/~vze2vrva/
Hi Gary, thanks for the tips. Note that [1] appears to be GPLd and
we're looking for a routine with licenses as permissive as the
PSF/matplotlib license. I believe [2] and [4] are both pointing to
the same algorithm, by Paul Bourke - this one has a C++ implementation
that includes the following license restriction
 Additionally, the authors grant permission to modify this software
 and its documentation for any purpose, provided that such
 modifications are not distributed without the explicit consent of
 the authors and that existing copyright notices are retained in all
 copies. Some of the algorithms implemented by this software are
 patented, observe all applicable patent law.
Since this code implements the Bourke algorithm, I assume the other
implementations have the same patent restrictions, but I haven't taken
a close look. 
[3] is released under the MPL -
http://www.mozilla.org/MPL/MPL-1.1.html, which as I understand has a
complex licensing history - it certainly takes a lawyer to read
through it - I'm not sure what the status is.
[5] is certainly as possibility, if as you say, we contact the author
and see if he is willing to release it to us.
Hopefully, all of this is moot, as I understand that STSci has been
working on a routine ripped from gist and Perry says they are close to
having a prototype. I still think it's worthwhile investigating
whether marching squares is patented or enforceable - Mr Horton's
response was not terribly enlightening.
JDH

Some more possible contour generating code links:
http://www.geog.uni-hannover.de/grass/
http://www.triplexware.huckfinn.de/geogfix.html
http://www.triplexware.huckfinn.de/contweber.html
http://astronomy.swin.edu.au/~pbourke/projection/conrec/
These weren't too hard to find. There are probably more out there to be
found.
Gary R.
*********** REPLY SEPARATOR ***********
On 28/10/2004 at 23:41 gary ruben wrote:
> A quick google reveals this guy's contouring code:
> <http://members.bellatlantic.net/~vze2vrva/>
> which I found via this:
> <http://www.codeproject.com/cpp/contour.asp>
> Given that he has some C source code on his site, perhaps Mr Aramini
would
> be happy to allow its use into matplotlib. He certainly looks like a
happy
> fellow :-)
> 
> Gary R.
------------------------------------
Gary Ruben gr...@bi...
<http://users.bigpond.net.au/gazzar>

A quick google reveals this guy's contouring code:
<http://members.bellatlantic.net/~vze2vrva/>
which I found via this:
<http://www.codeproject.com/cpp/contour.asp>
Given that he has some C source code on his site, perhaps Mr Aramini would
be happy to allow its use into matplotlib. He certainly looks like a happy
fellow :-)
Gary R.
*********** REPLY SEPARATOR ***********
On 28/11/2004 at 06:34 Greg Whittier wrote:
> I'd suggest seeing how VTK handles this. I believe they have a patented
> and a non-patented contour filter (vtkContourFilter and
> vtkMarchingContourFilter). The VTK package has a python interface. The
> goals page mentions on embedding VTK for future 3d functionality. Could
> VTK be embedded to leverage some of the other good work they've done?
> 
> Greg
<snip>
------------------------------------
Gary Ruben gr...@bi...
<http://users.bigpond.net.au/gazzar>

I'd suggest seeing how VTK handles this. I believe they have a patented
and a non-patented contour filter (vtkContourFilter and
vtkMarchingContourFilter). The VTK package has a python interface. The
goals page mentions on embedding VTK for future 3d functionality. Could
VTK be embedded to leverage some of the other good work they've done?
Greg
On Tue, 2004年10月26日 at 21:07, gary ruben wrote:
> Rather than drawing the conclusion that Carl can't read English or that he
> thinks we're going to start a fundraiser to raise the 10000,ドル I think we
> can guess that marching squares is probably NOT covered by the patent, but
> that seeing a big dollar number and his title should scare us off testing
> the patent. Presumably there are alternatives to marching squares and I'd
> pursue them, unless you feel like poking Carl with another stick :-)
> 
> Gary R
> 
> *********** REPLY SEPARATOR ***********
> 
> On 26/10/2004 at 12:59 Horton, Carl (GE Healthcare) wrote:
> 
> > Curtis: attached is a copy of the license agreement required for use of
> > the Marching Cubes/VTK algorithms and related software. Once this
> > agreement has been executed and GE has received the requisite payments,
> > your license will be automatic. Thanks.
> > 
> > 			
> > 
> > 
> > > Carl B. Horton
> > > GE Healthcare
> > > Chief IP Counsel
> > > 
> > > P: 262 513-4022
> > > F: 414 918-1641
> > > C: 262 385-7315
> > > D: *320-4022 
> > > E: Car...@me...
> > www.gehealthcare.com
> > 
> > -----Original Message-----
> > From: Curtis Cooper [mailto:cu...@hi...]
> > Sent: Friday, October 01, 2004 2:42 PM
> > To: Horton, Carl (GE Healthcare)
> > Cc: Matplotlib Developers
> > Subject: Marching Squares Algorithm
> > 
> > 
> > Dear Mr. Horton:
> > 
> > I am investigating options for creating 2D contour plots for the freely
> > distributable Matplotlib package (http://matplotlib.sourceforge.net/).
> > The Matplotlib license requires all the software to be free for
> > noncommercial and commercial distribution.
> > 
> > I had the idea to try to implement marching squares for this package. We
> > know the marching cubes algorithm is patented, but what about the 2D
> > marching squares? Can my implementation be used in this freely
> > distributed package without obtaining a license grant?
> > 
> > Thanks,
> > Curtis
> 
> ------------------------------------
> Gary Ruben gr...@bi...
> <http://users.bigpond.net.au/gazzar>
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Greg Whittier <gr...@th...>

On Tuesday 26 October 2004 19:52, John Hunter wrote:
> >>>>> "Norbert" == Norbert Nemec <Nor...@gm...> writes:
>
> Norbert> Hi there, in the attachment, find a patch for the legend
> Norbert> to behave correctly when some of the handles are set to
> Norbert> None. (In which case the corresponding space is just left
> Norbert> empty.)
>
> When would some of the handles be None? That looks like a bug to
> me...
I'm probably using legends in an unusual way (you might call it "abusing"...): 
In my plot, I have certain information refering to individual plot-lines. 
These, I put regularly into the legend, together with a handle of the 
corresponding line.
Other information refers to the whole figure, but should be visible in a 
similar way as the regular legend information. The way I do this, is to place 
it in additional legend entries without handle.
As an example: i have different datasets for different energies and different 
bfields. One figure should now contain five plots of identical energy but 
different bfield. The legend box would then p.e. contain one line "energy=2.3 
eV" without handle, and five lines "bfield=?? T" with handles. In between, I 
can even put one additional empty line to make everything more readable.
The current code handles this "abuse" nearly correct, except for the incorrect 
rearrangement in _update_positions. My patch should not affect anyone who 
uses the legend in the regular way, and for those who abuse the legend 
intentionally or unintentionally, the patched version certainly behaves more 
predictable.
-- 
_________________________________________Norbert Nemec
 Bernhardstr. 2 ... D-93053 Regensburg
 Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
 eMail: <No...@Ne...>

Rather than drawing the conclusion that Carl can't read English or that he
thinks we're going to start a fundraiser to raise the 10000,ドル I think we
can guess that marching squares is probably NOT covered by the patent, but
that seeing a big dollar number and his title should scare us off testing
the patent. Presumably there are alternatives to marching squares and I'd
pursue them, unless you feel like poking Carl with another stick :-)
Gary R
*********** REPLY SEPARATOR ***********
On 26/10/2004 at 12:59 Horton, Carl (GE Healthcare) wrote:
> Curtis: attached is a copy of the license agreement required for use of
> the Marching Cubes/VTK algorithms and related software. Once this
> agreement has been executed and GE has received the requisite payments,
> your license will be automatic. Thanks.
> 
> 			
> 
> 
> > Carl B. Horton
> > GE Healthcare
> > Chief IP Counsel
> > 
> > P: 262 513-4022
> > F: 414 918-1641
> > C: 262 385-7315
> > D: *320-4022 
> > E: Car...@me...
> www.gehealthcare.com
> 
> -----Original Message-----
> From: Curtis Cooper [mailto:cu...@hi...]
> Sent: Friday, October 01, 2004 2:42 PM
> To: Horton, Carl (GE Healthcare)
> Cc: Matplotlib Developers
> Subject: Marching Squares Algorithm
> 
> 
> Dear Mr. Horton:
> 
> I am investigating options for creating 2D contour plots for the freely
> distributable Matplotlib package (http://matplotlib.sourceforge.net/).
> The Matplotlib license requires all the software to be free for
> noncommercial and commercial distribution.
> 
> I had the idea to try to implement marching squares for this package. We
> know the marching cubes algorithm is patented, but what about the 2D
> marching squares? Can my implementation be used in this freely
> distributed package without obtaining a license grant?
> 
> Thanks,
> Curtis
------------------------------------
Gary Ruben gr...@bi...
<http://users.bigpond.net.au/gazzar>

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
 Steve> The color (1000,1000,1000) has become (992,992,992). It
 Steve> looks to me like get_color() should multiply by 65535, or
 Steve> is there a special reason for using 65025?
Hi Steve,
Not that I know of :-) I think you'll be fine using 65535 in both
cases. I suggest you go ahead and check it in.
JDH

>>>>> "Norbert" == Norbert Nemec <Nor...@gm...> writes:
 Norbert> Hi there, in the attachment, find a patch for the legend
 Norbert> to behave correctly when some of the handles are set to
 Norbert> None. (In which case the corresponding space is just left
 Norbert> empty.)
When would some of the handles be None? That looks like a bug to
me...
 Norbert> Without this patch, everything is first set up correctly,
 Norbert> but then the _update_positions routine shifts the items
 Norbert> in the legend box around incorrectly.

Curtis: attached is a copy of the license agreement required for use of =
the Marching Cubes/VTK algorithms and related software. Once this =
agreement has been executed and GE has received the requisite payments, =
your license will be automatic. Thanks.
		=09
> Carl B. Horton
> GE Healthcare
> Chief IP Counsel
>=20
> P: 262 513-4022
> F: 414 918-1641
> C: 262 385-7315
> D: *320-4022=20
> E: Car...@me...
www.gehealthcare.com
-----Original Message-----
From: Curtis Cooper [mailto:cu...@hi...]
Sent: Friday, October 01, 2004 2:42 PM
To: Horton, Carl (GE Healthcare)
Cc: Matplotlib Developers
Subject: Marching Squares Algorithm
Dear Mr. Horton:
I am investigating options for creating 2D contour plots for the freely
distributable Matplotlib package (http://matplotlib.sourceforge.net/).
The Matplotlib license requires all the software to be free for
noncommercial and commercial distribution.
I had the idea to try to implement marching squares for this package. =
We
know the marching cubes algorithm is patented, but what about the 2D
marching squares? Can my implementation be used in this freely
distributed package without obtaining a license grant?
Thanks,
Curtis
 * * * * * * * * * * * * * * * * * * * * * * * * * * * *
 * Curtis S. Cooper, Graduate Research Assistant *
 * Lunar and Planetary Laboratory, University of Arizona *
 * http://www.lpl.arizona.edu/~curtis/		 *
 * Kuiper Space Sciences, Rm. 318 *
 * 1629 E. University Blvd., *
 * Tucson, AZ 85721 * * * * * * * * * * * * * * *
 * Wk: (520) 621-1471 *
 * * * * * * * * * * * *

Hi there,
in the attachment, find a patch for the legend to behave correctly when some 
of the handles are set to None. (In which case the corresponding space is 
just left empty.)
Without this patch, everything is first set up correctly, but then the 
_update_positions routine shifts the items in the legend box around 
incorrectly.
Ciao,
Norbert
-- 
_________________________________________Norbert Nemec
 Bernhardstr. 2 ... D-93053 Regensburg
 Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
 eMail: <No...@Ne...>