Eric, I've seen the comment "Why is the copy needed?" that you've added
to the axes' hist method. I think this was introduced by me some time
ago. Indeed, I think it is not really needed. If I remember correctly, I
had done the copying to avoid that the input x gets modified (I had bad
experience w
Olle Engdegård wrote:
> Hi,
>
> Combining "stepfilled" with log scale sometimes gives inappropriate plots:
>
> a=[4,4,4,4,4,4,4,4,4,4,4,5,5,5,5,5,5]
> hist(a, range=(0,10), bins=10, histtype="stepfilled", log=True)
>
> The problem is not restricted to the case here with more bins than unique
>
Eric Firing wrote:
> Manuel Metz wrote:
>> Hi,
>> I just noted a strange behavior of contour(). When a contour plot is
>> created with negative values and using a single color instead of a cmap,
>> contour _always_ uses the contour.negative_linestyle, even if lin
Hi,
I just noted a strange behavior of contour(). When a contour plot is
created with negative values and using a single color instead of a cmap,
contour _always_ uses the contour.negative_linestyle, even if linestyles
are specifically provided:
x = linspace(-pi,pi,100)
X,Y = meshgrid(x,x)
Michael Droettboom wrote:
> Manuel Metz wrote:
>> Michael Droettboom wrote:
>>
>>> There was a discussion on this list around a year ago about this. The
>>> concern was that not rendering $ as $ would break (matplotlib) backward
>>> compatibility with
139. Both work fine.
mm
>
> Manuel Metz wrote:
>> Manuel Metz wrote:
>>
>>> Jae-Joon Lee wrote:
>>>
>>>> I just committed the change. Although the change is trivial, I didn't
>>>> tested it in the numpy 1.2 or the svn version
und "$\$%1.2f$" works with usetex on or off, with the
> proviso that it uses math- rather than text-rendering for the numbers.
>
> Mike
In that case I suggest to note this somewhere in the docs (and User
Guide) with three exclamation marks (or is it ???).
Manuel
> Manue
Manuel Metz wrote:
> Jae-Joon Lee wrote:
>> I just committed the change. Although the change is trivial, I didn't
>> tested it in the numpy 1.2 or the svn version.
>
> Aaaargh, with numpy 1.2.1 this produces a warning !!! Very unlucky,
> since 0.98.5 i
Jae-Joon Lee wrote:
> I just committed the change. Although the change is trivial, I didn't
> tested it in the numpy 1.2 or the svn version.
Aaaargh, with numpy 1.2.1 this produces a warning !!! Very unlucky,
since 0.98.5 is released...
> -JJ
>
>
> On Sun, Dec 7, 2008 at 3:24 PM, John Hunter
I just noted that mathtext and LaTeX rendering behave differently
when using a single "$" character in a text string. This happened to me
when looking at the dollar_ticks example from the docs because I use
LaTeX rendering by default. The problem is here:
formatter = ticker.FormatStrFormatte
Sandro Tosi wrote:
> On Mon, Oct 27, 2008 at 15:25, Manuel Metz <[EMAIL PROTECTED]> wrote:
>> Just put the Debian bugreport on the list here. I will look at this.
>>
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503148
>
> Thanks Manuel, and sorry for not
Sandro Tosi wrote:
> Hello guys!
> A Debian Developers just reported a bug[1] on debian matplotlib during
> his preparation to introduce GCC 4.4: matplotlib will fail to build
> with GCC 4.4 due to a missing include.
>
> Attached is a patch to fix this problem, forged from an updated trunk;
> hope
Just put the Debian bugreport on the list here. I will look at this.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503148
mm
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest
There are some screenshot-figures (png output) in the docs that need
minor updates:
- histogram: ylabel is cropped because the yticklabels are too wide
- table demo: the table is croped on the bottom of the image
- scatter demo: x and y labels are unreadable (the _i); ylabel is cropped
- financial
David Huard wrote:
> On Mon, Oct 20, 2008 at 10:19 AM, John Hunter <[EMAIL PROTECTED]> wrote:
>> On Mon, Oct 20, 2008 at 9:01 AM, David Huard <[EMAIL PROTECTED]> wrote:
>>
>>> I would oppose any change to histogram calling convention that does not
>>> fix a critical bug. I agree that using a built-
John Hunter wrote:
> On Sat, Oct 18, 2008 at 8:34 AM, Manuel Metz <[EMAIL PROTECTED]> wrote:
>> With a clear checkout building the docs fails:
>>
>> [...]
>> Sphinx v0.4.2, building html
>> trying to load pickled env... not found
>> building [html]:
With a clear checkout building the docs fails:
[...]
Sphinx v0.4.2, building html
trying to load pickled env... not found
building [html]: targets for 348 source files that are out of date
updating environment: 348 added, 0 changed, 0 removed
reading... api/afm_api api/artist_api Exception occurre
Please see the end of the mail for the important point !!!
Eric Firing wrote:
> Manuel,
>
> Although it doesn't hurt, I don't think it is worthwhile changing range
> to xrange. From the 2.5 docs:
[...snip...]
> Note "minimal" advantage. xrange was intended for special-case use, not
> general
2 and you can also provide it as an
> optional argument.
>
> Regards,
>
> -JJ
>
>
> On Thu, Oct 16, 2008 at 8:43 PM, Manuel Metz <[EMAIL PROTECTED]> wrote:
>> Manuel Metz wrote:
>>> Jae-Joon Lee wrote:
>>>> Hi Manuel,
>>>>
&
Manuel Metz wrote:
> Jae-Joon Lee wrote:
>> Hi Manuel,
>>
>> I think it is a good to introduce the update_from method in Collections.
>> But, I'm not sure if it is a good idea to also update sizes, paths and
>> rotation (in RegularPolyCoolection). My impressi
ccount your
> changes and post my version of patch later today.
>
> Regards,
>
> -JJ
>
>
>
>
> On Wed, Oct 15, 2008 at 4:07 PM, Manuel Metz <[EMAIL PROTECTED]> wrote:
>> hmm
>>
>> Original Message
>> Jae-J
JJ
Attached is my current version of the patch. I've moved all of the
properties-copying stuff to collections, which makes the changes
legend.py more clearer (but I'm not fully happy with the patch and
haven't commit anything yet)
mm
--
---
Jae-Joon Lee wrote:
>> - the parameter numpoints should be used (it's ignored right now)
>>
>
> Thanks Manuel. I guess we can simply reuse xdata_marker for this purpose.
>
>
>> - Some private variables are accessed and a new RegularPolycollection is
>> created (does this work eg. with a StarPoly
I found a few typos in artists.rst. Added a patch (don't want to commit
it, because I'm not actively working on the docs)
The first sentence of the section "Object containers" also needs to be
fixed (or I don't understand it):
"Now that we know how to inspect set the properties of a given object
Jae-Joon Lee wrote:
>> - the parameter numpoints should be used (it's ignored right now)
>>
>
> Thanks Manuel. I guess we can simply reuse xdata_marker for this purpose.
>
>
>> - Some private variables are accessed and a new RegularPolycollection is
>> created (does this work eg. with a StarPoly
John Hunter wrote:
> On Wed, Oct 8, 2008 at 10:27 PM, Erik Tollerud <[EMAIL PROTECTED]> wrote:
>> Ah, that makes more sense Jae-Joon - thanks!
>
> Jae-Joon -- could you handle this patch submission?
>
> Thanks,
> JDH
Hi,
I also had a look at this patch -- as that's a feature I was
interested i
Hi Mike,
I just stumbled over this bug report (#2126188) on sourceforge. This
seems to appear in version 5471, committed by you.
Manuel
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Buil
Hi all,
I think I have finally found a nice way to implement step-plots with
different linestyles. The way this is done required some re-writing of
lines.py, but I think it is done in a consistent manner:
A new property *drawstyle* is introduced. By default this just
connects the datapoints by
> Hi,
>I think there is bug in get_xticklabels(). According to the doc it
> should return a list of Text instances, instead it returns a list of
> TextWithDash instances. This also makes the following impossible (which
> should work of course):
>
> xtl = ax.get_xticklabels()
> ax.set_xtickl
Hi,
I think there is bug in get_xticklabels(). According to the doc it
should return a list of Text instances, instead it returns a list of
TextWithDash instances. This also makes the following impossible (which
should work of course):
xtl = ax.get_xticklabels()
ax.set_xticklabels(xtl)
Manu
Manuel Metz wrote:
> Hi all,
> I ran into a problem where I wanted to plot a step-plot with dashed
> lines instead of solid lines which can be important for print media.
> This isn't possible with the current matplotlib version, so I added
> support for this. The patc
Hi all,
I ran into a problem where I wanted to plot a step-plot with dashed
lines instead of solid lines which can be important for print media.
This isn't possible with the current matplotlib version, so I added
support for this. The patch is attached, but I didn't commit it yet
since I wan
Hi,
I just committed a patch that allows for multiple histogram where each
data-set might have a different length (see example
histogram_demo_extended.py). I don't think that it breaks any existing
code, but I would feel much better if someone could check that ...
Manuel
--
John Hunter wrote:
> On Wed, Aug 6, 2008 at 8:51 AM, Manuel Metz <[EMAIL PROTECTED]> wrote:
>
>> I think the section Controlling axes properties of
>> http://matplotlib.sourceforge.net/tutorial.html needs to be updated, since
>>
>> frame = gca(gca(),
Hi,
I think the section Controlling axes properties of
http://matplotlib.sourceforge.net/tutorial.html needs to be updated, since
frame = gca(gca(), 'frame')
setp(frame, 'linewidth', 2)
doesn't work any more with mpl 0.98.x ...
Manuel
[ 2008303 ] AttributeError: Unknown property histtype
I think this bug can be closed.
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK
Paul Kienzle wrote:
> On Thu, Jul 17, 2008 at 08:50:03AM +0200, Manuel Metz wrote:
>> Just because the discussion about clabel started, I want to post a short
>> snipplet of code that I found useful. It was some sort of hack to get a
>> nicer float formating for co
John Hunter wrote:
> On Wed, Jul 16, 2008 at 7:20 AM, David M. Kaplan <[EMAIL PROTECTED]> wrote:
>
> Thanks for the submission -- I await more informed commentary from
> those who actually use contouring
>
Just because the discussion about clabel started, I want to post a short
snipplet of
Andrew Hawryluk wrote:
> Hopefully this isn't old news for you. Since the 0.98 release, the histogram
> plot doesn't work properly with 2D arrays: it is quite slow and the output is
> wrong. Passing a flattened array produces the quick, correct output that we
> are accustomed to. Here is the tes
Darren Dale wrote:
>
> On Monday 30 June 2008 10:40:27 Darren Dale wrote:
>> On Monday 30 June 2008 09:06:59 am John Hunter wrote:
>>> On Mon, Jun 30, 2008 at 7:10 AM, Michael Droettboom <[EMAIL PROTECTED]>
> wrote:
Hate to say "me too", but I don't really understand text with dash
eith
John Hunter wrote:
> Manuel and Michael worked on fixing a bug with TextWithDash, but this
> introduced a bug will all tick labels so I reverted the changes. The
> problem is that the text layout code in Text (eg draw,
> get_window_extent) is using "get_position" which in TextWithDash is
> the das
Hi,
just want to point to a bug (2002836) reported on sourceforge.
I could track this a little bit more down and found that a subscript
like r'x_{\leftarrow}' fails, whereas r'x_\leftarrow' works (!); also
fails e.g. for r'x_{\leftrightarrow}'. Anything that starts with \right
or \Left wo
Olle Engdegård wrote:
> hist(histtype="step") worked fine in rev5412, but in the latest I get
>
hist(randn(1000), histtype="step")
> Traceback (most recent call last):
> /.../
> raise TypeError, 'There is no patch property "%s"'%key
> TypeError: There is no patch property "closed"
>
>
Chris Walker wrote:
> "John Hunter" <[EMAIL PROTECTED]> writes:
>
>> On Fri, Jun 13, 2008 at 9:25 AM, Chris Walker
>> <[EMAIL PROTECTED]> wrote:
>>
So if we want to support stable, *and*
the latest releases, we've got a lot of ongoing compatibility work to
do. For backend maintaine
John Hunter wrote:
> On Fri, Jun 13, 2008 at 7:40 AM, Manuel Metz <[EMAIL PROTECTED]> wrote:
>
>> Paul Novak had planed to work on scatter legend and I am also interested in
>> this, so we came up with a code fragment, but it doesn't do the job well. I
>> thin
John Hunter wrote:
> On Thu, Jun 12, 2008 at 8:56 PM, T J <[EMAIL PROTECTED]> wrote:
>> I am making a scatter plot and want the legend to display the symbols.
>> This functionality doesn't seem to exist, so I have followed the
>> workaround outlined here:
>>
>> http://www.nabble.com/Legend-for-a-s
When looking, e.g. at axes.py, I see 3 different arguments passed to
numpy astype()/array()/zero() and friends:
x = np.asarray(x).astype(np.float32)
x = np.zeros( x, np.float_ )
x = np.ones((col,), float)
Is there a preferred one to stick to ?!
Manuel
---
Olle Engdegård wrote:
> Hi,
>
> Some more thoughts about hist():
>
> A "range" parameter should be added and used in histogram()
Hi Olle,
what do you mean by "range" parameter. What should this parameter
actually do ?
I just committed a patch to the trunk that adds the features as you
a
Michael Droettboom wrote:
> Thanks. I have fixed 1), and added a "closed" kwarg to fill() and
> Polygon.__init__() (which defaults to True to mimic behavior of 0.91 and
> earlier). hist() has been updated to call fill() with closed=False.
>
> Cheers,
> Mike
Great - thanks. So, I committed a p
could be added to API_CHANGES,
>>>>> as well as to the Axes.fill docstring.
>>>>>
>>>>> Does anyone know how Matlab, IDL, etc. handle this?
>>>> Here is the Matlab help text; matlab does automatically close the
>>>> polygons:
Erik Tollerud wrote:
> While going through and updating some scripts to use the new features
> that were recently added to hist(), I found myself very confused by
> the align keywords - I had to go and look at Manuel Metz's post a
> couple weeks ago to believe it wasn't a typo in the documentation.
John Hunter wrote:
> On Sat, May 24, 2008 at 6:02 PM, Olle Engdegård <[EMAIL PROTECTED]> wrote:
>
>> I very much miss the 'l' shortcut for toggling log/lin y-scale in the
>> trunk! I use it a lot.
>>
>> I suggest restoring it with something like
>>
>> if self.get_yscale() is ("log" or "linear"):
>
Dear all,
as there was no disagreeing feedback ;-) I continued my work on the
hist() method. I just committed a patch with some major re-writing of
the hist() method to the trunk. I personally think it is very useful.
hist() now
- supports 2D input data (i.e. multiple data, but not yet l
Hi,
I had one or two more looks at the hist() function. There are a few
things I wondered about:
(I) Isn't it more intuitive to interpret the "width" keyword as "width
relative to the real width of a bin" rather than as an absolute value ?
Here is an example, why I think so: Say I want to c
Erik Tollerud wrote:
> It'd be nice to get this into the new release unless it has been
> somehow fixed by some other code path in the latest svn... the line
> numbers on the diff are no longer accurate, but the idea is still the
> same - just change all lines of the form
>
> caplines.extend( self
ctually does).
Manuel
> thanks,
> Johann
>
> Manuel Metz wrote:
>> Eric Firing wrote:
>>
>>> John Hunter wrote:
>>>
>>>> On Wed, Apr 2, 2008 at 6:39 PM, Erik Tollerud <[EMAIL PROTECTED]> wrote:
>>>>
>>>>
Eric Firing wrote:
> Manuel Metz wrote:
>> Hi,
>>while adding the step-histogram I learned about the change of
>> numpy.histogram. As MPL trunk relies in numpy 1.1, I think its a good
>> idea to switch to the new histogram, i.e. use "new=True". Indee
Here's the link to the numpy wiki:
http://projects.scipy.org/scipy/numpy/roadmap#Semanticchangeforhistogram
Manuel Metz wrote:
> Hi,
>while adding the step-histogram I learned about the change of
> numpy.histogram. As MPL trunk relies in numpy 1.1, I think its a good
>
Hi,
while adding the step-histogram I learned about the change of
numpy.histogram. As MPL trunk relies in numpy 1.1, I think its a good
idea to switch to the new histogram, i.e. use "new=True". Indeed, this
is required to be able to allow to give bin-edges, which is possible
with MPL 0.91.
Eric Firing wrote:
> John Hunter wrote:
>> On Wed, Apr 2, 2008 at 6:39 PM, Erik Tollerud <[EMAIL PROTECTED]> wrote:
>>
>>> are slightly different). There's a slight compatibility issue in that
>>> as it stands in that the returned tuple now has 4 values (I added a
>>> list of the lines that are
Erik Tollerud wrote:
> No one thinks this is worth committing to SVN? I find myself using it
> quite a bit in my own work - different fields have different ideas
> about the "right" way to draw a histogram, so it's good to have
> options, I think...
>
> On Wed, Apr 2, 2008 at 4:39 PM, Erik Toller
Hi,
I have fixed the double-zoom Bug in the trunk (revision 5053), but
not in the 0_91maint branch. In 0.91 it's not so easy to find out
whether an axes is shared with another (cbook:Group is nice ;-) ) For
0.91: is it always guaranteed that the release_zoom event for the master
is called b
Manuel Metz wrote:
Paul Smith wrote:
I'm plotting two curves in one subplot with twinx to allow different y
scales. The script below is an example. When zooming in using
zoom-to-rect on Tk's navigation toolbar2 (TkAgg is my backend) I think
the x axis part of the zoom is happe
Paul Smith wrote:
I'm plotting two curves in one subplot with twinx to allow different y scales.
The script below is an example.
When zooming in using zoom-to-rect on Tk's navigation toolbar2 (TkAgg is my
backend) I think the x axis part of the zoom is happening twice. Rubberbanding
the exampl
John Hunter wrote:
> On Thu, Apr 3, 2008 at 8:40 AM, Manuel Metz <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> in matplotlib 0.91 there was a function draw_point for the backends.
>> This seems to be gone (except for backend_agg2.py and backend_emf.py
>>
Hi,
in matplotlib 0.91 there was a function draw_point for the backends.
This seems to be gone (except for backend_agg2.py and backend_emf.py
!?). I guess it wasn't used very often; instead I see that there is now
a function draw_point in lines.py. Is it possible to re-add this
functionality t
Hello,
I have attached a patch that addresses the following:
plot accepts the linestyles arguments '-','--','-.',':' [+ some more]
and the Collection class accepts the
linestyle arguments 'solid','dashed','dashdot','dotted'.
This patch allows to use both notations. A test script is attached
x27;+' and 'x' markers which is missing.
Manuel
Manuel Metz wrote:
Happend with your commit from version 4979 -> 4989. Who's going to fix
that ? Whom can I directly contact ?
Original Message
Subject: [matplotlib-devel] axes.py scatter doc-bug
Date: Wed
Paul Novak wrote:
> A few weeks ago there was a discussion about putting scatter symbols in
> the legend (see
> http://www.nabble.com/Show-shapes-on-scatterplot-legend--to15744380.html).
>
> I would like to implement scatter symbols in the legend, but I am having
> some problems doing so. In th
Happend with your commit from version 4979 -> 4989. Who's going to fix
that ? Whom can I directly contact ?
Original Message
Subject: [matplotlib-devel] axes.py scatter doc-bug
Date: Wed, 12 Mar 2008 12:30:12 +0100
From: Manuel Metz <[EMAIL PROTECTED]>
To: ma
Hi,
the doc-string of the axes scatter method is buggy. Somehow the
svn-conflict messages got committed to the repository:
I mean this
<<< .working
[...]
===
[...]
>>> .merge-right.r4987
... stuff)
Manuel
-
T
Erik Tollerud wrote:
> I use the scatter(x,y) command to make scatter plots, but I noticed
> today (on the SVN version of mpl) that when I call legend() after
> giving scatter(x,y,label='somelabel') , the legend doesn't show the
> marker symbols - it only has a square patch colored in the color th
Hi,
might I ask again whether anyone can attend to update the doc-string of
the scatter function ?
Manuel
Manuel Metz wrote:
There was a question on the matplotlib-users list about symbols in
[snip]
Btw: shouldn't the
"verts" keyword be removed, since marker=(verts,0
There was a question on the matplotlib-users list about symbols in
scatter, that made me realize that the new "marker = (5,0)" ... syntax,
that I contributed some time ago, were not documented. So I tried to
write a doc string.
Can anyone please check this and add the patch? Btw: shouldn't the
Hi all,
I find the usage of linestyle very _unconvenient_, since there are these
two options - linestyle='--' and linestyle='dashed' - which are not
exchangable.
I had some code where I initially used the Line2D class, so I had to use
linestyle='--'. Now I changed my code to use a LineCollectio
Michael Droettboom wrote:
> Manuel Metz wrote:
>> Hi,
>> I figured out a bug in the FancyArrow class (sorry, I didn't track it
>> down, yet). Might be related to my strange axes limits ?
>>
>> Please have a look at the attached example. As you can see,
Hi,
I figured out a bug in the FancyArrow class (sorry, I didn't track it
down, yet). Might be related to my strange axes limits ?
Please have a look at the attached example. As you can see, in the lower
panel the head is not rendered correctly.
I used the lates svn, revision 4730.
Manuel
Found the same bug, which is a
"""
try:
except:
finally:
"""
clause, which is not allowed ;-)
Nils Wagner wrote:
> Hi all,
>
> python setup.py install --prefix=$HOME/local
> results in
>
> font_manager.py", line 115
> finally:
>^
> SyntaxError: invalid syntax
>
> Nils
>
> I
Hi,
attached is a patch for contour.py against latest svn that adds support
for the keyword "linestyles" for contour plots. Could someone commit
that to svn?
Manuel
Index: contour.py
===
--- contour.py (revision 4093)
+++ contour.
Darren Dale wrote:
> On Friday 19 October 2007 10:20:43 am John Hunter wrote:
>> On 10/19/07, Darren Dale <[EMAIL PROTECTED]> wrote:
>>> I don't remember how to find the answer. It looks like scatter() creates
>>> polygons, while plot() uses draw_markers:
>> I see -- scatter uses collections, and
There is a minor bug in line 852 in patches.py
verbose.report('patches.Ellipse renderer ...
This has to be
mpl.verbose.report('patches.Ellipse renderer ...
Manuel
-
This SF.net email is sponsored by: Spl
Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
--
---
Manuel Metz [EMAIL PROTECTED]
Argelander Institut fuer Astronomie
Auf dem Huegel 71 (room
.
The errorbar docstring will need to be modified to explain the new
kwargs. Additional comments are interspersed below.
>
Manuel Metz wrote:
Hello,
I have attached a patch that adds the ability to draw upper/lower
limits indicators for errorbars. New keyword args had to be introduced
to
ded (boilerplate.py?)
Manuel
Eric Firing wrote:
Manuel Metz wrote:
May I ask again: Is there any interest in a step-plotting function?
Yes, so thanks for taking the initiative and for being persistent.
If so, who will commit the patch? Do I have to add more myself
(documentation for sure needs
May I ask again: Is there any interest in a step-plotting function?
If so, who will commit the patch? Do I have to add more myself
(documentation for sure needs to be added, what else ?)
Manuel
Manuel Metz wrote:
> Hi,
> okay, I have added a keyword 'where' as suggested. I
d - but the way the patch was written, I don't think it will
support anything but float (especially not the unit types).
Eric
Ted
At 07:59 AM 8/14/2007, Manuel Metz wrote:
Hi,
I have created a patch against latest svn that adds a function step
to the axes class to plot step-functions
Hi,
I have created a patch against latest svn that adds a function step to
the axes class to plot step-functions ;-) It's really simple but nice
... Any interest in adding this?
Manuel
<>Index: axes.py
===
--- axes.py (revision
e above wished might be implemented?
Manuel
--
---
Manuel Metz [EMAIL PROTECTED]
Argelander Institut fuer Astronomie
Auf dem Huegel 71 (room 3.06)
D - 53121 Bonn
E-Mail: [EMAIL PROTECTED]
Web:www.astro.uni-bonn.de/~mmetz
e.
>
> I think the best fix would be in both, matplotlib and inkscape.
> matplotlib has no need to put the definitions inside the group and can
> simply avoid that, but still inkscape should cope with this kind of
> (legal!) SVG code in a better way.
>
>
>
> Manuel Met
--
---
Manuel Metz [EMAIL PROTECTED]
Argelander Institut fuer Astronomie
Auf dem Huegel 71 (room 3.06)
D - 53121 Bonn
E-Mail: [EMAIL PROTECTED]
Web:www.astro.uni-bonn.de/~mmetz
Phone: (+49) 228 / 73-3660
Fax:(+49) 228 / 73-3672
d be a major advance. I thought ubuntu
>> was better about keeping up with current releases.
>
> Edgy appears to be offering 0.87.5, which is not quite so bad. I have
> no idea what will happen in Feisty, however.
Yes, matplotlib version in edgy is 0.87.5, in feisty it is 0.87.7
May I ask again for hints ???
> However, there is problem with the asterisk symbols I'm not sure how to
> solve, and I ask for your advice!!! As you can see in the attached
> example output, custom_symbol2a.png, the length of the arms of the
> asterisk-symbol appear different even so have numerica
Hi,
I'm not quite sure, but I think there is a bug in backend_agg.py in the
function draw_point(). I got an error when trying to use this function,
and the attached patch fixed the problem. As you can see, it seems that
there is just a parameter (rotation) missing.
Manuel
Index: backend_agg.py
=
reads:
if marker is None and not (verts is None):
^^
I've attached a patch... I apologize again ...
Manuel
Manuel Metz wrote:
> John Hunter wrote:
>>>>>>>>>>>>> "Manuel" == Manuel Metz <[EMAIL PROTECTED]> wri
John Hunter wrote:
>>>>>> >>>>>> "Manuel" == Manuel Metz <[EMAIL PROTECTED]> writes:
> >
> > Manuel> There is a subtle but essential difference ;-) : for i in
> > Manuel> xrange(1,len(r), 2 ) ^^^ , i.e. ev
John Hunter wrote:
>>>>>> "Manuel" == Manuel Metz <[EMAIL PROTECTED]> writes:
>
> Manuel> There is a subtle but essential difference ;-) : for i in
> Manuel> xrange(1,len(r), 2 ) ^^^ , i.e. every second value gets
> Manuel> r
John Hunter wrote:
>>>>>> "Manuel" == Manuel Metz <[EMAIL PROTECTED]> writes:
>
> Manuel> Argh - okay - this is a mistranslation from german to
> Manuel> english - sorry. I wanted to say "starlike". So probably
> Man
John Hunter wrote:
>>>>>> "Manuel" == Manuel Metz <[EMAIL PROTECTED]> writes:
>
> Manuel> Hi, I just submitted a patch to sourceforge and also
> Manuel> attached it to this email:
>
> Manuel> The applied patch m
Hi,
first of all "scatter_custom_symbol.py" is great ! I really like this.
But...
May I express some idea/suggestions concerning custom symbols:
I came from supermongo to matplotlib. And I liked the way you could
define symbols in supermongo:
PTYPE n s
where "s" gives the style of the symbol:
99 matches
Mail list logo
