matplotlib-users Mailing List for matplotlib

We didnt get any comments against, so I committed the changes this morning. We 
will no longer try to support sans-serif mathmode fonts with the usetex 
option, since there is no native support for them in latex. If you are using 
svn matplotlib, I suggest clearing your tex.cache after updating.
Darren
On Wednesday 14 June 2006 8:19 pm, Darren Dale wrote:
> I agree that this little experiment of trying to work around latex's
> limitations has been too much trouble. I suggest we go back to the old
> behavior, and anyone who wants sans-serif fonts in their exponents can use
> regular mathtext. I'm hopeful that Edin can make some strides with mpl's
> mathtext support, and in the meantime, people should get decent results if
> they set ps.useafm : True in their rc settings.
>
> Comments?
>
> On Wednesday 14 June 2006 19:53, Ryan Krauss wrote:
> > (Sorry, I submitted this email with a real figure instead of a toy
> > example and the file size was too big and it awaits moderator
> > approval).
> >
> > I am afraid I asked you to open a can of worms and now I don't know
> > what we should do. With my font size settings, \small looks to small
> > for the exponents. I tried \normalsize and actually got decent
> > results with \large (replacing all occurances of \small in your
> > ticker.py). See that attached file. But if \small looked good with
> > your settings, I am afraid things are now dependent on the font
> > settings in the rc file as far as what should go in the latex command
> > for the exponents.
> >
> > I remember that this problem came up because I complained about serif
> > fonts in my exponents and we were having a hard time making tex use
> > sans serif math fonts.
> >
> > Maybe the best solution is for me to go back in time and retract that
> > complaint.
> >
> > I don't know. Sorry about the mess this had made. I have plots I am
> > fairly happy with (I will poke around in my rc file and see if I can
> > find out why my x and y axis fonts look different).
> >
> > Ryan
> >
> > On 6/14/06, Ryan Krauss <rya...@gm...> wrote:
> > > I am afraid I asked you to open a can of worms and now I don't know
> > > what we should do. With my font size settings, \small looks to small
> > > for the exponents. I tried \normalsize and actually got decent
> > > results with \large (replacing all occurances of \small in your
> > > ticker.py). See that attached file. But if \small looked good with
> > > your settings, I am afraid things are now dependent on the font
> > > settings in the rc file as far as what should go in the latex command
> > > for the exponents.
> > >
> > > I remember that this problem came up because I complained about serif
> > > fonts in my exponents and we were having a hard time making tex use
> > > sans serif math fonts.
> > >
> > > Maybe the best solution is for me to go back in time and retract that
> > > complaint.
> > >
> > > I don't know. Sorry about the mess this had made. I have plots I am
> > > fairly happy with (I will poke around in my rc file and see if I can
> > > find out why my x and y axis fonts look different).
> > >
> > > Ryan
> > >
> > > On 6/14/06, Ryan Krauss <rya...@gm...> wrote:
> > > > I feel bad that I caused this problem and am now asking you to fix
> > > > it.
> > > >
> > > > Ryan
> > > >
> > > > On 6/14/06, Darren Dale <dd...@co...> wrote:
> > > > > This is an artifact that was introduced when I tried to give you
> > > > > support for sans-serif fonts in the exponent. Try the attached
> > > > > ticker.py, it wraps the exponent in {\small}. Let me know if this
> > > > > is acceptable, and I'll commit it.
> > > > >
> > > > > On Wednesday 14 June 2006 19:14, Ryan Krauss wrote:
> > > > > > I still have the problem with large exponents with your
> > > > > > matplotlibrc file (but the y-axis plots are no longer different).
> > > > > >
> > > > > > Any thoughts on what I should try next?
> > > > > >
> > > > > > Ryan
> > > > > >
> > > > > > On 6/14/06, Darren Dale <dd...@co...> wrote:
> > > > > > > On Wednesday 14 June 2006 18:51, you wrote:
> > > > > > > > There was a lot of stuff in my tex.cache, but deleting didn't
> > > > > > > > solve my problem.
> > > > > > > >
> > > > > > > > I may have some strange choices for my fonts and font sizes.
> > > > > > > > Can you send me a copy of your matplotlibrc file.
> > > > > > > >
> > > > > > > > Ryan
> > > > > > > >
> > > > > > > > On 6/14/06, Darren Dale <dd...@co...> wrote:
> > > > > > > > > Hi Ryan,
> > > > > > > > >
> > > > > > > > > I'm using the latest svn as well (2479), and I cant
> > > > > > > > > reproduce your problem. Try deleting your tex.cache.
> > > > > > > > >
> > > > > > > > > Darren
> > > > > > > > >
> > > > > > > > > On Wednesday 14 June 2006 18:14, Ryan Krauss wrote:
> > > > > > > > > > I am having a problem with the fonts for exponents on
> > > > > > > > > > semilog plots with usetex.
> > > > > > > > > >
> > > > > > > > > > The attached figure can be generated on my machine with
> > > > > > > > > > figure(1)
> > > > > > > > > > t=arange(0,10,0.01)
> > > > > > > > > > y=sin(2*pi*t)
> > > > > > > > > > semilogx(t,y)
> > > > > > > > > >
> > > > > > > > > > I just upgraded to the latest svn and now the y-axis
> > > > > > > > > > plots look different from the x-axis.
> > > > > > > > > > matplotlib.__version__
> > > > > > > > > > Out[6]: '0.87.3'
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Ryan
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Darren S. Dale, Ph.D.
> > > > > > > > > Cornell High Energy Synchrotron Source
> > > > > > > > > Cornell University
> > > > > > > > > 200L Wilson Lab
> > > > > > > > > Rt. 366 & Pine Tree Road
> > > > > > > > > Ithaca, NY 14853
> > > > > > > > >
> > > > > > > > > dd...@co...
> > > > > > > > > office: (607) 255-9894
> > > > > > > > > fax: (607) 255-9001
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > _______________________________________________
> > > > > > > > > Matplotlib-users mailing list
> > > > > > > > > Mat...@li...
> > > > > > > > > https://lists.sourceforge.net/lists/listinfo/matplotlib-use
> > > > > > > > >rs
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > Matplotlib-users mailing list
> > > > > > > > Mat...@li...
> > > > > > > > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> > > > > > >
> > > > > > > --
> > > > > > > Darren S. Dale, Ph.D.
> > > > > > > Cornell High Energy Synchrotron Source
> > > > > > > Cornell University
> > > > > > > 200L Wilson Lab
> > > > > > > Rt. 366 & Pine Tree Road
> > > > > > > Ithaca, NY 14853
> > > > > > >
> > > > > > > dd...@co...
> > > > > > > office: (607) 255-9894
> > > > > > > fax: (607) 255-9001
> > > > >
> > > > > --
> > > > > Darren S. Dale, Ph.D.
> > > > > Cornell High Energy Synchrotron Source
> > > > > Cornell University
> > > > > 200L Wilson Lab
> > > > > Rt. 366 & Pine Tree Road
> > > > > Ithaca, NY 14853
> > > > >
> > > > > dd...@co...
> > > > > office: (607) 255-9894
> > > > > fax: (607) 255-9001
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Matplotlib-users mailing list
> > > > > Mat...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
-- 
Darren S. Dale, Ph.D.
dd...@co...

With usetex mpl creates different fonts on the axes ticks and the 
$\times 10^<number>$ labels.
In [1]: matplotlib.__version__
Out[1]: '0.87.3'
(from svn)
-- 
Random number generation is the art of producing pure gibberish as 
quickly as possible.

John Hunter wrote:
>>>>>>"Bryan" == Bryan Cole <br...@co...> writes:
> 
> 
> Bryan> MPL uses CXX instead of SWIG; I'm no C++ export so I havn't
> Bryan> looked at adding __get/setstate__ functions to the objects
> Bryan> themselves. copy_reg is nice because you can add
> 
> Actually, most of the mpl extension code is CXX, but just to make
> things difficult for you, some of it is SWIG as well. 
And some is old-fashioned C: cntr.c. And if you use basemap, then you 
are using a pyrex extension.
Eric

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
 Eric> John Hunter wrote:
 >>>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
 >>
 Eric> they will not be transparent. If you need transparent
 Eric> masked regions, then try pcolor instead of imshow. Pcolor
 Eric> plots nothing at all in masked cells. Pcolormesh, on the
 Eric> other hand, is like imshow in plotting the assigned bad
 Eric> color and in using a single alpha for everything.
 >> I'm confused about the comments about alpha not working on
 >> imshow -- can you elaborate. On the agg backend at least, the
 >> alpha channel is respected in imshow, eg
 >> examples/layer_images.py. Is there a reason it does not (or
 >> should not) work in the masked example?
 Eric> John,
 Eric> I don't know why it doesn't work; I know only that in my
 Eric> example, it doesn't work as I perhaps naively think it
 Eric> should. My interpretation of alpha is that if alpha is zero
 Eric> in any colored region, and if nothing else is drawn on top,
 Eric> then the background should show through; that is, the r,g,b
 Eric> values in the r,g,b,a tuple for a region should have no
 Eric> effect if a is zero. If you uncomment
 Eric> #cmap.set_bad((1,1,1,0) in my example, you will find that
 Eric> the masked region is white; and if you change the rgb part
 Eric> of that tuple, it takes on that color, regardless of alpha.
I'm not sure what is going on in your example, but this test case
shows that the alpha channel is respected. I made a red RGBA array
and set the alpha channel for the center to be transparent and it
behaves as expected: you can see the line through the transparent
region of the rectangle and the axes bgcolor shows through. I had to
make a small change to svn to make this work because the image wasn't
respecting the zorder (revision 2495). So the bug you are
experiencing is likely to be in the front-end code.
from pylab import figure, show, nx
# a red rectangle with a transparent center
X = nx.ones((20,20,4), nx.Float)
X[:,:,1] = 0
X[:,:,2] = 0
X[5:15,5:15,-1] = 0 
fig = figure()
ax = fig.add_subplot(111)
l, = ax.plot(nx.arange(20))
l.set_zorder(2)
 
im = ax.imshow(X)
im.set_zorder(3) # put the image over the line
show()

>>>>> "Bryan" == Bryan Cole <br...@co...> writes:
 Bryan> MPL uses CXX instead of SWIG; I'm no C++ export so I havn't
 Bryan> looked at adding __get/setstate__ functions to the objects
 Bryan> themselves. copy_reg is nice because you can add
Actually, most of the mpl extension code is CXX, but just to make
things difficult for you, some of it is SWIG as well. Basically, I
decided at some point that SWIG was a better choice, and when I wanted
to expose more of the agg functionality directly through the agg
module (which is different from backend_agg), I decided to do it in
C++. The lines module, for example, uses agg to construct paths which
it then passes off to the various backends. I do not think any of
these SWIG objects are persistent since they are created at draw time
and not cached, but I just wanted to make you aware of them.
JDH

On Sun, 2006年06月18日 at 15:38 +1000, John Pye wrote:
> FWIW I found that I was able to pickle C++ objects but simply adding
> python methods __reduce__ and __setstate__ in my SWIG .i file -- I'm not
> sure if Matplotlib uses this approach or not. I didn't need to use
> copy_reg (perhaps it's preferable? I don't know)
MPL uses CXX instead of SWIG; I'm no C++ export so I havn't looked at
adding __get/setstate__ functions to the objects themselves. copy_reg is
nice because you can add pickle-ability without modifying any matplotlib
code. I've hit another potential problem though: it's not possible to
access the full internal state of these objects from their python API,
meaning they can't be stored this way. It looks like I need to
understand the Figure creation process in a bit more detail.
BC
> 
> http://freesteam.cvs.sourceforge.net/freesteam/freesteam/freesteam.i?revision=1.16&view=markup
> (this is from the steam properties project that I run,
> http://freesteam.sf.net/)
> 
> Cheers
> JP
> 
> Bryan Cole wrote:
> 
> >On Sun, 2006年06月18日 at 00:05 +1000, John Pye wrote:
> > 
> >
> >>Hi all,
> >>
> >>A thought just occurred to me: I wonder if it would be useful to be able
> >>to 'pickle' Matplotlib plots, using the python cPickle library. This
> >>way, I could save my plots in a form that would allow me to load them
> >>back later (with just the necessary source data) and fiddle with things
> >>like titles and legends and so on. Would be useful perhaps in the
> >>context of preparing diagrams for an article or report.
> >>
> >>Has anyone tried this? Would it be recommended/not recommended/not even
> >>possible?
> >> 
> >>
> >
> >I had a look at this a while back. It looks like the well thought out
> >structure of MPL should make this easy, although it would require a few
> >adjustments. To make a Figure object pickle-able, all the internal
> >objects in a Figure must also be pickle-able. Most of the innards of a
> >Figure are python objects which should pickle without problem. The only
> >parts which aren't are the "BinOps". These are custom C-coded objects
> >which implement 'lazy evaluation' of the transformation expressions.
> >They're defined in the _transforms.cxx/h files.
> >
> >In theory, you can easily make these C-objects pickle-able using the
> >'copy_reg' module; you just register two functions, one to extracts the
> >object's state as a pickle-able object, the other to construct a new
> >instance of the object, initialised with the previously stored state.
> >
> >However, I ran into a problem: there's some bug in either python or CXX
> >(the automatic C++ class wrapper which mpl uses for the compiled
> >components) which results in a segfault when I tried pickling copy_reg
> >enhanced BinOps. The templating techniques used by CXX are completely
> >beyond me so this is where things have stuck.
> >
> >... but ... I just now tested this again with python-2.4.2 and
> >mpl-0.87.2 and it works! yeay. Thus, if every object in
> >matplotlib._transforms gets given a python reduction/construction
> >function pair and registers them with copy_reg, this *should* be enough
> >to make a Figure pickle-able. Unless I've missed something else...
> >
> >I may try this out later this week, unless someone else tries it first.
> >
> >Bryan
> >
> >PS. copy_reg example follows >>>
> >
> >import cPickle as pickle
> >import copy_reg
> >
> >#let's test this on a simple 'Value' BinOp
> >from matplotlib._transforms import Value
> >
> >def fcon(val):
> > #constructor
> > return Value(val)
> >
> >def fred(o):
> > #reduction functions
> > val = o.get()
> > return fcon, (val,)
> >
> >#my starting object
> >a=Value(5)
> >print a, a.get()
> >
> >copy_reg.pickle(type(a), fred)
> >
> >data = pickle.dumps(a)
> >
> >new = pickle.loads(data)
> >print "new", new, new.get()
> >
> > 
> >
> >>Cheers
> >>JP
> >> 
> >>
> >
> >
> >
> >
> >_______________________________________________
> >Matplotlib-users mailing list
> >Mat...@li...
> >https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >
> > 
> >

FWIW I found that I was able to pickle C++ objects but simply adding
python methods __reduce__ and __setstate__ in my SWIG .i file -- I'm not
sure if Matplotlib uses this approach or not. I didn't need to use
copy_reg (perhaps it's preferable? I don't know)
http://freesteam.cvs.sourceforge.net/freesteam/freesteam/freesteam.i?revision=1.16&view=markup
(this is from the steam properties project that I run,
http://freesteam.sf.net/)
Cheers
JP
Bryan Cole wrote:
>On Sun, 2006年06月18日 at 00:05 +1000, John Pye wrote:
> 
>
>>Hi all,
>>
>>A thought just occurred to me: I wonder if it would be useful to be able
>>to 'pickle' Matplotlib plots, using the python cPickle library. This
>>way, I could save my plots in a form that would allow me to load them
>>back later (with just the necessary source data) and fiddle with things
>>like titles and legends and so on. Would be useful perhaps in the
>>context of preparing diagrams for an article or report.
>>
>>Has anyone tried this? Would it be recommended/not recommended/not even
>>possible?
>> 
>>
>
>I had a look at this a while back. It looks like the well thought out
>structure of MPL should make this easy, although it would require a few
>adjustments. To make a Figure object pickle-able, all the internal
>objects in a Figure must also be pickle-able. Most of the innards of a
>Figure are python objects which should pickle without problem. The only
>parts which aren't are the "BinOps". These are custom C-coded objects
>which implement 'lazy evaluation' of the transformation expressions.
>They're defined in the _transforms.cxx/h files.
>
>In theory, you can easily make these C-objects pickle-able using the
>'copy_reg' module; you just register two functions, one to extracts the
>object's state as a pickle-able object, the other to construct a new
>instance of the object, initialised with the previously stored state.
>
>However, I ran into a problem: there's some bug in either python or CXX
>(the automatic C++ class wrapper which mpl uses for the compiled
>components) which results in a segfault when I tried pickling copy_reg
>enhanced BinOps. The templating techniques used by CXX are completely
>beyond me so this is where things have stuck.
>
>... but ... I just now tested this again with python-2.4.2 and
>mpl-0.87.2 and it works! yeay. Thus, if every object in
>matplotlib._transforms gets given a python reduction/construction
>function pair and registers them with copy_reg, this *should* be enough
>to make a Figure pickle-able. Unless I've missed something else...
>
>I may try this out later this week, unless someone else tries it first.
>
>Bryan
>
>PS. copy_reg example follows >>>
>
>import cPickle as pickle
>import copy_reg
>
>#let's test this on a simple 'Value' BinOp
>from matplotlib._transforms import Value
>
>def fcon(val):
> #constructor
> return Value(val)
>
>def fred(o):
> #reduction functions
> val = o.get()
> return fcon, (val,)
>
>#my starting object
>a=Value(5)
>print a, a.get()
>
>copy_reg.pickle(type(a), fred)
>
>data = pickle.dumps(a)
>
>new = pickle.loads(data)
>print "new", new, new.get()
>
> 
>
>>Cheers
>>JP
>> 
>>
>
>
>
>
>_______________________________________________
>Matplotlib-users mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
> 
>