another incorrectly clipped PNG in the gallery

In article <4C935C08.1000807@...287...>,
Alan G Isaac <alan.isaac@...287...>
wrote:

http://matplotlib.sourceforge.net/examples/pylab_examples/accented_text.html

It's realistic, and that has a lot to be said for it.

One of my problems with matplotlib is that it is far too willing to
truncate axis labels and related information. I'd be much happier with a
layout model that always showed the axis labels in full.

-- Russell

Ditto on this. In addition, it would be useful to prevent axes labels from spilling over into another axes’ area.

Ben Root

···

On Wed, Sep 22, 2010 at 12:04 PM, Russell E. Owen <rowen@…3288…> wrote:

In article <4C935C08.1000807@…287…>,

Alan G Isaac <alan.isaac@…2015…87…>
wrote:

http://matplotlib.sourceforge.net/examples/pylab_examples/accented_text.html

It’s realistic, and that has a lot to be said for it.

One of my problems with matplotlib is that it is far too willing to

truncate axis labels and related information. I’d be much happier with a

layout model that always showed the axis labels in full.

– Russell

Benjamin Root wrote:

On Wed, Sep 22, 2010 at 12:04 PM, Russell E. Owen <rowen@...2756... I'd be much happier with a

Ditto on this. In addition, it would be useful to prevent axes labels from spilling over into another axes' area.

Someone was working on a wxSizer-like layout tool for MPL -- anyone know what happened to that?

Also -- do all MPL artists (text, etc) know enough about how big they are to do this at all? I recall trying to do a bit myself, and had a hard time finding out how big a label was, and thus didn't know where to put an axis so the label wouldn't be chopped off.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@...259...

I think the issue was that it could not be generalized that an artist knows its size until it comes time to render. I think the main culprit here is text labels (particularly latex stuff). If it could be known what an artist’s size is when the artist is made, then I think a lot of code could be simplified because all artists would reference itself relative to their parent artist (think particularly how axes and figure objects have size properties).

Although, as a counter-point, we don’t want to inhibit a user’s ability to have something outside of its parents (annotations, arrows and such). Maybe most artists would have a property indicating whether it should be constrained or not.

Now that I think about it even more, doing a proper layout engine would be a headache…

Ben Root

···

On Wed, Sep 22, 2010 at 2:28 PM, Christopher Barker <Chris.Barker@…259…> wrote:

Benjamin Root wrote:

On Wed, Sep 22, 2010 at 12:04 PM, Russell E. Owen <rowen@…2756…

I’d be much happier with a

Ditto on this. In addition, it would be useful to prevent axes labels

from spilling over into another axes’ area.

Someone was working on a wxSizer-like layout tool for MPL – anyone know

what happened to that?

Also – do all MPL artists (text, etc) know enough about how big they

are to do this at all? I recall trying to do a bit myself, and had a

hard time finding out how big a label was, and thus didn’t know where to

put an axis so the label wouldn’t be chopped off.

-Chris

I submitted bug report #3073546 on the issue of axis labels getting truncated.

https://sourceforge.net/tracker/?func=detail&atid=560720&aid=3073546&group_id=80706

You might want to add your suggestion about axis labels or submit a new ticket.

Regards,

– Russell

···

On Sep 22, 2010, at 11:16 AM, Benjamin Root wrote:

On Wed, Sep 22, 2010 at 12:04 PM, Russell E. Owen <rowen@…2756…> wrote:

In article <4C935C08.1000807@…287…>,
Alan G Isaac <alan.isaac@…287…>
wrote:

http://matplotlib.sourceforge.net/examples/pylab_examples/accented_text.html

It’s realistic, and that has a lot to be said for it.

One of my problems with matplotlib is that it is far too willing to
truncate axis labels and related information. I’d be much happier with a
layout model that always showed the axis labels in full.

Ditto on this. In addition, it would be useful to prevent axes labels from spilling over into another axes’ area.

    In article <4C935C08.1000807@…287…
    <mailto:4C935C08.1000807@…287…>>,
    Alan G Isaac <alan.isaac@…287… <mailto:alan.isaac@…287…>>
    wrote:

    >
    http://matplotlib.sourceforge.net/examples/pylab_examples/accented_text.html

    It's realistic, and that has a lot to be said for it.

    One of my problems with matplotlib is that it is far too willing to
    truncate axis labels and related information. I'd be much happier
    with a
    layout model that always showed the axis labels in full.

Ditto on this. In addition, it would be useful to prevent axes labels
from spilling over into another axes' area.

I submitted bug report #3073546 on the issue of axis labels getting
truncated.
https://sourceforge.net/tracker/?func=detail&atid=560720&aid=3073546&group_id=80706
<https://sourceforge.net/tracker/?func=detail&atid=560720&aid=3073546&group_id=80706>

You might want to add your suggestion about axis labels or submit a new
ticket.

The problem is not a bug; it is inherent in the fundamental design. Therefore I moved the ticket over to feature requests. I want to keep the bugs list for real bugs that we can realistically expect to solve fairly quickly.

I don't know whether Andrew Straw's wx sizer-inspired code (mplsizer toolkit) solves the problem or not. My impression is that it does not--I think it is working with the Axes positions, not with axis and tick labels, which are what cause most of the difficulties.

Eric

···

On 09/22/2010 10:11 AM, Russell Owen wrote:

On Sep 22, 2010, at 11:16 AM, Benjamin Root wrote:

On Wed, Sep 22, 2010 at 12:04 PM, Russell E. Owen <rowen@…2756… >> <mailto:rowen@…2756…>> wrote:

Regards,

-- Russell

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev

_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Until a more permanent solution is figured out, can anyone recommend
any workarounds, even if they are a little clunky? I'm embedding mpl
plots in wxPython and am also finding this issue suboptimal.

Che

···

On Wed, Sep 22, 2010 at 6:16 PM, Eric Firing <efiring@...202...> wrote:

On 09/22/2010 10:11 AM, Russell Owen wrote:

On Sep 22, 2010, at 11:16 AM, Benjamin Root wrote:

On Wed, Sep 22, 2010 at 12:04 PM, Russell E. Owen <rowen@…2756… >>> <mailto:rowen@…2756…>> wrote:

In article &lt;4C935C08\.1000807@\.\.\.287\.\.\.
&lt;mailto:4C935C08.1000807@...287...&gt;&gt;,
Alan G Isaac &lt;alan\.isaac@\.\.\.287\.\.\. &lt;mailto:alan.isaac@...287...&gt;&gt;
wrote:

&gt;
http://matplotlib.sourceforge.net/examples/pylab_examples/accented_text.html

It&#39;s realistic, and that has a lot to be said for it\.

One of my problems with matplotlib is that it is far too willing to
truncate axis labels and related information\. I&#39;d be much happier
with a
layout model that always showed the axis labels in full\.

Ditto on this. In addition, it would be useful to prevent axes labels
from spilling over into another axes' area.

I submitted bug report #3073546 on the issue of axis labels getting
truncated.
https://sourceforge.net/tracker/?func=detail&atid=560720&aid=3073546&group_id=80706
<https://sourceforge.net/tracker/?func=detail&atid=560720&aid=3073546&group_id=80706>

You might want to add your suggestion about axis labels or submit a new
ticket.

The problem is not a bug; it is inherent in the fundamental design.
Therefore I moved the ticket over to feature requests. I want to keep
the bugs list for real bugs that we can realistically expect to solve
fairly quickly.

I don't know whether Andrew Straw's wx sizer-inspired code (mplsizer
toolkit) solves the problem or not. My impression is that it does
not--I think it is working with the Axes positions, not with axis and
tick labels, which are what cause most of the difficulties.

Eric

Change your subplots adjust parameters to make the default bottom,
left, wspace and hspace wider. This will reduce the chance of
overlaps.

http://matplotlib.sourceforge.net/search.html?q=subplots_adjust

The defaults can be changed in your rc file

  http://matplotlib.sourceforge.net/users/customizing.html

See also these recipes on the FAQ to automatically choose boundaries

  http://matplotlib.sourceforge.net/faq/howto_faq.html#move-the-edge-of-an-axes-to-make-room-for-tick-labels

  http://matplotlib.sourceforge.net/faq/howto_faq.html#automatically-make-room-for-tick-labels

Automatic layout to avoid overlap is not an easy problem -- Michael
Droetboom worked on it for a while but didn't get to a satisfactory
point. So far our philosophy has been : make it easy to customize
rather than do it automatically. I realize this is not always a good
approach, especially in automated figure generators where you don't
have access to the data ahead of time.

JDH

···

On Wed, Sep 22, 2010 at 8:31 PM, C M <cmpython@...287...> wrote:

Until a more permanent solution is figured out, can anyone recommend
any workarounds, even if they are a little clunky? I'm embedding mpl
plots in wxPython and am also finding this issue suboptimal.

A (partial) workaround is possible using the axes_grid1 toolkit (i.e.,
you need matplotlib 1.0).
Attached is a module I just cooked up (based on my previous attempt @
http://www.mail-archive.com/matplotlib-users@lists.sourceforge.net/msg18129.html),
and it seems to work quite well.
The usage is simple.

        ax = plt.axes([0,0,1,1])

        ax.set_yticks([0.5])
        ax.set_yticklabels(["very long label"])

        make_axes_area_auto_adjustable(ax) # This is where axes_grid1 comes in

Then, the axes area(including ticklabels and axis label) will be
automatically adjusted to fit in the given extent ([0, 0, 1, 1] in the
above case).

While this is mainly for a single axes plot, you may use it with
multi-axes plot (but somewhat trickier to use). A few examples are
included in the module.

Regards,

-JJ

make_room_for_ylabel_using_axesgrid.py (6.86 KB)

···

On Thu, Sep 23, 2010 at 10:31 AM, C M <cmpython@...287...> wrote:

Until a more permanent solution is figured out, can anyone recommend
any workarounds, even if they are a little clunky? I'm embedding mpl
plots in wxPython and am also finding this issue suboptimal.

Che

This thread is a few months old now, but I just wanted to mention that I am using JJ’s workaround (thanks!) in my app–with either one or two y axes–and it is just excellent.

This should definitely be at least an option for matplotlib users–the quality of the appearance of the plots now is like night and day, because, to me, seeing a plot without its axes labels (I’m talking about in a resizable plot embedded in an application, not a static graph for inclusion in a publication) is a major look and feel demerit.

Che

···

On Thu, Sep 30, 2010 at 7:55 AM, Jae-Joon Lee <lee.j.joon@…287…> wrote:

On Thu, Sep 23, 2010 at 10:31 AM, C M <cmpython@…287…> wrote:

Until a more permanent solution is figured out, can anyone recommend

any workarounds, even if they are a little clunky? I’m embedding mpl

plots in wxPython and am also finding this issue suboptimal.

Che

A (partial) workaround is possible using the axes_grid1 toolkit (i.e.,

you need matplotlib 1.0).

Attached is a module I just cooked up (based on my previous attempt @

http://www.mail-archive.com/matplotlib-users@lists.sourceforge.net/msg18129.html),

and it seems to work quite well.

The usage is simple.

    ax = plt.axes([0,0,1,1])



    ax.set_yticks([0.5])

    ax.set_yticklabels(["very long label"])



    make_axes_area_auto_adjustable(ax) # This is where axes_grid1 comes in

Then, the axes area(including ticklabels and axis label) will be

automatically adjusted to fit in the given extent ([0, 0, 1, 1] in the

above case).

While this is mainly for a single axes plot, you may use it with

multi-axes plot (but somewhat trickier to use). A few examples are

included in the module.

Regards,

-JJ

Although this has been a big improvement, there is a lingering issue
that I want to get around to cleaning up now.

When I use this workaround that Jae Joon provided, it works just fine
except that if I call canvas.draw() (because I am adding a star to a
particular marker when point picking), it causes the whole canvas to
"jump" a little bit.

What happens is that on the first call to .draw() the plot area
increases vertically a tiny amount and the title moves up slightly.
On subsequent calls, the plot surface doesn't increase vertically but
the title text moves slightly up and then down quickly. This happens
each time I point pick for the first 5 or so times, and then it stops
doing it. I don't even have to add any new points to the plot, just
call canvas.draw() and it will do this.

It is visually distracting and a look and feel demerit for the app for sure.

I've tried to make a sample that is not embedded in wxPython but so
far I can't reproduce the problem.

Jae Joon or anyone, any ideas about why this is occurring and how to
prevent it? If need be I will try to work up a sample that
demonstrates it, but so far I've failed in that.

Thanks,
Che

···

On Thu, Sep 30, 2010 at 7:55 AM, Jae-Joon Lee <lee.j.joon@...287...> wrote:

On Thu, Sep 23, 2010 at 10:31 AM, C M <cmpython@...287...> wrote:

Until a more permanent solution is figured out, can anyone recommend
any workarounds, even if they are a little clunky? I'm embedding mpl
plots in wxPython and am also finding this issue suboptimal.

Che

A (partial) workaround is possible using the axes_grid1 toolkit (i.e.,
you need matplotlib 1.0).
Attached is a module I just cooked up (based on my previous attempt @
http://www.mail-archive.com/matplotlib-users@lists.sourceforge.net/msg18129.html),
and it seems to work quite well.
The usage is simple.

   ax = plt\.axes\(\[0,0,1,1\]\)

   ax\.set\_yticks\(\[0\.5\]\)
   ax\.set\_yticklabels\(\[&quot;very long label&quot;\]\)

   make\_axes\_area\_auto\_adjustable\(ax\) \# This is where axes\_grid1 comes in

Then, the axes area(including ticklabels and axis label) will be
automatically adjusted to fit in the given extent ([0, 0, 1, 1] in the
above case).

While this is mainly for a single axes plot, you may use it with
multi-axes plot (but somewhat trickier to use). A few examples are
included in the module.

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.

Regards,

-JJ

···

On Tue, May 10, 2011 at 3:06 AM, C M <cmpython@...287...> wrote:

On Thu, Sep 30, 2010 at 7:55 AM, Jae-Joon Lee <lee.j.joon@...287...> wrote:

On Thu, Sep 23, 2010 at 10:31 AM, C M <cmpython@...287...> wrote:

Until a more permanent solution is figured out, can anyone recommend
any workarounds, even if they are a little clunky? I'm embedding mpl
plots in wxPython and am also finding this issue suboptimal.

Che

A (partial) workaround is possible using the axes_grid1 toolkit (i.e.,
you need matplotlib 1.0).
Attached is a module I just cooked up (based on my previous attempt @
http://www.mail-archive.com/matplotlib-users@lists.sourceforge.net/msg18129.html),
and it seems to work quite well.
The usage is simple.

   ax = plt\.axes\(\[0,0,1,1\]\)

   ax\.set\_yticks\(\[0\.5\]\)
   ax\.set\_yticklabels\(\[&quot;very long label&quot;\]\)

   make\_axes\_area\_auto\_adjustable\(ax\) \# This is where axes\_grid1 comes in

Then, the axes area(including ticklabels and axis label) will be
automatically adjusted to fit in the given extent ([0, 0, 1, 1] in the
above case).

While this is mainly for a single axes plot, you may use it with
multi-axes plot (but somewhat trickier to use). A few examples are
included in the module.

Although this has been a big improvement, there is a lingering issue
that I want to get around to cleaning up now.

When I use this workaround that Jae Joon provided, it works just fine
except that if I call canvas.draw() (because I am adding a star to a
particular marker when point picking), it causes the whole canvas to
"jump" a little bit.

What happens is that on the first call to .draw() the plot area
increases vertically a tiny amount and the title moves up slightly.
On subsequent calls, the plot surface doesn't increase vertically but
the title text moves slightly up and then down quickly. This happens
each time I point pick for the first 5 or so times, and then it stops
doing it. I don't even have to add any new points to the plot, just
call canvas.draw() and it will do this.

It is visually distracting and a look and feel demerit for the app for sure.

I've tried to make a sample that is not embedded in wxPython but so
far I can't reproduce the problem.

Jae Joon or anyone, any ideas about why this is occurring and how to
prevent it? If need be I will try to work up a sample that
demonstrates it, but so far I've failed in that.

Thanks,
Che

It seems I can't build matplotlib from source. Would it be possible to
attach the amended files to this list and I'll try them?

Thank you,
Che

···

On Wed, May 11, 2011 at 12:29 AM, Jae-Joon Lee <lee.j.joon@...287...> 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.