Re: [Matplotlib-users] Subplot x-tick labels overlap with each other and with titles
I have been wondering the same thing. Matlab is able to prevent labels from
overlapping each other. Why can't matplotlib?
Chris Rodgers-7 wrote:
>
> Hi
>
> Whenever I create figures with at least 3x3 subplots, the x-tick
> labels overlap with each other and they also overlap with the title of
> the adjacent subplot, rendering the entire figure illegible. I know
> that I can fine-tune the plot to look exactly the way I want with
> "wspace" and "hspace" for instance, but I don't understand why this is
> the default behavior. I wonder if I have a system font issue, such
> that matplotlib thinks the fonts are smaller than they really are.
>
> My questions:
> 1) Is this the intended behavior of matplotlib, or is there something
> wrong with my installation?
> 2) Assuming I don't have an installation issue, is there a very
> general parameter I can change so that the overlap doesn't occur,
> rather than manually adjusting every figure?
>
>
> Minimal code to reproduce the problem:
>
> import numpy as np
> import matplotlib.pyplot as plt
> plt.figure()
> plt.subplot(331)
> plt.subplot(334)
> plt.plot(np.arange(1))
> plt.title('Title')
> plt.show()
>
>
> I'm attaching the output figure, although I'm not sure if the list
> accepts attachments. The x-tick labels on subplot 334 overlap each
> other, and the title of subplot 334 overlaps with the x-tick labels in
> subplot 331.
>
>
> System:
> Ubuntu 10.04 x64
> All packages are the stable versions from Synaptic, including ipython,
> python, numpy, matplotlib 0.99.1.1
> I've also tried the Enthought distribution with matplotlib 1.0.1 and
> the results are the same
> I've tried both "Wx" and "Tk" backends and the results are the same
> I've tried `matplotlib.rcParams['xtick.labelsize'] = 'x-small'`, and
> this does make the labels smaller, but for sufficiently large numbers
> the overlap still occurs.
>
> Thanks for any help!
> Chris
>
>
> --
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today. Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> ___
> Matplotlib-users mailing list
> Matplotlib-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
--
View this message in context:
http://old.nabble.com/Subplot-x-tick-labels-overlap-with-each-other-and-with-titles-tp31560643p33080989.html
Sent from the matplotlib - users mailing list archive at Nabble.com.
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Subplot x-tick labels overlap with each other and with titles
On Wed, Jan 4, 2012 at 1:14 PM, jeffsp wrote:
>
> I have been wondering the same thing. Matlab is able to prevent labels
> from
> overlapping each other. Why can't matplotlib?
>
>
> Chris Rodgers-7 wrote:
> >
> > Hi
> >
> > Whenever I create figures with at least 3x3 subplots, the x-tick
> > labels overlap with each other and they also overlap with the title of
> > the adjacent subplot, rendering the entire figure illegible. I know
> > that I can fine-tune the plot to look exactly the way I want with
> > "wspace" and "hspace" for instance, but I don't understand why this is
> > the default behavior. I wonder if I have a system font issue, such
> > that matplotlib thinks the fonts are smaller than they really are.
> >
> > My questions:
> > 1) Is this the intended behavior of matplotlib, or is there something
> > wrong with my installation?
> > 2) Assuming I don't have an installation issue, is there a very
> > general parameter I can change so that the overlap doesn't occur,
> > rather than manually adjusting every figure?
> >
> >
> > Minimal code to reproduce the problem:
> >
> > import numpy as np
> > import matplotlib.pyplot as plt
> > plt.figure()
> > plt.subplot(331)
> > plt.subplot(334)
> > plt.plot(np.arange(1))
> > plt.title('Title')
> > plt.show()
> >
> >
> > I'm attaching the output figure, although I'm not sure if the list
> > accepts attachments. The x-tick labels on subplot 334 overlap each
> > other, and the title of subplot 334 overlaps with the x-tick labels in
> > subplot 331.
>
Have you try calling `plt.tight_layout()` right before `plt.show()`?
-Tony
> >
> > System:
> > Ubuntu 10.04 x64
> > All packages are the stable versions from Synaptic, including ipython,
> > python, numpy, matplotlib 0.99.1.1
> > I've also tried the Enthought distribution with matplotlib 1.0.1 and
> > the results are the same
> > I've tried both "Wx" and "Tk" backends and the results are the same
> > I've tried `matplotlib.rcParams['xtick.labelsize'] = 'x-small'`, and
> > this does make the labels smaller, but for sufficiently large numbers
> > the overlap still occurs.
> >
> > Thanks for any help!
> > Chris
>
>
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Subplot x-tick labels overlap with each other and with titles
plt.tight_layout(), sweet
it still makes the labels too close to read, even if they don't overlap.
that is, they're just a continuous string of numbers with no whitespace
between.
it does clean up the rest of the plot really nicely, though, without having
to continually dick around with subplots_adjust
Tony Yu-3 wrote:
>
> On Wed, Jan 4, 2012 at 1:14 PM, jeffsp wrote:
>
>>
>> I have been wondering the same thing. Matlab is able to prevent labels
>> from
>> overlapping each other. Why can't matplotlib?
>>
>>
>> Chris Rodgers-7 wrote:
>> >
>> > Hi
>> >
>> > Whenever I create figures with at least 3x3 subplots, the x-tick
>> > labels overlap with each other and they also overlap with the title of
>> > the adjacent subplot, rendering the entire figure illegible. I know
>> > that I can fine-tune the plot to look exactly the way I want with
>> > "wspace" and "hspace" for instance, but I don't understand why this is
>> > the default behavior. I wonder if I have a system font issue, such
>> > that matplotlib thinks the fonts are smaller than they really are.
>> >
>> > My questions:
>> > 1) Is this the intended behavior of matplotlib, or is there something
>> > wrong with my installation?
>> > 2) Assuming I don't have an installation issue, is there a very
>> > general parameter I can change so that the overlap doesn't occur,
>> > rather than manually adjusting every figure?
>> >
>> >
>> > Minimal code to reproduce the problem:
>> >
>> > import numpy as np
>> > import matplotlib.pyplot as plt
>> > plt.figure()
>> > plt.subplot(331)
>> > plt.subplot(334)
>> > plt.plot(np.arange(1))
>> > plt.title('Title')
>> > plt.show()
>> >
>> >
>> > I'm attaching the output figure, although I'm not sure if the list
>> > accepts attachments. The x-tick labels on subplot 334 overlap each
>> > other, and the title of subplot 334 overlaps with the x-tick labels in
>> > subplot 331.
>>
>
> Have you try calling `plt.tight_layout()` right before `plt.show()`?
>
> -Tony
>
>> >
>> > System:
>> > Ubuntu 10.04 x64
>> > All packages are the stable versions from Synaptic, including ipython,
>> > python, numpy, matplotlib 0.99.1.1
>> > I've also tried the Enthought distribution with matplotlib 1.0.1 and
>> > the results are the same
>> > I've tried both "Wx" and "Tk" backends and the results are the same
>> > I've tried `matplotlib.rcParams['xtick.labelsize'] = 'x-small'`, and
>> > this does make the labels smaller, but for sufficiently large numbers
>> > the overlap still occurs.
>> >
>> > Thanks for any help!
>> > Chris
>>
>>
>
> --
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> ___
> Matplotlib-users mailing list
> Matplotlib-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
--
View this message in context:
http://old.nabble.com/Subplot-x-tick-labels-overlap-with-each-other-and-with-titles-tp31560643p33081289.html
Sent from the matplotlib - users mailing list archive at Nabble.com.
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Subplot x-tick labels overlap with each other and with titles
On Wednesday, January 4, 2012, jeffsp wrote: > > plt.tight_layout(), sweet > > it still makes the labels too close to read, even if they don't overlap. > that is, they're just a continuous string of numbers with no whitespace > between. > > it does clean up the rest of the plot really nicely, though, without having > to continually dick around with subplots_adjust > > Well, it is a new feature with plenty of room for improvements. Maybe some sort of mindist parameter would be useful to establish a minimum distance between text objects? Ben Root -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
[Matplotlib-users] cycling mechanism
Hello all, So, I am getting to the point where I need to implement a color cycling mechanism throughout pyplot. So, before I get too deep in implementing it, I have some thoughts that I need feedback on. 1) Not all plotting functions use color cycling right now. Currently, only plot() and any function that calls plot in its process (such as errorbar()). Glaring omissions are bar() and scatter(), and pie() could also benefit from having a uniform cycling mechanism. So, the issue going forward is, do we want to enable common cycling for all the pyplot/axes plotting functions which would require updating the test images and break backwards compatibility (in a sense), or do we want to have a per-function default rcparams that would contain one-element cycles that would effectively maintain current drawing results? 2) I also have the need to implement line-style cycling for b&w publications. Of course if I implement that, then why not hatch-cycling? marker-cycling? I have seen use-cases for all of these, and I am considering how to have a generalized framework for this. So my question is, what attributes would we like to see cycle-able? Here is a short list and some usecases I have come up with. Please extend this with ideas of your own. color - plot(), errorbar(), scatter(), bar(), hist(), pie(), stem() linestyle - plot(), errorbar(), stem() hatch - bar(), hist(), pie() marker - plot(), errorbar(), scatter(), stem() linewidth? facecolor/edgecolor? joinstyle? 3) rcparam names. I was thinking about how to name these cycles in the matplotlibrc file. Possibly: cycle.colors cycle.linestyles cycle.hatches cycle.markers And these would represent the global default, meanwhile, function-specific cycles could be given by: cycle.colors.pie cycle.colors.bar cycle.linestyles.plot cycle.linestyles.errorbar I was thinking that in code, one would access the full name attribute for the function, and I would extend the __get__ function to intelligently fall back to the global default if the full-name attribute is not specified. However, would there be confusion in a situation such as a person who wanted to use barh() but only had specified cycle.colors.bar? 4) Ultimately, my goal is to be able to create some typical profiles that have useful cycle specs, and possibly make some available as convenience functions, such as a b&w mode. Such a mode would set the default colormap to a grayscale-friendly colorscale, and use line style, hatch and marker cycles instead of a full color cycle. Thoughts? Comments? Cheers! Ben Root -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] cycling mechanism
On Wed, Jan 4, 2012 at 6:52 PM, Benjamin Root wrote: > > Thoughts? Comments? None other than my eternal gratitude if you do this: it's one of the few things (perhaps the only one) I still miss from the old gnuplot, which made it trivial to switch from color to b/w mode and it would produce sensible output immediately in either mode. Cheers, f -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] cycling mechanism
On Jan 4, 2012, at 20:52, Benjamin Root wrote: > Hello all, > > So, I am getting to the point where I need to implement a color cycling > mechanism throughout pyplot. So, before I get too deep in implementing it, I > have some thoughts that I need feedback on. > > 1) Not all plotting functions use color cycling right now. Currently, only > plot() and any function that calls plot in its process (such as errorbar()). > Glaring omissions are bar() and scatter(), and pie() could also benefit from > having a uniform cycling mechanism. So, the issue going forward is, do we > want to enable common cycling for all the pyplot/axes plotting functions > which would require updating the test images and break backwards > compatibility (in a sense), or do we want to have a per-function default > rcparams that would contain one-element cycles that would effectively > maintain current drawing results? > > 2) I also have the need to implement line-style cycling for b&w publications. > Of course if I implement that, then why not hatch-cycling? marker-cycling? I > have seen use-cases for all of these, and I am considering how to have a > generalized framework for this. So my question is, what attributes would we > like to see cycle-able? Here is a short list and some usecases I have come up > with. Please extend this with ideas of your own. > > color - plot(), errorbar(), scatter(), bar(), hist(), pie(), stem() > linestyle - plot(), errorbar(), stem() > hatch - bar(), hist(), pie() > marker - plot(), errorbar(), scatter(), stem() > > linewidth? facecolor/edgecolor? joinstyle? > > 3) rcparam names. I was thinking about how to name these cycles in the > matplotlibrc file. Possibly: > > cycle.colors > cycle.linestyles > cycle.hatches > cycle.markers > > And these would represent the global default, meanwhile, function-specific > cycles could be given by: > > cycle.colors.pie > cycle.colors.bar > cycle.linestyles.plot > cycle.linestyles.errorbar > > I was thinking that in code, one would access the full name attribute for the > function, and I would extend the __get__ function to intelligently fall back > to the global default if the full-name attribute is not specified. However, > would there be confusion in a situation such as a person who wanted to use > barh() but only had specified cycle.colors.bar? > > 4) Ultimately, my goal is to be able to create some typical profiles that > have useful cycle specs, and possibly make some available as convenience > functions, such as a b&w mode. Such a mode would set the default colormap to > a grayscale-friendly colorscale, and use line style, hatch and marker cycles > instead of a full color cycle. > > Thoughts? Comments? My first thought is that maybe we need an object to collect and abstract all of these style attributes, and then cycle through a sequence of those. In the future we could move the matplotlib API to use such an object instead of the billion parameters that are individually passed now. Just 0.02 to distract me from the dissertation. Ryan -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] cycling mechanism
On Wed, Jan 4, 2012 at 9:33 PM, Ryan May wrote: > On Jan 4, 2012, at 20:52, Benjamin Root wrote: > > > Hello all, > > > > So, I am getting to the point where I need to implement a color cycling > mechanism throughout pyplot. So, before I get too deep in implementing it, > I have some thoughts that I need feedback on. > > > > 1) Not all plotting functions use color cycling right now. Currently, > only plot() and any function that calls plot in its process (such as > errorbar()). Glaring omissions are bar() and scatter(), and pie() could > also benefit from having a uniform cycling mechanism. So, the issue going > forward is, do we want to enable common cycling for all the pyplot/axes > plotting functions which would require updating the test images and break > backwards compatibility (in a sense), or do we want to have a per-function > default rcparams that would contain one-element cycles that would > effectively maintain current drawing results? > > > > 2) I also have the need to implement line-style cycling for b&w > publications. Of course if I implement that, then why not hatch-cycling? > marker-cycling? I have seen use-cases for all of these, and I am > considering how to have a generalized framework for this. So my question > is, what attributes would we like to see cycle-able? Here is a short list > and some usecases I have come up with. Please extend this with ideas of > your own. > > > > color - plot(), errorbar(), scatter(), bar(), hist(), pie(), stem() > > linestyle - plot(), errorbar(), stem() > > hatch - bar(), hist(), pie() > > marker - plot(), errorbar(), scatter(), stem() > > > > linewidth? facecolor/edgecolor? joinstyle? > > > > 3) rcparam names. I was thinking about how to name these cycles in the > matplotlibrc file. Possibly: > > > > cycle.colors > > cycle.linestyles > > cycle.hatches > > cycle.markers > > > > And these would represent the global default, meanwhile, > function-specific cycles could be given by: > > > > cycle.colors.pie > > cycle.colors.bar > > cycle.linestyles.plot > > cycle.linestyles.errorbar > > > > I was thinking that in code, one would access the full name attribute > for the function, and I would extend the __get__ function to intelligently > fall back to the global default if the full-name attribute is not > specified. However, would there be confusion in a situation such as a > person who wanted to use barh() but only had specified cycle.colors.bar? > > > > 4) Ultimately, my goal is to be able to create some typical profiles > that have useful cycle specs, and possibly make some available as > convenience functions, such as a b&w mode. Such a mode would set the > default colormap to a grayscale-friendly colorscale, and use line style, > hatch and marker cycles instead of a full color cycle. > > > > Thoughts? Comments? > > My first thought is that maybe we need an object to collect and abstract > all of these style attributes, and then cycle through a sequence of those. > In the future we could move the matplotlib API to use such an object > instead of the billion parameters that are individually passed now. > > +1 > Just 0.02 to distract me from the dissertation. > > Oh yeah... I got one of those to complete as well... Ben Root Ryan -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] cycling mechanism
> 2) I also have the need to implement line-style cycling for b&w > publications. What about also grey level cycling for b&w? Sometimes for b&w it looks better to use different gray levels rather than different line-styles. See this for an example: http://media.aau.dk/null_space_pursuits/2011/06/recovery-of-compressively-sensed-sparse-signals-in-noise-pt-2.html Alejandro. -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] cycling mechanism
On Wed, Jan 4, 2012 at 9:53 PM, Alejandro Weinstein < alejandro.weinst...@gmail.com> wrote: > > 2) I also have the need to implement line-style cycling for b&w > > publications. > > What about also grey level cycling for b&w? Sometimes for b&w it looks > better to use different gray levels rather than different > line-styles. See this for an example: > > > http://media.aau.dk/null_space_pursuits/2011/06/recovery-of-compressively-sensed-sparse-signals-in-noise-pt-2.html > > Alejandro. > > The cycles can be specified either in code and/or in matplotlibrc as a list of colors. We can certainly make sure that tuples of rgb values would be valid. The point of this project is to get the plotting functions to universally use cycles that can be specified by the user. Profiles can be created for different styles and combinations of effects. Ben Root -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
