You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[ENH]: Position artists (particularly Annotations) relative to multiple other artists #22223
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.
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.)
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!
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!
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.
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?
Activity
story645 commentedon Jan 13, 2022
I think I 've wanted a variant of this for a while; adding a text labeling API to FancyArrowPatch to get tikz like labeling
----->
label
maybe |--a1--[bbox]--a2-->
jklymak commentedon Jan 13, 2022
I think this positioning style is only supported for annotations, so far as I know?
anntzer commentedon Jan 13, 2022
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_extentcurrently default theirrendererarg tofigure._cachedRenderer; I think all should, for consistency and ease of use.)github-actions commentedon Nov 19, 2025
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!
prerana2005 commentedon Mar 14, 2026
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!
amanparganiha commentedon Mar 30, 2026
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.
vaddemallikarjuna24 commentedon Apr 7, 2026
Hi! Just a gentle reminder in case this PR was missed.
Please let me know if any changes are needed. Thank you!
timhoffm commentedon Apr 7, 2026
@vaddemallikarjuna24 What are you talking about? This is an issue not a PR, and no PR is linked.
dikshajangra12918-oss commentedon Apr 10, 2026
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?
Add IndirectTransform for lazy coordinate resolution