Re: [Matplotlib-users] Possible bug / odd behaviour in GridSpec?

[Jae-Joon Lee]

On Thu, May 12, 2011 at 7:18 AM, David Andrews  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

Re: [Matplotlib-users] Possible bug / odd behaviour in GridSpec?

[Jae-Joon Lee]

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  wrote:
> 2011/5/12 David Andrews :
>> 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] Feature request: automatic scaling of subplots, margins, etc

[Jae-Joon Lee]

On Thu, May 12, 2011 at 2:59 AM, Benjamin Root  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] Feature request: automatic scaling of subplots, margins, etc

[Jae-Joon Lee]

On Thu, May 12, 2011 at 2:37 AM, Brendan Barnwell  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] Possible bug / odd behaviour in GridSpec?

[Goyo]

2011/5/12 David Andrews :
> 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

[Matplotlib-users] Possible bug / odd behaviour in GridSpec?

[David Andrews]

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] Setting defaults that are not accessible via rcParams

[Goyo]

2011/5/11 calle :
> [...]
> So is there for example a way to set sth like
>
> axes([0.125,0.2,0.95-0.125,0.95-0.2])
>
> or alike without the need to repeat it for every single plot?

Not that I'm aware of. But in what sense is that worst than repeat
subplot() for every single plot? Yes there are magic numbers there but
subplot also uses magic numbers under the hood, if I'm not wrong.

You can wrap your axes call into another function so at least the
magic numbers are not visible in the higher level code if they are
always the same.

Goyo

--
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

[Benjamin Root]

On Wed, May 11, 2011 at 4:31 PM, Eric Firing  wrote:

> On 05/11/2011 09:11 AM, Benjamin Root wrote:
> >
> >
> > On Wed, May 11, 2011 at 1:43 PM, todd rme  > > wrote:
> >
> > On Wed, May 11, 2011 at 1:59 PM, Benjamin Root  > > wrote:
> >  >
> >  >
> >  > On Wed, May 11, 2011 at 12:47 PM, Brendan Barnwell
> > 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
> > notic

Re: [Matplotlib-users] Feature request: automatic scaling of subplots, margins, etc

[Eric Firing]

On 05/11/2011 09:11 AM, Benjamin Root wrote:
>
>
> On Wed, May 11, 2011 at 1:43 PM, todd rme  > wrote:
>
> On Wed, May 11, 2011 at 1:59 PM, Benjamin Root  > wrote:
>  >
>  >
>  > On Wed, May 11, 2011 at 12:47 PM, Brendan Barnwell
> 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 go

Re: [Matplotlib-users] Feature request: automatic scaling of subplots, margins, etc

[Benjamin Root]

On Wed, May 11, 2011 at 1:43 PM, todd rme  wrote:

> On Wed, May 11, 2011 at 1:59 PM, Benjamin Root  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

[todd rme]

On Wed, May 11, 2011 at 1:59 PM, Benjamin Root  wrote:
>
>
> On Wed, May 11, 2011 at 12:47 PM, Brendan Barnwell 
> 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

[Justin McCann]

On Wed, May 11, 2011 at 1:59 PM, Benjamin Root  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

[Benjamin Root]

On Wed, May 11, 2011 at 12:47 PM, Brendan Barnwell wrote:

> [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
>  > >   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

[Brendan Barnwell]

[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
 > >   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] another incorrectly clipped PNG in the gallery

[C M]

On Wed, May 11, 2011 at 11:07 AM, C M  wrote:
> On Wed, May 11, 2011 at 12:29 AM, Jae-Joon Lee  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

[Matplotlib-users] "undefined symbol" error message when importing from matplotlib._path

[Frank Thommen]

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 "", line 1, in 
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

[Matplotlib-users] Setting defaults that are not accessible via rcParams

[calle]

Hej,

Being a student of Geophysics, I regularly have to hand in some reports, for
which I'm doing a lot of plotting. I am using a latex-template of my own,
inserting the graphics from pdf. 
Now I am looking for a convenient way to set some defaults for the format of
plots I am using. I have created a module to easily set my default values
(square format, normal format, subplot-format, default colors, linestyles
etc.). The problem is, that there are some parameters I need to change with
every single plot command (like the space to annotate the axis in the small
subplots) because they are not accessible via matplotlibrc or rcParams. That
is some tedious work and not very convenient regarding the consistency of my
reports. 

So is there for example a way to set sth like 

axes([0.125,0.2,0.95-0.125,0.95-0.2])

or alike without the need to repeat it for every single plot?

Thank you very much in advance,

Calle




-- 
View this message in context: 
http://old.nabble.com/Setting-defaults-that-are-not-accessible-via-rcParams-tp31592659p31592659.html
Sent from the matplotlib - users mailing list archive at Nabble.com.


--
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] Re : matplotlibrc for [ieee] publications

[alex arsenovic]

hi, just curious if anyone wants to add some publication formating
settings? if you send me the rc params, and publication infos i add them
to the project. 


http://code.google.com/p/mplrc/




On Sat, 2011-04-16 at 14:21 -0400, alex arsenovic wrote:
> i created the project for 'mplrc' here
> https://code.google.com/p/mplrc/
> 
> let me know what you all think. if you all send me your publications'
> settings i can add them, or if you want an account ill make you one. 
> 
> one thing to mention is that the params dictionary probably should set
> all possible settings so that there is no ambiguity. i have yet to do
> this.
> 
> here is an example of my ieee format
> 
> 
> On Fri, 2011-04-15 at 14:09 -0400, Tony Yu wrote:
> > 
> > 
> > On Fri, Apr 15, 2011 at 8:36 AM, Auré Gourrier
> >  wrote:
> > Good Idea !
> > I'm also using mpl for other publications than ieee and it
> > sounds like a small mplrc data base with targeted journal
> > specifications would be worthwhile doing ! I would be ready to
> > contribute.
> > Cheers,
> > Auré
> > 
> > 
> > 
> > 
> > Is there any reason this needs to done with rc files? I prefer to put
> > document-specific configuration into modules. For example, you could
> > have a module that looks like:
> > 
> > mplrc/
> > __init__.py
> > aps_fullpage.py
> > aps_twocolumn.py
> > ieee.py
> > ...
> > 
> > (`aps` could even be directory). And each module would set rc
> > parameters using function calls; for example, aps_twocolumn.py might
> > look like:
> > 
> > import matplotlib.pyplot as plt
> > plt.rc('axes', labelsize=10)
> > plt.rc('text', fontsize=10)
> > plt.rc('legend', fontsize=10)
> > plt.rc('xtick', labelsize=8)
> > plt.rc('ytick', labelsize=8)
> > plt.rc('text', usetex=False)
> > plt.rc('figure', figsize=(3.4039, 2.1037))
> > 
> > (Alternatively, you could create a separate rc file and just have the
> > module load that rc file). The advantage of this module-based approach
> > is that you could simply import the module whenever you need it (e.g.,
> > just add `import mplrc.aps_twocolumn` at the top of your script). If I
> > used an rc file instead, I'd have to copy the rc file to my working
> > directory each time, or somehow, manually load the rc file from a
> > path.
> > 
> > Just a suggestion.
> > 
> > -Tony
> > 
> 



--
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

[Daniel Mader]

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

Re: [Matplotlib-users] Feature request: automatic scaling of subplots, margins, etc

[Jae-Joon Lee]

On Wed, May 11, 2011 at 5:03 PM, Daniel Mader
 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

[Daniel Mader]

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 :
> On Fri, May 6, 2011 at 5:20 PM, Daniel Mader
>  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