matplotlib-devel Mailing List for matplotlib (Page 5)

I was rounding where I should have been truncating. I think this is 
fixed now in SVN.
Mike
Ryan May wrote:
> On Wed, Mar 4, 2009 at 12:16 PM, Michael Droettboom <md...@st... 
> <mailto:md...@st...>> wrote:
>
> The 'regular' font stuff just isn't very well tested yet. I think
> I have a fix in SVN now.
>
>
> Thanks for the quick fix, it got rid of my errors. However, I'm 
> seeing a little more of the funky font baseline that you had fixed. 
> My original script doesn't show any problem, but I've attached an 
> image produced with the mathtext_demo.py. Notice the odd baseline for 
> versus in the title and sin in the equation on the graph. Thoughts?
>
> Ryan
>
> -- 
> Ryan May
> Graduate Research Assistant
> School of Meteorology
> University of Oklahoma
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a 600ドル discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> ------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> 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

The 'regular' font stuff just isn't very well tested yet. I think I 
have a fix in SVN now.
Mike
Ryan May wrote:
> Mike (or anyone else),
>
> I've been using the following combination of settings:
>
> mathtext.fontset : stixsans
> mathtext.default : regular
>
> I've noticed this crashes when I run scripts that include mathtext 
> with \rm{} commands. In fact, I get a massive traceback with this 
> configuration when running the mathtext_examples.py. Here's the last 
> few lines:
>
> File 
> "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/pyparsing.py", 
> line 950, in _parseNoCache
> tokens = fn( instring, tokensStart, retTokens )
> File 
> "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/mathtext.py", 
> line 2381, in symbol
> return [Hlist( [self._make_space(0.2),
> File 
> "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/mathtext.py", 
> line 2351, in _make_space
> state.font, rcParams['mathtext.default'], 'm', state.fontsize, 
> state.dpi)
> File 
> "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/mathtext.py", 
> line 446, in get_metrics
> info = self._get_info(font, font_class, sym, fontsize, dpi)
> File 
> "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/mathtext.py", 
> line 579, in _get_info
> self._get_glyph(fontname, font_class, sym, fontsize)
> File 
> "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/mathtext.py", 
> line 812, in _get_glyph
> fontname, font_class, uniindex)
> File 
> "/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/mathtext.py", 
> line 919, in _map_virtual_font
> mapping = mapping[font_class]
> KeyError: 'regular'
>
> Is this a supported configuration? I know that I personally like the 
> look of the text with these two settings. Thoughts?
>
> Ryan
>
> -- 
> Ryan May
> Graduate Research Assistant
> School of Meteorology
> University of Oklahoma
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a 600ドル discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> ------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> 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

Mike (or anyone else),
I've been using the following combination of settings:
mathtext.fontset : stixsans
mathtext.default : regular
I've noticed this crashes when I run scripts that include mathtext with
\rm{} commands. In fact, I get a massive traceback with this configuration
when running the mathtext_examples.py. Here's the last few lines:
 File
"/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/pyparsing.py",
line 950, in _parseNoCache
 tokens = fn( instring, tokensStart, retTokens )
 File
"/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/mathtext.py",
line 2381, in symbol
 return [Hlist( [self._make_space(0.2),
 File
"/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/mathtext.py",
line 2351, in _make_space
 state.font, rcParams['mathtext.default'], 'm', state.fontsize,
state.dpi)
 File
"/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/mathtext.py",
line 446, in get_metrics
 info = self._get_info(font, font_class, sym, fontsize, dpi)
 File
"/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/mathtext.py",
line 579, in _get_info
 self._get_glyph(fontname, font_class, sym, fontsize)
 File
"/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/mathtext.py",
line 812, in _get_glyph
 fontname, font_class, uniindex)
 File
"/home/rmay/.local/lib64/python2.5/site-packages/matplotlib/mathtext.py",
line 919, in _map_virtual_font
 mapping = mapping[font_class]
KeyError: 'regular'
Is this a supported configuration? I know that I personally like the look
of the text with these two settings. Thoughts?
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Great. I applied your patch and pushed it to the web repository.
I agree, that some more serious refactoring might be good. I have
been leaving comments throughout the code with my thoughts on this.
Cheers,
Jon.
On Wed, Mar 4, 2009 at 4:53 AM, Reinier Heeres <re...@he...> wrote:
> Hi all,
>
> I was also a bit disappointed about the fact that 3d plotting support
> was dropped. I'm happy to help out to get it going again, so here's a
> patch to get surface plotting working; I'm busy with the contour plots
> as well.
> (We might want to do some code refactoring as well when it's functional).
>
> Regards,
> Reinier
>
> On Wed, Mar 4, 2009 at 5:01 AM, Rob Clewley <rob...@gm...> wrote:
>> On Tue, Mar 3, 2009 at 11:39 AM, John Hunter <jd...@gm...> wrote:
>>
>>> Well, it is painfully slow, since it does everything in software, and there
>>> are some corner cases where the zorder clipping is broken in the presence of
>>> alpha transparency, and it doesn't do lighting, shadows, etc.... But it
>>> does do enough for basic stuff, so we would be happy if you could resurrect
>>> it cleanly enough for a toolkit.
>>>
>>
>> I'd just like to add that having a *bare minimum* 3D capability in mpl
>> is extremely useful to me -- i.e. being to visualize 3D data as a
>> point cloud or a wireframe mesh. While teaching with python and doing
>> numerical experiments in my research it's invaluable to be able to
>> throw together a wholly non-publication quality 3D plot to get a quick
>> idea of what's going on. I would imagine that others who use mpl
>> professionally (and not necessarily only for public consumption) would
>> agree on the value of maintaining this bare minimum even if there is
>> no short- or medium-term expectation that it will develop into
>> anything more sophisticated.
>>
>> Cheers,
>> Rob
>>
>> ------------------------------------------------------------------------------
>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>> -Strategies to boost innovation and cut costs with open source participation
>> -Receive a 600ドル discount off the registration fee with the source code: SFAD
>> http://p.sf.net/sfu/XcvMzF8H
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>
>
> --
> Reinier Heeres
> Waalstraat 17
> 2515 XK Den Haag
> The Netherlands
>
> Tel: +31 6 10852639
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a 600ドル discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Hi all,
I was also a bit disappointed about the fact that 3d plotting support
was dropped. I'm happy to help out to get it going again, so here's a
patch to get surface plotting working; I'm busy with the contour plots
as well.
(We might want to do some code refactoring as well when it's functional).
Regards,
Reinier
On Wed, Mar 4, 2009 at 5:01 AM, Rob Clewley <rob...@gm...> wrote:
> On Tue, Mar 3, 2009 at 11:39 AM, John Hunter <jd...@gm...> wrote:
>
>> Well, it is painfully slow, since it does everything in software, and there
>> are some corner cases where the zorder clipping is broken in the presence of
>> alpha transparency, and it doesn't do lighting, shadows, etc.... But it
>> does do enough for basic stuff, so we would be happy if you could resurrect
>> it cleanly enough for a toolkit.
>>
>
> I'd just like to add that having a *bare minimum* 3D capability in mpl
> is extremely useful to me -- i.e. being to visualize 3D data as a
> point cloud or a wireframe mesh. While teaching with python and doing
> numerical experiments in my research it's invaluable to be able to
> throw together a wholly non-publication quality 3D plot to get a quick
> idea of what's going on. I would imagine that others who use mpl
> professionally (and not necessarily only for public consumption) would
> agree on the value of maintaining this bare minimum even if there is
> no short- or medium-term expectation that it will develop into
> anything more sophisticated.
>
> Cheers,
> Rob
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a 600ドル discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
-- 
Reinier Heeres
Waalstraat 17
2515 XK Den Haag
The Netherlands
Tel: +31 6 10852639

On Tue, Mar 3, 2009 at 11:39 AM, John Hunter <jd...@gm...> wrote:
> Well, it is painfully slow, since it does everything in software, and there
> are some corner cases where the zorder clipping is broken in the presence of
> alpha transparency, and it doesn't do lighting, shadows, etc.... But it
> does do enough for basic stuff, so we would be happy if you could resurrect
> it cleanly enough for a toolkit.
>
I'd just like to add that having a *bare minimum* 3D capability in mpl
is extremely useful to me -- i.e. being to visualize 3D data as a
point cloud or a wireframe mesh. While teaching with python and doing
numerical experiments in my research it's invaluable to be able to
throw together a wholly non-publication quality 3D plot to get a quick
idea of what's going on. I would imagine that others who use mpl
professionally (and not necessarily only for public consumption) would
agree on the value of maintaining this bare minimum even if there is
no short- or medium-term expectation that it will develop into
anything more sophisticated.
Cheers,
Rob

> One of the mpl backends is svg; can you use something like Inkscape to
> make the plot adjustments you are talking about?
>
> Eric [F]
I'll second this recommendation - indeed, it's my default workflow
(except that I use Illustrator). By definition, vector image formats
contain all the data needed to (re)make the plot. Everything can be
rescaled, line weights changed, colors modified, etc.
-Eric B

On Sun, Mar 1, 2009 at 2:02 PM, Eric Firing <ef...@ha...> wrote:
>
> > Would i be right in assuming that it would take roughly the same amount
> of effort as writing a new backend? ie for each motplotlib action it would
> need a function to store that action and a function to call that action
> again.
>
> It is much more than that; it would take a backend to write out the new
> format, and an interpreter to turn that format back into mpl objects or
> API calls.
I don't think this approach would be viable, because the backend doesn't
know the progeny of the object (eg a tick line). I think to have a proper
serialized format, you would want to do it at the artist layer.
JDH

On Mon, Mar 2, 2009 at 3:52 PM, Gael Varoquaux <
gae...@no...> wrote:
> On Mon, Mar 02, 2009 at 01:49:38PM -0600, Ryan May wrote:
> > Other than the automatic regeneration from latex, what you want sounds
> > like what we already have: small python scripts.
>
> > In general, I'm completely amazed by how many people want to develop a
> new
> > markup/script language to wrap what is already a simple and expressive
> > language, both for plots and (at least around here) analyses. If
> there
> > are some spots that require too many lines of code to accomplish
> something
> > really simple, then maybe we need to API additions. But in general, I
> > think we have a format for specifying how to make a plot: python.
>
> Although I agree with you that reinventing an extra scripting layer is
> often a bad solution to a problem which should simply be solved by having
> a good scripting API in Python, I believe there is here a fundamental
> misconception.
>
> Python is an imperative, Turing-complete. This is a very good thing for a
> scripting language. For making a description of a static object as a
> plot, this is not a good thing. For instance, if I want to make a plot,
> save it, and later blow up all the fonts, I really don't want to be using
> an imperative, Turing-complete language for the persistence model, as
> static analysis of this persisted object is going to be next to
> impossible. Same thing if I want to change colormaps, or just about
> anything in my persisted object, for the same reason.
>
> A good rule for most software design is that the state of the
> application, or of the object of interest, in our case the plot, should
> be fully represented by a fully-static set of values, that I like to call
> the model. Although this sounds like a tautology, this design rule is
> more often broken than followed. For instance the status of an
> application may be entirely dependent on its past, or the important state
> variables may be hidden in places where you can't get hold of them (eg
> the status of a GUI widget, or inside a generator).
>
> Having a very clean separation between your (fully-static) model, and the
> logics around is a very important part of good application design, and I
> believe I know this because I have so often made an error and violated
> this rule :).
>
> If you have this static model, rather than an imperative language, then
> you can have persistence. By the way, Mayavi2 achieves its code
> generation by introspection on the model. The generated lines of code are
> just a way of expressing the changes.
>
> Sorry for being fussy, I am just trying to pass on what I believe I am
> learning painfully :).
>
Not at all. You made some good points. I hadn't really thought about the
prospect of things changing in the core of the rest of the code. It was
probably just a knee jerk reaction to something I hear a lot around here,
regarding making a small language/configuration file for automating analyses
*in python*. :)
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from: Norman Oklahoma United States.

On Tue, Mar 3, 2009 at 9:56 AM, Jonathan Taylor <jon...@ut...
> wrote:
> That sounds reasonable. Can I ask what it is that was primitive?
> Having looked through the code I see that a few shortcuts were made to
> minimize the amount of code written that makes it especially
> susceptible to changes in the 2D code. That said, it seems like it
> was comparable functionally to matlab's 3d plots, which is my goal for
> it.
>
Well, it is painfully slow, since it does everything in software, and there
are some corner cases where the zorder clipping is broken in the presence of
alpha transparency, and it doesn't do lighting, shadows, etc.... But it
does do enough for basic stuff, so we would be happy if you could resurrect
it cleanly enough for a toolkit.
>
> P.S. I saw your talk at NIPS 2008 this year. I have used mpl for a
> while now but that demo where you url.opened() yahoo finance and
> plotted it with those nice dates in 2/3 lines was very nice. ;)
Yep, that is a favorite example of mine :-) I'm giving a talk at SIAM on
Thursday, and I think I'll do this one again, time permitting.
JDH

That sounds reasonable. Can I ask what it is that was primitive?
Having looked through the code I see that a few shortcuts were made to
minimize the amount of code written that makes it especially
susceptible to changes in the 2D code. That said, it seems like it
was comparable functionally to matlab's 3d plots, which is my goal for
it.
Best,
Jon.
P.S. I saw your talk at NIPS 2008 this year. I have used mpl for a
while now but that demo where you url.opened() yahoo finance and
plotted it with those nice dates in 2/3 lines was very nice. ;)
On Tue, Mar 3, 2009 at 9:14 AM, John Hunter <jd...@gm...> wrote:
>
>
> On Mon, Mar 2, 2009 at 10:13 PM, Jonathan Taylor
> <jon...@ut...> wrote:
>>
>> Hi,
>>
>> I saw that 3D plotting was dropped from matplotlib since the last time
>> I used it. Unfortunately, it is pretty necessary for some of the work
>> I am doing. Thus, I have started the process of refactoring the code
>> to work with recent versions of matplotlib.
>>
>> Right now, it is still in very early stages and is quite flaky but I
>> do have some functionality. In particular, I am able to do a regular
>> 3d plot, a wireframe plot and a scatter plot. If this interests
>> anyone I am making the code available via git. Instructions are
>> available on my website at:
>
> That's great -- a number of people were very disappointed to see the
> functionality removed, even though it was primitive compared to a good 3D
> toolkit. The problem was, we could never find a core developer who was
> interested in taking it under his wing. Once you get this to a satisfactory
> point, I suggest you develop it as an mpl toolkit. That way, it will get
> installed with every mpl distro (the plain vanilla toolkits we ship, the
> complex ones like basemap are distributed separately) but without the
> implicit promise of full support until someone is willing to step up and
> offer to fully support it.
>
> JDH
>
>

On Mon, Mar 2, 2009 at 10:13 PM, Jonathan Taylor <
jon...@ut...> wrote:
> Hi,
>
> I saw that 3D plotting was dropped from matplotlib since the last time
> I used it. Unfortunately, it is pretty necessary for some of the work
> I am doing. Thus, I have started the process of refactoring the code
> to work with recent versions of matplotlib.
>
> Right now, it is still in very early stages and is quite flaky but I
> do have some functionality. In particular, I am able to do a regular
> 3d plot, a wireframe plot and a scatter plot. If this interests
> anyone I am making the code available via git. Instructions are
> available on my website at:
>
That's great -- a number of people were very disappointed to see the
functionality removed, even though it was primitive compared to a good 3D
toolkit. The problem was, we could never find a core developer who was
interested in taking it under his wing. Once you get this to a satisfactory
point, I suggest you develop it as an mpl toolkit. That way, it will get
installed with every mpl distro (the plain vanilla toolkits we ship, the
complex ones like basemap are distributed separately) but without the
implicit promise of full support until someone is willing to step up and
offer to fully support it.
JDH

Hi,
I saw that 3D plotting was dropped from matplotlib since the last time
I used it. Unfortunately, it is pretty necessary for some of the work
I am doing. Thus, I have started the process of refactoring the code
to work with recent versions of matplotlib.
Right now, it is still in very early stages and is quite flaky but I
do have some functionality. In particular, I am able to do a regular
3d plot, a wireframe plot and a scatter plot. If this interests
anyone I am making the code available via git. Instructions are
available on my website at:
http://jonathantaylor.ca/projects.shtml
Feel free to send any patches my way.
Best,
Jon.

On Mon, Mar 02, 2009 at 01:49:38PM -0600, Ryan May wrote:
> Other than the automatic regeneration from latex, what you want sounds
> like what we already have: small python scripts.
> In general, I'm completely amazed by how many people want to develop a new
> markup/script language to wrap what is already a simple and expressive
> language, both for plots and (at least around here) analyses. If there
> are some spots that require too many lines of code to accomplish something
> really simple, then maybe we need to API additions. But in general, I
> think we have a format for specifying how to make a plot: python.
Although I agree with you that reinventing an extra scripting layer is
often a bad solution to a problem which should simply be solved by having
a good scripting API in Python, I believe there is here a fundamental
misconception.
Python is an imperative, Turing-complete. This is a very good thing for a
scripting language. For making a description of a static object as a
plot, this is not a good thing. For instance, if I want to make a plot,
save it, and later blow up all the fonts, I really don't want to be using
an imperative, Turing-complete language for the persistence model, as
static analysis of this persisted object is going to be next to
impossible. Same thing if I want to change colormaps, or just about
anything in my persisted object, for the same reason.
A good rule for most software design is that the state of the
application, or of the object of interest, in our case the plot, should
be fully represented by a fully-static set of values, that I like to call
the model. Although this sounds like a tautology, this design rule is
more often broken than followed. For instance the status of an
application may be entirely dependent on its past, or the important state
variables may be hidden in places where you can't get hold of them (eg
the status of a GUI widget, or inside a generator).
Having a very clean separation between your (fully-static) model, and the
logics around is a very important part of good application design, and I
believe I know this because I have so often made an error and violated
this rule :).
If you have this static model, rather than an imperative language, then
you can have persistence. By the way, Mayavi2 achieves its code
generation by introspection on the model. The generated lines of code are
just a way of expressing the changes.
Sorry for being fussy, I am just trying to pass on what I believe I am
learning painfully :).
Ga

On Sun, Mar 1, 2009 at 8:17 AM, sam tygier <sam...@ya...> wrote:
> Eric Firing wrote:
> > Sandro Tosi wrote:
> >> Hi Sam,
> >>
> >> On Wed, Feb 25, 2009 at 09:35, sam tygier <sam...@ya...>
> wrote:
> >>> I think this topic has come up before, but i don't think anything has
> >>> resulted from it.
> >>>
> > Correct, because the capability would require a *lot* of work to
> > implement,
>
> Would i be right in assuming that it would take roughly the same amount of
> effort as writing a new backend? ie for each motplotlib action it would need
> a function to store that action and a function to call that action again.
>
> > and most of us don't see a compelling need; we believe that a
> > better practice is to structure one's work so that plotting is separated
> > from data (result) generation in any cases where the latter is highly
> > time-consuming.
>
> It might not be essential, but it would offer an additional work flow, that
> a few people seem to like.
>
> I think it would be especially useful when it comes to putting plots into
> papers. I often find that i want to tweak something like the font size or
> labels. having a modifiable plot format seems the easiest way to achieve
> that. maybe the could even be some integration into latex so that if you
> were to resize your plot in your paper, it would be re-rendered with the
> fonts adjusted.
Other than the automatic regeneration from latex, what you want sounds like
what we already have: small python scripts.
In general, I'm completely amazed by how many people want to develop a new
markup/script language to wrap what is already a simple and expressive
language, both for plots and (at least around here) analyses. If there are
some spots that require too many lines of code to accomplish something
really simple, then maybe we need to API additions. But in general, I think
we have a format for specifying how to make a plot: python. Now, if we're
taking the output from some monstrous application or set of scripts, it
might be nice to get the commands that made the plot, like MayaVi 2 and its
ability to record. However, at the end of the day what MayaVi creates is a
python script, and I think that's more useful than any general markup since
I can look at that file and figure out what's going on without learning
anything new.
Now, a matplotlib backend that writes out python code could be useful and
cool, though it would only matter for the large applications/scripts. In
fact, it's at the application level that such functionality would probably
belong.
My 0.02 anyways.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from: Norman Oklahoma United States.

Jae-Joon Lee wrote:
> The following code show how the FontProperties is currently hashed.
>
> def __hash__(self):
> l = self.__dict__.items()
> l.sort()
> return hash(repr(l))
>
>
> The hash does not account user's rcParams setting. And due to the font
> caching, findfont(FontProperties()) returns the same font even if user
> changes the rcParams["font.family"] and other parameters.
>
> So, I propose to change it to something like below.
>
> def __hash__(self):
> l = [(k, getattr(self, "get" + k)()) for k in self.__dict__]
> return hash(repr(l))
> 
You'll need to maintain the call to sort in there, since dictionaries 
don't make any guarantee about ordering. But otherwise, that seems like 
a reasonable solution to the problem. There was a bug report about this 
on the list recently.
> The other change I want to make is the behavior of the findfont(None).
> As of now, it returns "fontManager.defaultFont" which is set when
> fontManager is initialized. Therefore, it returns same font even if
> user change the rcParams. I prefer to have "findfont(None) ==
> findfont(FontProperties())".
> 
That should be fine.
> Unless others object, I'll commit the changes to the trunk.
> 
Sure. Just be careful not to change the pickled cache file format if 
possible (it doesn't seem like what you propose will do that) -- but 
that always causes upgrade headaches when that cache format changes.
Mike

sam tygier wrote:
> Eric Firing wrote:
>> Sandro Tosi wrote:
>>> Hi Sam,
>>>
>>> On Wed, Feb 25, 2009 at 09:35, sam tygier <sam...@ya...> wrote:
>>>> I think this topic has come up before, but i don't think anything has
>>>> resulted from it.
>>>>
>> Correct, because the capability would require a *lot* of work to 
>> implement,
> 
> Would i be right in assuming that it would take roughly the same amount of effort as writing a new backend? ie for each motplotlib action it would need a function to store that action and a function to call that action again.
It is much more than that; it would take a backend to write out the new 
format, and an interpreter to turn that format back into mpl objects or 
API calls.
One of the mpl backends is svg; can you use something like Inkscape to 
make the plot adjustments you are talking about?
Eric
> 
>> and most of us don't see a compelling need; we believe that a 
>> better practice is to structure one's work so that plotting is separated 
>> from data (result) generation in any cases where the latter is highly 
>> time-consuming.
> 
> It might not be essential, but it would offer an additional work flow, that a few people seem to like.
> 
> I think it would be especially useful when it comes to putting plots into papers. I often find that i want to tweak something like the font size or labels. having a modifiable plot format seems the easiest way to achieve that. maybe the could even be some integration into latex so that if you were to resize your plot in your paper, it would be re-rendered with the fonts adjusted.
> 
>>>> I'd like a way for saving a plot from from matplotlib, so that it can be
>>>> re-rendered later, possibly with a different backend, maybe to a different
>>>> size, and maybe with changes to the labels. This would save me having to
>>>> rerun the simulation that generated the plot.
>>>>
>>>> Ideally this would work by having a save_plot() function, that would save
>>>> all state of the current plot into a file. This could then be loaded by a
>>>> program to regenerate that plot.
>>> Can't this be achieved by pickling/unpickling the mpl objects? Didn't
>>> manage to test it, but it should work.
>> No, this has been discussed several times. Quite a bit of work would be 
>> required to make all the extension code compatible with pickling. More 
>> work, more complexity, more difficult code maintenance and testing. 
>> It's not worth it, given the developer resources available for mpl.
> 
> a file format avoids all the issues that pickling causes.
> 
> thanks for all the comments
> 
> sam tygier
> 
> 
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a 600ドル discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Eric Firing wrote:
> Sandro Tosi wrote:
>> Hi Sam,
>>
>> On Wed, Feb 25, 2009 at 09:35, sam tygier <sam...@ya...> wrote:
>>> I think this topic has come up before, but i don't think anything has
>>> resulted from it.
>>>
> Correct, because the capability would require a *lot* of work to 
> implement,
Would i be right in assuming that it would take roughly the same amount of effort as writing a new backend? ie for each motplotlib action it would need a function to store that action and a function to call that action again.
> and most of us don't see a compelling need; we believe that a 
> better practice is to structure one's work so that plotting is separated 
> from data (result) generation in any cases where the latter is highly 
> time-consuming.
It might not be essential, but it would offer an additional work flow, that a few people seem to like.
I think it would be especially useful when it comes to putting plots into papers. I often find that i want to tweak something like the font size or labels. having a modifiable plot format seems the easiest way to achieve that. maybe the could even be some integration into latex so that if you were to resize your plot in your paper, it would be re-rendered with the fonts adjusted.
>>> I'd like a way for saving a plot from from matplotlib, so that it can be
>>> re-rendered later, possibly with a different backend, maybe to a different
>>> size, and maybe with changes to the labels. This would save me having to
>>> rerun the simulation that generated the plot.
>>>
>>> Ideally this would work by having a save_plot() function, that would save
>>> all state of the current plot into a file. This could then be loaded by a
>>> program to regenerate that plot.
>> Can't this be achieved by pickling/unpickling the mpl objects? Didn't
>> manage to test it, but it should work.
> 
> No, this has been discussed several times. Quite a bit of work would be 
> required to make all the extension code compatible with pickling. More 
> work, more complexity, more difficult code maintenance and testing. 
> It's not worth it, given the developer resources available for mpl.
a file format avoids all the issues that pickling causes.
thanks for all the comments
sam tygier