Re: [matplotlib-devel] .cvsignore
Thanks Mike. I checked the contents of all the .cvsignore files and compared them with propget svn:ignore. I removed every instance of .cvsignore, with the exception of toolkits/basemap/.cvsignore and toolkits/basemap-0.9.6.1/.cvsignore. Darren On Wednesday 05 December 2007 09:16:11 am Michael Droettboom wrote: > It looks like these are already set in the "SVN way" (maybe cvs2svn did it): > > svn propget svn:ignore . > > build > dist > docs > *.pyc > .project > matplotlibrc > win32_static > > > ...so it's probably safe to remove them, unless we plan to migrate back > to CVS someday ;) > > Cheers, > Mike > > Darren Dale wrote: > > Is it safe to remove the instances of .cvsignore from the svn repository? > > > > - > > SF.Net email is sponsored by: The Future of Linux Business White Paper > > from Novell. From the desktop to the data center, Linux is going > > mainstream. Let it simplify your IT future. > > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > > ___ > > Matplotlib-devel mailing list > > Matplotlib-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Darren S. Dale, Ph.D. Staff Scientist Cornell High Energy Synchrotron Source Cornell University 275 Wilson Lab Rt. 366 & Pine Tree Road Ithaca, NY 14853 [EMAIL PROTECTED] office: (607) 255-3819 fax: (607) 255-9001 http://www.chess.cornell.edu - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Experimental overlapping-prevention on the transforms branch
On Dec 4, 2007 4:02 PM, Ted Drain <[EMAIL PROTECTED]> wrote: > Looks very nice! We'd love to have smarter layout systems as we > create a lot of plots for people (i.e. standard scripts that people > run instead of edit) and it's difficult to apply nice layouts that > work for every case that comes up. > > Can any of this be extended to make the auto-ticking algorithms smart > enough to not overlap tick mark text fields so much? We get this all > the time with date plots and it drives people nuts. This drives me nuts too -- I almost always do autofmt_xdate. Perhaps we should just make rotated and right aligned the default for dates. Particularly in combination with Michael's autolayout, it should help the common use case. One problem that needs to be addressed is autofmt_xdate currently raises if you are not using a subplot geometry (because it turns off xticklabels for the upper subplots), but with a little thought we could make this more generic to work with general axes. This is hte main reason I have been holding off making it the default. One other problem to be aware of in this area: usetex does not support rotated text, so autofmt_xdate and related tricks will still not work until usetex supports arbitrary rotations. One thing that has been on my wish list is to expose the agg image functionality a little better to make things like rotating the ft2font pixel buffer easier. JDH - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Experimental overlapping-prevention on the transforms branch
On Wednesday 05 December 2007 09:39:33 am John Hunter wrote: > On Dec 4, 2007 4:02 PM, Ted Drain <[EMAIL PROTECTED]> wrote: > > Looks very nice! We'd love to have smarter layout systems as we > > create a lot of plots for people (i.e. standard scripts that people > > run instead of edit) and it's difficult to apply nice layouts that > > work for every case that comes up. > > > > Can any of this be extended to make the auto-ticking algorithms smart > > enough to not overlap tick mark text fields so much? We get this all > > the time with date plots and it drives people nuts. > > This drives me nuts too -- I almost always do autofmt_xdate. Perhaps > we should just make rotated and right aligned the default for dates. > Particularly in combination with Michael's autolayout, it should help > the common use case. One problem that needs to be addressed is > autofmt_xdate currently raises if you are not using a subplot geometry > (because it turns off xticklabels for the upper subplots), but with a > little thought we could make this more generic to work with general > axes. This is hte main reason I have been holding off making it the > default. > > One other problem to be aware of in this area: usetex does not support > rotated text, so autofmt_xdate and related tricks will still not work > until usetex supports arbitrary rotations. One thing that has been on > my wish list is to expose the agg image functionality a little better > to make things like rotating the ft2font pixel buffer easier. I mentioned the usetex limitation a while back on mpl-dev, the post was titled "arbitrary rotation of images". Darren - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Experimental overlapping-prevention on the transforms branch
Michael Droettboom wrote: > ...probably because I forgot to attach it. (When will my e-mail > client read my mind?) I've also attached a version with a new version > of the layout algorithm -- in addition to making all axes that were > initially aligned remain aligned, it sets an axes that originally were > the same size to remain the same size. Better... but aside from it > theoretically picking up some false positives, it tends to add more > space than necessary between axes. It probably needs a fourth pass to > minimize the gaps. Thanks, got them this time. They both look acceptable, the 2nd looks pretty good. I gather it doesn't require any additional user commands, but just picks up the desired layout based on the axes bounds (in other words, the same script)? - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Experimental overlapping-prevention on the transforms branch
Michael Droettboom wrote: > Andrew, > > I'm embarrassed to admit I wasn't familiar with mplsizer before I > looked into this. The user "API" of mplsizer actually looks like it > would be much easier to support the text-overlapping problem, since > the placement of the axes in a grid is more explicit. I may want to > reconsider how I'm doing things... Well, I haven't exactly advertised mplsizer very heavily, so I can't blame you. I don't know what you're implying by putting API in quotes, but in my defense -- I just did my best to copy wx's, so if you want to talk about the wx "API" that's ok by me. Now if you complain about the (lack of) documentation, that'll hurt. ;) > > But as for your question, it doesn't really "break" things for > mplsizer. As you probably know, each axes keeps track of an > "original" and "active" bounding box. The "original" can be thought > of as "what the user specified", via either subplot(), > axes([l,b,w,h]), or mplsizer. The text-overlapping algorithm works by > first determining how much the axes bounds need to shrink to make room > for the text (for every axes), and then adjusts all axes such that any > that were aligned to begin with remain aligned. Since text does not > grow as the figure size does, this shrinking and re-alignment happens > on every redraw (it technically only has to happen when the figure is > resized, the dpi changes or axes are added or removed, but that's an > optimization for another time...) I see, so is it correct that, at some certain minimum figure size, the overlapping code no longer has to shrink axes, and everything will be aligned as before? > > The attached image shows your example run through the new > text-overlapping routine. I set the mplsizer border to 0.0 to make > the effect more obvious. As you can see, the edges of the axes remain > aligned. Unfortunately, axes that were the same *size* before > adjusting for text are now different. I think this is a problem both > aesthetically and for clarity, but it's hard to avoid given that mpl > allows the user to arbitrarily put a new axes at any position > whatsoever -- that is, there aren't any explicit relationships between > axes to suggest that two or more axes should maintain the same aspect > ratio. The subplot() API and the mplsizer API do help with that, > though... maybe it's better to only do this with axes created that > way, and leave arbitrarily placed axes alone. Food for thought... I must admit that I didn't get the attachment, but perhaps all the better as I should download the transforms branch and start testing. I don't have time this week, however... Nevertheless, I'm having difficulty following the above without something to look at. Perhaps a small API addition would help solve the situation. Something that would force disparate axes to share the same aspect ratio and size? That would seem to solve 99% of the problem I worry about. Something like this (egregiously long kwparam version): ax1 = axes([l,b,w,h], shared_data_aspect_key='group1' ) ax2 = axes([l,b,w,h], shared_data_aspect_key='group1' ) ax3 = axes([l,b,w,h], shared_data_aspect_key='group2' ) ax4 = axes([l,b,w,h], shared_data_aspect_key='group2' ) > [As an aside, I had a little trouble installing mplsizer. "python > setup.py install" put an mplsizer egg in my site-packages, but "import > matplotlib.toolkits.mplsizer" failed. > > >>> import matplotlib.toolkits.mplsizer as mplsizer > Traceback (most recent call last): > File "", line 1, in > ImportError: No module named toolkits.mplsizer > > I was able to get this to work my manually copying the > mplsizer/build/lib/matplotlib/toolkits/mplsizer directory to > site-packages/matplotlib/toolkits/ . I have very little experience > with eggs... is there something I'm doing wrong with the install?] Sigh. I dunno. This works on some of my computers and not on others and I don't know what's different. I'm going to have to either figure it out or rip the setuptools out. Again, not this week... - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] eggs or pythonmac packages on OS X?
Russell E Owen wrote: > At 10:08 AM -0500 2007-12-05, Stephen Uhlhorn wrote: >> Just for my edification, why can't the egg version be linked >> against/include a different Tcl/Tk? > > If you mean why can't it be built that way in the first place, I > don't know. The guy who builds it apparently doesn't read this list, Sure he does (if you mean the matplotlib list), and he did ask about it right before this release. Maybe that was asked on matplotlib-devel though (I filter them to the same place). > I suspect the official egg can somehow be patched, but I find it > easier to just build my own and put that on pythonmac. Ideally, there would be only one binary version, and it would work with either Tcl/Tk. Is that possible? or is this like the old wx situation, where it can only be run with the same version it is built against. Arrggg! I hope not. If there really do need to be two, then they should be labeled somehow, and both be up on python mac. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] eggs or pythonmac packages on OS X?
I feel a 0.91.2 in the next few weeks, and I'll be sure to do this and send you a test build. - Charlie On Dec 5, 2007 1:30 PM, Russell E Owen <[EMAIL PROTECTED]> wrote: > At 10:03 AM -0800 2007-12-05, Christopher Barker wrote: > >Russell E Owen wrote: > >>At 10:08 AM -0500 2007-12-05, Stephen Uhlhorn wrote: > >>>Just for my edification, why can't the egg version be linked > >>>against/include a different Tcl/Tk? > >> > >>If you mean why can't it be built that way in the first place, I > >>don't know. The guy who builds it apparently doesn't read this list, > > > >Sure he does (if you mean the matplotlib list), and he did ask about > >it right before this release. Maybe that was asked on > >matplotlib-devel though (I filter them to the same place). > > It was on matploblib-devel. I'll start skimming that newsgroup. > > >>I suspect the official egg can somehow be patched, but I find it > >>easier to just build my own and put that on pythonmac. > > > >Ideally, there would be only one binary version, and it would work > >with either Tcl/Tk. Is that possible? or is this like the old wx > >situation, where it can only be run with the same version it is > >built against. Arrggg! I hope not. > > The version I build *can* be used with the built in Tcl/Tk. The > version Charlie Moad builds cannot be used with TkAgg and a 3rd party > Tcl/Tk -- it not only won't use the library, but it also acts flaky. > Older versions crashed. 0.91.1 doesn't crash, but import of pylab > fails with a traceback. > > For some reason it seems to be necessary to have a 3rd party Tcl/Tk > installed when building matplotlib. It seems a shame. Tkinter in > Python 2.4 was the same way, but that got fixed in Python 2.5 (I > don't whether the installer got fixed or whether whoever builds Mac > Python 2.5 installed a 3rd party Tcl/Tk). > > >If there really do need to be two, then they should be labeled > >somehow, and both be up on python mac. > > Since there don't need to be two versions this is not necessary. > > However, Charlie Moad appears to be willing to start building a > version that works with 3rd party Tcl/Tk. I really hope that happens. > > -- Russell > > - > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > ___ > Matplotlib-users mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Experimental overlapping-prevention on the transforms branch
Andrew Straw wrote: > Michael Droettboom wrote: >> ...probably because I forgot to attach it. (When will my e-mail >> client read my mind?) I've also attached a version with a new version >> of the layout algorithm -- in addition to making all axes that were >> initially aligned remain aligned, it sets an axes that originally were >> the same size to remain the same size. Better... but aside from it >> theoretically picking up some false positives, it tends to add more >> space than necessary between axes. It probably needs a fourth pass to >> minimize the gaps. > Thanks, got them this time. > > They both look acceptable, the 2nd looks pretty good. I gather it > doesn't require any additional user commands, but just picks up the > desired layout based on the axes bounds (in other words, the same script)? That's correct. The only change to your script that I made was: hsizer.Add(ax,name='row %d, col %d'%(r,c),all=1,border=0.3,expand=1) to hsizer.Add(ax,name='row %d, col %d'%(r,c),all=1,border=0.0,expand=1) And the very latest version of the transforms branch requires auto layout to be turned on by setting the rcParam "figure.autolayout" to True. (That's just so I can continue to experiment without tripping up others...) There should be more padding between the axes and the tick labels -- that's due to an unrelated bug because the dpi is changing on-the-fly. Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Experimental overlapping-prevention on the transforms branch
On Wednesday 05 December 2007 11:32:29 am Michael Droettboom wrote: > Michael Droettboom wrote: > > Darren Dale wrote: > >>> One other problem to be aware of in this area: usetex does not support > >>> rotated text, so autofmt_xdate and related tricks will still not work > >>> until usetex supports arbitrary rotations. One thing that has been on > >>> my wish list is to expose the agg image functionality a little better > >>> to make things like rotating the ft2font pixel buffer easier. > >> > >> I mentioned the usetex limitation a while back on mpl-dev, the post was > >> titled "arbitrary rotation of images". > > > > Between 0.90 and 0.91, the Agg backend grew a "draw_text_image" method, > > which can draw an image at an arbitrary angle. It is hardcoded to take > > the inverted greyscale images generated by FT2Font, but it should > > provide a roadmap as to how to handle the rgba images used by the usetex > > machinery. > > Usetex now supports arbitrary angles with the Agg backend. It grabs > only the greyscale part of the usetex image (which isn't new -- usetex > has always thrown away any color coming from (La)TeX), and then uses > draw_text_image to do the drawing. (draw_image continues to not support > rotation, but that is probably best done elsewhere anyway, if the need > ever arises). Thank you for doing this Mike. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Experimental overlapping-prevention on the transforms branch
Darren Dale wrote: >> One other problem to be aware of in this area: usetex does not support >> rotated text, so autofmt_xdate and related tricks will still not work >> until usetex supports arbitrary rotations. One thing that has been on >> my wish list is to expose the agg image functionality a little better >> to make things like rotating the ft2font pixel buffer easier. > > I mentioned the usetex limitation a while back on mpl-dev, the post was > titled "arbitrary rotation of images". Between 0.90 and 0.91, the Agg backend grew a "draw_text_image" method, which can draw an image at an arbitrary angle. It is hardcoded to take the inverted greyscale images generated by FT2Font, but it should provide a roadmap as to how to handle the rgba images used by the usetex machinery. Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Experimental overlapping-prevention on the transforms branch
Michael Droettboom wrote: > Darren Dale wrote: >>> One other problem to be aware of in this area: usetex does not support >>> rotated text, so autofmt_xdate and related tricks will still not work >>> until usetex supports arbitrary rotations. One thing that has been on >>> my wish list is to expose the agg image functionality a little better >>> to make things like rotating the ft2font pixel buffer easier. >> I mentioned the usetex limitation a while back on mpl-dev, the post was >> titled "arbitrary rotation of images". > > Between 0.90 and 0.91, the Agg backend grew a "draw_text_image" method, > which can draw an image at an arbitrary angle. It is hardcoded to take > the inverted greyscale images generated by FT2Font, but it should > provide a roadmap as to how to handle the rgba images used by the usetex > machinery. Usetex now supports arbitrary angles with the Agg backend. It grabs only the greyscale part of the usetex image (which isn't new -- usetex has always thrown away any color coming from (La)TeX), and then uses draw_text_image to do the drawing. (draw_image continues to not support rotation, but that is probably best done elsewhere anyway, if the need ever arises). Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Experimental overlapping-prevention on the transforms branch
Andrew, I'm embarrassed to admit I wasn't familiar with mplsizer before I looked into this. The user "API" of mplsizer actually looks like it would be much easier to support the text-overlapping problem, since the placement of the axes in a grid is more explicit. I may want to reconsider how I'm doing things... But as for your question, it doesn't really "break" things for mplsizer. As you probably know, each axes keeps track of an "original" and "active" bounding box. The "original" can be thought of as "what the user specified", via either subplot(), axes([l,b,w,h]), or mplsizer. The text-overlapping algorithm works by first determining how much the axes bounds need to shrink to make room for the text (for every axes), and then adjusts all axes such that any that were aligned to begin with remain aligned. Since text does not grow as the figure size does, this shrinking and re-alignment happens on every redraw (it technically only has to happen when the figure is resized, the dpi changes or axes are added or removed, but that's an optimization for another time...) The attached image shows your example run through the new text-overlapping routine. I set the mplsizer border to 0.0 to make the effect more obvious. As you can see, the edges of the axes remain aligned. Unfortunately, axes that were the same *size* before adjusting for text are now different. I think this is a problem both aesthetically and for clarity, but it's hard to avoid given that mpl allows the user to arbitrarily put a new axes at any position whatsoever -- that is, there aren't any explicit relationships between axes to suggest that two or more axes should maintain the same aspect ratio. The subplot() API and the mplsizer API do help with that, though... maybe it's better to only do this with axes created that way, and leave arbitrarily placed axes alone. Food for thought... > Also, while you're working on this stuff, it would be really cool to be > able to automatically drop the axes spines off the data area. Our lab > makes lots of use of this style, and it would be very cool of MPL could > do this out of the box. Here's an example: > http://jeb.biologists.org/cgi/content/full/209/16/3170/FIG2 I don't know > how far off what you're currently doing this would be, but I figure it > can't hurt my cause too much to get the idea on your radar ;) Consider it in the long queue (which is generally a dynamic priority queue, not FIFO ;). Good to have things in the back of my mind as I'm looking elsewhere. [As an aside, I had a little trouble installing mplsizer. "python setup.py install" put an mplsizer egg in my site-packages, but "import matplotlib.toolkits.mplsizer" failed. >>> import matplotlib.toolkits.mplsizer as mplsizer Traceback (most recent call last): File "", line 1, in ImportError: No module named toolkits.mplsizer I was able to get this to work my manually copying the mplsizer/build/lib/matplotlib/toolkits/mplsizer directory to site-packages/matplotlib/toolkits/ . I have very little experience with eggs... is there something I'm doing wrong with the install?] Cheers, Mike > Michael Droettboom wrote: >> I have implemented (experimental) support for auto-shrinking of axes >> to prevent their tick labels, axis labels and titles from overlapping >> other axes. It's been tested on everything in backend_driver.py and >> seems to work fairly well, with a few minor glitches related to fixed >> aspect ratio axes and colorbars. >> >> The important user-visible change is that the position of an axes (as >> set by axes([l, b, w, h])) is now inclusive of the axis labels, tick >> labels and axes title. The auto-layout algorithm prevents (well, >> reduces) any of the text from going outside of that bounds. I >> couldn't figure out a good to maintain the old convention, where the >> axes position is the position of only the "data" area, since it makes >> it unclear, particularly with multi-axes figures, when text should be >> considered "out of bounds". With respect to the examples, this only >> affected a few of them where the position of the axes was manually >> nudged to make room for text. Simply removing those lines results in >> better-looking plots. Maybe this API change doesn't matter, but if it >> does, we can brainstorm ways around it. I'd prefer not to keep both >> ways alive indefinitely, but perhaps there is a good argument for that >> anyway. >> >> One of the considerations I made was to keep the axes aligned with one >> another. For example, if you have two axes stacked on top of one >> another, and one axes has large numbers on the y-axis, but the other >> does not, the left edge of both axes' data areas should remain >> aligned. The layout algorithm ensures that if an edge of an axes was >> aligned with other axes to begin with, it will always remain so. This >> applies whether the axes position was specified with "axes([l, b, w,
Re: [matplotlib-devel] .cvsignore
It looks like these are already set in the "SVN way" (maybe cvs2svn did it): > svn propget svn:ignore . build dist docs *.pyc .project matplotlibrc win32_static ...so it's probably safe to remove them, unless we plan to migrate back to CVS someday ;) Cheers, Mike Darren Dale wrote: > Is it safe to remove the instances of .cvsignore from the svn repository? > > - > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] .cvsignore
Is it safe to remove the instances of .cvsignore from the svn repository? - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Annotation 'data offset'
All, I have just submitted a patch to the Annotation class that allows specification of a 'data offset' frame for the text coordinate. This allows you to specify a data point to annotate and an offset that will stay the same regardless of scale. Please let me know if this should be given a different name (like 'offset' or 'point offset', etc). --James Evans - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Annotation 'data offset'
On Dec 5, 2007 6:14 PM, James Evans <[EMAIL PROTECTED]> wrote: > I have just submitted a patch to the Annotation class that allows > specification of a 'data offset' frame for the text coordinate. This allows > you to specify a data point to annotate and an offset that will stay the > same regardless of scale. Please let me know if this should be given a > different name (like 'offset' or 'point offset', etc). Hey James, thanks a lot for this patch. As you know, it has been on my TODO list :-) I made one minor change, which is to rename 'data offset' to 'offset points' since 'data' in the annotation coords refers to the native coordinate system. Since we have 'axes points' and the like, I thought 'offset points' would be most consistent. Anyhow, very useful! JDH - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
