matplotlib-devel Mailing List for matplotlib (Page 6)

On Wednesday 15 October 2008 04:59:28 pm John Hunter wrote:
> I just took the plunge and pushed the beta website live. We are now
> purely driven off the sphinx living in the doc dir.
It looks great, really nice work guys. Sorry I havent been able to keep up 
with the list recently, unfortunately its unlikely to change for a while.
I noticed that the PDF download link at 
http://matplotlib.sourceforge.net/contents.html is broken.
Darren

I see most of your points and the current version is definitely better
in many respects... I had originally tried to update the collections
rather than make new ones, but didn't understand enough of the
internals to implement the update_from method.
But regarding the size variation... I think the size variation is
important because, in my view, the purpose of the legend for a scatter
plot is to as accurately as possible reflect the data represented. I
have certainly seen plots where there are two sets of symbols, one of
which ranges over a bunch of sizes, and others that are uniform. If
they appear almost the same on the legend, it takes much more time to
figure out which is which, especially in cases where most of the
symbols are small (so that the shape and color are somewhat harder to
see). The eye is very good at picking out gross features in size
variation, and I think that's important. I'm not totally stuck on it
(I was somewhat dissatisfied in the initial implementation in that if
you have very big or very small symbols, the legend is difficult to
read... I meant to implement some smarter scaling of the legend but
wanted to see what other people thought before doing that work).
As for the y-offsets... The main justification there is to distinguish
scatter plots from line plots that just aren't joining the points
together. I personally have made plots where one set of data is best
represented as data points with a trend, but it also makes sense to
overlay a scatter plot of data on top of it. In that case, seeing
data that appear "scattered" in the legend helps clarify the
distinction between the two sets of data.
So while I like most of the changes, I still think the y offsets and
size variation should at least be an option (and I personally would
want them on by default), although I am much more attached to the
y-offsets than the size issue. Your thoughts?
On Thu, Oct 16, 2008 at 4:43 AM, Manuel Metz <mm...@as...> wrote:
> 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 impression is that update_from
>>> method is to update gc related attributes. For comparison,
>>> Patch.update_from() does not update the path.
>>
>> That's exactly the point why I wasn't fully happy with the patch. The
>> path is generated by the _path_generator, so instead of copying the path
>> it seems to be better to create an instance of the corresponding class
>> (e.g. the StarPolygonCollection class, as suggested before).
>>
>> One should update the rotation attribute (!!); it's only one number. A
>> '+' marker, for example, has rotation = 0, whereas a 'x' marker has
>> rotation=pi/4. That's the only difference between those two !
>>
>>> Also, is it okay to update properties without checking its length?. It
>>> does not seem to cause any problems though.
>>
>> It's in principal not a problem to copy the sizes attribute without
>> checking the length. If it's shorter the the number of items the sizes
>> are repeated; if it's longer it gets truncated.
>>
>> mm
>>
>>> I guess It would better to use xdata_markers than xdata in the
>>> get_handle() method. The difference is when numpoints==1. Using xdata
>>> gives two marker points.
>>>
>>> I was actually about to to commit my patch. I'll try to account your
>>> changes and post my version of patch later today.
>>>
>>> Regards,
>>>
>>> -JJ
>>>
>>>
>>>
>>>
>>> On Wed, Oct 15, 2008 at 4:07 PM, Manuel Metz <mm...@as...> wrote:
>>>> hmm
>>>>
>>>> -------- Original Message --------
>>>> 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 StarPolygonCollection? I haven't
>>>>>> checked, but I don't think so !). Instead of creating a new
>>>>>> RegularPolyCollection it might be more useful to make a copy of the
>>>>>> existing object... I was thinking about a update_from() method for the
>>>>>> Collection class(es) similar to update_from() for lines.
>>>>>>
>>>>> By changing "RegularPolyCoolection" to "type(handles)", it works for
>>>>> StarPolygonCollection.
>>>>>
>>>>> In Erik's current implementation, the markers in the legend have
>>>>> varying colors, sizes, and y offsets.
>>>>> The color variation seems fine. But do we need to vary the sizes and
>>>>> y-offsets? My inclination is to use a fixed size (median?) and a fixed
>>>>> y offset. How does Erik and others think?
>>>>>
>>>>> Regards,
>>>>>
>>>>> -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
>>>>
>
> Hi Jae-Joon,
> so here is my revised version of the patch. What do you think ?
>
> Manuel
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
-- 
Erik Tollerud
Graduate Student
Center For Cosmology
Department of Physics and Astronomy
2142 Frederick Reines Hall
University of California, Irvine
Office Phone: (949)824-2587
Cell: (651)307-9409
eto...@uc...

Manuel,
Although it doesn't hurt, I don't think it is worthwhile changing range 
to xrange. From the 2.5 docs:
xrange( [start,] stop[, step])
 This function is very similar to range(), but returns an ``xrange 
object'' instead of a list. This is an opaque sequence type which yields 
the same values as the corresponding list, without actually storing them 
all simultaneously. The advantage of xrange() over range() is minimal 
(since xrange() still has to create the values when asked for them) 
except when a very large range is used on a memory-starved machine or 
when all of the range's elements are never used (such as when the loop 
is usually terminated with break).
Note "minimal" advantage. xrange was intended for special-case use, not 
general use.
And from Python 3.0, http://docs.python.org/dev/3.0/whatsnew/3.0.html
xrange() renamed to range(), so range() will no longer produce a list 
but an iterable yielding integers when iterated over.
This implies to me that range is the preferred form, and xrange is 
intended to go away.
Eric
mme...@us... wrote:
> Revision: 6217
> http://matplotlib.svn.sourceforge.net/matplotlib/?rev=6217&view=rev
> Author: mmetz_bn
> Date: 2008年10月16日 11:15:25 +0000 (2008年10月16日)
> 
> Log Message:
> -----------
> minor optimizations: replacing range by xrange in for loops
> 
> Modified Paths:
> --------------
> trunk/matplotlib/lib/matplotlib/axes.py
> 
> Modified: trunk/matplotlib/lib/matplotlib/axes.py
> ===================================================================
> --- trunk/matplotlib/lib/matplotlib/axes.py	2008年10月15日 20:53:09 UTC (rev 6216)
> +++ trunk/matplotlib/lib/matplotlib/axes.py	2008年10月16日 11:15:25 UTC (rev 6217)
> @@ -243,7 +243,7 @@
> x, y, multicol = self._xy_from_y(y)
> 
> if multicol:
> - for j in range(y.shape[1]):
> + for j in xrange(y.shape[1]):
> color = self._get_next_cycle_color()
> seg = mlines.Line2D(x, y[:,j],
> color = color,
> @@ -285,7 +285,7 @@
> ret.append(seg)
> 
> if multicol:
> - for j in range(y.shape[1]):
> + for j in xrange(y.shape[1]):
> makeline(x[:,j], y[:,j])
> else:
> makeline(x, y)
> @@ -324,7 +324,7 @@
> closed = kwargs.get('closed', True)
> func = makefill
> if multicol:
> - for j in range(y.shape[1]):
> + for j in xrange(y.shape[1]):
> func(x[:,j], y[:,j])
> else:
> func(x, y)
> @@ -372,7 +372,7 @@
> func = makefill
> 
> if multicol:
> - for j in range(y.shape[1]):
> + for j in xrange(y.shape[1]):
> func(x[:,j], y[:,j])
> else:
> func(x, y)
> @@ -3897,9 +3897,9 @@
> pass
> elif align == 'center':
> if orientation == 'vertical':
> - left = [left[i] - width[i]/2. for i in range(len(left))]
> + left = [left[i] - width[i]/2. for i in xrange(len(left))]
> elif orientation == 'horizontal':
> - bottom = [bottom[i] - height[i]/2. for i in range(len(bottom))]
> + bottom = [bottom[i] - height[i]/2. for i in xrange(len(bottom))]
> 
> else:
> raise ValueError, 'invalid alignment: %s' % align
> @@ -4571,7 +4571,7 @@
> elif nc == 1:
> x = [x.ravel()]
> else:
> - x = [x[:,i] for i in range(nc)]
> + x = [x[:,i] for i in xrange(nc)]
> else:
> raise ValueError, "input x can have no more than 2 dimensions"
> if not hasattr(x[0], '__len__'):
> @@ -4665,7 +4665,7 @@
> else:
> def doplot(*args):
> shuffled = []
> - for i in range(0, len(args), 3):
> + for i in xrange(0, len(args), 3):
> shuffled.extend([args[i+1], args[i], args[i+2]])
> return self.plot(*shuffled)
> 
> 
> 
> This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-checkins mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-checkins

On Oct 13, 2008, at 4:59 PM, Anne Archibald wrote:
> but I have written a simple line
> integral convolution operator I'd be happy to contribute.
Anne-
I would be interested in seeing the code, regardless of where it finds 
a home.
Would you mind sharing, or would you rather wait?
-Rob
----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331

> Eric Firing wrote:
>
> Andrew Hawryluk wrote:
>> The interpolation algorithm used in imshow() can produce spurious 
>> results, as has been noted before:
>> 
>> _http://article.gmane.org/gmane.comp.python.matplotlib.general/12062_
>> 
>> This happens because the data is converted to RGB before the 
>> interpolation/resampling, rather than after. How hard would it be to 
>> reverse this so that the data array is first interpolated & resampled
>> and then converted by cmap to RGB?
>
> To me, it looks very hard. The color mapping is done first, in
python, and not repeated with
> every draw. The interpolation is done by agg at rendering time.
Logically, I don't know any
> reason why agg shouldn't do what you suggest: interpolate the scalar
field and then convert
> to rgb.
> Maybe agg can do it this way. If so, it would still take quite a
bit of work by someone
> comfortable with agg (i.e., not me) to make the change.
>
> Eric
Ah, that is certainly more difficult that what I would be prepared to
attempt, which is unfortunate because it would greatly improve the
output and reduce the interpolation's computation by a factor of three
(RGB).
Until someone feels up to the challenge, I will just add a manual
interpolation step when necessary for my data. e.g.:
import matplotlib.pyplot as p
import numpy as n
import scipy.ndimage
a = n.random.normal(size=(10,10))
p.imshow(a,interpolation='nearest') # the actual data
p.figure()
p.imshow(a,interpolation='bicubic') # an AGG interpolation of the RGB
values
b = scipy.ndimage.zoom(a,25)[:-24,:-24]
p.figure()
p.imshow(b) # the data interpolated at 25x magnification with a cubic
spline
Thanks for the information,
Andrew

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 impression is that update_from
>> method is to update gc related attributes. For comparison,
>> Patch.update_from() does not update the path.
> 
> That's exactly the point why I wasn't fully happy with the patch. The
> path is generated by the _path_generator, so instead of copying the path
> it seems to be better to create an instance of the corresponding class
> (e.g. the StarPolygonCollection class, as suggested before).
> 
> One should update the rotation attribute (!!); it's only one number. A
> '+' marker, for example, has rotation = 0, whereas a 'x' marker has
> rotation=pi/4. That's the only difference between those two !
> 
>> Also, is it okay to update properties without checking its length?. It
>> does not seem to cause any problems though.
> 
> It's in principal not a problem to copy the sizes attribute without
> checking the length. If it's shorter the the number of items the sizes
> are repeated; if it's longer it gets truncated.
> 
> mm
> 
>> I guess It would better to use xdata_markers than xdata in the
>> get_handle() method. The difference is when numpoints==1. Using xdata
>> gives two marker points.
>>
>> I was actually about to to commit my patch. I'll try to account your
>> changes and post my version of patch later today.
>>
>> Regards,
>>
>> -JJ
>>
>>
>>
>>
>> On Wed, Oct 15, 2008 at 4:07 PM, Manuel Metz <mm...@as...> wrote:
>>> hmm
>>>
>>> -------- Original Message --------
>>> 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 StarPolygonCollection? I haven't
>>>>> checked, but I don't think so !). Instead of creating a new
>>>>> RegularPolyCollection it might be more useful to make a copy of the
>>>>> existing object... I was thinking about a update_from() method for the
>>>>> Collection class(es) similar to update_from() for lines.
>>>>>
>>>> By changing "RegularPolyCoolection" to "type(handles)", it works for
>>>> StarPolygonCollection.
>>>>
>>>> In Erik's current implementation, the markers in the legend have
>>>> varying colors, sizes, and y offsets.
>>>> The color variation seems fine. But do we need to vary the sizes and
>>>> y-offsets? My inclination is to use a fixed size (median?) and a fixed
>>>> y offset. How does Erik and others think?
>>>>
>>>> Regards,
>>>>
>>>> -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
>>>
Hi Jae-Joon,
 so here is my revised version of the patch. What do you think ?
Manuel

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 impression is that update_from
> method is to update gc related attributes. For comparison,
> Patch.update_from() does not update the path.
That's exactly the point why I wasn't fully happy with the patch. The
path is generated by the _path_generator, so instead of copying the path
 it seems to be better to create an instance of the corresponding class
(e.g. the StarPolygonCollection class, as suggested before).
 One should update the rotation attribute (!!); it's only one number. A
'+' marker, for example, has rotation = 0, whereas a 'x' marker has
rotation=pi/4. That's the only difference between those two !
> Also, is it okay to update properties without checking its length?. It
> does not seem to cause any problems though.
 It's in principal not a problem to copy the sizes attribute without
checking the length. If it's shorter the the number of items the sizes
are repeated; if it's longer it gets truncated.
mm
> I guess It would better to use xdata_markers than xdata in the
> get_handle() method. The difference is when numpoints==1. Using xdata
> gives two marker points.
> 
> I was actually about to to commit my patch. I'll try to account your
> changes and post my version of patch later today.
> 
> Regards,
> 
> -JJ
> 
> 
> 
> 
> On Wed, Oct 15, 2008 at 4:07 PM, Manuel Metz <mm...@as...> wrote:
>> hmm
>>
>> -------- Original Message --------
>> 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 StarPolygonCollection? I haven't
>>>> checked, but I don't think so !). Instead of creating a new
>>>> RegularPolyCollection it might be more useful to make a copy of the
>>>> existing object... I was thinking about a update_from() method for the
>>>> Collection class(es) similar to update_from() for lines.
>>>>
>>> By changing "RegularPolyCoolection" to "type(handles)", it works for
>>> StarPolygonCollection.
>>>
>>> In Erik's current implementation, the markers in the legend have
>>> varying colors, sizes, and y offsets.
>>> The color variation seems fine. But do we need to vary the sizes and
>>> y-offsets? My inclination is to use a fixed size (median?) and a fixed
>>> y offset. How does Erik and others think?
>>>
>>> Regards,
>>>
>>> -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
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>

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 impression is that update_from
method is to update gc related attributes. For comparison,
Patch.update_from() does not update the path.
Also, is it okay to update properties without checking its length?. It
does not seem to cause any problems though.
I guess It would better to use xdata_markers than xdata in the
get_handle() method. The difference is when numpoints==1. Using xdata
gives two marker points.
I was actually about to to commit my patch. I'll try to account your
changes and post my version of patch later today.
Regards,
-JJ
On Wed, Oct 15, 2008 at 4:07 PM, Manuel Metz <mm...@as...> wrote:
> hmm
>
> -------- Original Message --------
> 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 StarPolygonCollection? I haven't
>>> checked, but I don't think so !). Instead of creating a new
>>> RegularPolyCollection it might be more useful to make a copy of the
>>> existing object... I was thinking about a update_from() method for the
>>> Collection class(es) similar to update_from() for lines.
>>>
>>
>> By changing "RegularPolyCoolection" to "type(handles)", it works for
>> StarPolygonCollection.
>>
>> In Erik's current implementation, the markers in the legend have
>> varying colors, sizes, and y offsets.
>> The color variation seems fine. But do we need to vary the sizes and
>> y-offsets? My inclination is to use a fixed size (median?) and a fixed
>> y offset. How does Erik and others think?
>>
>> Regards,
>>
>> -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
>
>
> --
> ---------------------------------------
> Manuel Metz ............ Stw@AIfA
> Argelander Institut fuer Astronomie
> Auf dem Huegel 71 (room 3.06)
> D - 53121 Bonn
>
> E-Mail: mm...@as...
> Web: www.astro.uni-bonn.de/~mmetz
> Phone: (+49) 228 / 73-3660
> Fax: (+49) 228 / 73-3672
> ---------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Andrew Hawryluk wrote:
> The interpolation algorithm used in imshow() can produce spurious 
> results, as has been noted before:
> 
> _http://article.gmane.org/gmane.comp.python.matplotlib.general/12062_
> 
> This happens because the data is converted to RGB before the 
> interpolation/resampling, rather than after. How hard would it be to 
> reverse this so that the data array is first interpolated & resampled 
> and then converted by cmap to RGB?
To me, it looks very hard. The color mapping is done first, in python, 
and not repeated with every draw. The interpolation is done by agg at 
rendering time. Logically, I don't know any reason why agg shouldn't do 
what you suggest: interpolate the scalar field and then convert to rgb. 
 Maybe agg can do it this way. If so, it would still take quite a bit 
of work by someone comfortable with agg (i.e., not me) to make the change.
Eric

The interpolation algorithm used in imshow() can produce spurious
results, as has been noted before:
http://article.gmane.org/gmane.comp.python.matplotlib.general/12062
This happens because the data is converted to RGB before the
interpolation/resampling, rather than after. How hard would it be to
reverse this so that the data array is first interpolated & resampled
and then converted by cmap to RGB?
Andrew Hawryluk

On Wed, Oct 15, 2008 at 4:04 PM, Andrew Straw <str...@as...> wrote:
> Dang that looks good. The only glitches that I see are:
>
> 1) after the ">>> hist(x, 100)""" line in the Python pre-formatted text
> box, there's an extra line's worth of vertical space.
>
> 2) The heading "Plotting commands" overlaps slightly with the top line
> of the following table.
>
> This is on Firefox 3 with Ubuntu 8.04.
I'm seeing that too -- added a couple of hacks to fix it
JDH

Dang that looks good. The only glitches that I see are:
1) after the ">>> hist(x, 100)""" line in the Python pre-formatted text
box, there's an extra line's worth of vertical space.
2) The heading "Plotting commands" overlaps slightly with the top line
of the following table.
This is on Firefox 3 with Ubuntu 8.04.
-Andrew
John Hunter wrote:
> I just took the plunge and pushed the beta website live. We are now
> purely driven off the sphinx living in the doc dir.
> 
> There is still plenty of material from the old site (stuff from the
> FAQ, the credits, stuff from the user's guide, goals/known issues) so
> once again please feel free to contribute. It's much easier now that
> it is plain rest and sphinx. One area where all developers can easily
> contribute is by extending the FAQ when we get common questions on the
> mailing lists. I would also really like to see sections on contours,
> images and colormaps, colorbars, time series plotting (eg the spectral
> stuff), collections....
> 
> http://matplotlib.sourceforge.net
> 
> Let me know if you find any problems.
> 
> JDH
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I just took the plunge and pushed the beta website live. We are now
purely driven off the sphinx living in the doc dir.
There is still plenty of material from the old site (stuff from the
FAQ, the credits, stuff from the user's guide, goals/known issues) so
once again please feel free to contribute. It's much easier now that
it is plain rest and sphinx. One area where all developers can easily
contribute is by extending the FAQ when we get common questions on the
mailing lists. I would also really like to see sections on contours,
images and colormaps, colorbars, time series plotting (eg the spectral
stuff), collections....
 http://matplotlib.sourceforge.net
Let me know if you find any problems.
JDH

hmm
-------- Original Message --------
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 StarPolygonCollection? I haven't
>> checked, but I don't think so !). Instead of creating a new
>> RegularPolyCollection it might be more useful to make a copy of the
>> existing object... I was thinking about a update_from() method for the
>> Collection class(es) similar to update_from() for lines.
>>
> 
> By changing "RegularPolyCoolection" to "type(handles)", it works for
> StarPolygonCollection.
> 
> In Erik's current implementation, the markers in the legend have
> varying colors, sizes, and y offsets.
> The color variation seems fine. But do we need to vary the sizes and
> y-offsets? My inclination is to use a fixed size (median?) and a fixed
> y offset. How does Erik and others think?
> 
> Regards,
> 
> -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
-- 
---------------------------------------
 Manuel Metz ............ Stw@AIfA
 Argelander Institut fuer Astronomie
 Auf dem Huegel 71 (room 3.06)
 D - 53121 Bonn
 E-Mail: mm...@as...
 Web: www.astro.uni-bonn.de/~mmetz
 Phone: (+49) 228 / 73-3660
 Fax: (+49) 228 / 73-3672
---------------------------------------

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 StarPolygonCollection? I haven't
>> checked, but I don't think so !). Instead of creating a new
>> RegularPolyCollection it might be more useful to make a copy of the
>> existing object... I was thinking about a update_from() method for the
>> Collection class(es) similar to update_from() for lines.
>>
> 
> By changing "RegularPolyCoolection" to "type(handles)", it works for
> StarPolygonCollection.
> 
> In Erik's current implementation, the markers in the legend have
> varying colors, sizes, and y offsets.
> The color variation seems fine. But do we need to vary the sizes and
> y-offsets? My inclination is to use a fixed size (median?) and a fixed
> y offset. How does Erik and others think?
> 
> Regards,
> 
> -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

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
we want to configure, we need to now how to get at that object."
"inspect" or "set" ???
mm

On Wed, Oct 15, 2008 at 2:42 PM, Michael Droettboom <md...@st...> wrote:
> Weird. Have to admit I don't understand this HTML stuff very well... ;)
Don't worry about it -- I am going to try and revert these changes
with a thinner logo. I'll let you know when it's ready for testing.
JDH

Weird. Have to admit I don't understand this HTML stuff very well... ;)
John Hunter wrote:
> On Wed, Oct 15, 2008 at 2:22 PM, Michael Droettboom <md...@st...> wrote:
> 
>> Nope, I'm not seeing this, even when I shrink the window width way down.
>>
>> This is Firefox 2.0 on RHEL4.
>>
>> Does putting a &nbsp; between matplotlib and home help?
>> 
>
> I tried this, and it put matplotlib and home together, but on the line
> below the icon. I tried to make sure there were no spaces between the
> image and the start of the matplotlib word, but wasn't able to kill
> the newline
>
> firefox 2.0.0.14 on solaris x86
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Wed, Oct 15, 2008 at 2:22 PM, Michael Droettboom <md...@st...> wrote:
> Nope, I'm not seeing this, even when I shrink the window width way down.
>
> This is Firefox 2.0 on RHEL4.
>
> Does putting a &nbsp; between matplotlib and home help?
I tried this, and it put matplotlib and home together, but on the line
below the icon. I tried to make sure there were no spaces between the
image and the start of the matplotlib word, but wasn't able to kill
the newline
firefox 2.0.0.14 on solaris x86

Nope, I'm not seeing this, even when I shrink the window width way down.
This is Firefox 2.0 on RHEL4.
Does putting a   between matplotlib and home help?
Mike
John Hunter wrote:
> On Wed, Oct 15, 2008 at 10:17 AM, Michael Droettboom <md...@st...> wrote:
>
> 
>>> I'm happy to do use a smaller logo on the doc pages, but off hand do
>>> not know how to do it. I am knee deep in trying to convert the
>>> existing docs, because as you probably gathered the sphinx docs will
>>> soon entirely replace the existing web pages entirely. So if you
>>> could help with this logo change that would be great. Either route
>>> (smaller logo or single icon) is fine by me.....
>>> 
>
> I am having problems in that the "matplotlib home" text is getting
> wrapped with the new icon. Screenshot attached. Are you not seeing
> this?
>
> I may work on a thinner default logo, because I like having the
> consistency between pages....
>
> JDH
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Wed, Oct 15, 2008 at 2:18 PM, John Hunter <jd...@gm...> wrote:
> I am having problems in that the "matplotlib home" text is getting
> wrapped with the new icon. Screenshot attached. Are you not seeing
> this?
umm, forgot the attachment

On Wed, Oct 15, 2008 at 10:17 AM, Michael Droettboom <md...@st...> wrote:
>> I'm happy to do use a smaller logo on the doc pages, but off hand do
>> not know how to do it. I am knee deep in trying to convert the
>> existing docs, because as you probably gathered the sphinx docs will
>> soon entirely replace the existing web pages entirely. So if you
>> could help with this logo change that would be great. Either route
>> (smaller logo or single icon) is fine by me.....
I am having problems in that the "matplotlib home" text is getting
wrapped with the new icon. Screenshot attached. Are you not seeing
this?
I may work on a thinner default logo, because I like having the
consistency between pages....
JDH

"John Hunter" <jd...@gm...> writes:
> On Wed, Oct 15, 2008 at 8:18 AM, Michael Droettboom <md...@st...> wrote:
> > The new stylesheet for the docs looks great, John!
> 
> I just ripped this off hook-line-and-sinker from the sphinx docs, and
> added the few css bits you created earlier. They do look nice :-)
Indeed they do. 
http://matplotlib.sourceforge.net/doc/html/index.html links to
http://matplotlib.sourceforge.net/doc/html/goals.html which doesn't
seem to exist yet.
I guess this is temporary, but thought it worth pointing out. 
Chris

On Wed, Oct 15, 2008 at 10:28 AM, Chris Walker
<ch...@ch...> wrote:
>
> http://matplotlib.sourceforge.net/doc/html/index.html links to
> http://matplotlib.sourceforge.net/doc/html/goals.html which doesn't
> seem to exist yet.
>
> I guess this is temporary, but thought it worth pointing out.
Thanks -- all bug reports welcome because I may not be aware of them.
The goals page is horribly out of date so I am just going to scrap it
for now. We can resurrect it later if need be.
JDH

John Hunter wrote:
> On Wed, Oct 15, 2008 at 8:18 AM, Michael Droettboom <md...@st...> wrote:
> 
>> The new stylesheet for the docs looks great, John!
>> 
>
> I just ripped this off hook-line-and-sinker from the sphinx docs, and
> added the few css bits you created earlier. They do look nice :-)
>
> 
>> One extremely minor nit: perhaps the logo is a too large in this
>> context. On smaller screens, like a 1024x768 laptop, it encompasses
>> about a third of the usable browser window space.
>>
>> Would it be possible to keep it the current size for the main home page,
>> but use a smaller version for the documentation pages? Or, to the
>> extreme, just use a small icon-sized logo like in the Python 2.6 docs?
>> 
>
> I'm happy to do use a smaller logo on the doc pages, but off hand do
> not know how to do it. I am knee deep in trying to convert the
> existing docs, because as you probably gathered the sphinx docs will
> soon entirely replace the existing web pages entirely. So if you
> could help with this logo change that would be great. Either route
> (smaller logo or single icon) is fine by me.....
> 
Sure. I'll look into this.
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA