Ryan May wrote:
> On Thu, May 7, 2009 at 3:13 PM, Eric Firing <efir...@hawaii.edu
> <mailto:efir...@hawaii.edu>> wrote:
>
> Ryan May wrote:
>
> On Tue, Apr 28, 2009 at 9:54 PM, Thomas Robitaille
> <thomas.robitai...@gmail.com
> <mailto:thomas.robitai...@gmail.com>
> <mailto:thomas.robitai...@gmail.com
> <mailto:thomas.robitai...@gmail.com>>> wrote:
>
> Thanks! I could not find any documentation relating to this,
> so I was
> wondering whether it would be better to go with a well-documented
> function such as text or figtext? What would be best to use?
>
> Thomas
>
> On 28 Apr 2009, at 22:27, Yong-Duk Jin wrote:
>
> > You can use 'LABELPAD' to adjust label position.
> > e.g.
> >
> > import pylab
> > hAxes = pylab.axes()
> > pylab.xlabel('test')
> > hAxes.xaxis.LABELPAD = 0
> > pylab.show()
> >
>
>
> There's now a documented way to do this in SVN HEAD, by passing
> labelpad as an argument to the xlabel/ylabel functions.
>
>
> Ryan,
>
> Good idea, thanks.
>
> Quick thought, with no investigation on my part: wouldn't it be more
> natural and more useful if text placement pads like this were in
> font-size units, like the "em" and "ex", so that they would scale
> with the font size? I think that this would make the need to set
> them manually much less common.
>
>
> Good idea, I agree that might help. I was just going for somewhat of a
> quick hack, by just cleaning up access to a pre-existing constant.
> Right now it adds this pad value scaled by dpi/72.0 to an appropriate
> start in pixels. Any idea how the math could include a font size?
In any case where the text object exists at the time the calculation is
needed, and the method doing the calculation has access to that object,
it is just a matter of changing, for example,
self.label.set_position( (x, bottom -
self.labelpad*self.figure.dpi / 72.0))
to
pad = (self.labelpad_rel * self.label.get_size() *
self.figure.dpi / 72.0)
self.label.set_position( (x, bottom - pad))
I think that most of the pads used in mpl are associated with text
objects in such a way that this can be done. The question then becomes
one of how to implement it in a way that doesn't wreck existing code,
and doesn't create intolerable clutter. If this can be done, I think it
would make a *significant* improvement in mpl usability--at least for
anyone who needs to rescale plots for publication or for presentation
display, for example.
Another thing to watch out for in trying to make such a change: the pad
calculation would need to be done late enough to reflect the font size
at draw-time. I have not looked to see whether this is already the
case, or whether it would require substantial refactoring.
I was not suggesting that your labelpad patch should be changed right
away, but rather using it as an opportunity to raise the larger design
question, and see whether anyone is interested in pursuing it.
I have raised questions about pad units before, and in fact we now have
legend.borderpad (in legend font units) that replaces legend.pad (in
normalized axes units).
Eric
>
> Ryan
>
> --
> Ryan May
> Graduate Research Assistant
> School of Meteorology
> University of Oklahoma
> Sent from Norman, Oklahoma, United States
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
