matplotlib-devel Mailing List for matplotlib

On Tuesday 04 December 2007 5:21:38 pm John Hunter wrote:
> On Dec 4, 2007 4:16 PM, Darren Dale <dar...@co...> wrote:
> > Damn thats frustrating. I just repeated the same steps I took before I
> > wrote about finding a problem, and now everything is ok. Sorry for the
> > noise.
>
> Try flushing ~/.matplotlib and retest -- some of the bugs may be
> masked by the cache
Done, no errors.

On Dec 4, 2007 4:16 PM, Darren Dale <dar...@co...> wrote:
> Damn thats frustrating. I just repeated the same steps I took before I wrote
> about finding a problem, and now everything is ok. Sorry for the noise.
Try flushing ~/.matplotlib and retest -- some of the bugs may be
masked by the cache
JDH

On Tuesday 04 December 2007 4:06:19 pm John Hunter wrote:
> On Dec 4, 2007 2:17 PM, Darren Dale <dar...@co...> wrote:
> > I'm checking the matplotlib-0.91.1 gentoo ebuild that S=E9bastien Fabbro
> > put together. After installing, I get a number of errors when running
> > backend_driver.py that are probably related to MANIFEST.in: missing
> > pyplot and npyma. There are many other errors exposed by backend_driver
> > as well, but maybe some will clear up with an improved MANIFEST.
Damn thats frustrating. I just repeated the same steps I took before I wrot=
e=20
about finding a problem, and now everything is ok. Sorry for the noise.

Ted Drain wrote:
> 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 doesn't address that particular issue -- but I'd like to get to it 
at some point.
BTW - have you tried using figure().autofmt_xdate()? It will rotate the 
x-axis label to 30 degrees, which often helps with date plots. Not the 
whole solution, but may work in a bind...
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

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.
Ted
At 01:50 PM 12/4/2007, 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, h])" or "subplot(121)", or "axes().set_position([l, b, w, h])".
>
>Attached is an example where tick labels have been put in weird 
>places to demonstrate how all this works, with before and after pictures.
>
>Cheers,
>Mike
>
>--
>Michael Droettboom
>Science Software Branch
>Operations and Engineering Division
>Space Telescope Science Institute
>Operated by AURA for NASA
>
>
>
>#!/usr/bin/env python """ Example: simple line plot. Show how to 
>make and save a simple line plot with labels, title and grid """ 
>from pylab import * t = arange(0.0, 1.0+0.01, 0.01) s = 
>cos(2*2*pi*t) ax1 = subplot(211) plot(t, s, '-', lw=2) 
>xlabel('xlabel for bottom axes') ylabel('ylabel on the right') 
>title('About as simple as it gets, folks') grid(True) 
>ax1.yaxis.set_label_position('right') 
>ax1.xaxis.set_ticklabels(['Monday', 'Tuesday', 'Wednesday', 
>'Thursday', 'Friday']) for label in 
>ax1.get_xticklabels(): label.set_rotation(45) ax2 = subplot(212) 
>plot(t, s, '-', lw=2) grid(True) xlabel('xlabel for bottom axes (the 
>ticks are on the top for no good reason)') ylabel('I\'m a lefty') 
>ax2.xaxis.set_label_position('bottom') 
>ax2.xaxis.set_ticks_position('top') #savefig('simple_plot.png') 
>savefig('simple_plot') show()
>-------------------------------------------------------------------------
>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
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Ted Drain Jet Propulsion Laboratory ted...@jp... 

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, h])" or 
"subplot(121)", or "axes().set_position([l, b, w, h])".
Attached is an example where tick labels have been put in weird places 
to demonstrate how all this works, with before and after pictures.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Dec 4, 2007 2:17 PM, Darren Dale <dar...@co...> wrote:
> I'm checking the matplotlib-0.91.1 gentoo ebuild that S=E9bastien Fabbro =
put
> together. After installing, I get a number of errors when running
> backend_driver.py that are probably related to MANIFEST.in: missing pyplo=
t
> and npyma. There are many other errors exposed by backend_driver as well,=
 but
> maybe some will clear up with an improved MANIFEST.
Could you post some of the errors?
Thanks,
JDH

Darren Dale wrote:
> I'm checking the matplotlib-0.91.1 gentoo ebuild that Sébastien Fabbro put 
> together. After installing, I get a number of errors when running 
> backend_driver.py that are probably related to MANIFEST.in: missing pyplot 
> and npyma. There are many other errors exposed by backend_driver as well, but 
> maybe some will clear up with an improved MANIFEST.
pyplot.py is in lib, and MANIFEST.in already recursively includes 
everything in lib, so I don't think this is the problem.
npyma is inside of lib/numerix/, which again should not have required 
any change to MANIFEST.in.
Eric

On Tuesday 04 December 2007 9:18:14 am John Hunter wrote:
> Charlie is fixing a few problems with the release, and noticed that
> many of the new directories and files that have been created of late
> were not added to MANIFEST.in, which is used by sdist in the build
> process to build a correct source distribution. He added a few things
> (eg ttconv and setup.cfg.template) but please take a look over this
> file if you have made significant additions or reorganizations in the
> last 6 months to make sure everything is there. It picks up pattern
> matches recursively so it is usually enough to update with a new dir
> or wildcard, but please maintain this file as you contribute. It's
> easy to forget if you are not involved in the build, so I'll update
> the CODING_GUIDE
I'm checking the matplotlib-0.91.1 gentoo ebuild that S=E9bastien Fabbro pu=
t=20
together. After installing, I get a number of errors when running=20
backend_driver.py that are probably related to MANIFEST.in: missing pyplot=
=20
and npyma. There are many other errors exposed by backend_driver as well, b=
ut=20
maybe some will clear up with an improved MANIFEST.
Charlie, will you have time to upload an improved src distribution any time=
=20
soon?
Darren

Thanks. Fixed in r4590.
Cheers,
Mike
Jeff Whitaker wrote:
> Mike:
> 
> shading='faceted' doesn't work (no edges are drawn around the polygons).
> 
> -Jeff
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Charlie is fixing a few problems with the release, and noticed that
many of the new directories and files that have been created of late
were not added to MANIFEST.in, which is used by sdist in the build
process to build a correct source distribution. He added a few things
(eg ttconv and setup.cfg.template) but please take a look over this
file if you have made significant additions or reorganizations in the
last 6 months to make sure everything is there. It picks up pattern
matches recursively so it is usually enough to update with a new dir
or wildcard, but please maintain this file as you contribute. It's
easy to forget if you are not involved in the build, so I'll update
the CODING_GUIDE
JDH

Mike:
shading='faceted' doesn't work (no edges are drawn around the polygons).
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/PSD1 FAX : (303)497-6449
325 Broadway Boulder, CO, USA 80305-3328