From: Yuri D'E. <wa...@us...> - 2011-02-25 12:20:17
|
In the following: <<<<<<<<<<< import matplotlib as mpl import matplotlib.figure import matplotlib.backends.backend_agg fig = mpl.figure.Figure() cvs = mpl.backends.backend_agg.FigureCanvasAgg(fig) fig.set_size_inches((20,20)) fig.suptitle("Horray!", fontsize=20) plot = fig.add_subplot(111) plot.set_title("Subtitle") plot.plot([1,2,3], [3,2,1]) fig.savefig("out.png", bbox_inches='tight') >>>>>>>>>>> suptitle is stripped from the figure. Of course the title is present if you unset bbox_inches, but that's unexpected behavior for me. Is this a bug? Thanks |
From: Jae-Joon L. <lee...@gm...> - 2011-03-01 03:44:45
|
On Fri, Feb 25, 2011 at 9:15 PM, Yuri D'Elia <wa...@us...> wrote: > In the following: > > <<<<<<<<<<< > import matplotlib as mpl > import matplotlib.figure > import matplotlib.backends.backend_agg > > fig = mpl.figure.Figure() > cvs = mpl.backends.backend_agg.FigureCanvasAgg(fig) > fig.set_size_inches((20,20)) > fig.suptitle("Horray!", fontsize=20) > plot = fig.add_subplot(111) > plot.set_title("Subtitle") > plot.plot([1,2,3], [3,2,1]) > fig.savefig("out.png", bbox_inches='tight') >>>>>>>>>>>> > > suptitle is stripped from the figure. > Of course the title is present if you unset bbox_inches, but that's unexpected behavior for me. > > Is this a bug? Unfortunately, bbox_inches option is never meant to be complete in figuring out the exact size of the figure area. However, you can use "bbox_extra_artists" keyword argument to specify additional artists that should be considered when dertermining the plot size. mytitle = fig.suptitle("Horray!", fontsize=20) ... fig.savefig("out.png", bbox_inches='tight', bbox_extra_artists=[mytitle]) Regards, -JJ > > Thanks > > > ------------------------------------------------------------------------------ > Free Software Download: Index, Search & Analyze Logs and other IT data in > Real-Time with Splunk. Collect, index and harness all the fast moving IT data > generated by your applications, servers and devices whether physical, virtual > or in the cloud. Deliver compliance at lower cost and gain new business > insights. http://p.sf.net/sfu/splunk-dev2dev > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > |
From: Yuri D'E. <wa...@us...> - 2011-03-02 12:22:01
|
On Tue, 1 Mar 2011 12:44:20 +0900 Jae-Joon Lee <lee...@gm...> wrote: > > Is this a bug? > > Unfortunately, bbox_inches option is never meant to be complete in > figuring out the exact size of the figure area. Why not? What's the purpose of bbox_inches='tight' otherwise? > However, you can use "bbox_extra_artists" keyword argument to specify > additional artists that should be considered when dertermining the > plot size. > > mytitle = fig.suptitle("Horray!", fontsize=20) > > ... > > fig.savefig("out.png", bbox_inches='tight', bbox_extra_artists=[mytitle]) That doesn't work for me either. |
From: Yuri D'E. <wa...@th...> - 2011-03-02 14:48:03
|
On Wed, 2 Mar 2011 22:01:02 +0900 Jae-Joon Lee <lee...@gm...> wrote: > >> > Is this a bug? > >> > >> Unfortunately, bbox_inches option is never meant to be complete in > >> figuring out the exact size of the figure area. > > > > Why not? What's the purpose of bbox_inches='tight' otherwise? > > Figuring out enclosing bbox when arbitrary spline paths are involved > is difficult (I think there is no exact solution). So I only intended > to support common cases. Ok, I can understand that, but shouldn't all artists used to construct the picture, as suptitle, be considered? > >> However, you can use "bbox_extra_artists" keyword argument to specify > >> additional artists that should be considered when dertermining the > >> plot size. > >> > >> mytitle = fig.suptitle("Horray!", fontsize=20) > >> > >> ... > >> > >> fig.savefig("out.png", bbox_inches='tight', bbox_extra_artists=[mytitle]) > > > > That doesn't work for me either. > > Can you be more specific? Does it throw an exception? Or the code runs > without any error but the output is still wrong? No error/exception are produced. The output is simply identical to the one without bbox_extra_artists. This also works in my previous example: import matplotlib as mpl import matplotlib.figure import matplotlib.backends.backend_agg fig = mpl.figure.Figure() cvs = mpl.backends.backend_agg.FigureCanvasAgg(fig) fig.set_size_inches((20,20)) plot = fig.add_subplot(111) plot.set_title("Subtitle") plot.plot([1,2,3], [3,2,1]) st = fig.suptitle("Horray!", fontsize=20) fig.savefig("out.png", bbox_inches='tight', bbox_extra_artists=[st]) |
From: Benjamin R. <ben...@ou...> - 2011-03-04 20:58:00
|
On Wed, Mar 2, 2011 at 8:46 AM, Yuri D'Elia <wa...@th...> wrote: > > > > On Wed, 2 Mar 2011 22:01:02 +0900 > Jae-Joon Lee <lee...@gm...> wrote: > > > >> > Is this a bug? > > >> > > >> Unfortunately, bbox_inches option is never meant to be complete in > > >> figuring out the exact size of the figure area. > > > > > > Why not? What's the purpose of bbox_inches='tight' otherwise? > > > > Figuring out enclosing bbox when arbitrary spline paths are involved > > is difficult (I think there is no exact solution). So I only intended > > to support common cases. > > Ok, I can understand that, but shouldn't all artists used to construct the > picture, as suptitle, be considered? > > > >> However, you can use "bbox_extra_artists" keyword argument to specify > > >> additional artists that should be considered when dertermining the > > >> plot size. > > >> > > >> mytitle = fig.suptitle("Horray!", fontsize=20) > > >> > > >> ... > > >> > > >> fig.savefig("out.png", bbox_inches='tight', > bbox_extra_artists=[mytitle]) > > > > > > That doesn't work for me either. > > > > Can you be more specific? Does it throw an exception? Or the code runs > > without any error but the output is still wrong? > > No error/exception are produced. The output is simply identical to the one > without bbox_extra_artists. > > This also works in my previous example: > > import matplotlib as mpl > import matplotlib.figure > import matplotlib.backends.backend_agg > > fig = mpl.figure.Figure() > cvs = mpl.backends.backend_agg.FigureCanvasAgg(fig) > fig.set_size_inches((20,20)) > plot = fig.add_subplot(111) > plot.set_title("Subtitle") > plot.plot([1,2,3], [3,2,1]) > st = fig.suptitle("Horray!", fontsize=20) > fig.savefig("out.png", bbox_inches='tight', bbox_extra_artists=[st]) > > Which version of matplotlib are you using? This example works for me using the latest matplotlib from source. Also, why the awkward usage and imports? If you want to force the Agg backend to be used, you could just do: import matplotlib matplotlib.use("Agg") before any other matplotlib imports. Ben Root |
From: Yuri D'E. <wa...@us...> - 2011-03-07 10:37:16
|
On Fri, 4 Mar 2011 14:57:34 -0600 Benjamin Root <ben...@ou...> wrote: > Which version of matplotlib are you using? This example works for me using > the latest matplotlib from source. Also, why the awkward usage and Yes, with matplotlib 1.0 bbox_extra_artists now works. I consider bbox_extra_artists some kind of a hack (IMHO, all artists should be considered with a 'tight' box), but coming from gnuplot/asymptote maybe my point of view is biased. What would be the point of a 'tight' box that excludes parts of the plot? I would specify the coordinates myself if I needed clipping. > imports? If you want to force the Agg backend to be used, you could just > do: > > import matplotlib > matplotlib.use("Agg") > > before any other matplotlib imports. Thanks for the suggestion, that looks promising, but doesn't work: ---- import matplotlib as mpl mpl.use("Agg") import matplotlib.figure fig = mpl.figure.Figure() fig.set_size_inches((20,20)) plot = fig.add_subplot(111) plot.set_title("Subtitle") plot.plot([1,2,3], [3,2,1]) st = fig.suptitle("Horray!", fontsize=20) fig.savefig("out.png", bbox_inches='tight', bbox_extra_artists=[st]) ---- produces: Traceback (most recent call last): File "test.py", line 13, in <module> fig.savefig("out.png", bbox_inches='tight', bbox_extra_artists=[st]) File "/usr/lib/pymodules/python2.6/matplotlib/figure.py", line 1084, in savefig self.canvas.print_figure(*args, **kwargs) AttributeError: 'NoneType' object has no attribute 'print_figure' I find the documentation a bit scattered around this subject. I'm not using the pyplot interface, so I guess that .use("Agg") doesn't do anything for me? I also have no reason to use the pyplot interface, why should I? I have no matlab background, and I mostly use matplotlib procedurally (ie not interactively). |
From: Benjamin R. <ben...@ou...> - 2011-03-07 15:25:49
|
On Mon, Mar 7, 2011 at 4:36 AM, Yuri D'Elia <wa...@us...> wrote: > On Fri, 4 Mar 2011 14:57:34 -0600 > Benjamin Root <ben...@ou...> wrote: > > > Which version of matplotlib are you using? This example works for me > using > > the latest matplotlib from source. Also, why the awkward usage and > > Yes, with matplotlib 1.0 bbox_extra_artists now works. > > I consider bbox_extra_artists some kind of a hack (IMHO, all artists should > be considered with a 'tight' box), but coming from gnuplot/asymptote maybe > my point of view is biased. > What would be the point of a 'tight' box that excludes parts of the plot? I > would specify the coordinates myself if I needed clipping. > > > imports? If you want to force the Agg backend to be used, you could just > > do: > > > > import matplotlib > > matplotlib.use("Agg") > > > > before any other matplotlib imports. > > Thanks for the suggestion, that looks promising, but doesn't work: > > ---- > import matplotlib as mpl > mpl.use("Agg") > import matplotlib.figure > fig = mpl.figure.Figure() > fig.set_size_inches((20,20)) > plot = fig.add_subplot(111) > plot.set_title("Subtitle") > plot.plot([1,2,3], [3,2,1]) > st = fig.suptitle("Horray!", fontsize=20) > fig.savefig("out.png", bbox_inches='tight', bbox_extra_artists=[st]) > ---- > > The problem is that you are creating your figure wrong. Try this: import matplotlib as mpl mpl.use("Agg") import matplotlib.pyplot as plt fig = plt.figure(figsize=(20, 20)) ax = fig.add_subplot(111) ax.set_title("Subtitle") ax.plot([1, 2, 3], [3, 2, 1]) st = fig.suptitle("Horray!", fontsize=20) fig.savefig("out.png", bbox_inches='tight', bbox_extra_artists=[st]) Notice that I am using the pyplot interface. Matplotlib was intended to be used through either this pyplot interface or the pylab interface (which I do not personally recommend if you want full control over your plots). If you don't use either interfaces, then don't be surprised when things do not work properly. In particular, creating the figure object by directly calling the Figure constructor bypasses important steps that involves attaching the appropriate backend to the figure object. Also notice that I name the object coming from add_subplot() "ax" instead of "plot". This is for clarity and to avoid confusion with the command "plot". This is also the generally accepted coding convention in matplotlib. > > I find the documentation a bit scattered around this subject. > I'm not using the pyplot interface, so I guess that .use("Agg") doesn't do > anything for me? > I also have no reason to use the pyplot interface, why should I? I have no > matlab background, and I mostly use matplotlib procedurally (ie not > interactively). > The only accepted ways to use matplotlib are through either the pyplot or the pylab interfaces. This is why they are called interfaces. It does not matter if you are using matplotlib interactively or procedurally. I personally use the pyplot interface in all of my scripts, as I rarely ever do interactive plotting. The pylab interface is more geared towards interactive plotting. These interfaces are designed to make your life easier. Think of it this way. The developers can make many changes to matplotlib internals from one release to the next, but we do our best to make the interface as stable as possible. If you write code that do not utilize the pylab or pyplot interfaces, then your scripts will likely break at the next release. Trust me, a lot of your problems will be solved by picking an interface (I recommend pyplot) and sticking with it. I hope this is helpful, Ben Root |
From: Yuri D'E. <wa...@th...> - 2011-03-07 16:54:49
|
On Mon, 7 Mar 2011 09:25:23 -0600 Benjamin Root <ben...@ou...> wrote: > The problem is that you are creating your figure wrong. Try this: > > import matplotlib as mpl > mpl.use("Agg") > import matplotlib.pyplot as plt > > fig = plt.figure(figsize=(20, 20)) > ax = fig.add_subplot(111) > ax.set_title("Subtitle") > ax.plot([1, 2, 3], [3, 2, 1]) > st = fig.suptitle("Horray!", fontsize=20) > fig.savefig("out.png", bbox_inches='tight', bbox_extra_artists=[st]) > > Notice that I am using the pyplot interface. Matplotlib was intended to be > used through either this pyplot interface or the pylab interface (which I do > not personally recommend if you want full control over your plots). If you > don't use either interfaces, then don't be surprised when things do not work > properly. In particular, creating the figure object by directly calling the > Figure constructor bypasses important steps that involves attaching the > appropriate backend to the figure object. I was reading this at the time: http://matplotlib.sourceforge.net/faq/usage_faq.html I inferred pyplot was just a matlab-like interface on top of matplotlib, and figured using directly the matplotlib was acceptable. Reading the documentation of the single objects of matplotlib was enough to get me started. I see pyplot as having more shortcuts for common operations, but I was unsure how far can I could go by using pyplot only. Generally, I didn't have any trouble. The includes are a bit verbose, but that's it. > Also notice that I name the object coming from add_subplot() "ax" instead of > "plot". This is for clarity and to avoid confusion with the command > "plot". This is also the generally accepted coding convention in > matplotlib. Indeed, thanks for the remark. Thanks again for your comments. |
From: Benjamin R. <ben...@ou...> - 2011-03-07 16:59:35
|
On Mon, Mar 7, 2011 at 10:33 AM, Yuri D'Elia <wa...@th...> wrote: > On Mon, 7 Mar 2011 09:25:23 -0600 > Benjamin Root <ben...@ou...> wrote: > > > The problem is that you are creating your figure wrong. Try this: > > > > import matplotlib as mpl > > mpl.use("Agg") > > import matplotlib.pyplot as plt > > > > fig = plt.figure(figsize=(20, 20)) > > ax = fig.add_subplot(111) > > ax.set_title("Subtitle") > > ax.plot([1, 2, 3], [3, 2, 1]) > > st = fig.suptitle("Horray!", fontsize=20) > > fig.savefig("out.png", bbox_inches='tight', bbox_extra_artists=[st]) > > > > Notice that I am using the pyplot interface. Matplotlib was intended to > be > > used through either this pyplot interface or the pylab interface (which I > do > > not personally recommend if you want full control over your plots). If > you > > don't use either interfaces, then don't be surprised when things do not > work > > properly. In particular, creating the figure object by directly calling > the > > Figure constructor bypasses important steps that involves attaching the > > appropriate backend to the figure object. > > I was reading this at the time: > > http://matplotlib.sourceforge.net/faq/usage_faq.html > > I inferred pyplot was just a matlab-like interface on top of matplotlib, > and figured using directly the matplotlib was acceptable. > Yeah, I am guessing that page is a little out-dated and could be better worded. However, the page does say that the preferred style is the pyplot interface. Also notice that it is extremely rare for any of the documentation to directly create the matplotlib objects without the pyplot or pylab interface. The pointof the statement "MATLAB-like" is that most of the plotting functions available in MATLAB are also available in matplotlib. In addition, the phrase "more MATLAB-like" is meant to state that various mathematical functions are made available as well. This was designed to make transitions from MATLAB to matplotlib easier for the user. Ultimately, we desire that the user transitions completely over to the pyplot interface. Note that this has nothing to do with interactivity or proceedural. If anything, pylab was more intended for interactivity because its syntax is more concise, but you lose a lot of control. > Reading the documentation of the single objects of matplotlib was enough to > get me started. I see pyplot as having more shortcuts for common operations, > but I was unsure how far can I could go by using pyplot only. > > Think of it this way. Matplotlib depends a lot upon hierarchical design. The pyplot (or pylab) interfaces sit on top of that heirarchy and represents the matplotlib environment. This environment creates figures. These figures can many components, the most important of which are one or more axes objects. Each axes object has two or more axis objects and are responsible for plotting themselves. While there are some convenience functions through pyplot for doing some things like setting an axis label, it is not required to use pyplot for that. You can (and often should) use the axes object's method for doing so. The point is that you can use the matplotlib objects for a lot of things, and it is great that you are embracing the object oriented nature of matplotlib. However, your problem was caused by-passing the hierarchy: The interface should create the figure objects, the figure objects should create the axes objects, the axes objects should create the axis objects, and so on and so forth. I hope that makes it clearer for you, and I hope you continue to use matplotlib and find it useful! Ben Root |
From: Yuri D'E. <wa...@us...> - 2011-03-07 13:25:06
|
On Mon, 7 Mar 2011 11:36:45 +0100 Yuri D'Elia <wa...@us...> wrote: > On Fri, 4 Mar 2011 14:57:34 -0600 > Benjamin Root <ben...@ou...> wrote: > > > Which version of matplotlib are you using? This example works for me using > > the latest matplotlib from source. Also, why the awkward usage and > > Yes, with matplotlib 1.0 bbox_extra_artists now works. Just out of curiosity, is this: legend = plot.legend() pic.savefig(..., bbox_extra_artists=[legend]) supposed to work? Traceback (most recent call last): File "./plot.py", line 108, in <module> fig.savefig(sys.argv[1], bbox_inches='tight', bbox_extra_artists=xa) File "/usr/lib/pymodules/python2.6/matplotlib/figure.py", line 1084, in savefig self.canvas.print_figure(*args, **kwargs) File "/usr/lib/pymodules/python2.6/matplotlib/backend_bases.py", line 1894, in print_figure in kwargs.pop("bbox_extra_artists", [])] TypeError: get_window_extent() takes exactly 1 argument (2 given) |
From: Jae-Joon L. <lee...@gm...> - 2011-03-07 17:04:16
|
On Mon, Mar 7, 2011 at 7:36 PM, Yuri D'Elia <wa...@us...> wrote: > I consider bbox_extra_artists some kind of a hack (IMHO, all artists should be considered with a 'tight' box), but coming from gnuplot/asymptote maybe my point of view is biased. > What would be the point of a 'tight' box that excludes parts of the plot? I would specify the coordinates myself if I needed clipping. > In fact, supporting the "bbox_inches" is a real hack. As I mentioned in my previous email, matplotlib artists can have spline paths. And artists can also be clipped by an arbitrary spline path. And, generally speaking, finding out the exact bounding box of an artist is difficult (but I must confess that I'm not an expert on this field and any correction or advise will be appreciated). I believe the AGG library, that matplotlib is based on, can provide an approximate bounding box for spline paths, but I'm not sure if it will work when clipping is involved (at least, the *get_window_extent* does not properly work when clipping is involved). I'll consider to support all artists in a "tight" bbox mode if *get_window_extent* gives back exact bounding box (accounting the clipping) for "all" artists. Otherwise, I'm not inclined to do this. Regards, -JJ |
From: Yuri D'E. <wa...@us...> - 2011-03-07 17:10:07
|
On Tue, 8 Mar 2011 02:03:54 +0900 Jae-Joon Lee <lee...@gm...> wrote: > On Mon, Mar 7, 2011 at 7:36 PM, Yuri D'Elia <wa...@us...> wrote: > In fact, supporting the "bbox_inches" is a real hack. > As I mentioned in my previous email, matplotlib artists can have > spline paths. And artists can also be clipped by an arbitrary spline > path. And, generally speaking, finding out the exact bounding box of > an artist is difficult (but I must confess that I'm not an expert on > this field and any correction or advise will be appreciated). I > believe the AGG library, that matplotlib is based on, can provide an > approximate bounding box for spline paths, but I'm not sure if it will > work when clipping is involved (at least, the *get_window_extent* > does not properly work when clipping is involved). I see. But can't you simply skip spline paths from the calculation? This would remove the need for bbox_extra_artists for 99% of the cases. > I'll consider to support all artists in a "tight" bbox mode if > *get_window_extent* gives back exact bounding box (accounting the > clipping) for "all" artists. Otherwise, I'm not inclined to do this. I don't know if you read this already, but: all artists should at least work with bbox_extra_artists, right? While placing the legend outside the plot I tried the following: egend = plot.legend() pic.savefig(..., bbox_extra_artists=[legend]) but it fails: Traceback (most recent call last): File "./plot.py", line 108, in <module> fig.savefig(sys.argv[1], bbox_inches='tight', bbox_extra_artists=xa) File "/usr/lib/pymodules/python2.6/matplotlib/figure.py", line 1084, in savefig self.canvas.print_figure(*args, **kwargs) File "/usr/lib/pymodules/python2.6/matplotlib/backend_bases.py", line 1894, in print_figure in kwargs.pop("bbox_extra_artists", [])] TypeError: get_window_extent() takes exactly 1 argument (2 given) |
From: Benjamin R. <ben...@ou...> - 2011-03-07 17:21:11
|
On Mon, Mar 7, 2011 at 11:09 AM, Yuri D'Elia <wa...@us...> wrote: > On Tue, 8 Mar 2011 02:03:54 +0900 > Jae-Joon Lee <lee...@gm...> wrote: > > > On Mon, Mar 7, 2011 at 7:36 PM, Yuri D'Elia <wa...@us...> wrote: > > In fact, supporting the "bbox_inches" is a real hack. > > As I mentioned in my previous email, matplotlib artists can have > > spline paths. And artists can also be clipped by an arbitrary spline > > path. And, generally speaking, finding out the exact bounding box of > > an artist is difficult (but I must confess that I'm not an expert on > > this field and any correction or advise will be appreciated). I > > believe the AGG library, that matplotlib is based on, can provide an > > approximate bounding box for spline paths, but I'm not sure if it will > > work when clipping is involved (at least, the *get_window_extent* > > does not properly work when clipping is involved). > > I see. But can't you simply skip spline paths from the calculation? > This would remove the need for bbox_extra_artists for 99% of the cases. > > > I'll consider to support all artists in a "tight" bbox mode if > > *get_window_extent* gives back exact bounding box (accounting the > > clipping) for "all" artists. Otherwise, I'm not inclined to do this. > > I don't know if you read this already, but: all artists should at least > work with bbox_extra_artists, right? > > While placing the legend outside the plot I tried the following: > > egend = plot.legend() > pic.savefig(..., bbox_extra_artists=[legend]) > > but it fails: > > Traceback (most recent call last): > File "./plot.py", line 108, in <module> > fig.savefig(sys.argv[1], bbox_inches='tight', bbox_extra_artists=xa) > File "/usr/lib/pymodules/python2.6/matplotlib/figure.py", line 1084, in > savefig > self.canvas.print_figure(*args, **kwargs) > File "/usr/lib/pymodules/python2.6/matplotlib/backend_bases.py", line > 1894, in print_figure > in kwargs.pop("bbox_extra_artists", [])] > TypeError: get_window_extent() takes exactly 1 argument (2 given) > > And this appears to be a bug. Looks like the call signature for the legend object's get_window_extent() doesn't match the call signature for all other artists. I will write up a patch for this. Ben Root |
From: Jae-Joon L. <lee...@gm...> - 2011-03-07 17:28:49
|
On Tue, Mar 8, 2011 at 2:20 AM, Benjamin Root <ben...@ou...> wrote: > And this appears to be a bug. Looks like the call signature for the legend > object's get_window_extent() doesn't match the call signature for all other > artists. > Yes. It is a bug. Meanwhile, you may use bbox_extra_artists=[leg.legendPatch] as a workaround. Regards, -JJ |
From: Brendan B. <bre...@br...> - 2011-03-07 19:00:40
|
On 2011-03-07 08:59, Benjamin Root wrote: > On Mon, Mar 7, 2011 at 10:33 AM, Yuri D'Elia<wa...@th...> wrote: >> I was reading this at the time: >> >> http://matplotlib.sourceforge.net/faq/usage_faq.html >> >> I inferred pyplot was just a matlab-like interface on top of matplotlib, >> and figured using directly the matplotlib was acceptable. >> > > Yeah, I am guessing that page is a little out-dated and could be better > worded. However, the page does say that the preferred style is the pyplot > interface. Also notice that it is extremely rare for any of the > documentation to directly create the matplotlib objects without the pyplot > or pylab interface. I think this documentation should definitely be updated, then. I've been using matplotlib a lot the last few months and was totally unaware that pyplot was "required". Good thing I read this message! :-) > The interface should create the figure objects, the figure objects should > create the axes objects, the axes objects should create the axis objects, > and so on and so forth. That makes perfect sense, but is not at all what's implied by the text on the page linked above. Best wishes, -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown |
From: Benjamin R. <ben...@ou...> - 2011-03-07 19:42:16
|
On Mon, Mar 7, 2011 at 12:42 PM, Brendan Barnwell <bre...@br...>wrote: > On 2011-03-07 08:59, Benjamin Root wrote: > > On Mon, Mar 7, 2011 at 10:33 AM, Yuri D'Elia<wa...@th...> wrote: > >> I was reading this at the time: > >> > >> http://matplotlib.sourceforge.net/faq/usage_faq.html > >> > >> I inferred pyplot was just a matlab-like interface on top of > matplotlib, > >> and figured using directly the matplotlib was acceptable. > >> > > > > Yeah, I am guessing that page is a little out-dated and could be better > > worded. However, the page does say that the preferred style is the > pyplot > > interface. Also notice that it is extremely rare for any of the > > documentation to directly create the matplotlib objects without the > pyplot > > or pylab interface. > > I think this documentation should definitely be updated, then. > I've > been using matplotlib a lot the last few months and was totally > unaware that pyplot was "required". Good thing I read this message! :-) > > > The interface should create the figure objects, the figure objects should > > create the axes objects, the axes objects should create the axis objects, > > and so on and so forth. > > That makes perfect sense, but is not at all what's implied by the > text on the page linked above. > > Best wishes, > -- > Brendan Barnwell > "Do not follow where the path may lead. Go, instead, where there is > no path, and leave a trail." > --author unknown > > Tell me what you think about this wording. Don't worry about the links on the page: https://github.com/WeatherGod/matplotlib/blob/62a02cce1ef98ff2360049ef31074bd9e82670d3/doc/faq/usage_faq.rst I greatly appreciate any further comments you have. Your perspective is invaluable for improving our docs for users like you. Ben Root |
From: Yuri D'E. <wa...@us...> - 2011-03-08 10:21:58
|
On Mon, 7 Mar 2011 13:41:49 -0600 Benjamin Root <ben...@ou...> wrote: > > I've > > been using matplotlib a lot the last few months and was totally > > unaware that pyplot was "required". Good thing I read this message! :-) I'm glad I'm not the only one :) > > > The interface should create the figure objects, the figure objects should > > > create the axes objects, the axes objects should create the axis objects, > > > and so on and so forth. I've read the revised link you posted: https://github.com/WeatherGod/matplotlib/blob/62a02cce1ef98ff2360049ef31074bd9e82670d3/doc/faq/usage_faq.rst I think you should definitely put the above sentence, which IMHO makes the relation of pyplot (and usage of matplotlib) astoundingly clear. |
From: Yuri D'E. <yur...@eu...> - 2011-03-07 10:25:46
|
On Sun, 6 Mar 2011 21:47:04 +0900 Jae-Joon Lee <lee...@gm...> wrote: > > Ok, I can understand that, but shouldn't all artists used to construct the picture, as suptitle, be considered? > > I think considering all the artists is not very practical (as some of > them could have spline paths), but what we may be able to do is to > consider all the texts in the figure. I'll try to implement them. Can you describe a scenario where considering all artists may produce wrong/unintended results? Considering all texts in the figure might be a good-enough solution, but I honestly have an hard time figuring out a case where bbox_inches should ignore some elements. I come from a gnuplot/asymptote background, so my view could be biased. > > import matplotlib as mpl > > import matplotlib.figure > > import matplotlib.backends.backend_agg > > > > fig = mpl.figure.Figure() > > cvs = mpl.backends.backend_agg.FigureCanvasAgg(fig) > > fig.set_size_inches((20,20)) > > plot = fig.add_subplot(111) > > plot.set_title("Subtitle") > > plot.plot([1,2,3], [3,2,1]) > > st = fig.suptitle("Horray!", fontsize=20) > > fig.savefig("out.png", bbox_inches='tight', bbox_extra_artists=[st]) > > > > I believe you're using a matplotlib version that the > "bbox_extra_artists" keyword was not yet implemented. > Can you try to install 1.0 version of matpltolib? > As Benjamin has confirmed, this is supposed to work (with recent > version of matplotlib). > If upgrading is not possible, I'll try to come up with a workaround (I > don't think it will be done with a few lines of code though). Yes, thanks. By upgrading to 1.0, bbox_extra_artists now works. |