Skip to content

[ENH]: Position artists (particularly Annotations) relative to multiple other artists #22223

Open

Description

@stanleyjs

Problem

Currently we can position text relative to a single artist, as described in https://matplotlib.org/stable/tutorials/text/annotations.html?highlight=complex%20coordinate#using-complex-coordinates-with-annotations.

I would like to position texts relative to multiple artists. For instance, let's consider two text artists, txt1 positioned at (0.5,0.25) and txt2 (.5,0.75). Assume they are left-aligned and of width 0.1, so the left edge of each of their bbox is at 0.5, the right edge is at 0.6, and assume that txt2 at (.5,0.75) is top-aligned, so the top of its bbox is 0.75, and txt1 is bottom-aligned, so the bottom of its bbox is 0.25.

I would like some function combine_artists(txt1,txt2) that returns an object that combines the coordinate systems of txt1 and txt2 so that an artist can be positioned relative to the combined bbox. For instance, I would like to position some artist txt3 that is vertically centered between txt1 and txt2. Its data coordinate is (0.5,0.5), but its relative position coordinate in the combined txt1+txt2 space would be (0,0.5).

Proposed solution

There may already be a way to do this in the library, as it seems transforms are addable. What remains then is making the interface to creating the combined bbox/transform in a way that is easily accessible. I already tried just adding the transforms of the txt1 and txt2, which seemed like the most intuitive way for this to work.

Activity

  1. story645 commented on Jan 13, 2022

    @story645
    Member

    I think I 've wanted a variant of this for a while; adding a text labeling API to FancyArrowPatch to get tikz like labeling

    ar = FancyArrowPatch
    ar.set_label(str, pos={'over', 'under'. 'within'} , offset= ratio on interval of line, pad) #base off tikz api
    over under within (default)
    label
    ----->
    ----->
    label
    --label-->
    relpos=0 relpos=1 relpos=.5 (default)
    label-----> ----->label ---label--->

    maybe |--a1--[bbox]--a2-->

  2. jklymak commented on Jan 13, 2022

    @jklymak
    Member

    I think this positioning style is only supported for annotations, so far as I know?

  3. anntzer commented on Jan 13, 2022

    @anntzer
    Contributor

    I think the first thing to do would actually to make this kind of coordinate systems generally available, rather than being special-cased in the Annotation API. Given that Annotations support arbitrary callables (although taking a renderer as arg, which we can't do for a plain Transform) I guess the general approach (of course, we can have more specific helpers, but let's think about the general case first) would be something like IndirectTransform(func: Callable[[], Transform]) and one would write e.g. IndirectTransform(lambda: BboxTranformTo(artist.get_window_extent())).

    (Note, by the way, that some but not all implementations of get_window_extent currently default their renderer arg to figure._cachedRenderer; I think all should, for consistency and ease of use.)

  4. github-actions commented on Nov 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!

  5. added
    keepItems to be ignored by the “Stale” Github Action
    and removed
    status: inactiveMarked by the “Stale” Github Action
    on Nov 19, 2025
  6. prerana2005 commented on Mar 14, 2026

    @prerana2005

    Hi, I'm exploring this issue as part of a GSoC '26 proposal for the Indirect Transforms project. I've been going through _get_xy_transform in text.py and would love to work on this. Happy to take it forward!

  7. amanparganiha commented on Mar 30, 2026

    @amanparganiha
    Contributor

    I'm also exploring this for my GSoC '26 proposal. I've been studying the transform hierarchy (CompositeGenericTransform, BlendedGenericTransform) and Annotation._get_xy() coordinate dispatching. I've also opened PR #31422 to familiarize myself with the codebase.

  8. vaddemallikarjuna24 commented on Apr 7, 2026

    @vaddemallikarjuna24

    Hi! Just a gentle reminder in case this PR was missed.
    Please let me know if any changes are needed. Thank you!

  9. timhoffm commented on Apr 7, 2026

    @timhoffm
    Member

    @vaddemallikarjuna24 What are you talking about? This is an issue not a PR, and no PR is linked.

  10. dikshajangra12918-oss commented on Apr 10, 2026

    @dikshajangra12918-oss
    Contributor

    Hii,
    I noticed the callable case already kind of does lazy resolution - it calls the function at draw time. So I started wondering if it makes sense to pull that pattern out into something like an IndirectTransform class in transforms.py, so other artists could also use it, not just Annotation.

    Is this the right direction? Or is there something I'm missing about why it needs to stay inside_AnnotationBase?

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

    New featurekeepItems to be ignored by the “Stale” Github Action

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions