matplotlib-devel Mailing List for matplotlib

Tony,
Sorry. It turned to be a bug I introduced during the update.
It should be fixed in r6499.
Thanks,
-JJ
On Fri, Dec 5, 2008 at 3:47 PM, Jae-Joon Lee <lee...@gm...> wrote:
> Tony,
>
> I'll look at this problem.
> Anyhow, it seems to me that it happens because the handle length is too short.
> Can you try longer handle length and see what happens?
> The code for drawing handles are mostly identical to the previous one.
>
> Regards,
>
> -JJ
>
>
> On Fri, Dec 5, 2008 at 1:46 PM, Tony Yu <ts...@gm...> wrote:
>>
>> On Dec 4, 2008, at 7:21 PM, Jae-Joon Lee wrote:
>>
>>> John,
>>>
>>> I just committed changes to SVN that reflect most of your comments.
>>> I didn't add the optional transformation support yet though.
>>
>>
>> I'm getting a truncated line when calling:
>>
>>>>> plt.legend(numpoints=1)
>>
>> In the legend, I see a short dashed line followed by the marker. Before, the
>> line went through the marker. I've attached a couple of images showing
>> numpoints set to 1 and 2.
>>
>> I think this behavior was introduced with the improved legend class.
>>
>> Thanks,
>> -Tony
>>
>>
>>
>>
>> mpl svn 6497
>>
>

Tony,
I'll look at this problem.
Anyhow, it seems to me that it happens because the handle length is too short.
Can you try longer handle length and see what happens?
The code for drawing handles are mostly identical to the previous one.
Regards,
-JJ
On Fri, Dec 5, 2008 at 1:46 PM, Tony Yu <ts...@gm...> wrote:
>
> On Dec 4, 2008, at 7:21 PM, Jae-Joon Lee wrote:
>
>> John,
>>
>> I just committed changes to SVN that reflect most of your comments.
>> I didn't add the optional transformation support yet though.
>
>
> I'm getting a truncated line when calling:
>
>>>> plt.legend(numpoints=1)
>
> In the legend, I see a short dashed line followed by the marker. Before, the
> line went through the marker. I've attached a couple of images showing
> numpoints set to 1 and 2.
>
> I think this behavior was introduced with the improved legend class.
>
> Thanks,
> -Tony
>
>
>
>
> mpl svn 6497
>

On Dec 4, 2008, at 7:21 PM, Jae-Joon Lee wrote:
> John,
>
> I just committed changes to SVN that reflect most of your comments.
> I didn't add the optional transformation support yet though.
I'm getting a truncated line when calling:
 >>> plt.legend(numpoints=1)
In the legend, I see a short dashed line followed by the marker. 
Before, the line went through the marker. I've attached a couple of 
images showing numpoints set to 1 and 2.
I think this behavior was introduced with the improved legend class.
Thanks,
-Tony

Eric Firing wrote:
> Ryan May wrote:
>> Now, what about dates? I'm having problems using dates for the x-axis 
>> for fill_between. I know I can use date2num on my array, but I was 
>> wonder if there was some magic I could add to the fill_between code.
> 
> Magic is the operative word. It is sprinkled like pixie dust throughout 
> mpl. You may be able to figure it out by looking at the code for other 
> functions that do support units. You could look for recent commits by 
> Ted Drain, if I remember correctly, and by John, both of whom fill gaps 
> in units handling every now and then.
> 
> For example, note this line at the top of scatter:
> 
> self._process_unit_info(xdata=x, ydata=y, kwargs=kwargs)
Well, combine all that pixie dust with a few wonderful thoughts, and we should 
all be flying like Peter Pan! :)
Seriously, thanks for the pointer. _process_unit_info() combined with 
convert_[x|y]units() made it work. Old example and my own code here both work. 
Checked into r6497.
Thanks,
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

John,
I just committed changes to SVN that reflect most of your comments.
I didn't add the optional transformation support yet though.
On Tue, Dec 2, 2008 at 7:45 AM, John Hunter <jd...@gm...> wrote:
> On Mon, Dec 1, 2008 at 6:00 PM, Jae-Joon Lee <lee...@gm...> wrote:
>
>> As implementing an optional transformation should be trivial, I'll
>> just go ahead an work on it. But it seems not clear to me how to
>> approach this without any specific use case given.
>
> In another thread yesterday, someone was asking about a general way to
> create a shadow effect. It occurred to me that we could probably use
> the offsetbox for this. One could create an offset box for a given
> artist that draws the artist offset from the original by 5 points or 5
> pixels, in a gray color that creates the appearance of a shadow.
> Would this be a reasonable use case to test the offset transformation
> in either points or pixels?
>
> JDH
>
I kind of prefer to use transforms.offset_copy() for simple offsets.
But it may better to use some kind of container (e.g., offsetbox) if
you have multiple artists.
I'll think about it.
Regards,
-JJ