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 <[EMAIL PROTECTED]> 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 >https://lists.sourceforge.net/lists/listinfo/matplotlib-users ------------------------------------------------------------------------- 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 https://lists.sourceforge.net/lists/listinfo/matplotlib-users
