[matplotlib-devel] ginput in nbagg backend to use in IPython Notebooks
Hello List, Are there any plans to make ginput work in the nbagg backend? It would be so cool if I could use that in an IPython Notebook together with the other widgets. Thanks, Mark -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] xkcd doesn't seem to work in MacOSX backend
Hello list, I don't seem to get xkcd to work in the MacOSX backend. When I try to make a plot I get a nice white figure with nothing on it. Here's what I did: import matplotlib.pyplot as plt %matplotlib # responds with Using matplotlib backend: MacOSX plt.plot([1,2,3]) # gives white figure with nothing on it When I do a kernel restart and specify the qt backend it works fine (so I have a workaround), but I presume it should work, right? Thanks, Mark -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] xkcd doesn't seem to work in MacOSX backend
Sorry, forgot to mention that: 1.4.0 On Tue, Nov 18, 2014 at 5:00 PM, Benjamin Root ben.r...@ou.edu wrote: Which version of matplotlib are you using? On Tue, Nov 18, 2014 at 10:55 AM, Mark Bakker mark...@gmail.com wrote: Hello list, I don't seem to get xkcd to work in the MacOSX backend. When I try to make a plot I get a nice white figure with nothing on it. Here's what I did: import matplotlib.pyplot as plt %matplotlib # responds with Using matplotlib backend: MacOSX plt.plot([1,2,3]) # gives white figure with nothing on it When I do a kernel restart and specify the qt backend it works fine (so I have a workaround), but I presume it should work, right? Thanks, Mark -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] xkcd doesn't seem to work in MacOSX backend
Like I said, it works fine when I select the QT backend. So I have a workaround. I was just wondering wether it was supposed to work with the MacOSX backend. Does anybody know? If so, I'll file a bug report. Mark On Tue, Nov 18, 2014 at 6:55 PM, Phil Elson pelson@gmail.com wrote: Isn't the XKCD stuff baked into the Agg backend. Is it even possible to produce XKCD svg or PDFs? On 18 November 2014 17:01, Jens Nielsen jenshniel...@gmail.com wrote: I can reproduce it with the following traceback. Can you please open a bug report on Github for this issue? ``` Traceback (most recent call last): File /usr/local/lib/python2.7/site-packages/matplotlib/artist.py, line 59, in draw_wrapper draw(artist, renderer, *args, **kwargs) File /usr/local/lib/python2.7/site-packages/matplotlib/figure.py, line 1079, in draw func(*args) File /usr/local/lib/python2.7/site-packages/matplotlib/artist.py, line 59, in draw_wrapper draw(artist, renderer, *args, **kwargs) File /usr/local/lib/python2.7/site-packages/matplotlib/axes/_base.py, line 2092, in draw a.draw(renderer) File /usr/local/lib/python2.7/site-packages/matplotlib/artist.py, line 59, in draw_wrapper draw(artist, renderer, *args, **kwargs) File /usr/local/lib/python2.7/site-packages/matplotlib/lines.py, line 712, in draw drawFunc(renderer, gc, tpath, affine.frozen()) File /usr/local/lib/python2.7/site-packages/matplotlib/lines.py, line 1067, in _draw_lines self._lineFunc(renderer, gc, path, trans) File /usr/local/lib/python2.7/site-packages/matplotlib/lines.py, line 1107, in _draw_solid renderer.draw_path(gc, path, trans) File /usr/local/lib/python2.7/site-packages/matplotlib/patheffects.py, line 115, in draw_path rgbFace) File /usr/local/lib/python2.7/site-packages/matplotlib/patheffects.py, line 217, in draw_path renderer.draw_path(gc, tpath, affine, rgbFace) File /usr/local/lib/python2.7/site-packages/matplotlib/backends/backend_macosx.py, line 58, in draw_path gc.draw_path(path, transform, linewidth, rgbFace) AttributeError: GraphicsContextBase instance has no attribute 'draw_path' ``` best Jens On Tue, Nov 18, 2014 at 4:12 PM, Mark Bakker mark...@gmail.com wrote: Sorry, forgot to mention that: 1.4.0 On Tue, Nov 18, 2014 at 5:00 PM, Benjamin Root ben.r...@ou.edu wrote: Which version of matplotlib are you using? On Tue, Nov 18, 2014 at 10:55 AM, Mark Bakker mark...@gmail.com wrote: Hello list, I don't seem to get xkcd to work in the MacOSX backend. When I try to make a plot I get a nice white figure with nothing on it. Here's what I did: import matplotlib.pyplot as plt %matplotlib # responds with Using matplotlib backend: MacOSX plt.plot([1,2,3]) # gives white figure with nothing on it When I do a kernel restart and specify the qt backend it works fine (so I have a workaround), but I presume it should work, right? Thanks, Mark -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Download BIRT iHub F-Type - The Free
Re: [matplotlib-devel] problems with shared axis
Dang, I looked at it, but so much has changed since 0.98.3 release that I have little chance of getting any changes implemented. Any plans for a new release that you know of? Thanks, Mark On Mon, Oct 27, 2008 at 7:29 PM, Eric Firing [EMAIL PROTECTED] wrote: Mark Bakker wrote: I was gone for the weekend (sorry, but that 'life' thing gets in the way of getting things done sometimes). I don't have a way to build stuff at the moment. Can I just check out the axes.py and replace my current one, or are there too many changes? The changes were in ticker.py and axes.py. Whether plugging in the current versions would work depends on the age of the other files you have. If you have a fairly recent svn build, then updating those two files probably would work. You could use svn to get the diffs specifically for my changes related to shared axes. Eric Mark On Fri, Oct 24, 2008 at 7:57 AM, Eric Firing [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] wrote: Mark Bakker wrote: Hello list (especially Erik, who can fix this I hope) - I have had problems with shared axes, especially when one of the axis has an aspect ratio that is set 'equal'. It has been discussed on the list before (mostly with Erik Firing), but it hasn't been fixed yet. What I want to do is have two plots. The top plot has an aspect ratio that is 'equal'. The idea is to have a contour plot in the top figure, while the bottom figure gives a cross-sectional picture of what I am plotting. This used to work well (quite some time ago), including zooming and such. But now I cannot plot it at all, let alone zoom. My first problem is when I add a subplot with a shared x-axis, it changes the limits on the original x-axis. That seems to be a bug: ax1 = subplot(211) plot([1,2,3]) # Now the limits of the x-axis go from 0 to 2. subplot(212,sharex=ax1) # Now the limits of both x-axis go from 0 to 1. After all, the new subplot shares the axis with the existing subplot, so why doesn't it copy the axis limits from that subplot? But the bigger problem occurs when I want the aspect ratio of one of the first axis to be 'equal'. ax1 = subplot(211,aspect='equal') plot([1,2,3]) subplot(212,sharex=ax1) Mark, I made some more changes so that the above works by changing the adjustable to 'datalim'. Have I broken anything? Does this work for your applications? Eric The second subplot is added, but the length of the graph is not the same as for the first subplot. It also resets the xlimits to go from 0 to 1, as before, which means the first subplot becomes unreadable (it still enforces 'equal' in the first subplot by changing the limits of the y-axis). When I now change the limits on the x-axis, the aspect ratio is not equal anymore ax1.set_xlim(0,2) draw() Thanks for your help. I am willing to help in testing any changes. Best regards, Mark - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net mailto:Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] problems with shared axis
Thanks Eric. You know that this has been on my wish list for a long time. Let me know if I can test anything or help in any other way, Mark On Wed, Oct 22, 2008 at 10:54 AM, Eric Firing [EMAIL PROTECTED] wrote: Mark Bakker wrote: Hello list (especially Erik, who can fix this I hope) - I have had problems with shared axes, especially when one of the axis has an aspect ratio that is set 'equal'. It has been discussed on the list before (mostly with Erik Firing), but it hasn't been fixed yet. What I want to do is have two plots. The top plot has an aspect ratio that is 'equal'. The idea is to have a contour plot in the top figure, while the bottom figure gives a cross-sectional picture of what I am plotting. This used to work well (quite some time ago), including zooming and such. But now I cannot plot it at all, let alone zoom. My first problem is when I add a subplot with a shared x-axis, it changes the limits on the original x-axis. That seems to be a bug: ax1 = subplot(211) plot([1,2,3]) # Now the limits of the x-axis go from 0 to 2. subplot(212,sharex=ax1) # Now the limits of both x-axis go from 0 to 1. After all, the new subplot shares the axis with the existing subplot, so why doesn't it copy the axis limits from that subplot? I may have the fix for this, but I need more time to check and refine it--and try to make sure that I don't break anything else in the process. But the bigger problem occurs when I want the aspect ratio of one of the first axis to be 'equal'. ax1 = subplot(211,aspect='equal') plot([1,2,3]) subplot(212,sharex=ax1) The second subplot is added, but the length of the graph is not the same as for the first subplot. It also resets the xlimits to go from 0 to 1, as before, which means the first subplot becomes unreadable (it still enforces 'equal' in the first subplot by changing the limits of the y-axis). When I now change the limits on the x-axis, the aspect ratio is not equal anymore I will see what I can do. There are definitely some bugs that need to be squashed. Eric ax1.set_xlim(0,2) draw() Thanks for your help. I am willing to help in testing any changes. Best regards, Mark - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] problems with shared axis
Hello list (especially Erik, who can fix this I hope) - I have had problems with shared axes, especially when one of the axis has an aspect ratio that is set 'equal'. It has been discussed on the list before (mostly with Erik Firing), but it hasn't been fixed yet. What I want to do is have two plots. The top plot has an aspect ratio that is 'equal'. The idea is to have a contour plot in the top figure, while the bottom figure gives a cross-sectional picture of what I am plotting. This used to work well (quite some time ago), including zooming and such. But now I cannot plot it at all, let alone zoom. My first problem is when I add a subplot with a shared x-axis, it changes the limits on the original x-axis. That seems to be a bug: ax1 = subplot(211) plot([1,2,3]) # Now the limits of the x-axis go from 0 to 2. subplot(212,sharex=ax1) # Now the limits of both x-axis go from 0 to 1. After all, the new subplot shares the axis with the existing subplot, so why doesn't it copy the axis limits from that subplot? But the bigger problem occurs when I want the aspect ratio of one of the first axis to be 'equal'. ax1 = subplot(211,aspect='equal') plot([1,2,3]) subplot(212,sharex=ax1) The second subplot is added, but the length of the graph is not the same as for the first subplot. It also resets the xlimits to go from 0 to 1, as before, which means the first subplot becomes unreadable (it still enforces 'equal' in the first subplot by changing the limits of the y-axis). When I now change the limits on the x-axis, the aspect ratio is not equal anymore ax1.set_xlim(0,2) draw() Thanks for your help. I am willing to help in testing any changes. Best regards, Mark - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] problems with labeling contour lines in 0.98.3
Hello David - Sorry for the late reply. I am back from vacation. Any luck on solving the problem of the disappearing contour lines when labelling? It works fine when you don't use the 'inline', but the picture is of course not as nice, as the labels are not in-line anymore. Maybe that gives a clue to what goes wrong? Thanks, Mark On Wed, Sep 3, 2008 at 12:47 PM, David M. Kaplan [EMAIL PROTECTED]wrote: Hi, Back from vacation. The problem with not being able to end point selection is easy to fix - allow keyboard clicks to also select points and enter to also exit (this is the solution matlab uses). This is easy to add and I will try to work on it sometime over the next couple of weeks. I will try your example sometime soon and see what happens. It sounds like the problem has something to do with what happens when the label covers the entire contour - currently the contour gets deleted entirely, but this seems to be doing something strange in your case. Cheers, David On Thu, 2008-08-21 at 16:02 +0200, Mark Bakker wrote: David - Enjoy your vacation. I tried the contour_label_demo and it works fine, but my problem remains. I suggest you try the example I provided below, and notice the difference between labeling with inline=True and inline=False. When inline=True the contours in the middle part (which don't get labeled, presumably because there isn't enough room) get erased. I figured out the manual input problem. The trick is that you require to press the middle button to end (I'll do a post to the user's list). Many laptops don't have a middle button. Although suggestions are found on the web that pushing both buttons simultaneously works, I have never seen it work. What you have to do is configure your touchpad such that a corner acts as the middle button. Once I figured that out, I could end manually selecting the labels. Very nice. If I may, I strongly recommend you change the code such that pushing the right button ends the manual input. Is there any reason not to use the right button for that? I hope you can fix the inline problem. Thanks for all the other new cool features, Mark On Tue, Aug 19, 2008 at 4:06 PM, [EMAIL PROTECTED] wrote: Hi, I am currently on vacation, so I can´t be of much help - back beginning of next month. It would be useful if you could try the clabel and ginput demo scripts and send images of the resulting figures so that we can determine exactly what things work and don´t work. Thanks, David Mark Bakker [EMAIL PROTECTED] ha escrito: Hello David and the developers list- I have had little luck on the mailing list, so sorry for writing you directly (David may be on vacation). I have two problems labeling contour lines in 0.98.3. First, when I call clabel, it removes all contours that are not labeled (because the label doesn't fit on the section of contour, I presume). This seems like a bug to me (or a really odd feature). It doesn't do this when inline = False, but I don't think it should do it either when inline = True Easy example: x,y = meshgrid( linspace(-10,10,50), linspace(-10,10,50) ) z = log(x**2 + y**2) cobj = contour(x,y,z) # Note that there are 8 contours levels (11 contour sections in all) cobj.clabel() a list of 8 text.Text objects draw() # Now only 5 contours are drawn; the ones in the middle are removed. Second, when using the new manual labeling of contour labels (which is pretty neat!), how do I end this feature? The doc string says: right click, or potentially click both mouse buttons together (which already worries me). Neither works for me on win32, mpl 0.98.3, TkAgg backend, interactive mode. Does anybody have a solution? Thanks, Mark This message was sent using IMP, the Internet Messaging Program
Re: [matplotlib-devel] problems with labeling contour lines in 0.98.3
David - Enjoy your vacation. I tried the contour_label_demo and it works fine, but my problem remains. I suggest you try the example I provided below, and notice the difference between labeling with inline=True and inline=False. When inline=True the contours in the middle part (which don't get labeled, presumably because there isn't enough room) get erased. I figured out the manual input problem. The trick is that you require to press the middle button to end (I'll do a post to the user's list). Many laptops don't have a middle button. Although suggestions are found on the web that pushing both buttons simultaneously works, I have never seen it work. What you have to do is configure your touchpad such that a corner acts as the middle button. Once I figured that out, I could end manually selecting the labels. Very nice. If I may, I strongly recommend you change the code such that pushing the right button ends the manual input. Is there any reason not to use the right button for that? I hope you can fix the inline problem. Thanks for all the other new cool features, Mark On Tue, Aug 19, 2008 at 4:06 PM, [EMAIL PROTECTED] wrote: Hi, I am currently on vacation, so I can´t be of much help - back beginning of next month. It would be useful if you could try the clabel and ginput demo scripts and send images of the resulting figures so that we can determine exactly what things work and don´t work. Thanks, David Mark Bakker [EMAIL PROTECTED] ha escrito: Hello David and the developers list- I have had little luck on the mailing list, so sorry for writing you directly (David may be on vacation). I have two problems labeling contour lines in 0.98.3. First, when I call clabel, it removes all contours that are not labeled (because the label doesn't fit on the section of contour, I presume). This seems like a bug to me (or a really odd feature). It doesn't do this when inline = False, but I don't think it should do it either when inline = True Easy example: x,y = meshgrid( linspace(-10,10,50), linspace(-10,10,50) ) z = log(x**2 + y**2) cobj = contour(x,y,z) # Note that there are 8 contours levels (11 contour sections in all) cobj.clabel() a list of 8 text.Text objects draw() # Now only 5 contours are drawn; the ones in the middle are removed. Second, when using the new manual labeling of contour labels (which is pretty neat!), how do I end this feature? The doc string says: right click, or potentially click both mouse buttons together (which already worries me). Neither works for me on win32, mpl 0.98.3, TkAgg backend, interactive mode. Does anybody have a solution? Thanks, Mark This message was sent using IMP, the Internet Messaging Program. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] The new logo (was: future of mpl documentation)
I agree that the new logo looks nice, but I also think that Rob is right: When you see the logo you wouldn't know that we are talking about a general purpose plotting package. So the question is: are we going for looks over meaning? I guess the other way around would be terrible: choosing meaning over looks you are stuck with an ugly logo that carries the right message. So to me, looks it is, Mark On Jun 1, 2008, at 9:47 AM, Rob Hetland wrote: 2. I like the figure to the side (and agree that there should be only one), but it seems that polar plots are more rarely used than normal x-y plots. Perhaps an x-y plot (the histogram, for example) would be better advertising. I was the one who originally chose the polar plot. I admit, it was mainly for aesthetics. Here are a few reasons: * I think a circular plot works better on the logo than a rectangular plot would. * The polar plot is one of the more attractive plots in the examples. * It's a plotting featuring that most plotting software wouldn't have so it seems to differentiate matplotlib from other plotting software. Originally, it wasn't a big deal because there were other plots in the logo. Still, I'd be in favor of keeping the polar plot for aesthetic reasons. Great, now I'm that guy who's arguing for looks over practicality. :( -Tony - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] new release?
That fixes it on my machine.
Except that the function GetRealpathAndStat is in cbook.py (I don't even
have a mplutil.py file).
Thanks,
Mark
On Tue, May 13, 2008 at 7:21 PM, Michael Droettboom [EMAIL PROTECTED] wrote:
I suspect on Windows it is safe enough (in most cases) to use the realpath
as the key, in lieu of anything better. But that would require testing on
Windows to make sure. Can you try replacing the GetRealpathAndStat in
mplutil.py with the following?
class GetRealpathAndStat:
def __init__(self):
self._cache = {}
def __call__(self, path):
result = self._cache.get(path)
if result is None:
realpath = os.path.realpath(path)
if sys.platform == win32:
stat_key = realpath
else:
stat = os.stat(realpath)
stat_key = (stat.st_ino, stat.st_dev)
result = realpath, stat_key
self._cache[path] = result
return result
get_realpath_and_stat = GetRealpathAndStat()
Cheers,
Mike
Mark Bakker wrote:
John, Michael -
Now that we are talking about a new release, did you guys ever manage to
fix the bug described below. It had to do with greek symbols not showing up
in postscript files on windows. John seemed to have tracked down the source
of the problem, but I never heard of a solution.
Thanks,
Mark
On Tue, Mar 25, 2008 at 7:50 PM, John Hunter [EMAIL PROTECTED] mailto:
[EMAIL PROTECTED] wrote:
On Tue, Mar 25, 2008 at 12:02 PM, Michael Droettboom
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
The *intention* is that the fonts *should* be included (with the
exception of ps.useafm == True). That was definitely not a
deliberate
change.
However, as one of the ones who hasn't been able to reproduce this
problem, I'm afraid I'm not of much help. From reading the
code, I'm
still completely stumped as to why the font is not embedded.
Someone
will have to step through with a debugger on one of the broken
systems
to figure this out, I'm afraid.
I was able to replicate the bug and find the source of the problem.
I
am not 100% sure how to fix it, but someone who knows os.stat better
might. The problem is that matplotlib.cbook.get_realpath_and_stat
class GetRealpathAndStat:
def __init__(self):
self._cache = {}
def __call__(self, path):
result = self._cache.get(path)
if result is None:
realpath = os.path.realpath(path)
stat = os.stat(realpath)
stat_key = (stat.st_ino, stat.st_dev)
result = realpath, stat_key
self._cache[path] = result
return result
get_realpath_and_stat = GetRealpathAndStat()
is returning the same stat ino and dev for all the font files, and
thus the renderer.used_characters dictionary is getting improper keys
-- always (0,0). So the first font in the gate, in this case Vera,
is
getting a place in the dict and subsequent fonts (the cm* ones) are
not. The basic problem is that the inode and dev appear to be unix
only.
Michael: if you let me know better what this key is supposed to be
doing (can we not simply use the filename for windows?) then I can
attempt or test some fixes.
JDH
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] new release?
John, Michael -
Now that we are talking about a new release, did you guys ever manage to fix
the bug described below. It had to do with greek symbols not showing up in
postscript files on windows. John seemed to have tracked down the source of
the problem, but I never heard of a solution.
Thanks,
Mark
On Tue, Mar 25, 2008 at 7:50 PM, John Hunter [EMAIL PROTECTED] wrote:
On Tue, Mar 25, 2008 at 12:02 PM, Michael Droettboom [EMAIL PROTECTED]
wrote:
The *intention* is that the fonts *should* be included (with the
exception of ps.useafm == True). That was definitely not a deliberate
change.
However, as one of the ones who hasn't been able to reproduce this
problem, I'm afraid I'm not of much help. From reading the code, I'm
still completely stumped as to why the font is not embedded. Someone
will have to step through with a debugger on one of the broken systems
to figure this out, I'm afraid.
I was able to replicate the bug and find the source of the problem. I
am not 100% sure how to fix it, but someone who knows os.stat better
might. The problem is that matplotlib.cbook.get_realpath_and_stat
class GetRealpathAndStat:
def __init__(self):
self._cache = {}
def __call__(self, path):
result = self._cache.get(path)
if result is None:
realpath = os.path.realpath(path)
stat = os.stat(realpath)
stat_key = (stat.st_ino, stat.st_dev)
result = realpath, stat_key
self._cache[path] = result
return result
get_realpath_and_stat = GetRealpathAndStat()
is returning the same stat ino and dev for all the font files, and
thus the renderer.used_characters dictionary is getting improper keys
-- always (0,0). So the first font in the gate, in this case Vera, is
getting a place in the dict and subsequent fonts (the cm* ones) are
not. The basic problem is that the inode and dev appear to be unix
only.
Michael: if you let me know better what this key is supposed to be
doing (can we not simply use the filename for windows?) then I can
attempt or test some fixes.
JDH
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] bug in mathtext eps output
I am trying this problem on the developer's list. Whenever I type a greek symbol in mathtext and save the figure as eps, the greek symbols don't show up in the eps file. Confirmed on several windows machines. Python 2.4. mpl 0.91.2. (but it worked fine under 0.90.1). Does anybody else have this problem? It worked for mpl 0.90.1. Has something changed in mathtext that causes this? Mark Bakker - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Problem with Agg Ellipses
Tedd, Michael - Sorry to join this discussion late, but wouldn't it be easier to use a representation of an ellipse in complex variables? That's what I have been using and it seems pretty quick to me. Have you guys tried this? Any experience you want to share? Mark - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Inches?
Just to clarify: the OFFICIAL definition of an inch is 2.54 cm. So rounding errors shouldn't be much of a problem. Date: Mon, 29 Oct 2007 09:37:06 -0400 From: Michael Droettboom [EMAIL PROTECTED] I agree that we have to remain in inches internally. Non-metric units are pretty ingrained in the printing world (not just in matplotlib) -- Postscript, for example, always does page sizes in inches, even if you're using a metric page size like A4. The current definition of a point as 1/72 of a modern inch is also fairly standard worldwide. Even printers in France, for example, are spec'd in points par pouce (ppp), which is exactly equivalent to dots per inch (dpi). However, that's just an implementation detail we have to stick with. Matplotlib has Figure.get/set_size_inches now. What's to stop us from adding get/set_size_cm, and doing the conversion right there? There might be some rounding error, but I don't think it matters in this particular case. We would probably also want to add a figsize_cm kwarg to the Figure constructor (which would be mutually exclusive to figsize). What do you think? Cheers, Mike - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
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
[matplotlib-devel] Interactive save still broken in Tkinter
Sorry to bug you about this again. This is an old problem that hasn't been fixed yet. I don't know how to fix it, but I hope somebody does. Using Tkinter, in interactive mode, using pylab, after saving by clicking on the save button on Toolbar2, any reference to the figure will have disappeared (although the figure window remains open). So the next plot command will create an entirely new figure. This bug was started, we think, when we switched to the *much* nicer filedialog that we are using right now. I would like to keep using the nicer filedialog, but I also would like the bug to be fixed. Anybody any ideas? Thanks, Mark - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] subplots adjust
Darren -Although I agree with your on some level, the advantage of the current toolbar is that it is easy to incorporate in a GUI, where the user can define his own drop down menu. So I vote for a backend native slider, but keep the button on the toolbar. I have been thinking about an easier way to have user-defined toolbars (and I am sure others have much better ideas). I would rather put energy towards modifyable toolbars than a dropdown menu,Mark --Message: 4Date: Mon, 7 Aug 2006 09:34:57 -0400 From: Darren Dale [EMAIL PROTECTED]Subject: [matplotlib-devel] subplots adjustTo: matplotlib-devel@lists.sourceforge.net Message-ID: [EMAIL PROTECTED]Content-Type: text/plain;charset=us-asciiI am writing to ask about the subplots adjust widget. I think the gui would be better implimented by each backend using the native widgets rather than bythe existing set of backend-neutral sliders, which are somewhat unbecoming.The proposed backend-specific widgets could call the generic subplot resize routines, and really shouldn't be that difficult to impliment. Also, I wasthinking that subplot_adjust should be selectable from a standarddropdown File, Edit, View... menubar instead of on the main toolbar. The save button could also be moved to the drop down menu bar.Darren-- - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
