Re: [Matplotlib-users] Feature request: automatic scaling of subplots, margins, etc
Hi Jae-Loon, thanks for your comments! Of course I do agree that a figure layout should not change in interactive mode. However, I don't see why this should happen upon a panning action. A different case is when the label or title font sizes are changed, but I was assuming this is adjusted prior to the creation of the figure. For the time being I am very happy with Tony's solution. It works nice most of the time, only very complex figures take forever now to be drawn. The current behavior *looks* broken to any user who does not understand the internals. And it's too likely that even simple figures look horrible. I'd definitely vote for a more end-user friendly solution (with end users I have scientific users in mind who generally appreciate the beauty of the generated plots but who don't integrated the library into some other application). Best regards, Daniel 2011/5/11 Jae-Joon Lee lee.j.j...@gmail.com: On Fri, May 6, 2011 at 5:20 PM, Daniel Mader danielstefanma...@googlemail.com wrote: From many postings here I have learned that this is the absolute intention, i.e. it is broken by design unless the programmer takes care about this. I think there are pros and cons, and I don't think the current design is simply broken. For example, it will be very distracting if the axes area changes while you're doing some interactive stuff (e.g., panning). Anyhow I admit that the default layout may not be optimal for figures with multiple subplots, and there is a room for improvement. There are a few approach you can take. * If you're only interested in saved outputs, you may use savefig with bbox_inches=tight. Note that this changes the size of figure. * Use Tony's script to adjust the subplot params automatically. * use axes_grid1 toolkit which enables you to change the axes position on the fly. Check http://www.mail-archive.com/matplotlib-users@lists.sourceforge.net/msg18743.html. For current git master branch, check examples/axes_grid/make_room_for_ylabel_using_axesgrid.py Regards, -JJ -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Feature request: automatic scaling of subplots, margins, etc
On Wed, May 11, 2011 at 5:03 PM, Daniel Mader danielstefanma...@googlemail.com wrote: Hi Jae-Loon, thanks for your comments! Of course I do agree that a figure layout should not change in interactive mode. However, I don't see why this should happen upon a panning action. A different case is when the label or title font sizes are changed, but I was assuming this is adjusted prior to the creation of the figure. Since you said the current design is broken, I thought you want things adjusted *whenever* a figure is updated. So, I guess what you want is some functionality like what Tony's script does? One of the reason that I was not very inclined to Tony's approach is that it only works for subplots (and I guess it only works with subplots with pure n x m grid. Correct me if I'm wrong). But maybe it is better than nothing. I'll consider how things can be improved. Regards, -JJ For the time being I am very happy with Tony's solution. It works nice most of the time, only very complex figures take forever now to be drawn. The current behavior *looks* broken to any user who does not understand the internals. And it's too likely that even simple figures look horrible. I'd definitely vote for a more end-user friendly solution (with end users I have scientific users in mind who generally appreciate the beauty of the generated plots but who don't integrated the library into some other application). Best regards, Daniel -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Feature request: automatic scaling of subplots, margins, etc
Hi again, Hi Jae-Loon, thanks for your comments! Of course I do agree that a figure layout should not change in interactive mode. However, I don't see why this should happen upon a panning action. A different case is when the label or title font sizes are changed, but I was assuming this is adjusted prior to the creation of the figure. Since you said the current design is broken, I thought you want things adjusted *whenever* a figure is updated. So, I guess what you want is some functionality like what Tony's script does? One of the reason that I was not very inclined to Tony's approach is that it only works for subplots (and I guess it only works with subplots with pure n x m grid. Correct me if I'm wrong). But maybe it is better than nothing. I'll consider how things can be improved. I do sense a match of ideas here :) This is exactly what I am missing! It is very good to hear that you are so open to suggestions and possible improvements! It is a great pleasure to work with Scipy/Matplotlib and interact with the community! Best regards, Daniel -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
[Matplotlib-users] undefined symbol error message when importing from matplotlib._path
Hi, we're running Matplotlib 1.0.0 with Python 2.6.2 on CentOS 5.6. When importing from matplotlib._path, users get an error message undefined symbol: _ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l I'm at a loss. There were no errors during the installation Generating the error: $ python-2.6 Python 2.6.2 (r262:71600, Aug 5 2010, 14:21:11) [GCC 4.4.4] on linux2 Type help, copyright, credits or license for more information. from matplotlib._path import affine_transform Traceback (most recent call last): File stdin, line 1, in module ImportError: /g/software/linux/pack/python-2.6/lib/python2.6/site-packages/matplotlib/_path.so: undefined symbol: _ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l exit() $ Anyone has seen this before and/or knows a fix? There are some reports about such an error on the web, but they are all quite old and I cannot relate them to the current issue. Thanks in advance frank -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] another incorrectly clipped PNG in the gallery
On Wed, May 11, 2011 at 11:07 AM, C M cmpyt...@gmail.com wrote: On Wed, May 11, 2011 at 12:29 AM, Jae-Joon Lee lee.j.j...@gmail.com wrote: I think I fixed a similar bug at some point but I'm not sure if that is related with this. Are you using the *make_axes_area_auto_adjustable* from the current git master (check examples/axes_grid/make_room_for_ylabel_using_axesgrid.py)? If not can you try that? Also please post your code. I have not set up with git since Matplotlib made the change from svn. I just downloaded git to get started but don't know how to use it yet; for now is there a way to just check out the files I need to test this, or is there some other (non-git) way to get this update? Thanks, Che -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Feature request: automatic scaling of subplots, margins, etc
[Accidentally sent this reply privately the first time, natch.] On 2011-05-11 04:29, Jae-Joon Lee wrote: On Wed, May 11, 2011 at 5:03 PM, Daniel Mader danielstefanma...@googlemail.com wrote: Hi Jae-Loon, thanks for your comments! Of course I do agree that a figure layout should not change in interactive mode. However, I don't see why this should happen upon a panning action. A different case is when the label or title font sizes are changed, but I was assuming this is adjusted prior to the creation of the figure. Since you said the current design is broken, I thought you want things adjusted *whenever* a figure is updated. So, I guess what you want is some functionality like what Tony's script does? One of the reason that I was not very inclined to Tony's approach is that it only works for subplots (and I guess it only works with subplots with pure n x m grid. Correct me if I'm wrong). But maybe it is better than nothing. I'll consider how things can be improved. One thing I've always wondered: is it fundamentally impossible to change the fact that, in matplotlib, you cannot know how big a drawn object will be until you actually draw it? When I was doing some animation stuff a while back this caused me a lot of headache, for the reasons Tony Yu mentioned: it means you have to draw everything multiple times. It would really help if it were possible to specify objects' parameters and get their sizes without drawing them. -- Brendan Barnwell Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail. --author unknown -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Feature request: automatic scaling of subplots, margins, etc
On Wed, May 11, 2011 at 12:47 PM, Brendan Barnwell brenb...@brenbarn.netwrote: [Accidentally sent this reply privately the first time, natch.] On 2011-05-11 04:29, Jae-Joon Lee wrote: On Wed, May 11, 2011 at 5:03 PM, Daniel Mader danielstefanma...@googlemail.com wrote: Hi Jae-Loon, thanks for your comments! Of course I do agree that a figure layout should not change in interactive mode. However, I don't see why this should happen upon a panning action. A different case is when the label or title font sizes are changed, but I was assuming this is adjusted prior to the creation of the figure. Since you said the current design is broken, I thought you want things adjusted *whenever* a figure is updated. So, I guess what you want is some functionality like what Tony's script does? One of the reason that I was not very inclined to Tony's approach is that it only works for subplots (and I guess it only works with subplots with pure n x m grid. Correct me if I'm wrong). But maybe it is better than nothing. I'll consider how things can be improved. One thing I've always wondered: is it fundamentally impossible to change the fact that, in matplotlib, you cannot know how big a drawn object will be until you actually draw it? When I was doing some animation stuff a while back this caused me a lot of headache, for the reasons Tony Yu mentioned: it means you have to draw everything multiple times. It would really help if it were possible to specify objects' parameters and get their sizes without drawing them. -- Brendan Barnwell Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail. --author unknown Most things, we do know the sizes of. It is my understanding that it is the text objects that is the unknown. If this could be solved, then a layout engine would be much more feasible. The problem is that even LaTeX has to re-render things multiple times to get this right for an arbitrary font. If we were to restrict ourselves to particular fonts and package those fonts with matplotlib, then we could have an internal table of size information for each glyph and compute it on the fly and lay everything out right. But, that would cause us to give up significant benefits for another benefit. I think the pain of the bootstrapping/re-rendering approach could be reduced significantly if we could get various aspects of matplotlib figure building to be faster. Last time I checked, there is significant amount of processing time spent in calculating the ticks for the axes. Maybe if we focus some efforts in improving the efficiency of certain parts of matplotlib, maybe we could introduce a convenience function like the one earlier in this thread that some users can choose to use with only a slight penalty in speed. I personally would not want to make it default, but certainly would consider highly advertising such a function. Just my two cents, Ben Root -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Feature request: automatic scaling of subplots, margins, etc
On Wed, May 11, 2011 at 1:59 PM, Benjamin Root ben.r...@ou.edu wrote: ... Most things, we do know the sizes of. It is my understanding that it is the text objects that is the unknown. If this could be solved, then a layout engine would be much more feasible. The problem is that even LaTeX has to re-render things multiple times to get this right for an arbitrary font. If we were to restrict ourselves to particular fonts and package those fonts with matplotlib, then we could have an internal table of size information for each glyph and compute it on the fly and lay everything out right. But, that would cause us to give up significant benefits for another benefit. ... I suppose a compromise would be to have that internal table for a fixed set of fonts, and if the user asks for a font that's not shipped with matplotlib, then they fall back to the current (presumably slower) method. Would probably complicate things in the layout code, though. Justin -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Feature request: automatic scaling of subplots, margins, etc
On Wed, May 11, 2011 at 1:59 PM, Benjamin Root ben.r...@ou.edu wrote: On Wed, May 11, 2011 at 12:47 PM, Brendan Barnwell brenb...@brenbarn.net wrote: One thing I've always wondered: is it fundamentally impossible to change the fact that, in matplotlib, you cannot know how big a drawn object will be until you actually draw it? When I was doing some animation stuff a while back this caused me a lot of headache, for the reasons Tony Yu mentioned: it means you have to draw everything multiple times. It would really help if it were possible to specify objects' parameters and get their sizes without drawing them. -- Brendan Barnwell Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail. --author unknown Most things, we do know the sizes of. It is my understanding that it is the text objects that is the unknown. If this could be solved, then a layout engine would be much more feasible. The problem is that even LaTeX has to re-render things multiple times to get this right for an arbitrary font. If we were to restrict ourselves to particular fonts and package those fonts with matplotlib, then we could have an internal table of size information for each glyph and compute it on the fly and lay everything out right. But, that would cause us to give up significant benefits for another benefit. I think the pain of the bootstrapping/re-rendering approach could be reduced significantly if we could get various aspects of matplotlib figure building to be faster. Last time I checked, there is significant amount of processing time spent in calculating the ticks for the axes. Maybe if we focus some efforts in improving the efficiency of certain parts of matplotlib, maybe we could introduce a convenience function like the one earlier in this thread that some users can choose to use with only a slight penalty in speed. I personally would not want to make it default, but certainly would consider highly advertising such a function. Just my two cents, Ben Root Perhaps there could be three options: 1. Manual mode: current behavior 2. Database mode: uses a list of known fonts. When a font not found in the database is used, it falls back to manual mode. 3. Automatic mode: uses a list of known fonts. When a font not found in the database is used, it renders the text alone in an invisible figure to calculate the space needed, then uses that information to set the margins. Alternatively, create a temporary mini font database just for the characters needed. The former approach may be faster, but the latter may be easier to program since it could share a lot of code with the database. There could also be a function to scan a particular font and add to the database (there would probably be a separate user database in your matplotlib configuration directory that this would use, as well as probably caching the measurements from text used in automatic mode for future versions of the figure). -Todd -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Feature request: automatic scaling of subplots, margins, etc
On Wed, May 11, 2011 at 1:43 PM, todd rme toddrme2...@gmail.com wrote: On Wed, May 11, 2011 at 1:59 PM, Benjamin Root ben.r...@ou.edu wrote: On Wed, May 11, 2011 at 12:47 PM, Brendan Barnwell brenb...@brenbarn.net wrote: One thing I've always wondered: is it fundamentally impossible to change the fact that, in matplotlib, you cannot know how big a drawn object will be until you actually draw it? When I was doing some animation stuff a while back this caused me a lot of headache, for the reasons Tony Yu mentioned: it means you have to draw everything multiple times. It would really help if it were possible to specify objects' parameters and get their sizes without drawing them. -- Brendan Barnwell Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail. --author unknown Most things, we do know the sizes of. It is my understanding that it is the text objects that is the unknown. If this could be solved, then a layout engine would be much more feasible. The problem is that even LaTeX has to re-render things multiple times to get this right for an arbitrary font. If we were to restrict ourselves to particular fonts and package those fonts with matplotlib, then we could have an internal table of size information for each glyph and compute it on the fly and lay everything out right. But, that would cause us to give up significant benefits for another benefit. I think the pain of the bootstrapping/re-rendering approach could be reduced significantly if we could get various aspects of matplotlib figure building to be faster. Last time I checked, there is significant amount of processing time spent in calculating the ticks for the axes. Maybe if we focus some efforts in improving the efficiency of certain parts of matplotlib, maybe we could introduce a convenience function like the one earlier in this thread that some users can choose to use with only a slight penalty in speed. I personally would not want to make it default, but certainly would consider highly advertising such a function. Just my two cents, Ben Root Perhaps there could be three options: 1. Manual mode: current behavior 2. Database mode: uses a list of known fonts. When a font not found in the database is used, it falls back to manual mode. 3. Automatic mode: uses a list of known fonts. When a font not found in the database is used, it renders the text alone in an invisible figure to calculate the space needed, then uses that information to set the margins. Alternatively, create a temporary mini font database just for the characters needed. The former approach may be faster, but the latter may be easier to program since it could share a lot of code with the database. There could also be a function to scan a particular font and add to the database (there would probably be a separate user database in your matplotlib configuration directory that this would use, as well as probably caching the measurements from text used in automatic mode for future versions of the figure). -Todd That might be a possible direction. Obviously, any route taken will have to be well thought-out and designed. What is great about moving over to git is that the user community can easily experiment on larger changes to the code-base, and make it easier for others to test out experimental designs and collaborate. I encourage those in this thread to make a fork of matplotlib on github and experiment with some of these ideas and we all can play around with some of these parts. As a further bit of information, I believe that there is an old project that attempted a layout engine for matplotlib ( https://github.com/matplotlib/mplsizer). I have never used it, nor do I have any idea if it still works, but it may be an interesting codebase to start from. As a further comment about a database of text size information. An interesting complication I just noticed are fonts that allow certain combinations of characters to overlap a bit. For example, right now I noticed that using Gils Sans in LibreOffice that the word Tracking has the 'r' in with the 'T'. Calculating the amount of space a particular set of characters might take up may not be very straight-forward. Just another 2 cents, Ben Root -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Feature request: automatic scaling of subplots, margins, etc
On 05/11/2011 09:11 AM, Benjamin Root wrote: On Wed, May 11, 2011 at 1:43 PM, todd rme toddrme2...@gmail.com mailto:toddrme2...@gmail.com wrote: On Wed, May 11, 2011 at 1:59 PM, Benjamin Root ben.r...@ou.edu mailto:ben.r...@ou.edu wrote: On Wed, May 11, 2011 at 12:47 PM, Brendan Barnwell brenb...@brenbarn.net mailto:brenb...@brenbarn.net wrote: One thing I've always wondered: is it fundamentally impossible to change the fact that, in matplotlib, you cannot know how big a drawn object will be until you actually draw it? When I was doing some animation stuff a while back this caused me a lot of headache, for the reasons Tony Yu mentioned: it means you have to draw everything multiple times. It would really help if it were possible to specify objects' parameters and get their sizes without drawing them. -- Brendan Barnwell Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail. --author unknown Most things, we do know the sizes of. It is my understanding that it is the text objects that is the unknown. If this could be solved, then a layout engine would be much more feasible. The problem is that even LaTeX has to re-render things multiple times to get this right for an arbitrary font. If we were to restrict ourselves to particular fonts and package those fonts with matplotlib, then we could have an internal table of size information for each glyph and compute it on the fly and lay everything out right. But, that would cause us to give up significant benefits for another benefit. I think the pain of the bootstrapping/re-rendering approach could be reduced significantly if we could get various aspects of matplotlib figure building to be faster. Last time I checked, there is significant amount of processing time spent in calculating the ticks for the axes. Maybe if we focus some efforts in improving the efficiency of certain parts of matplotlib, maybe we could introduce a convenience function like the one earlier in this thread that some users can choose to use with only a slight penalty in speed. I personally would not want to make it default, but certainly would consider highly advertising such a function. Just my two cents, Ben Root Perhaps there could be three options: 1. Manual mode: current behavior 2. Database mode: uses a list of known fonts. When a font not found in the database is used, it falls back to manual mode. 3. Automatic mode: uses a list of known fonts. When a font not found in the database is used, it renders the text alone in an invisible figure to calculate the space needed, then uses that information to set the margins. Alternatively, create a temporary mini font database just for the characters needed. The former approach may be faster, but the latter may be easier to program since it could share a lot of code with the database. There could also be a function to scan a particular font and add to the database (there would probably be a separate user database in your matplotlib configuration directory that this would use, as well as probably caching the measurements from text used in automatic mode for future versions of the figure). -Todd That might be a possible direction. Obviously, any route taken will have to be well thought-out and designed. What is great about moving over to git is that the user community can easily experiment on larger changes to the code-base, and make it easier for others to test out experimental designs and collaborate. I encourage those in this thread to make a fork of matplotlib on github and experiment with some of these ideas and we all can play around with some of these parts. As a further bit of information, I believe that there is an old project that attempted a layout engine for matplotlib (https://github.com/matplotlib/mplsizer). I have never used it, nor do I have any idea if it still works, but it may be an interesting codebase to start from. As a further comment about a database of text size information. An interesting complication I just noticed are fonts that allow certain combinations of characters to overlap a bit. For example, right now I noticed that using Gils Sans in LibreOffice that the word Tracking has the 'r' in with the 'T'. Calculating the amount of space a particular set of characters might take up may not be very straight-forward. The calculation doesn't have to be perfect, it just has to be good enough for layout purposes. If one were to ignore kerning, the predicted width of a text string
Re: [Matplotlib-users] Feature request: automatic scaling of subplots, margins, etc
On Wed, May 11, 2011 at 4:31 PM, Eric Firing efir...@hawaii.edu wrote: On 05/11/2011 09:11 AM, Benjamin Root wrote: On Wed, May 11, 2011 at 1:43 PM, todd rme toddrme2...@gmail.com mailto:toddrme2...@gmail.com wrote: On Wed, May 11, 2011 at 1:59 PM, Benjamin Root ben.r...@ou.edu mailto:ben.r...@ou.edu wrote: On Wed, May 11, 2011 at 12:47 PM, Brendan Barnwell brenb...@brenbarn.net mailto:brenb...@brenbarn.net wrote: One thing I've always wondered: is it fundamentally impossible to change the fact that, in matplotlib, you cannot know how big a drawn object will be until you actually draw it? When I was doing some animation stuff a while back this caused me a lot of headache, for the reasons Tony Yu mentioned: it means you have to draw everything multiple times. It would really help if it were possible to specify objects' parameters and get their sizes without drawing them. -- Brendan Barnwell Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail. --author unknown Most things, we do know the sizes of. It is my understanding that it is the text objects that is the unknown. If this could be solved, then a layout engine would be much more feasible. The problem is that even LaTeX has to re-render things multiple times to get this right for an arbitrary font. If we were to restrict ourselves to particular fonts and package those fonts with matplotlib, then we could have an internal table of size information for each glyph and compute it on the fly and lay everything out right. But, that would cause us to give up significant benefits for another benefit. I think the pain of the bootstrapping/re-rendering approach could be reduced significantly if we could get various aspects of matplotlib figure building to be faster. Last time I checked, there is significant amount of processing time spent in calculating the ticks for the axes. Maybe if we focus some efforts in improving the efficiency of certain parts of matplotlib, maybe we could introduce a convenience function like the one earlier in this thread that some users can choose to use with only a slight penalty in speed. I personally would not want to make it default, but certainly would consider highly advertising such a function. Just my two cents, Ben Root Perhaps there could be three options: 1. Manual mode: current behavior 2. Database mode: uses a list of known fonts. When a font not found in the database is used, it falls back to manual mode. 3. Automatic mode: uses a list of known fonts. When a font not found in the database is used, it renders the text alone in an invisible figure to calculate the space needed, then uses that information to set the margins. Alternatively, create a temporary mini font database just for the characters needed. The former approach may be faster, but the latter may be easier to program since it could share a lot of code with the database. There could also be a function to scan a particular font and add to the database (there would probably be a separate user database in your matplotlib configuration directory that this would use, as well as probably caching the measurements from text used in automatic mode for future versions of the figure). -Todd That might be a possible direction. Obviously, any route taken will have to be well thought-out and designed. What is great about moving over to git is that the user community can easily experiment on larger changes to the code-base, and make it easier for others to test out experimental designs and collaborate. I encourage those in this thread to make a fork of matplotlib on github and experiment with some of these ideas and we all can play around with some of these parts. As a further bit of information, I believe that there is an old project that attempted a layout engine for matplotlib (https://github.com/matplotlib/mplsizer). I have never used it, nor do I have any idea if it still works, but it may be an interesting codebase to start from. As a further comment about a database of text size information. An interesting complication I just noticed are fonts that allow certain combinations of characters to overlap a bit. For example, right now I noticed that using Gils Sans in LibreOffice that the word Tracking has the 'r' in with the 'T'. Calculating the amount of space a particular set of characters might take up may not be very
[Matplotlib-users] Possible bug / odd behaviour in GridSpec?
Hi, I've come across something I don't entirely understand in the behaviour of gridspec. It's not obvious from the code docs for this module, but is it only supposed to be able to deal with 'square' layouts, e.g. 3x3, 4x4 etc? Taking some code from an example on the gridspec page ... import matplotlib.pylab as plt import matplotlib.gridspec as gridspec #gs = gridspec.GridSpec(3, 3) # OK gs = gridspec.GridSpec(6, 3) # Will cause an error later on ax1 = plt.subplot(gs[0, :]) ax2 = plt.subplot(gs[1,:-1]) ax3 = plt.subplot(gs[1:,-1]) ax4 = plt.subplot(gs[-1,0]) ax5 = plt.subplot(gs[-1,-2]) plt.show() ... will fail if that line is uncommented, giving an index error. I don't see any reason why these slices should fail however, though obviously it won't use all the available space within the whole grid? Substituting a 'square' grid for the (6,3), e.g. (4,4), (5,5) etc seems to be fine though. I'm quite interested in getting involved with mpl development, partly as a way to get my head around python numpy and aid porting a bunch of stuff I use over to python from IDL. Unless I'm doing something totally wrong by expecting the above snippet to work, then I'd happily spend some time looking into this in more detail, having written some similar code in IDL. The docs for that module also look like they could benefit from some work. Cheers, Dave - David Andrews PhD Student, Radio Space Plasma Physics Group, University of Leicester, UK -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Possible bug / odd behaviour in GridSpec?
2011/5/12 David Andrews irbda...@gmail.com: Hi, I've come across something I don't entirely understand in the behaviour of gridspec. It's not obvious from the code docs for this module, but is it only supposed to be able to deal with 'square' layouts, e.g. 3x3, 4x4 etc? Taking some code from an example on the gridspec page ... import matplotlib.pylab as plt import matplotlib.gridspec as gridspec #gs = gridspec.GridSpec(3, 3) # OK gs = gridspec.GridSpec(6, 3) # Will cause an error later on ax1 = plt.subplot(gs[0, :]) ax2 = plt.subplot(gs[1,:-1]) ax3 = plt.subplot(gs[1:,-1]) ax4 = plt.subplot(gs[-1,0]) ax5 = plt.subplot(gs[-1,-2]) plt.show() ... will fail if that line is uncommented, giving an index error. Works for me. Ubuntu 11.04 Natty, stock python 2.7.1 and matplotlib 1.0.1 from https://launchpad.net/~valavanisalex/+archive/matplotlib. -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Feature request: automatic scaling of subplots, margins, etc
On Thu, May 12, 2011 at 2:37 AM, Brendan Barnwell brenb...@brenbarn.net wrote: One thing I've always wondered: is it fundamentally impossible to change the fact that, in matplotlib, you cannot know how big a drawn object will be until you actually draw it? Well, I don't think this is 100% correct. As far as I can see, there is two issues involved. 1) size of text may depend on the renderer (since font selection could be different). 2) Position of some artist depend on position of other artist (e.g., the exact location of axis label depend on sizes of tick labels). In fact, neither of these require drawing. But, the easiest way is to draw it (primarily due to the second point). Can you describe what you were doing with your animation? Matplotlib provide some framework to overcome these limitation (e.g., classes in the offsetbox module). And there may be easier ways that does what you want. Regards, -JJ -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Feature request: automatic scaling of subplots, margins, etc
On Thu, May 12, 2011 at 2:59 AM, Benjamin Root ben.r...@ou.edu wrote: Most things, we do know the sizes of. It is my understanding that it is the text objects that is the unknown. If this could be solved, then a layout engine would be much more feasible. I doubt it. As far as I know, the main reason that things needed to be drawn is because the location and size of some artist depends on location and size of other artists. Unfortunately, with current matplotlib code, most of these things are determined inside the draw method. Therefore, we need to separate out those things out from the draw method. Another option, which I think is more feasible, is to implement a BBoxRenderer which does not draw anything but only update the size and location of artists. Regards, -JJ The problem is that even LaTeX has to re-render things multiple times to get this right for an arbitrary font. If we were to restrict ourselves to particular fonts and package those fonts with matplotlib, then we could have an internal table of size information for each glyph and compute it on the fly and lay everything out right. But, that would cause us to give up significant benefits for another benefit. -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Possible bug / odd behaviour in GridSpec?
Yes, this is a bug that has been fixed. https://github.com/matplotlib/matplotlib/commit/76851eb Regards, -JJ On Thu, May 12, 2011 at 7:53 AM, Goyo goyod...@gmail.com wrote: 2011/5/12 David Andrews irbda...@gmail.com: Hi, I've come across something I don't entirely understand in the behaviour of gridspec. It's not obvious from the code docs for this module, but is it only supposed to be able to deal with 'square' layouts, e.g. 3x3, 4x4 etc? Taking some code from an example on the gridspec page ... import matplotlib.pylab as plt import matplotlib.gridspec as gridspec #gs = gridspec.GridSpec(3, 3) # OK gs = gridspec.GridSpec(6, 3) # Will cause an error later on ax1 = plt.subplot(gs[0, :]) ax2 = plt.subplot(gs[1,:-1]) ax3 = plt.subplot(gs[1:,-1]) ax4 = plt.subplot(gs[-1,0]) ax5 = plt.subplot(gs[-1,-2]) plt.show() ... will fail if that line is uncommented, giving an index error. Works for me. Ubuntu 11.04 Natty, stock python 2.7.1 and matplotlib 1.0.1 from https://launchpad.net/~valavanisalex/+archive/matplotlib. -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Possible bug / odd behaviour in GridSpec?
On Thu, May 12, 2011 at 7:18 AM, David Andrews irbda...@gmail.com wrote: I'm quite interested in getting involved with mpl development, partly as a way to get my head around python numpy and aid porting a bunch of stuff I use over to python from IDL. Unless I'm doing something totally wrong by expecting the above snippet to work, then I'd happily spend some time looking into this in more detail, having written some similar code in IDL. The docs for that module also look like they could benefit from some work. Yes, the docs need lots of work I guess and any contribution will be greatly appreciated. If you're willing to improve the docs for gridspec, I'm more than happy to help you (I am the main author of that module). The best way to contribute is to use github pull request and matplotlib is hosted here https://github.com/matplotlib/matplotlib Regards, -JJ -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
