matplotlib-users Mailing List for matplotlib (Page 7)

I see. Thanks, Ben.

-Soumyaroop

On Thu, May 12, 2011 at 10:32 AM, Benjamin Root <ben...@ou...> wrote:
> On Thursday, May 12, 2011, Soumyaroop Roy <roy...@gm...> wrote:
>> Here's a short follow up question:
>> Is there a concept of erasing in matplotlib? If I were to erase an
>> axvline that I drew earlier, how would I do that? Can you use del to
>> delete the object and then force a redraw?
>>
>> -Soumyaroop
>>
>> On Mon, May 2, 2011 at 11:35 AM, Soumyaroop Roy
>> <roy...@gm...> wrote:
>>> Thanks Justin. I have the event handling thing in place and was really
>>> looking for drawing options. Thanks for the tips. I'll look into them.
>>> regards,
>>> Soumyaroop
>>>
>>> On Mon, May 2, 2011 at 11:06 AM, Justin McCann <jn...@gm...> wrote:
>>>>
>>>> You'll want to use event handling to figure out where the user clicked,
>>>> and then you have a couple of options: Axes.vlines(), or pylab.axvline(). It
>>>> seems like pylab.axvline() will always span the entire y-axis by default,
>>>> but with Axes.vlines() you need to specify the ymin/ymax. Maybe someone else
>>>> knows of an argument to pass to Axes.vlines() that will always span the
>>>> entire y-axis.
>>>> Here's the code (assuming 'ipython -pylab'):
>>>> ========
>>>> fig = figure()
>>>> plot([1,2,3,4], [5,6,7,8])
>>>> def onclick(event):
>>>>     """Draw a vertical line spanning the axes every time the user clicks
>>>> inside them"""
>>>>     if event.inaxes: # make sure the click was within a set of axes
>>>>         pylab.axvline(event.xdata, axes=event.inaxes, color='r',
>>>> linestyle=':') # red dotted line
>>>>         event.inaxes.figure.canvas.draw() # force a re-draw
>>>> cid = fig.canvas.mpl_connect('button_press_event', onclick) # add the
>>>> click handler
>>>> ... interact with it
>>>> fig.canvas.mpl_disconnect(cid) # get rid of the click-handler
>>>> ========
>>>> Docs:
>>>> Axes.vlines():
>>>> http://matplotlib.sourceforge.net/api/axes_api.html#matplotlib.axes.Axes.vlines
>>>> pyplot.axvline():
>>>> http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.axvline
>>>> Event
>>>> handling: http://matplotlib.sourceforge.net/users/event_handling.html
>>>>
>>>> Example: http://matplotlib.sourceforge.net/examples/event_handling/data_browser.html
>>>>    Justin
>>>>
>>>> On Mon, May 2, 2011 at 10:08 AM, Soumyaroop Roy <roy...@gm...>
>>>> wrote:
>>>>>
>>>>> Any pointers on this?
>>>>> On Sat, Apr 30, 2011 at 12:34 AM, Soumyaroop Roy
>>>>> <roy...@gm...> wrote:
>>>>>>
>>>>>> Hi there:
>>>>>> I have an x-y plot and I want to draw a vertical marker (an x=c line) on
>>>>>> the plot on a mouse click.
>>>>>> How should I approach it?
>>>>>> regards,
>>>>>> Soumyaroop
>>>>>
>>>>>
>
> No, don't use del. If you save the object returned by the call to
> axvline, then you should be able to call its .remove() method.
>
> That should do the proper bookkeeping.
>
> Ben Root
>

You can always get a tarball of the current git master by going here:

https://github.com/matplotlib/matplotlib

clicking on "Download" and choosing one of the "download source" options 
at the top of the popup box.

Mike

On 05/11/2011 11:07 AM, C M wrote:
> On Wed, May 11, 2011 at 11:07 AM, C M<cmp...@gm...>  wrote:
>    
>> On Wed, May 11, 2011 at 12:29 AM, Jae-Joon Lee<lee...@gm...>  wrote:
>>      
>>> I think I fixed a similar bug at some point but I'm not sure if that
>>> is related with this.
>>> Are you using the *make_axes_area_auto_adjustable* from the current
>>> git master (check
>>> examples/axes_grid/make_room_for_ylabel_using_axesgrid.py)? If not can
>>> you try that? Also please post your code.
>>>        
>>      
> I have not set up with git since Matplotlib made the change from svn.
> I just downloaded git to get started but don't know how to use it yet;
> for now is there a way to just check out the files I need to test
> this, or is there some other (non-git) way to get this update?
>
> Thanks,
> Che
>
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>    


-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

On Thursday, May 12, 2011, Soumyaroop Roy <roy...@gm...> wrote:
> Here's a short follow up question:
> Is there a concept of erasing in matplotlib? If I were to erase an
> axvline that I drew earlier, how would I do that? Can you use del to
> delete the object and then force a redraw?
>
> -Soumyaroop
>
> On Mon, May 2, 2011 at 11:35 AM, Soumyaroop Roy
> <roy...@gm...> wrote:
>> Thanks Justin. I have the event handling thing in place and was really
>> looking for drawing options. Thanks for the tips. I'll look into them.
>> regards,
>> Soumyaroop
>>
>> On Mon, May 2, 2011 at 11:06 AM, Justin McCann <jn...@gm...> wrote:
>>>
>>> You'll want to use event handling to figure out where the user clicked,
>>> and then you have a couple of options: Axes.vlines(), or pylab.axvline(). It
>>> seems like pylab.axvline() will always span the entire y-axis by default,
>>> but with Axes.vlines() you need to specify the ymin/ymax. Maybe someone else
>>> knows of an argument to pass to Axes.vlines() that will always span the
>>> entire y-axis.
>>> Here's the code (assuming 'ipython -pylab'):
>>> ========
>>> fig = figure()
>>> plot([1,2,3,4], [5,6,7,8])
>>> def onclick(event):
>>>     """Draw a vertical line spanning the axes every time the user clicks
>>> inside them"""
>>>     if event.inaxes: # make sure the click was within a set of axes
>>>         pylab.axvline(event.xdata, axes=event.inaxes, color='r',
>>> linestyle=':') # red dotted line
>>>         event.inaxes.figure.canvas.draw() # force a re-draw
>>> cid = fig.canvas.mpl_connect('button_press_event', onclick) # add the
>>> click handler
>>> ... interact with it
>>> fig.canvas.mpl_disconnect(cid) # get rid of the click-handler
>>> ========
>>> Docs:
>>> Axes.vlines():
>>> http://matplotlib.sourceforge.net/api/axes_api.html#matplotlib.axes.Axes.vlines
>>> pyplot.axvline():
>>> http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.axvline
>>> Event
>>> handling: http://matplotlib.sourceforge.net/users/event_handling.html
>>>
>>> Example: http://matplotlib.sourceforge.net/examples/event_handling/data_browser.html
>>>    Justin
>>>
>>> On Mon, May 2, 2011 at 10:08 AM, Soumyaroop Roy <roy...@gm...>
>>> wrote:
>>>>
>>>> Any pointers on this?
>>>> On Sat, Apr 30, 2011 at 12:34 AM, Soumyaroop Roy
>>>> <roy...@gm...> wrote:
>>>>>
>>>>> Hi there:
>>>>> I have an x-y plot and I want to draw a vertical marker (an x=c line) on
>>>>> the plot on a mouse click.
>>>>> How should I approach it?
>>>>> regards,
>>>>> Soumyaroop
>>>>
>>>>

No, don't use del. If you save the object returned by the call to
axvline, then you should be able to call its .remove() method.

That should do the proper bookkeeping.

Ben Root

Hello again,

I tried the script you provided to test the PolyCollection and that works fine.
I am working under Mac OS X 10.6.6 Snow Leopard and use matplotlib 1.0.1.

That is the script where I fail with eps but not with pdf:



import matplotlib.pyplot as plt
import numpy
from scipy import stats

p=0.3
m=0
s1min=120
s1max=140
s2min=1200
s2max=1600

x = numpy.arange((s2max*-1.5), (s2max*1.5), 0.2)

def pdf(x,s1,s2):
    return p * stats.norm.pdf(x, loc=m, scale=s1) + (1-p) * stats.norm.pdf(x, loc=m, scale=s2)


pdf_min = pdf(x,s1min,s2min)
pdf_max = pdf(x,s1max,s2max)

plt.plot(x, pdf_min, x, pdf_max, color="k")
plt.fill_between(x, pdf_min, pdf_max, color='0.85')


#plt.show()
#plt.savefig("testplot.eps")
plt.savefig("testplot.pdf")


/Johannes

Am 12.05.2011 um 15:28 schrieb John Hunter:

> 
> 
> On Thu, May 12, 2011 at 3:42 AM, Johannes Radinger <JRa...@gm...> wrote:
> Hello ,
> 
> sofar I know how to safe a plot into a *.eps file and it works good,
> but there is one issue with filled areas between two functions.
> 
> When I try to use:
> plt.fill_between(x, pdf_min, pdf_max, color='0.85')
> 
> and I try to open it on my mac I fail. So far as I know
> is the mac converting the eps internally to pdf to be
> displayed, but it seems it can't be converted.
> 
> If I try to set the output to *.pdf it works perfectly and I can
> open the file. Something in the combination of fill_between
> and eps is causing the error. I tried also color="red" but with
> the same problems.
> 
> Is there anything I've to set because I need the output as
> a working eps.
> 
> 
> under the hool, fill_between uses a PolyCollection.  Below is a simple example which uses a PolyCollection directly.  Does this crash when you convert eps -> pdf.  If not, maybe we can hone in on what is special about the vertices in your fill_between example.  Also, you should give us some information about what version of matplotlib and OSX you are running.
> 
> 
> import numpy as np
> import matplotlib.collections as mcollections
> import matplotlib.pyplot as plt
> 
> theta = np.linspace(0, 2*np.pi, 20)
> x1 = np.cos(theta)
> y1 = np.sin(theta)
> 
> x2 = x1 + 5
> y2 = y1 + 5
> 
> verts1 = zip(x1, y1)
> verts2 = zip(x2, y2)
> 
> c = mcollections.PolyCollection([verts1, verts2], facecolors=['red', 'green'])
> 
> ax = plt.subplot(111)
> ax.add_collection(c)
> ax.axis([-5, 10, -5, 10])
> 
> plt.savefig('test.eps')
> plt.show()
> 

Here's a short follow up question:
Is there a concept of erasing in matplotlib? If I were to erase an
axvline that I drew earlier, how would I do that? Can you use del to
delete the object and then force a redraw?

-Soumyaroop

On Mon, May 2, 2011 at 11:35 AM, Soumyaroop Roy
<roy...@gm...> wrote:
> Thanks Justin. I have the event handling thing in place and was really
> looking for drawing options. Thanks for the tips. I'll look into them.
> regards,
> Soumyaroop
>
> On Mon, May 2, 2011 at 11:06 AM, Justin McCann <jn...@gm...> wrote:
>>
>> You'll want to use event handling to figure out where the user clicked,
>> and then you have a couple of options: Axes.vlines(), or pylab.axvline(). It
>> seems like pylab.axvline() will always span the entire y-axis by default,
>> but with Axes.vlines() you need to specify the ymin/ymax. Maybe someone else
>> knows of an argument to pass to Axes.vlines() that will always span the
>> entire y-axis.
>> Here's the code (assuming 'ipython -pylab'):
>> ========
>> fig = figure()
>> plot([1,2,3,4], [5,6,7,8])
>> def onclick(event):
>>     """Draw a vertical line spanning the axes every time the user clicks
>> inside them"""
>>     if event.inaxes: # make sure the click was within a set of axes
>>         pylab.axvline(event.xdata, axes=event.inaxes, color='r',
>> linestyle=':') # red dotted line
>>         event.inaxes.figure.canvas.draw() # force a re-draw
>> cid = fig.canvas.mpl_connect('button_press_event', onclick) # add the
>> click handler
>> ... interact with it
>> fig.canvas.mpl_disconnect(cid) # get rid of the click-handler
>> ========
>> Docs:
>> Axes.vlines():
>> http://matplotlib.sourceforge.net/api/axes_api.html#matplotlib.axes.Axes.vlines
>> pyplot.axvline():
>> http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.axvline
>> Event
>> handling: http://matplotlib.sourceforge.net/users/event_handling.html
>>
>> Example: http://matplotlib.sourceforge.net/examples/event_handling/data_browser.html
>>    Justin
>>
>> On Mon, May 2, 2011 at 10:08 AM, Soumyaroop Roy <roy...@gm...>
>> wrote:
>>>
>>> Any pointers on this?
>>> On Sat, Apr 30, 2011 at 12:34 AM, Soumyaroop Roy
>>> <roy...@gm...> wrote:
>>>>
>>>> Hi there:
>>>> I have an x-y plot and I want to draw a vertical marker (an x=c line) on
>>>> the plot on a mouse click.
>>>> How should I approach it?
>>>> regards,
>>>> Soumyaroop
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> WhatsUp Gold - Download Free Network Management Software
>>> The most intuitive, comprehensive, and cost-effective network
>>> management toolset available today.  Delivers lowest initial
>>> acquisition cost and overall TCO of any competing solution.
>>> http://p.sf.net/sfu/whatsupgold-sd
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>
>>
>
>

On Thu, May 12, 2011 at 3:42 AM, Johannes Radinger <JRa...@gm...> wrote:

> Hello ,
>
> sofar I know how to safe a plot into a *.eps file and it works good,
> but there is one issue with filled areas between two functions.
>
> When I try to use:
> plt.fill_between(x, pdf_min, pdf_max, color='0.85')
>
> and I try to open it on my mac I fail. So far as I know
> is the mac converting the eps internally to pdf to be
> displayed, but it seems it can't be converted.
>
> If I try to set the output to *.pdf it works perfectly and I can
> open the file. Something in the combination of fill_between
> and eps is causing the error. I tried also color="red" but with
> the same problems.
>
> Is there anything I've to set because I need the output as
> a working eps.
>


under the hool, fill_between uses a PolyCollection.  Below is a simple
example which uses a PolyCollection directly.  Does this crash when you
convert eps -> pdf.  If not, maybe we can hone in on what is special about
the vertices in your fill_between example.  Also, you should give us some
information about what version of matplotlib and OSX you are running.


import numpy as np
import matplotlib.collections as mcollections
import matplotlib.pyplot as plt

theta = np.linspace(0, 2*np.pi, 20)
x1 = np.cos(theta)
y1 = np.sin(theta)

x2 = x1 + 5
y2 = y1 + 5

verts1 = zip(x1, y1)
verts2 = zip(x2, y2)

c = mcollections.PolyCollection([verts1, verts2], facecolors=['red',
'green'])

ax = plt.subplot(111)
ax.add_collection(c)
ax.axis([-5, 10, -5, 10])

plt.savefig('test.eps')
plt.show()

Hello,

I am trying to generate on the fly a non linear rainbow colorbar as in
picture Colorbar below.

I use a slider to automatically modify the aspect of the colorbar (see code
below).
This works fine except that I want to have a different behaviour of the
colorbar when moving the slider:
My wish is to have the limits of the colorbar remain fixed (cmin and cmax),
but the rainbow range should be shrinked (though the tick label of the
colorbar should not be modified).
 
I am seaching around using matplotlib.colors.LinearSegmentedColormap without
any success.
Should in this case the colormap be completly re created each time the
slider moves, or is it possible using any kwargs to automatically change the
behaviour of the colorbar as I wanted ?

Many thanks in advance for any help...



See example below, where the colorbar cmax limit is changed, whereas I
wanted that it remains fixed and the shape of the colorbar rainbow
decreases.


from matplotlib.pylab import *
import matplotlib.pyplot as plt
from matplotlib.widgets import Slider

sizeX = 4
sizeY = 21

dims = ( sizeY, sizeX )

data = zeros( dims )
for x in range( 0, sizeX ):
  for y in range( 0, sizeY ):
    data[ y, x ] = y

figure = plt.figure()
axes = figure.add_subplot( 111 )
figure.subplots_adjust(left=0.25, bottom=0.25)

cax = axes.matshow( data, aspect = 'auto', interpolation = 'nearest' )
col = figure.colorbar( cax, spacing='proportional', extend='min' )

vmax = 50
axmax  = figure.add_axes([0.25, 0.15, 0.65, 0.03],
axisbg='lightgoldenrodyellow')
smax = Slider( axmax, 'Max', 0, vmax, valinit = vmax )
cax.set_clim( vmin = 0, vmax = vmax )

def update(val):
  
    cax.set_clim( vmin = 0, vmax = smax.val )
    figure.canvas.draw()
    
smax.on_changed( update )


http://old.nabble.com/file/p31602280/Colorbar.png Colorbar.png 
-- 
View this message in context: http://old.nabble.com/Creating-non-linear-colorbar-Colorbar-tp31602280p31602280.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Hello ,

sofar I know how to safe a plot into a *.eps file and it works good,
but there is one issue with filled areas between two functions.

When I try to use:
plt.fill_between(x, pdf_min, pdf_max, color='0.85')

and I try to open it on my mac I fail. So far as I know
is the mac converting the eps internally to pdf to be
displayed, but it seems it can't be converted.

If I try to set the output to *.pdf it works perfectly and I can
open the file. Something in the combination of fill_between
and eps is causing the error. I tried also color="red" but with
the same problems.

Is there anything I've to set because I need the output as
a working eps.

/johannes

On Thu, May 12, 2011 at 7:18 AM, David Andrews <irb...@gm...> wrote:
> I'm quite interested in getting involved with mpl development, partly
> as a way to get my head around python & numpy and aid porting a bunch
> of stuff I use over to python from IDL.  Unless I'm doing something
> totally wrong by expecting the above snippet to work, then I'd happily
> spend some time looking into this in more detail, having written some
> similar code in IDL.  The docs for that module also look like they
> could benefit from some work.
>

Yes, the docs need lots of work I guess and any contribution will be
greatly appreciated.
If you're willing to improve the docs for gridspec, I'm more than
happy to help you (I am the main author of that module).
The best way to contribute is to use github pull request and
matplotlib is hosted here

 https://github.com/matplotlib/matplotlib

Regards,

-JJ

Yes, this is a bug that has been fixed.

https://github.com/matplotlib/matplotlib/commit/76851eb

Regards,

-JJ


On Thu, May 12, 2011 at 7:53 AM, Goyo <goy...@gm...> wrote:
> 2011/5/12 David Andrews <irb...@gm...>:
>> Hi,
>>
>> I've come across something I don't entirely understand in the
>> behaviour of gridspec.  It's not obvious from the code & docs for this
>> module, but is it only supposed to be able to deal with 'square'
>> layouts, e.g. 3x3, 4x4 etc?
>>
>> Taking some code from an example on the gridspec page ...
>>
>> import matplotlib.pylab as plt
>> import matplotlib.gridspec as gridspec
>> #gs = gridspec.GridSpec(3, 3) # OK
>> gs = gridspec.GridSpec(6, 3) # Will cause an error later on
>> ax1 = plt.subplot(gs[0, :])
>> ax2 = plt.subplot(gs[1,:-1])
>> ax3 = plt.subplot(gs[1:,-1])
>> ax4 = plt.subplot(gs[-1,0])
>> ax5 = plt.subplot(gs[-1,-2])
>> plt.show()
>>
>> ... will fail if that line is uncommented, giving an index error.
>
> Works for me.
> Ubuntu 11.04 Natty, stock python 2.7.1 and matplotlib 1.0.1 from
> https://launchpad.net/~valavanisalex/+archive/matplotlib.
>
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

On Thu, May 12, 2011 at 2:59 AM, Benjamin Root <ben...@ou...> wrote:
> Most things, we do know the sizes of.  It is my understanding that it is the
> text objects that is the unknown.  If this could be solved, then a layout
> engine would be much more feasible.

I doubt it. As far as I know, the main reason that things needed to be
drawn is because the location and size of some artist depends on
location and size of other artists.
Unfortunately, with current matplotlib code, most of these things are
determined inside the "draw" method. Therefore, we need to separate
out those things out from the draw method.

Another option, which I think is more feasible, is to implement a
BBoxRenderer which does not draw anything but only update the size and
location of artists.

Regards,

-JJ

> The problem is that even LaTeX has to
> re-render things multiple times to get this right for an arbitrary font.  If
> we were to restrict ourselves to particular fonts and package those fonts
> with matplotlib, then we could have an internal table of size information
> for each glyph and compute it on the fly and lay everything out right.  But,
> that would cause us to give up significant benefits for another benefit.

On Thu, May 12, 2011 at 2:37 AM, Brendan Barnwell <bre...@br...> wrote:
> One thing I've always wondered: is it fundamentally impossible to change the
> fact that, in matplotlib, you cannot know how big a drawn object will be
> until you actually draw it?

Well, I don't think this is 100% correct. As far as I can see, there
is two issues involved.

 1) size of text may depend on the renderer (since font selection
could be different).

 2) Position of some artist depend on position of other artist (e.g.,
the exact location of axis label depend on sizes of tick labels).

In fact, neither of these "require" drawing. But, the easiest way is
to draw it (primarily due to the second point).

Can you describe what you were doing with your animation?
Matplotlib provide some framework to overcome these limitation (e.g.,
classes in the offsetbox module). And there may be easier ways that
does what you want.

Regards,

-JJ

2011/5/12 David Andrews <irb...@gm...>:
> Hi,
>
> I've come across something I don't entirely understand in the
> behaviour of gridspec.  It's not obvious from the code & docs for this
> module, but is it only supposed to be able to deal with 'square'
> layouts, e.g. 3x3, 4x4 etc?
>
> Taking some code from an example on the gridspec page ...
>
> import matplotlib.pylab as plt
> import matplotlib.gridspec as gridspec
> #gs = gridspec.GridSpec(3, 3) # OK
> gs = gridspec.GridSpec(6, 3) # Will cause an error later on
> ax1 = plt.subplot(gs[0, :])
> ax2 = plt.subplot(gs[1,:-1])
> ax3 = plt.subplot(gs[1:,-1])
> ax4 = plt.subplot(gs[-1,0])
> ax5 = plt.subplot(gs[-1,-2])
> plt.show()
>
> ... will fail if that line is uncommented, giving an index error.

Works for me.
Ubuntu 11.04 Natty, stock python 2.7.1 and matplotlib 1.0.1 from
https://launchpad.net/~valavanisalex/+archive/matplotlib.

Hi,

I've come across something I don't entirely understand in the
behaviour of gridspec.  It's not obvious from the code & docs for this
module, but is it only supposed to be able to deal with 'square'
layouts, e.g. 3x3, 4x4 etc?

Taking some code from an example on the gridspec page ...

import matplotlib.pylab as plt
import matplotlib.gridspec as gridspec
#gs = gridspec.GridSpec(3, 3) # OK
gs = gridspec.GridSpec(6, 3) # Will cause an error later on
ax1 = plt.subplot(gs[0, :])
ax2 = plt.subplot(gs[1,:-1])
ax3 = plt.subplot(gs[1:,-1])
ax4 = plt.subplot(gs[-1,0])
ax5 = plt.subplot(gs[-1,-2])
plt.show()

... will fail if that line is uncommented, giving an index error.  I
don't see any reason why these slices should fail however, though
obviously it won't use all the available space within the whole grid?
Substituting a 'square' grid for the (6,3), e.g. (4,4), (5,5) etc
seems to be fine though.

I'm quite interested in getting involved with mpl development, partly
as a way to get my head around python & numpy and aid porting a bunch
of stuff I use over to python from IDL.  Unless I'm doing something
totally wrong by expecting the above snippet to work, then I'd happily
spend some time looking into this in more detail, having written some
similar code in IDL.  The docs for that module also look like they
could benefit from some work.

Cheers,

Dave

---------
David Andrews
PhD Student, Radio & Space Plasma Physics Group, University of Leicester, UK

2011/5/11 calle <ka...@we...>:
> [...]
> So is there for example a way to set sth like
>
> axes([0.125,0.2,0.95-0.125,0.95-0.2])
>
> or alike without the need to repeat it for every single plot?

Not that I'm aware of. But in what sense is that worst than repeat
subplot() for every single plot? Yes there are magic numbers there but
subplot also uses magic numbers under the hood, if I'm not wrong.

You can wrap your axes call into another function so at least the
magic numbers are not visible in the higher level code if they are
always the same.

Goyo

On Wed, May 11, 2011 at 4:31 PM, Eric Firing <ef...@ha...> wrote:

> On 05/11/2011 09:11 AM, Benjamin Root wrote:
> >
> >
> > On Wed, May 11, 2011 at 1:43 PM, todd rme <tod...@gm...
> > <mailto:tod...@gm...>> wrote:
> >
> >     On Wed, May 11, 2011 at 1:59 PM, Benjamin Root <ben...@ou...
> >     <mailto:ben...@ou...>> wrote:
> >      >
> >      >
> >      > On Wed, May 11, 2011 at 12:47 PM, Brendan Barnwell
> >     <bre...@br... <mailto:bre...@br...>>
> >      > wrote:
> >      >>        One thing I've always wondered: is it fundamentally
> >     impossible to
> >      >> change the fact that, in matplotlib, you cannot know how big a
> drawn
> >      >> object will be until you actually draw it?  When I was doing some
> >      >> animation stuff a while back this caused me a lot of headache,
> >     for the
> >      >> reasons Tony Yu mentioned: it means you have to draw everything
> >      >> multiple times.  It would really help if it were possible to
> specify
> >      >> objects' parameters and get their sizes without drawing them.
> >      >>
> >      >> -- Brendan Barnwell
> >      >> "Do not follow where the path may lead. Go, instead, where there
> >     is no
> >      >> path, and leave a trail." --author unknown
> >      >>
> >      >
> >      > Most things, we do know the sizes of.  It is my understanding
> >     that it is the
> >      > text objects that is the unknown.  If this could be solved, then
> >     a layout
> >      > engine would be much more feasible.  The problem is that even
> >     LaTeX has to
> >      > re-render things multiple times to get this right for an
> >     arbitrary font.  If
> >      > we were to restrict ourselves to particular fonts and package
> >     those fonts
> >      > with matplotlib, then we could have an internal table of size
> >     information
> >      > for each glyph and compute it on the fly and lay everything out
> >     right.  But,
> >      > that would cause us to give up significant benefits for another
> >     benefit.
> >      >
> >      > I think the pain of the bootstrapping/re-rendering approach could
> >     be reduced
> >      > significantly if we could get various aspects of matplotlib
> >     figure building
> >      > to be faster.  Last time I checked, there is significant amount of
> >      > processing time spent in calculating the ticks for the axes.
> >     Maybe if we
> >      > focus some efforts in improving the efficiency of certain parts of
> >      > matplotlib, maybe we could introduce a convenience function like
> >     the one
> >      > earlier in this thread that some users can choose to use with
> >     only a slight
> >      > penalty in speed.  I personally would not want to make it
> >     default, but
> >      > certainly would consider highly advertising such a function.
> >      >
> >      > Just my two cents,
> >      > Ben Root
> >
> >     Perhaps there could be three options:
> >
> >     1. Manual mode: current behavior
> >     2. Database mode: uses a list of known fonts.  When a font not found
> >     in the database is used, it falls back to manual mode.
> >     3. Automatic mode: uses a list of known fonts.  When a font not found
> >     in the database is used, it renders the text alone in an invisible
> >     figure to calculate the space needed, then uses that information to
> >     set the margins.  Alternatively, create a temporary mini font
> database
> >     just for the characters needed.  The former approach may be faster,
> >     but the latter may be easier to program since it could share a lot of
> >     code with the database.
> >
> >     There could also be a function to scan a particular font and add to
> >     the database (there would probably be a separate user database in
> your
> >     matplotlib configuration directory that this would use, as well as
> >     probably caching the measurements from text used in automatic mode
> for
> >     future versions of the figure).
> >
> >     -Todd
> >
> >
> > That might be a possible direction.  Obviously, any route taken will
> > have to be well thought-out and designed.  What is great about moving
> > over to git is that the user community can easily experiment on larger
> > changes to the code-base, and make it easier for others to test out
> > experimental designs and collaborate.  I encourage those in this thread
> > to make a fork of matplotlib on github and experiment with some of these
> > ideas and we all can play around with some of these parts.
> >
> > As a further bit of information, I believe that there is an old project
> > that attempted a layout engine for matplotlib
> > (https://github.com/matplotlib/mplsizer). I have never used it, nor do I
> > have any idea if it still works, but it may be an interesting codebase
> > to start from.
> >
> > As a further comment about a database of text size information.  An
> > interesting complication I just noticed are fonts that allow certain
> > combinations of characters to overlap a bit.  For example, right now I
> > noticed that using Gils Sans in LibreOffice that the word "Tracking" has
> > the 'r' in with the 'T'.  Calculating the amount of space a particular
> > set of characters might take up may not be very straight-forward.
>
> The calculation doesn't have to be perfect, it just has to be good
> enough for layout purposes.  If one were to ignore kerning, the
> predicted width of a text string would be slightly larger than the
> actual size.  I don't think this would cause serious layout problems.
>
> But--is doing the calculation this way actually much faster than letting
> the renderer do it?  Enough to be worth building and maintaining all the
> extra machinery?
>
> Eric
>
>
Kerning, that's the term. I couldn't think of it...

As for the issue about is it worth it to have all of this extra machinery,
that was pretty much my point of the email.  If someone wants to see if they
can make an elegant solution that works well and is easy to maintain, then I
would have no problem including it into the codebase.  However, I am very
doubtful of that and I would rather see effort in improving the efficiency
of various parts of matplotlib so that various brute-force approaches to
layout will have less time penalty.  Plus, it wouldn't hurt to have faster
graphics generation for the rest of us, either!

Ben Root

On 05/11/2011 09:11 AM, Benjamin Root wrote:
>
>
> On Wed, May 11, 2011 at 1:43 PM, todd rme <tod...@gm...
> <mailto:tod...@gm...>> wrote:
>
>     On Wed, May 11, 2011 at 1:59 PM, Benjamin Root <ben...@ou...
>     <mailto:ben...@ou...>> wrote:
>      >
>      >
>      > On Wed, May 11, 2011 at 12:47 PM, Brendan Barnwell
>     <bre...@br... <mailto:bre...@br...>>
>      > wrote:
>      >>        One thing I've always wondered: is it fundamentally
>     impossible to
>      >> change the fact that, in matplotlib, you cannot know how big a drawn
>      >> object will be until you actually draw it?  When I was doing some
>      >> animation stuff a while back this caused me a lot of headache,
>     for the
>      >> reasons Tony Yu mentioned: it means you have to draw everything
>      >> multiple times.  It would really help if it were possible to specify
>      >> objects' parameters and get their sizes without drawing them.
>      >>
>      >> -- Brendan Barnwell
>      >> "Do not follow where the path may lead. Go, instead, where there
>     is no
>      >> path, and leave a trail." --author unknown
>      >>
>      >
>      > Most things, we do know the sizes of.  It is my understanding
>     that it is the
>      > text objects that is the unknown.  If this could be solved, then
>     a layout
>      > engine would be much more feasible.  The problem is that even
>     LaTeX has to
>      > re-render things multiple times to get this right for an
>     arbitrary font.  If
>      > we were to restrict ourselves to particular fonts and package
>     those fonts
>      > with matplotlib, then we could have an internal table of size
>     information
>      > for each glyph and compute it on the fly and lay everything out
>     right.  But,
>      > that would cause us to give up significant benefits for another
>     benefit.
>      >
>      > I think the pain of the bootstrapping/re-rendering approach could
>     be reduced
>      > significantly if we could get various aspects of matplotlib
>     figure building
>      > to be faster.  Last time I checked, there is significant amount of
>      > processing time spent in calculating the ticks for the axes.
>     Maybe if we
>      > focus some efforts in improving the efficiency of certain parts of
>      > matplotlib, maybe we could introduce a convenience function like
>     the one
>      > earlier in this thread that some users can choose to use with
>     only a slight
>      > penalty in speed.  I personally would not want to make it
>     default, but
>      > certainly would consider highly advertising such a function.
>      >
>      > Just my two cents,
>      > Ben Root
>
>     Perhaps there could be three options:
>
>     1. Manual mode: current behavior
>     2. Database mode: uses a list of known fonts.  When a font not found
>     in the database is used, it falls back to manual mode.
>     3. Automatic mode: uses a list of known fonts.  When a font not found
>     in the database is used, it renders the text alone in an invisible
>     figure to calculate the space needed, then uses that information to
>     set the margins.  Alternatively, create a temporary mini font database
>     just for the characters needed.  The former approach may be faster,
>     but the latter may be easier to program since it could share a lot of
>     code with the database.
>
>     There could also be a function to scan a particular font and add to
>     the database (there would probably be a separate user database in your
>     matplotlib configuration directory that this would use, as well as
>     probably caching the measurements from text used in automatic mode for
>     future versions of the figure).
>
>     -Todd
>
>
> That might be a possible direction.  Obviously, any route taken will
> have to be well thought-out and designed.  What is great about moving
> over to git is that the user community can easily experiment on larger
> changes to the code-base, and make it easier for others to test out
> experimental designs and collaborate.  I encourage those in this thread
> to make a fork of matplotlib on github and experiment with some of these
> ideas and we all can play around with some of these parts.
>
> As a further bit of information, I believe that there is an old project
> that attempted a layout engine for matplotlib
> (https://github.com/matplotlib/mplsizer). I have never used it, nor do I
> have any idea if it still works, but it may be an interesting codebase
> to start from.
>
> As a further comment about a database of text size information.  An
> interesting complication I just noticed are fonts that allow certain
> combinations of characters to overlap a bit.  For example, right now I
> noticed that using Gils Sans in LibreOffice that the word "Tracking" has
> the 'r' in with the 'T'.  Calculating the amount of space a particular
> set of characters might take up may not be very straight-forward.

The calculation doesn't have to be perfect, it just has to be good 
enough for layout purposes.  If one were to ignore kerning, the 
predicted width of a text string would be slightly larger than the 
actual size.  I don't think this would cause serious layout problems.

But--is doing the calculation this way actually much faster than letting 
the renderer do it?  Enough to be worth building and maintaining all the 
extra machinery?

Eric

>
> Just another 2 cents,
> Ben Root
>
>
>
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
>
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

On Wed, May 11, 2011 at 1:43 PM, todd rme <tod...@gm...> wrote:

> On Wed, May 11, 2011 at 1:59 PM, Benjamin Root <ben...@ou...> wrote:
> >
> >
> > On Wed, May 11, 2011 at 12:47 PM, Brendan Barnwell <
> bre...@br...>
> > wrote:
> >>        One thing I've always wondered: is it fundamentally impossible to
> >> change the fact that, in matplotlib, you cannot know how big a drawn
> >> object will be until you actually draw it?  When I was doing some
> >> animation stuff a while back this caused me a lot of headache, for the
> >> reasons Tony Yu mentioned: it means you have to draw everything
> >> multiple times.  It would really help if it were possible to specify
> >> objects' parameters and get their sizes without drawing them.
> >>
> >> -- Brendan Barnwell
> >> "Do not follow where the path may lead. Go, instead, where there is no
> >> path, and leave a trail." --author unknown
> >>
> >
> > Most things, we do know the sizes of.  It is my understanding that it is
> the
> > text objects that is the unknown.  If this could be solved, then a layout
> > engine would be much more feasible.  The problem is that even LaTeX has
> to
> > re-render things multiple times to get this right for an arbitrary font.
> If
> > we were to restrict ourselves to particular fonts and package those fonts
> > with matplotlib, then we could have an internal table of size information
> > for each glyph and compute it on the fly and lay everything out right.
> But,
> > that would cause us to give up significant benefits for another benefit.
> >
> > I think the pain of the bootstrapping/re-rendering approach could be
> reduced
> > significantly if we could get various aspects of matplotlib figure
> building
> > to be faster.  Last time I checked, there is significant amount of
> > processing time spent in calculating the ticks for the axes.  Maybe if we
> > focus some efforts in improving the efficiency of certain parts of
> > matplotlib, maybe we could introduce a convenience function like the one
> > earlier in this thread that some users can choose to use with only a
> slight
> > penalty in speed.  I personally would not want to make it default, but
> > certainly would consider highly advertising such a function.
> >
> > Just my two cents,
> > Ben Root
>
> Perhaps there could be three options:
>
> 1. Manual mode: current behavior
> 2. Database mode: uses a list of known fonts.  When a font not found
> in the database is used, it falls back to manual mode.
> 3. Automatic mode: uses a list of known fonts.  When a font not found
> in the database is used, it renders the text alone in an invisible
> figure to calculate the space needed, then uses that information to
> set the margins.  Alternatively, create a temporary mini font database
> just for the characters needed.  The former approach may be faster,
> but the latter may be easier to program since it could share a lot of
> code with the database.
>
> There could also be a function to scan a particular font and add to
> the database (there would probably be a separate user database in your
> matplotlib configuration directory that this would use, as well as
> probably caching the measurements from text used in automatic mode for
> future versions of the figure).
>
> -Todd
>
>
That might be a possible direction.  Obviously, any route taken will have to
be well thought-out and designed.  What is great about moving over to git is
that the user community can easily experiment on larger changes to the
code-base, and make it easier for others to test out experimental designs
and collaborate.  I encourage those in this thread to make a fork of
matplotlib on github and experiment with some of these ideas and we all can
play around with some of these parts.

As a further bit of information, I believe that there is an old project that
attempted a layout engine for matplotlib (
https://github.com/matplotlib/mplsizer). I have never used it, nor do I have
any idea if it still works, but it may be an interesting codebase to start
from.

As a further comment about a database of text size information.  An
interesting complication I just noticed are fonts that allow certain
combinations of characters to overlap a bit.  For example, right now I
noticed that using Gils Sans in LibreOffice that the word "Tracking" has the
'r' in with the 'T'.  Calculating the amount of space a particular set of
characters might take up may not be very straight-forward.

Just another 2 cents,
Ben Root

On Wed, May 11, 2011 at 1:59 PM, Benjamin Root <ben...@ou...> wrote:
>
>
> On Wed, May 11, 2011 at 12:47 PM, Brendan Barnwell <bre...@br...>
> wrote:
>>        One thing I've always wondered: is it fundamentally impossible to
>> change the fact that, in matplotlib, you cannot know how big a drawn
>> object will be until you actually draw it?  When I was doing some
>> animation stuff a while back this caused me a lot of headache, for the
>> reasons Tony Yu mentioned: it means you have to draw everything
>> multiple times.  It would really help if it were possible to specify
>> objects' parameters and get their sizes without drawing them.
>>
>> -- Brendan Barnwell
>> "Do not follow where the path may lead. Go, instead, where there is no
>> path, and leave a trail." --author unknown
>>
>
> Most things, we do know the sizes of.  It is my understanding that it is the
> text objects that is the unknown.  If this could be solved, then a layout
> engine would be much more feasible.  The problem is that even LaTeX has to
> re-render things multiple times to get this right for an arbitrary font.  If
> we were to restrict ourselves to particular fonts and package those fonts
> with matplotlib, then we could have an internal table of size information
> for each glyph and compute it on the fly and lay everything out right.  But,
> that would cause us to give up significant benefits for another benefit.
>
> I think the pain of the bootstrapping/re-rendering approach could be reduced
> significantly if we could get various aspects of matplotlib figure building
> to be faster.  Last time I checked, there is significant amount of
> processing time spent in calculating the ticks for the axes.  Maybe if we
> focus some efforts in improving the efficiency of certain parts of
> matplotlib, maybe we could introduce a convenience function like the one
> earlier in this thread that some users can choose to use with only a slight
> penalty in speed.  I personally would not want to make it default, but
> certainly would consider highly advertising such a function.
>
> Just my two cents,
> Ben Root

Perhaps there could be three options:

1. Manual mode: current behavior
2. Database mode: uses a list of known fonts.  When a font not found
in the database is used, it falls back to manual mode.
3. Automatic mode: uses a list of known fonts.  When a font not found
in the database is used, it renders the text alone in an invisible
figure to calculate the space needed, then uses that information to
set the margins.  Alternatively, create a temporary mini font database
just for the characters needed.  The former approach may be faster,
but the latter may be easier to program since it could share a lot of
code with the database.

There could also be a function to scan a particular font and add to
the database (there would probably be a separate user database in your
matplotlib configuration directory that this would use, as well as
probably caching the measurements from text used in automatic mode for
future versions of the figure).

-Todd

On Wed, May 11, 2011 at 1:59 PM, Benjamin Root <ben...@ou...> wrote:

> ...
> Most things, we do know the sizes of.  It is my understanding that it is
> the text objects that is the unknown.  If this could be solved, then a
> layout engine would be much more feasible.  The problem is that even LaTeX
> has to re-render things multiple times to get this right for an arbitrary
> font.  If we were to restrict ourselves to particular fonts and package
> those fonts with matplotlib, then we could have an internal table of size
> information for each glyph and compute it on the fly and lay everything out
> right.  But, that would cause us to give up significant benefits for another
> benefit.
> ...
>

I suppose a compromise would be to have that internal table for a fixed set
of fonts, and if the user asks for a font that's not shipped with
matplotlib, then they fall back to the current (presumably slower) method.
Would probably complicate things in the layout code, though.

      Justin

On Wed, May 11, 2011 at 12:47 PM, Brendan Barnwell <bre...@br...>wrote:

> [Accidentally sent this reply privately the first time, natch.]
>
> On 2011-05-11 04:29, Jae-Joon Lee wrote:
>  > > On Wed, May 11, 2011 at 5:03 PM, Daniel Mader
>  > > <dan...@go...>  wrote:
>  >> >>  Hi Jae-Loon,
>  >> >>
>  >> >>  thanks for your comments! Of course I do agree that a figure
> layout
>  >> >>  should not change in interactive mode. However, I don't see
> why this
>  >> >>  should happen upon a panning action. A different case is when the
>  >> >>  label or title font sizes are changed, but I was assuming this is
>  >> >>  adjusted prior to the creation of the figure.
>  >> >>
>  > >
>  > > Since you said the current design is broken, I thought you want
> things
>  > > adjusted *whenever* a figure is updated.
>  > >
>  > > So, I guess what you want is some functionality like what Tony's
> script does?
>  > > One of the reason that I was not very inclined to Tony's approach is
>  > > that it only works for subplots (and I guess it only works with
>  > > subplots with pure n x m grid. Correct me if I'm wrong). But maybe it
>  > > is better than nothing. I'll consider how things can be improved.
>
>         One thing I've always wondered: is it fundamentally impossible to
> change the fact that, in matplotlib, you cannot know how big a drawn
> object will be until you actually draw it?  When I was doing some
> animation stuff a while back this caused me a lot of headache, for the
> reasons Tony Yu mentioned: it means you have to draw everything
> multiple times.  It would really help if it were possible to specify
> objects' parameters and get their sizes without drawing them.
>
> -- Brendan Barnwell
> "Do not follow where the path may lead. Go, instead, where there is no
> path, and leave a trail." --author unknown
>
>
Most things, we do know the sizes of.  It is my understanding that it is the
text objects that is the unknown.  If this could be solved, then a layout
engine would be much more feasible.  The problem is that even LaTeX has to
re-render things multiple times to get this right for an arbitrary font.  If
we were to restrict ourselves to particular fonts and package those fonts
with matplotlib, then we could have an internal table of size information
for each glyph and compute it on the fly and lay everything out right.  But,
that would cause us to give up significant benefits for another benefit.

I think the pain of the bootstrapping/re-rendering approach could be reduced
significantly if we could get various aspects of matplotlib figure building
to be faster.  Last time I checked, there is significant amount of
processing time spent in calculating the ticks for the axes.  Maybe if we
focus some efforts in improving the efficiency of certain parts of
matplotlib, maybe we could introduce a convenience function like the one
earlier in this thread that some users can choose to use with only a slight
penalty in speed.  I personally would not want to make it default, but
certainly would consider highly advertising such a function.

Just my two cents,
Ben Root

[Accidentally sent this reply privately the first time, natch.]

On 2011-05-11 04:29, Jae-Joon Lee wrote:
 > > On Wed, May 11, 2011 at 5:03 PM, Daniel Mader
 > > <dan...@go...>  wrote:
 >> >>  Hi Jae-Loon,
 >> >>
 >> >>  thanks for your comments! Of course I do agree that a figure 
layout
 >> >>  should not change in interactive mode. However, I don't see 
why this
 >> >>  should happen upon a panning action. A different case is when the
 >> >>  label or title font sizes are changed, but I was assuming this is
 >> >>  adjusted prior to the creation of the figure.
 >> >>
 > >
 > > Since you said the current design is broken, I thought you want 
things
 > > adjusted *whenever* a figure is updated.
 > >
 > > So, I guess what you want is some functionality like what Tony's 
script does?
 > > One of the reason that I was not very inclined to Tony's approach is
 > > that it only works for subplots (and I guess it only works with
 > > subplots with pure n x m grid. Correct me if I'm wrong). But maybe it
 > > is better than nothing. I'll consider how things can be improved.

	One thing I've always wondered: is it fundamentally impossible to
change the fact that, in matplotlib, you cannot know how big a drawn
object will be until you actually draw it?  When I was doing some
animation stuff a while back this caused me a lot of headache, for the
reasons Tony Yu mentioned: it means you have to draw everything
multiple times.  It would really help if it were possible to specify
objects' parameters and get their sizes without drawing them.

-- Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no 
path, and leave a trail." --author unknown

On Wed, May 11, 2011 at 11:07 AM, C M <cmp...@gm...> wrote:
> On Wed, May 11, 2011 at 12:29 AM, Jae-Joon Lee <lee...@gm...> wrote:
>> I think I fixed a similar bug at some point but I'm not sure if that
>> is related with this.
>> Are you using the *make_axes_area_auto_adjustable* from the current
>> git master (check
>> examples/axes_grid/make_room_for_ylabel_using_axesgrid.py)? If not can
>> you try that? Also please post your code.
>

I have not set up with git since Matplotlib made the change from svn.
I just downloaded git to get started but don't know how to use it yet;
for now is there a way to just check out the files I need to test
this, or is there some other (non-git) way to get this update?

Thanks,
Che

Hi,

we're running Matplotlib 1.0.0 with Python 2.6.2 on CentOS 5.6.  When 
importing from matplotlib._path, users get an error message

"undefined symbol: 
_ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l"


I'm at a loss.  There were no errors during the installation

Generating the error:

$ python-2.6
Python 2.6.2 (r262:71600, Aug  5 2010, 14:21:11)
[GCC 4.4.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> from matplotlib._path import affine_transform
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
ImportError: 
/g/software/linux/pack/python-2.6/lib/python2.6/site-packages/matplotlib/_path.so: 
undefined symbol: 
_ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l
 >>> exit()
$

Anyone has seen this before and/or knows a fix?  There are some reports 
about such an error on the web, but they are all quite old and I cannot 
relate them to the current issue.

Thanks in advance

     frank

hi, just curious if anyone wants to add some publication formating
settings? if you send me the rc params, and publication infos i add them
to the project. 


http://code.google.com/p/mplrc/




On Sat, 2011-04-16 at 14:21 -0400, alex arsenovic wrote:
> i created the project for 'mplrc' here
> https://code.google.com/p/mplrc/
> 
> let me know what you all think. if you all send me your publications'
> settings i can add them, or if you want an account ill make you one. 
> 
> one thing to mention is that the params dictionary probably should set
> all possible settings so that there is no ambiguity. i have yet to do
> this.
> 
> here is an example of my ieee format
> 
> 
> On Fri, 2011-04-15 at 14:09 -0400, Tony Yu wrote:
> > 
> > 
> > On Fri, Apr 15, 2011 at 8:36 AM, Auré Gourrier
> > <aur...@ya...> wrote:
> >         Good Idea !
> >         I'm also using mpl for other publications than ieee and it
> >         sounds like a small mplrc data base with targeted journal
> >         specifications would be worthwhile doing ! I would be ready to
> >         contribute.
> >         Cheers,
> >         Auré
> >         
> >         
> >         
> > 
> > Is there any reason this needs to done with rc files? I prefer to put
> > document-specific configuration into modules. For example, you could
> > have a module that looks like:
> > 
> > mplrc/
> >     __init__.py
> >     aps_fullpage.py
> >     aps_twocolumn.py
> >     ieee.py
> >     ...
> > 
> > (`aps` could even be directory). And each module would set rc
> > parameters using function calls; for example, aps_twocolumn.py might
> > look like:
> > 
> > import matplotlib.pyplot as plt
> > plt.rc('axes', labelsize=10)
> > plt.rc('text', fontsize=10)
> > plt.rc('legend', fontsize=10)
> > plt.rc('xtick', labelsize=8)
> > plt.rc('ytick', labelsize=8)
> > plt.rc('text', usetex=False)
> > plt.rc('figure', figsize=(3.4039, 2.1037))
> > 
> > (Alternatively, you could create a separate rc file and just have the
> > module load that rc file). The advantage of this module-based approach
> > is that you could simply import the module whenever you need it (e.g.,
> > just add `import mplrc.aps_twocolumn` at the top of your script). If I
> > used an rc file instead, I'd have to copy the rc file to my working
> > directory each time, or somehow, manually load the rc file from a
> > path.
> > 
> > Just a suggestion.
> > 
> > -Tony
> > 
>