matplotlib-devel Mailing List for matplotlib

Greetings!
First, my personal thanks to you good folks who make
a wonderful tool like matplotlib available.
I am currently trying to build matplotlib-1.0.1 against
libpng1.5.1, and _png.cpp failed to compile. Apparently,
libpng's info_ptr is now opaque, so the code required
multiple changes of this nature:
-- _png.cpp.orig 2011年02月12日 16:42:42.000000000 -0500
***************
*** 350,362 ****
 png_set_sig_bytes(png_ptr, 8);
 png_read_info(png_ptr, info_ptr);
! /*png_uint_32 width = info_ptr->width;*/
! /*png_uint_32 height = info_ptr->height;*/
! png_uint_32 width = png_get_image_width( png_ptr, info_ptr );
! png_uint_32 height = png_get_image_height( png_ptr, info_ptr );
! /*int bit_depth = info_ptr->bit_depth;*/
! int bit_depth = png_get_bit_depth( png_ptr, info_ptr );
 // Unpack 1, 2, and 4-bit images
 if (bit_depth < 8)
--- 350,359 ----
 png_set_sig_bytes(png_ptr, 8);
 png_read_info(png_ptr, info_ptr);
! png_uint_32 width = info_ptr->width;
! png_uint_32 height = info_ptr->height;
! int bit_depth = info_ptr->bit_depth;
 // Unpack 1, 2, and 4-bit images
 if (bit_depth < 8)
***************
Sorry to be sending problems :-).
I suspect you have probably noticed this
already, but just in case I figured I'd send
a "head's up". Thanks!
Sincerely,
 Mike Albert

On Sat, Jan 22, 2011 at 10:18 AM, Benjamin Root <ben...@ou...> wrote:
> On Tue, Jan 18, 2011 at 12:27 AM, Jae-Joon Lee <lee...@gm...>wrote:
>
>> Dear Matplotlib developers,
>>
>> Attached is a patch to improve the functionality of legend.
>> The two biggest changes are as follows,
>>
>> * Drawing of legend is delegated to "legend handlers".
>> * Introduces a new "Container" class. This is primarily to support
>> legend of complex plots (e.g., bar, errorbar, etc).
>>
>> The first change is to ease the creation of customized legends. See
>> "legend_demo_custom_handler.py" for example.
>> The second change is to support legend of complex plots. Axes
>> instances now have a "containers" attribute. And this is only intended
>> to be used for generating a legend. For example, "bar" plots create a
>> series of Rectangle patches. Previously, it returned a list of these
>> patches. With the current change, it creates a container object of
>> these rectangle patches and return it instead. As the container class
>> is derived from a tuple, it should be backward-compatible.
>> Furthermore, the container object is added to the Axes.containers
>> attributes. And legend command use this "container" attribute to
>> properly create a legend for the bar.
>>
>> A two example figures are attached.
>>
>> As this patch introduces relatively significant changes. I wanted to
>> get some comments from others before I commit.
>> The change will be divided into four commits.
>>
>> Regards,
>>
>> -JJ
>>
>>
> Nice. I will look through it this week and see if I can break it.
>
> Ben Root
>
>
Jae-Joon,
I finally got around to doing some testing with your refactor of legend. I
find the concepts behind the refactor interesting, however the current
implementation doesn't seem to work properly in some basic use-cases.
In particular, the following just produces an empty box:
import matplotlib.pyplot as plt
x = [1,2,3,4,5]
y1 = [1, 2, 3, 4, 5]
y2 = [5, 4, 3, 2, 1]
plt.plot(x, y1, 'rx-')
plt.plot(x, y2, 'bx-')
plt.legend(('a', 'b'))
plt.show()
However, it does work if I use the label= kwarg in the plot commands.
Another use-case that doesn't seem addressed yet (and isn't quite right in
regular mpl either) is legends for stemplots.
I haven't tried out the new features yet, as I am mostly concerned about
backwards-compatibility right now.
Ben Root

As suggested on
http://matplotlib.sourceforge.net/faq/howto_faq.html#submit-a-patch ,
I have submitted this to the patch tracker an am following it up, with
a tracker link! The patch tracker entry is:
https://sourceforge.net/tracker/?func=detail&aid=3178834&group_id=80706&atid=560722
Apologies if I am sticking rigidly (and annoyingly) to this process.
(I have also been observing the git-transition, so appreciate this
probably isn't the best time to integrate random patches)
On Mon, Feb 7, 2011 at 1:23 AM, Nicholas Devenish
<mis...@gm...> wrote:
> One of the things that bugs me about axes.hist is that with
> histtype='step' the automatic legend style is an empty box, instead of
> a line, as I would expect. This behaviour doesn't seem to make sense,
> because it seems a line would be much more appropriate for this case.
> Example is attached for the code:
>
> import matplotlib.pyplot as plt
> plt.hist([0,1,1,2,2,2], [0,1,2,3], histtype='step', label="histtype='step'")
> plt.legend()
> plt.show()
>
> I can get around this by using proxy Line2D objects in building the
> legend, but as this is an extremely common operation for me (the
> common style of histograms in my field is equivalent to step) this
> becomes messy and annoying. I'd rather not have to roll my own
> histogram drawing function, as it would be almost entirely duplicating
> the axes hist code, and don't know another way to get what I want. I
> understand that the way of setting Legend styles is something that has
> been looked at recently, but don't know the timescale for any changes.
>
> The cause of this is the fact that in axes.py::7799 (current SVN
> head), in axes.hist, patch objects are always created, even for the
> line-based step style. I searched the tracker briefly, and couldn't
> find this mentioned before. I therefore have a few questions:
>
> - Is this intended behaviour, that I am just not understanding the
> requirement for?
> - Would changing this to create (and thus return) Line2D's instead of
> Patch's for this histtype be a horrible breaking of the return
> interface?
>
> I've attached a patch that makes the simple change of swapping out the
> call to .fill for .plot (only the function is changed here, not yet
> the documentation), and it appears to work but I haven't tested
> exhaustively.
>
> Thoughts?
>
> Nick
>