Re: [matplotlib-devel] SaveFig bug in TkAgg backend
This is a well known problem, reported about a year or so ago. John Hunter tried to get some help on the (TK?) mailinglist, but I don't think anybody responded. I looked into it too, but couldn't find a solution (that doesn't mean much, except for that it is not blatently obvious). It would be great if somebody would know how to fix this. Strangely enough I have written a GUI myself where I use the toolbar, and the save button works fine there. Mark Date: Thu, 10 May 2007 13:31:18 -0600 From: Urvashi R.V. [EMAIL PROTECTED] Hi, When the save button is used on the matplotlib tkagg toolbar, it uses the Tk asksavefilename object from the tkFileDialog class, to pop up a little window that allows you to select the name and type of file to save.This function internally calls figure.destroy(). and the currently active figure gets destroyed (but it is still visible and memory is not freed). The next plot then creates a new figure window with the same figure._num as the previous. see... backend_tkagg.py : line 621 - class NavigationToolbar2TkAgg :: def save_figure(...) (callback for the toolbar.bsave button) The asksavefilename function call, triggers Gcf.destroy(). This can be seen by placing a print statement in _pylab_helpers.py : line 16 - class Gcf :: def destroy(num) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] unicode support for latex
Hi Darren,
I've made the changes you requested and committed it. (I didn't realize
that mpl-data/matplotlibrc was generated from the template -- I actually
already placed a descriptive line of text in the overwritten file.)
I'm attaching a file for the examples/ directory which I'm having
trouble checking in. I'm rushing out the door for a weekend away at the
moment, so if you can check this in, that'd be great, otherwise I'll try
again when I'm back online. I think it might be an issue with the
non-ASCII characters in the file.
I'll also update the wiki page when I get back.
-Andrew
Darren Dale wrote:
Hi Andrew,
On Thursday 17 May 2007 10:12:09 pm Andrew Straw wrote:
OK, here's the patch! :)
Andrew Straw wrote:
Hi All (esp. Darren),
The attached patch adds unicode support for LaTeX. Given the recent
discussion about adding preambles, I thought I'd run it past here first.
Anyone opposed if I check this in?
No opposition, but a couple requests. Would you add a commented out line to
matplotlibrc.template, with some brief discussion if you think it is
appropriate? Also, lets make it a policy that the custom preamble always
appears after all other preambles in texmanager amd backend_ps.
Note that I specifically added the rcParam text.latex.unicode to enable
this and a default False value to turn this off by default. I hope this
prevents breakage for folks who don't have the ucs and inputenc latex
packages installed while allowing unicode for those of us that do.
I have never used unicode with latex, will you add a nugget to
http://www.scipy.org/Cookbook/Matplotlib/UsingTex?
Darren
#!/usr/bin/env python
# -*- coding: latin-1 -*-
This demo is tex_demo.py modified to have unicode. See that file for
more information.
from matplotlib import rcParams
rcParams['text.usetex']=True
rcParams['text.latex.unicode']=True
from matplotlib.numerix import arange, cos, pi
from pylab import figure, axes, plot, xlabel, ylabel, title, \
grid, savefig, show
figure(1)
ax = axes([0.1, 0.1, 0.8, 0.7])
t = arange(0.0, 1.0+0.01, 0.01)
s = cos(2*2*pi*t)+2
plot(t, s)
xlabel(r'\textbf{time (s)}')
s = unicode(r'\textit{Velocity (°/sec)}','latin-1')
ylabel(unicode(r'\textit{Velocity (°/sec)}','latin-1'),fontsize=16)
title(r\TeX\ is Number $\displaystyle\sum_{n=1}^\infty\frac{-e^{i\pi}}{2^n}$!,
fontsize=16, color='r')
grid(True)
savefig('tex_demo')
show()
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] rc parameters and config file
I'm moving this discussion over to mpl-dev. Its gettin too hairy for the more general audience. On Friday 18 May 2007 12:02:30 pm Alexander Schmolck wrote: If I may make another suggestion (I don't have time to volunteer for implementing them in the forseeable future, but I might eventually if there's interest): Maybe the way configuration is handled could be improved: 1. It seems to me that letting users manipulate some raw dictionary (`rcParams`) in order to customize behavior is bad. Just now, on my first dig into matplotlib I've found a number of bugs that result from bad state in rcParams. As a user this has also caused me some wasted time, because typos and other illegal param choices are not caught early (but are relativley likely, because matplotlib has many and complex options). Using some dedicated class-instance instead of a dict would allow for: - automatic conistency checks on setting - possibly even change propagation (likely faster and certainly less error prone if done right: I'm not sure how many places rcParams dependent results apart from the tex-stuff are cached and should be recomputed when certain params change, but obviously an push/'event'-based solutin could be faster than pull/polling) - possibly better performance, because e.g. using immutable values would allow identity based checks to see if a rcParam changed and obviate the need to copy; - convenient doc lookup and searching an display of available alternatives (e.g. font-families etc) - better factoring of the matplotlibrc parsing and validation see below: This sounds like a good proposal to me. Some other devs had considered using the traits package to address some of these points. Maybe they will comment. 2. It also seems to me that having some custom config file format rather than just (a literal-only subset of) python is suboptimal. Why make people learn another and more limited syntax when python literals are already familiar and both more powerful and easier to use If someone donated a nickel for every time I have seen this argument on the mailing list, we might have enough money to buy John a doughnut. (e.g. the latex-preamble setting can't express multiple package options, because param values can't contain ',')? Thats a pretty big bug. See the disclaimer concerning preamble customizations :) It would also get rid of the IMO undesirable coupling of string-parsing and type-checking that the validate_* functions do at the moment; really setting an rcParam should also do the latter but not the former (and guaranteed validation on setting would also avoid the need to sprinkle random checks on reading through the code). IMO it would be much nicer if there was some more declarative way to specify options, check their validity on setting and assoicate docs with them (sort of like e.g. emcs-custom vars). Valid files in the old-syntax could be translated automatically quite easily, so I don't think it's a compatiblity issue. These are all good points, most of which have been brought up before. What we need is someone with sufficient time and motivation... Darren - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
