Arc reporting bogus bounding box?

I'm drawing a figure for inclusion into a LaTeX document, and I'm
having trouble getting matplotlib to export a .pdf that 'tightly'
encapsulates the drawing that is generated - I get a lot of whitespace
at the bottom, in particular.

After some experimentation, I've found that the culprit is an Arc that
I am drawing near the bottom of the page. The angle range is something
like pi/4 to 3*pi/4, so the actual line is located well above the
center of the circle defining the arc, but it appears that the arc is
reporting a bounding box that is the same as would be reported for a
circle.

Perhaps this isn't a bug and this behavior is useful to some, but I'd
really like to be able to get the resulting image fit tightly around
the drawn lines and not invisible bounding boxes.

Can anyone help me out? Is there some way I can force matplotlib to
'clip' the output?

Thanks,
Jason

P.S. I'm using matplotlib v. 0.98.5.2 on Python 2.6 running on x86_64 Linux

MPL, by default, does not do any clipping. So, i'm not sure why the
extent of the circle matters (I think even the bbox_inches option does
not take care of that) . Everything should be fine as far as you
create a figure in an appropriate size. Changing the suplotplot
parameters (or something similar) is not your option?

If possible, can you post a simplified version of your code that
demonstrate the problem?

Regards,

-JJ

···

On Sun, Oct 4, 2009 at 6:32 PM, Jason Sewall <jasonsewall@...287...> wrote:

I'm drawing a figure for inclusion into a LaTeX document, and I'm
having trouble getting matplotlib to export a .pdf that 'tightly'
encapsulates the drawing that is generated - I get a lot of whitespace
at the bottom, in particular.

After some experimentation, I've found that the culprit is an Arc that
I am drawing near the bottom of the page. The angle range is something
like pi/4 to 3*pi/4, so the actual line is located well above the
center of the circle defining the arc, but it appears that the arc is
reporting a bounding box that is the same as would be reported for a
circle.

Perhaps this isn't a bug and this behavior is useful to some, but I'd
really like to be able to get the resulting image fit tightly around
the drawn lines and not invisible bounding boxes.

Can anyone help me out? Is there some way I can force matplotlib to
'clip' the output?

Thanks,
Jason

P.S. I'm using matplotlib v. 0.98.5.2 on Python 2.6 running on x86_64 Linux

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Sure:
-------- bounds.py ---------
#!/usr/bin/python
import matplotlib
import pylab

if __name__ == '__main__':
    pylab.clf()
    ax = pylab.axes([0,0,1,1])
    ax.add_line(matplotlib.lines.Line2D((2, 5), (0.75, 6)))
    ax.add_patch(matplotlib.patches.Arc((2, 0), 1.5, 1.5, 0.0, 0,
180.0, fill=False))
    ax.axis('equal')
    pylab.savefig("fig-a.pdf", bbox_inches='tight', pad_inches=0)

···

On Sun, Oct 4, 2009 at 10:57 PM, Jae-Joon Lee <lee.j.joon@...287...> wrote:

MPL, by default, does not do any clipping. So, i'm not sure why the
extent of the circle matters (I think even the bbox_inches option does
not take care of that) . Everything should be fine as far as you
create a figure in an appropriate size. Changing the suplotplot
parameters (or something similar) is not your option?

If possible, can you post a simplified version of your code that
demonstrate the problem?

--------------------------------

What this does is make a stupid little picture of a hemi-circle and
and line going off somewhere. At any rate, the y dimensions of this
image are something like [-0.75, 6], while I'd expect it to be [0, 6]
- the 'imaginary' lower half of the circle is being used to compute
the final axes size. The y dimensions do no change if I choose
ax.axis('tight')

While I'm at it, I might as well as about image dimensions vs. axes limits.

If I change ax.axis('equal') manually to the correct bounding box of
the visible stuff (i.e. ax.axis([1.25, 5, 0, 6])), I then get an image
that is distorted, presumably to fit some pre-set aspect ratio. Is
there a way to fix this, too? I guess what I'd like is a way to say:
"When you save or render this image, set the output image dimensions
to be appropriate to aspect ratio x (usually 1:1 for me) and the
current axis setting"

I've used matplotlib for more than a few projects, but this aspect of
it has eluded me.

Thanks for all your help,
Jason

Jason Sewall wrote:

While I'm at it, I might as well as about image dimensions vs. axes limits.

If I change ax.axis('equal') manually to the correct bounding box of
the visible stuff (i.e. ax.axis([1.25, 5, 0, 6])), I then get an image
that is distorted, presumably to fit some pre-set aspect ratio. Is
there a way to fix this, too? I guess what I'd like is a way to say:
"When you save or render this image, set the output image dimensions
to be appropriate to aspect ratio x (usually 1:1 for me) and the
current axis setting"

Use the Axes.set_aspect() method for full control of the aspect ratio, and of what gets changed to preserve that aspect ratio.

Eric

···

I've used matplotlib for more than a few projects, but this aspect of
it has eluded me.

Thanks for all your help,
Jason

Thanks, that works great! Any ideas about Arc's effect on the 'tight' bounds?

···

On Sun, Oct 4, 2009 at 11:45 PM, Eric Firing <efiring@...202...> wrote:

Use the Axes.set_aspect() method for full control of the aspect ratio, and
of what gets changed to preserve that aspect ratio.

Jason Sewall wrote:

···

On Sun, Oct 4, 2009 at 11:45 PM, Eric Firing <efiring@...202...> wrote:

Use the Axes.set_aspect() method for full control of the aspect ratio, and
of what gets changed to preserve that aspect ratio.

Thanks, that works great! Any ideas about Arc's effect on the 'tight' bounds?

Sorry, I don't know anything at all about that offhand, and I can't look right now.

Eric

Jason,

This is now fixed in the svn.

http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/patches.py?r1=7840&r2=7857

Meanwhile, you may use the following workaround.

import matplotlib
import pylab
from matplotlib.path import Path

if __name__ == '__main__':
   pylab.clf()
   ax = pylab.axes([0,0,1,1])
   ax.add_line(matplotlib.lines.Line2D((2, 5), (0.75, 6)))
   arc = matplotlib.patches.Arc((2, 0), 1.5, 1.5, 0.0, 0, 180.0, fill=False)
   arc._path = Path.arc(arc.theta1, arc.theta2)
   ax.add_patch(arc)
   ax.axis('equal')

Note that the current pathces.Arc may update its _path during draw().
So, you may need to do

   arc._path = Path.arc(arc.theta1, arc.theta2)

whenever correct extent of the arc is required (i.e., before calling axis).

Regards,

-JJ

···

On Sun, Oct 4, 2009 at 11:51 PM, Jason Sewall <jasonsewall@...287...> wrote:

On Sun, Oct 4, 2009 at 11:45 PM, Eric Firing <efiring@...202...> wrote:

Use the Axes.set_aspect() method for full control of the aspect ratio, and
of what gets changed to preserve that aspect ratio.

Thanks, that works great! Any ideas about Arc's effect on the 'tight' bounds?

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Great! Thanks for the help!

Jason

···

On Wed, Oct 7, 2009 at 12:12 PM, Jae-Joon Lee <lee.j.joon@...287...> wrote:

Jason,

This is now fixed in the svn.

Meanwhile, you may use the following workaround.