Skip to content

No support for horizontal alignment in tick_params?  #13774

Closed as duplicate

Description

@lash81

Why does ax.tick_params not support horizontal alignment?

Also, there is no documentation for most of these supported keywords:
valid keywords are ['size', 'width', 'color', 'tickdir', 'pad', 'labelsize', 'labelcolor', 'zorder', 'gridOn', 'tick1On', 'tick2On', 'label1On', 'label2On', 'length', 'direction', 'left', 'bottom', 'right', 'top', 'labelleft', 'labelbottom', 'labelright', 'labeltop', 'labelrotation', 'grid_agg_filter', 'grid_alpha', 'grid_animated', 'grid_antialiased', 'grid_clip_box', 'grid_clip_on', 'grid_clip_path', 'grid_color', 'grid_contains', 'grid_dash_capstyle', 'grid_dash_joinstyle', 'grid_dashes', 'grid_drawstyle', 'grid_figure', 'grid_fillstyle', 'grid_gid', 'grid_in_layout', 'grid_label', 'grid_linestyle', 'grid_linewidth', 'grid_marker', 'grid_markeredgecolor', 'grid_markeredgewidth', 'grid_markerfacecolor', 'grid_markerfacecoloralt', 'grid_markersize', 'grid_markevery', 'grid_path_effects', 'grid_picker', 'grid_pickradius', 'grid_rasterized', 'grid_sketch_params', 'grid_snap', 'grid_solid_capstyle', 'grid_solid_joinstyle', 'grid_transform', 'grid_url', 'grid_visible', 'grid_xdata', 'grid_ydata', 'grid_zorder', 'grid_aa', 'grid_c', 'grid_ls', 'grid_lw', 'grid_mec', 'grid_mew', 'grid_mfc', 'grid_mfcalt', 'grid_ms', 'grid_aa', 'grid_c', 'grid_ls', 'grid_lw', 'grid_mec', 'grid_mew', 'grid_mfc', 'grid_mfcalt', 'grid_ms']

Originally posted by @tdpetrou in #8122 (comment)

Activity

  1. ImportanceOfBeingErnest commented on Mar 28, 2019

    @ImportanceOfBeingErnest
    Member

    There is a bit of discussion in #10911 (comment) and following comments.

    As to why it isn't implemented, the answer is simply noone has done it yet. The tick params used to be a big mess; by now it has become much cleaner code-wise. So maybe now is the time to actually add the missing properties.

  2. timhoffm commented on Mar 30, 2019

    @timhoffm
    Member

    Note: The horizontal alignment of Text is is something different compared to what's probably expected from horizontal alignment of tick labels. Text aligns itself relative to its reference point. The ticks should probably align to a common reference line. See the discussion in #13440.

  3. ImportanceOfBeingErnest commented on Mar 30, 2019

    @ImportanceOfBeingErnest
    Member

    I'm not in favour of overloading the notion horizontalalignment with different things. What I would expect and find useful is exactly what horizontalalignment does for text. Though of course one can introduce additional options like horizontalalignment="leftjustify" for the thing proposed in #13440.

  4. timhoffm commented on Mar 30, 2019

    @timhoffm
    Member

    I‘m not suggesting if or how to handle this. But horizontalalignment="left" is probably not that useful here. It basically would result in this example: #13440 (comment)

  5. ImportanceOfBeingErnest commented on Mar 30, 2019

    @ImportanceOfBeingErnest
    Member

    I don't think we need to question the usefulness. But let me reiterate.

    As an example, consider using long ticklabels as in A simple categorical heatmap. You want them to be right-aligned and rotated

    image

    which is achieved using setters via

    plt.setp(ax.get_xticklabels(), rotation=45, ha="right", rotation_mode="anchor")
    

    One could hence argue that setters are the way to set the properties of ticklabels in matplotlib. But, since the introduction of tick_params, there are some cases where those properties are overwritten by a more general axis-wide setting. An example of this is precisely #10911 (comment). It was hence argued that tick_params should be the recommended interface to set those properties; but if that is to be the case, clearly horizontalalignment, verticalalignment and rotation_mode are missing.

    So more generally, one could summarize this into the question: What is the recommended interface to set axis label properties in matplotlib?
    (And please read through #10911 completely, before trying to answer that question. Also, a similar issue is #10882)

  6. timhoffm commented on Apr 2, 2019

    @timhoffm
    Member

    Disclaimer: Did not take the time to read #10911 completely, but still want to give short feedback. Please let me know in case I'm completely out of context.

    From my naive point of view, your use case looks valid; and I would expect to be able to use tick_params there. Shall we maybe restrict horizontalalignment to xaxis and verticalalignment to yaxis` to not raise any false expectations concerning the not supported justify-alignment.

  7. ImportanceOfBeingErnest commented on Apr 3, 2019

    @ImportanceOfBeingErnest
    Member

    Following the principle of least astonishment I'd say that if specifiying ax.tick_params(axis="y", horizontalalignment="left") one would expect the horizontalalignment to apply to the y axis. This is still useful in conjunction with pad, e.g. ax.tick_params(axis="y", horizontalalignment="left", pad=-5) would give:

    image

    or ax.tick_params(axis="y", horizontalalignment="left", pad=20)

    image


    Worth noting: The "justify" case can currently be accomplished via mpl_toolkits.axisartist as shown in the demo_ticklabel_alignment example.

  8. timhoffm commented on Apr 14, 2019

    @timhoffm
    Member

    @ImportanceOfBeingErnest you are right with your example.

    Should we maybe allow the alignment parameters only for single axis? For ax.tick_params(axis="y", horizontalalignment="left") the alignment has quite different effects and it would be a rare usecase that this is desired behavior. OTOH it's not too bad leaving this up to the user.

  9. modified the milestones: v3.2.0, v3.3.0 on Aug 16, 2019
  10. modified the milestones: v3.3.0, v3.4.0 on Apr 30, 2020
  11. mooperd commented on Nov 28, 2020

    @mooperd

    +1

  12. 5 remaining items

  13. story645 commented on Oct 27, 2021

    @story645
    Member

    xref #20644

  14. modified the milestones: v3.6.0, v3.7.0 on Jul 8, 2022
  15. PBrockmann commented on Sep 15, 2024

    @PBrockmann

    With 3.9.2, I haven't be able to control anchor position for xticklabels especially in a secondary_xaxis.
    The parameter 'ha' is missing in

    second_xaxis.tick_params(labelrotation=30, labelsize=8)

    Am I missing something ?

  16. timhoffm commented on Sep 17, 2024

    @timhoffm
    Member

    @PBrockmann there is no out-of-the-box solution yet because the meaning of alignment is somewhat subtle. See the discussions above for details.

    Therefore, alignment is currently not available in tick_params. As a workaround, you can set the alignment on the individual ticklabel instances plt.setp(second_xaxis.get_xticklabels(), horizontalalignment='left'). This works for static plots, i.e. as long as you don't modify the ticks afterwards.

  17. PBrockmann commented on Sep 17, 2024

    @PBrockmann

    Ok thanks ! It works.
    See https://github.com/PBrockmann/PyAnalyseries

    I was expecting a control on a specific axe rather than with plt.

  18. added a commit that references this issue on May 4, 2025
  19. github-actions commented on Sep 19, 2025

    @github-actions

    This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!

  20. timhoffm commented on Sep 19, 2025

    @timhoffm
    Member

    Discussion is continued in #20644

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    API: consistencyConsistency of the matplotlib API, including naming, behavior, defaults, …status: duplicate

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions