matplotlib-devel Mailing List for matplotlib (Page 536)

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...>

I just installed matplotlib-0.63.4 on Mac OSX 10.3, with some 
difficulties i detail (and answer) below.
Using Fink (0.7.1), freetype2 (2.1.3-21), Tk and GTK.
python setup.py install fails because of wrong paths to find freetype2 
ft2build.h. Darwin include paths (in setupext.py) are '/usr/local', 
'/usr', 'sw'. freetype2 include paths are :
 > locate ft2build.h
 > /sw/lib/freetype2/include/ft2build.h
 > /usr/X11R6/include/freetype2/ft2build.h
Once '/usr/X11R6' or '/sw/lib/freetype2' to setupext.py paths for 
Darwin, build process works fine. Agg, GTKAgg, and TkAgg backends are 
available as described in your documentation.
I use matplotlib with ipython (python2.3.3, IPython0.6.3), and GTKAgg 
backend crashes if pygtk (2.0.0 here) is not build with threading. I 
used
 > python setup.py build --enable-threading
Thanks for this great matplotlib product.
-------------
Loic Chevallier
ATER section 34
Observatoire de Paris - section de Meudon
Laboratoire LUTH
Groupe Noyaux actifs de galaxies et milieu insterstellaire
http://www-obs.univ-lyon1.fr/transfer/
email:loi...@ob...
tel: 01.45.07.74.29 (bureau 249)

Hi there,
another tiny patch: adding **kwargs to the errorbar function and passing them 
through to the internal plot function. This allows arguments like "color" 
used on errorbar.
Ciao,
Nobbi
-- 
_________________________________________Norbert Nemec
 Bernhardstr. 2 ... D-93053 Regensburg
 Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
 eMail: <No...@Ne...>

John,
I'm trying to understand the methods
backend_gtk.ColorManagerGTK.get_color()
backend_gtk.ColorManagerGTK.get_rgb()
They convert color representations from rgb (three floats in the range
0.0 - 1.0) to gdk.Color (three integers in the range 0 - 65535)
get_rgb() divides by 65535 but get_color() multiplies by 65025. So if
I run
>>> import gtk
>>> import backend_gtk
>>> cm=backend_gtk.ColorManagerGTK()
>>> cm.set_drawing_area(gtk.DrawingArea())
>>> gdk_color=gtk.gdk.Color(1000,1000,1000)
>>> rgb_color=cm.get_rgb(gdk_color)
>>> gdk_color=cm.get_color(rgb_color)
>>> print gdk_color.red, gdk_color.green, gdk_color.blue
992 992 992
The color (1000,1000,1000) has become (992,992,992).
It looks to me like get_color() should multiply by 65535, or is there 
a special reason for using 65025?
Regards,
Steve

Here it is.
Did it slightly different by calling the option "bars_on_top=False", which is 
more descriptive.
Be aware, that this changes the default behaviour, but the difference is so 
subtle that only few people should notice at all. Still, I think this is the 
more reasonable default behaviour, since - usually - the plot line is more 
important than the errorbars and should be clearly visible.
On Friday 22 October 2004 15:24, John Hunter wrote:
> How about adding a kwarg to the signature of the errorbar function,
> which defaults to below=True (this would have the default behavior you
> want, errorbars below markers, but could be customized).
>
> Then you could add an if clause in the errorbar code which reverses
> the order of the calls.
>
> Since noone has done the zordering yet, and this issue has come up
> twice in the context of errorbars, it is probably worthwhile to add it
> now to the errorbar code.
>
> If I could impose in you one more time Norbert to submit a patch that
> allows the user to configure the order using a kwarg, I'll be happy to
> check it in.
-- 
_________________________________________Norbert Nemec
 Bernhardstr. 2 ... D-93053 Regensburg
 Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
 eMail: <No...@Ne...>

>>>>> "Norbert" == Norbert Nemec <Nor...@gm...> writes:
 Norbert> Thanks for the reply. Surprises me that people would
 Norbert> really argue about this issue, but well. :-)
There's just no accounting for the taste of some people... Here are
some links to the original discussion
 http://sourceforge.net/mailarchive/forum.php?thread_id=5434727&forum_id=33405
 http://sourceforge.net/mailarchive/forum.php?thread_id=5440722&forum_id=33405
 Norbert> Attached is a slighly changed patch: effectively, it does
 Norbert> not change the layering any more, but it changes the
 Norbert> internals of errorbar() in a way, that allows to swap the
 Norbert> layering by simply swapping two blocks of code. (Which
 Norbert> was nontrivial before, since the color from the plot line
 Norbert> can only be read after it has been drawn.)
 Norbert> Whether this swapping is then done by hand, by an option
 Norbert> or an entry in the rc file can be left to the future.
 Norbert> Maybe, submitting this patch will save someone else the
 Norbert> time to figure it out himself.
How about adding a kwarg to the signature of the errorbar function,
which defaults to below=True (this would have the default behavior you
want, errorbars below markers, but could be customized).
Then you could add an if clause in the errorbar code which reverses
the order of the calls.
Since noone has done the zordering yet, and this issue has come up
twice in the context of errorbars, it is probably worthwhile to add it
now to the errorbar code.
If I could impose in you one more time Norbert to submit a patch that
allows the user to configure the order using a kwarg, I'll be happy to
check it in.
BTW, Gary, any chance I could persuade you to write a tutorial/guide
to using errorbar / bar / barh for the users guide? barh is in CVS.
If you are averse to latex, you could submit in plain text and I can
convert it. I'm mostly done with the matlab interface section and
have been working on other sections (API) and I am having trouble
motivating myself to finish some of these matlab interface sections.
Since you are the world's expert on matplotlib bar charts, I thought
you would be a good victim, er candidate, to write that section. FYI,
I looked into changing the default meaning of x in the errorbar code
to have it refer to the center, rather than the left, as we discussed.
The problem is, this broke some of the table examples, which are a bit
hairy and written by John Gill, so I put it on the back burner. For
barh, however, I did make the y axis mean the center, since we are all
in agreement that this is the more intuitive behavior.
JDH

Thanks for the reply. Surprises me that people would really argue about this 
issue, but well. :-)
Attached is a slighly changed patch: effectively, it does not change the 
layering any more, but it changes the internals of errorbar() in a way, that 
allows to swap the layering by simply swapping two blocks of code. (Which was 
nontrivial before, since the color from the plot line can only be read after 
it has been drawn.)
Whether this swapping is then done by hand, by an option or an entry in the rc 
file can be left to the future.
Maybe, submitting this patch will save someone else the time to figure it out 
himself.
Ciao,
Nobbi
On Friday 22 October 2004 12:27, gary ruben wrote:
> Hi Norbert,
> I think this is the best place to post patches like this.
> There was some discussion a while back about the layer ordering of
> errorbars and other objects in the plot window. It was decided to leave it
> unchanged for the moment since about half of users want it one way and half
> the other. Some ideas were raised like being able to specify layers as
> command parameters or change the default in the resource file. I think that
> until this is pursued, it is unlikely that anything will be done.
> Gary
>
> *********** REPLY SEPARATOR ***********
>
> On 22/10/2004 at 11:29 Norbert Nemec wrote:
> > Hi there,
> >
> > here is a small patch layering errorbars behind the line of the plot
> > itself.
> >
> > Rationale:
> > If you use ecolor and have a plot with many dense points, the errorbars
> > may be
> > covering the line itself completely. The relayering makes the line fully
> > visible and puts the errorbars as "additional information" in the
> > background.
> >
> > Greetings,
> > Norbert
> >
> > PS: If sending small patches to this mailing list is a suboptimal way of
> > submission, please tell me how to do it better.
> >
> > --
> > _________________________________________Norbert Nemec
> > Bernhardstr. 2 ... D-93053 Regensburg
> > Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
> > eMail: <No...@Ne...>
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> > Use IT products in your business? Tell us what you think of them. Give us
> > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
> > more
> > http://productguide.itmanagersjournal.com/guidepromo.tmpl
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
> ------------------------------------
> Gary Ruben gr...@bi...
> <http://users.bigpond.net.au/gazzar>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
_________________________________________Norbert Nemec
 Bernhardstr. 2 ... D-93053 Regensburg
 Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
 eMail: <No...@Ne...>

Hi Norbert,
I think this is the best place to post patches like this.
There was some discussion a while back about the layer ordering of
errorbars and other objects in the plot window. It was decided to leave it
unchanged for the moment since about half of users want it one way and half
the other. Some ideas were raised like being able to specify layers as
command parameters or change the default in the resource file. I think that
until this is pursued, it is unlikely that anything will be done.
Gary
*********** REPLY SEPARATOR ***********
On 22/10/2004 at 11:29 Norbert Nemec wrote:
> Hi there,
> 
> here is a small patch layering errorbars behind the line of the plot
> itself. 
> 
> Rationale:
> If you use ecolor and have a plot with many dense points, the errorbars
> may be 
> covering the line itself completely. The relayering makes the line fully 
> visible and puts the errorbars as "additional information" in the
> background.
> 
> Greetings,
> Norbert
> 
> PS: If sending small patches to this mailing list is a suboptimal way of 
> submission, please tell me how to do it better.
> 
> -- 
> _________________________________________Norbert Nemec
> Bernhardstr. 2 ... D-93053 Regensburg
> Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
> eMail: <No...@Ne...>
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
> more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
------------------------------------
Gary Ruben gr...@bi...
<http://users.bigpond.net.au/gazzar>

Hi there,
on one of my machines, matplotlib.matlab segfaults on import. On another 
machine, it works fine. I already traced the segfault to the library 
_na_transforms.so, but now I don't know how to continue from here. Can anyone 
give me a hint how to debug a python module written in C/C++?
I have plenty of experience in C/C++, but I'm just starting on python.
Thanks for help!
Ciao,
Norbert
-- 
_________________________________________Norbert Nemec
 Bernhardstr. 2 ... D-93053 Regensburg
 Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
 eMail: <No...@Ne...>

Hi there,
here is a small patch layering errorbars behind the line of the plot itself. 
Rationale:
If you use ecolor and have a plot with many dense points, the errorbars may be 
covering the line itself completely. The relayering makes the line fully 
visible and puts the errorbars as "additional information" in the background.
Greetings,
Norbert
PS: If sending small patches to this mailing list is a suboptimal way of 
submission, please tell me how to do it better.
-- 
_________________________________________Norbert Nemec
 Bernhardstr. 2 ... D-93053 Regensburg
 Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
 eMail: <No...@Ne...>

>>>>> "Paul" == Paul Barrett <ba...@st...> writes:
 
 Paul> It would be nice if they would update their documents, since
 Paul> the %%BeginFont and %%EndFont keywords are from their
 Paul> document about embedding fonts.
 Hey, give 'em a minute will you? They just released the 3.0 spec in
 '92. It's going to take them a while to get the rest of their site
 docs updated... :-)
JDH

Jochen Voss wrote:
>Hello John,
>
>On Tue, Oct 19, 2004 at 10:00:48AM -0500, John Hunter wrote:
> 
>
>>>>>>>"Jochen" == Jochen Voss <vo...@se...> writes:
>>>>>>> 
>>>>>>>
>> Jochen> None, I looked at the generated PS file out of curiosity
>> Jochen> and noticed that it does not follow the DSC conventions
>> Jochen> very well. As this is just shuffling around comments it
>> Jochen> will probably not affect many applications.
>>
>>Are there other noncompliant things in the matplotlib ps output that
>>you are aware of, other than those you already fixed?
>> 
>>
>I think the horrible ones are fixed by now.
>
>Minor issues:
>
>The DSC spec states (at page 18): "If there is a section in
>the document that corresponds to a particular comment, that comment
>*must* be used to identify that section of the document."
>
>From reading this I would guess that all the "/something { ... } bind
>def" statements and the included fonts should be inside a
>
> %%BeginPrologue
> %%EndPrologue
>
>block. But I didn't check this properly.
>
>Then page 19 "strongly suggests" to use some headers like
>"%%CreationDate" and "%%Title".
>
>Page 70 of the SDC specification states that "%%BeginFont" and
>"%%EndFont" are outdated and should be replaced by "%%BeginResource"
>and "%%EndResource" statements.
> 
>
It would be nice if they would update their documents, since the 
%%BeginFont and %%EndFont keywords are from their document about 
embedding fonts.
 -- Paul
-- 
Paul Barrett, PhD Space Telescope Science Institute
Phone: 410-338-4475 ESS/Science Software Branch
FAX: 410-338-4767 Baltimore, MD 21218

Hello,
the file examples/matplotlib_icon.py lacks the magic python
line at the beginning. This can be corrected with the following
patch:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
diff -u -r1.5 matplotlib_icon.py
--- matplotlib_icon.py 10 Aug 2004 15:04:27 -0000 1.5
+++ matplotlib_icon.py 19 Oct 2004 17:48:33 -0000
@@ -1,3 +1,4 @@
+#!/usr/bin/env python
 """
 make the matplotlib svg minimization icon
 """
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
I hope this helps,
Jochen
--=20
http://seehuhn.de/