John,
One of the problems we've had is trying to design an auto-scaling algorithm that works well with any type date format since the date strings can be so large horizontally. I believe that having the draw time elements be able to query the renderer for things would help this out tremendously since we could then have the tick generator space out the dates along nice boundaries without overlapping the date strings.
Ted
···
At 01:07 PM 4/7/2007, John Hunter wrote:
On 4/7/07, Eric Firing <efiring@...202...> wrote:
> I put back get_lines() in collections and fixed a related bug in legend,
> so the test script now works in the sense that it makes a legend. It
> puts in an unlabeled line, presumably corresponding to the line
> collection making up the error bars. Maybe legend provides a way to
> avoid this. I haven't looked.
If I'm understanding the problem you are describing correctly, it
looks like _nolegend_ needs to be set here. For artists we do not want
to be included in the legend, the label should be set to '_nolegend_'
and legend will ignore it in auto-legending. Or at least it should
and if it is not it is a bug.
> The larger problem, and the one that probably made me yank get_lines
> (without realizing the legend code was using it--my mistake--I do try to
> check for things like that) is that legend really wants to know the
> draw-time locations of all plot elements, and for collections (among
> other things) this cannot be determined in general. The collection
> get_lines and get_verts methods can give the right answer to legend only
> if the data and offset transforms are the same. Sometimes they are,
> sometimes they are not. LineCollection.get_lines() probably could be
> improved to do a better job than at present, but never a perfect one.
One approach is to make every artist provide a get window extent which
returns a bounding box. There is the issue of how to get the renderer
before draw time, but we could fix this. It would be nice for draw
time layout algorithms to be able to assume this method, and a few
objects already provide it, eg text.
> This is an example of a more widespread problem that we have thought
> about and discussed (including some good ideas from John, of course),
> but solving it is not simple. For the time being, at least, we are
> stuck with some imperfections.
>
> In any case, thanks for bringing the legend/LineCollection bug to my
> attention. This is the sort of thing it is nice to get cleaned up
> before the next release, coming soon. Do you know of some other simple
> bugs like this we should look at ASAP?
I added unit/legend_unit.py script to create legends using a scatter
and vlines, which create RegPolyCollections and LineCollections. We
should use more stuff like this in general, unit scripts which
exercise the more arcane usages.
JDH
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options
Ted Drain wrote:
John,
One of the problems we've had is trying to design an auto-scaling algorithm that works well with any type date format since the date strings can be so large horizontally. I believe that having the draw time elements be able to query the renderer for things would help this out tremendously since we could then have the tick generator space out the dates along nice boundaries without overlapping the date strings.
This is only half of the solution; the other half is controlling the order in which things are done. In its most general form, this would involve some sort of dependency tree, automatically generated. I imagine this is how layout engines work. I know that Andrew contributed one quite some time ago, and so far I have done nothing with it. (Sorry, Andrew.) A simpler mechanism suggested by John was a set of pre- and post- hooks in draw functions that would enable one to manually put in dependencies and ensure that dependent calculations are done in the right order. In all of this, it is critical to avoid chicken-and-egg situations: e.g., label font size depends on physical room available, but tick spacing adjusts to accommodate the labels.
The transforms module already does part of what we are talking about here; dependency information is accumulated as BinOps are built from other BinOps, and everything is resolved at rendering time.
I think that any changes like this need to wait in line behind the upcoming numpyfication, and it would be nice to have some full outlines of alternative strategies before picking one and proceeding.
Ideas and strategy sketches tend to get lost in the email stack; would it help to have a wiki page for discussion of major design questions like this? Or is this overkill?
Eric
···
Ted
At 01:07 PM 4/7/2007, John Hunter wrote:
On 4/7/07, Eric Firing <efiring@...202...> wrote:
I put back get_lines() in collections and fixed a related bug in legend,
so the test script now works in the sense that it makes a legend. It
puts in an unlabeled line, presumably corresponding to the line
collection making up the error bars. Maybe legend provides a way to
avoid this. I haven't looked.
If I'm understanding the problem you are describing correctly, it
looks like _nolegend_ needs to be set here. For artists we do not want
to be included in the legend, the label should be set to '_nolegend_'
and legend will ignore it in auto-legending. Or at least it should
and if it is not it is a bug.
The larger problem, and the one that probably made me yank get_lines
(without realizing the legend code was using it--my mistake--I do try to
check for things like that) is that legend really wants to know the
draw-time locations of all plot elements, and for collections (among
other things) this cannot be determined in general. The collection
get_lines and get_verts methods can give the right answer to legend only
if the data and offset transforms are the same. Sometimes they are,
sometimes they are not. LineCollection.get_lines() probably could be
improved to do a better job than at present, but never a perfect one.
One approach is to make every artist provide a get window extent which
returns a bounding box. There is the issue of how to get the renderer
before draw time, but we could fix this. It would be nice for draw
time layout algorithms to be able to assume this method, and a few
objects already provide it, eg text.
This is an example of a more widespread problem that we have thought
about and discussed (including some good ideas from John, of course),
but solving it is not simple. For the time being, at least, we are
stuck with some imperfections.
In any case, thanks for bringing the legend/LineCollection bug to my
attention. This is the sort of thing it is nice to get cleaned up
before the next release, coming soon. Do you know of some other simple
bugs like this we should look at ASAP?
I added unit/legend_unit.py script to create legends using a scatter
and vlines, which create RegPolyCollections and LineCollections. We
should use more stuff like this in general, unit scripts which
exercise the more arcane usages.
JDH
My preference is for (possibly structured) text documents in the svn
repo, ala CODING_GUIDE
···
On 4/10/07, Eric Firing <efiring@...202...> wrote:
Ideas and strategy sketches tend to get lost in the email stack; would
it help to have a wiki page for discussion of major design questions
like this? Or is this overkill?