matplotlib-devel Mailing List for matplotlib

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))
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())".
Unless others object, I'll commit the changes to the trunk.
Regards,
-JJ

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, 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.
One nice benefit, however, would be that the data could be shipped to
another interpreter for plotting without worrying about threads/GIL/etc.
So, having an MPL-native plot description would be useful. But, I agree,
it would be a lot of work.

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, 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.
>> 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.
> 
> Of course, it might fall in uncompatibility from source (pickling)
> environment and the destination (unpickling) one.
Yes, pickling is fundamentally unreliable, and should be used only under 
controlled, non-critical circumstances, such as for caching.
Eric
> 
> Regards,

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.
>
> 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.
Of course, it might fall in uncompatibility from source (pickling)
environment and the destination (unpickling) one.
Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi