bugGNU Octave - Bugs: bug #52185, Make it possible to position...


bug #52185: Make it possible to position annotations relative to axes or data

Submitted by:  Etienne Dechamps <edechamps>
Submitted on:  Sat 07 Oct 2017 08:00:13 PM UTC  
Category: PlottingSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Feature Request
Status: ConfirmedAssigned to: None
Originator Name: Open/Closed: Open
Release: devOperating System: Any

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


Thu 04 Jan 2018 07:46:04 PM UTC, comment #3:

This is a known problem in Matlab as well and is related to how they chose to implement Annotation objects. Try an Internet search for "matlab annotation data units" and you will see lots of solutions. This Stack Overflow article was reasonable: https://stackoverflow.com/questions/11499370/how-to-plot-arrow-onto-a-figure-in-matlab

One of the solutions is the one suggested here of changing the parent to the axes. The most general seems to be using a function that Matlab provides to convert between "data" coordinates and "normalized" coordinates.

Rik <rik5>
Project Administrator
Mon 09 Oct 2017 11:24:52 AM UTC, comment #2:


The simplest solution I can think of is to add listeners to the axes properties:

Pantxo Diribarne <pantxo>
Project Member
Sun 08 Oct 2017 10:37:33 AM UTC, comment #1:

I discovered the following workaround which (almost) does what I want:

Indeed, by default, annotations get created in a separate "implicit" axes object that spans the entire figure. Changing the annotation to use a different axes as its parent changes its coordinate system to the data coordinate system of the specified axes, and voilà.

The downside is, when using arrows (for example), everything becomes relative to the data coordinate system, including the drawing of the arrowhead. This means, for example, that if the axes are non-square (or worse, use a log scale), the arrowhead will be deformed. This is probably not a problem for line annotations, however.

Etienne Dechamps <edechamps>
Sat 07 Oct 2017 08:00:13 PM UTC, original submission:

This feature request is a spin-off from the discussion in https://savannah.gnu.org/bugs/index.php?52184

Currently, https://www.gnu.org/software/octave/doc/v4.0.3/Plot-Annotations.html#index-annotation states:

> coordinates are interpreted using the "units" property of the annotation object. The default is "normalized", which means the lower left hand corner of the figure has coordinates ‘[0 0]’ and the upper right hand corner ‘[1 1]’.

To me this makes this functionality annoying to use, because I use annotations to point to specific features in the data that I'm plotting (e.g. using arrows). There's no easy way to make that work in a clean, reliable way, because the annotation is positioned relative to the figure, not the axes, which means that any changes to the position of the axes (or other unrelated formatting changes) will invalidate the annotations, making them brittle.

(I tried to write a custom function to fill that gap, but it turns out that's more difficult than it sounds - see bug #52184 linked above.)

It would make sense to have a unit where [0 0] is the bottom left corner of the axes (not the figure), and [1 1] is the top right corner of the axes.

What would be even better (at least for my use case) is to have a unit which is relative to the actual data limits of the axes themselves (i.e. the coordinates are expressed in terms of the data itself). However, as Dan Sebald rightly pointed out in the other thread, that might be tricky when it comes to more complicated plots.

Strangely enough, as Dan also noticed, it turns out that there is an (undocumented) "data" unit type available (and set by default) for annotations, but only when the gnuplot toolkit is used:

It doesn't seem to work, however - it behaves the same as "normalized".

Etienne Dechamps <edechamps>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by pantxo (Posted a comment)
  • -unavailable- added by edechamps (Commentators from original bug #52184)
  • -unavailable- added by edechamps (Commentators from original bug #52184)
  • -unavailable- added by edechamps (Commentators from original bug #52184)
  • -unavailable- added by edechamps (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 04 Jan 2018 07:46:04 PM UTCrik5StatusNone=>Confirmed
    Sat 07 Oct 2017 08:02:48 PM UTCedechampsCarbon-Copy-=>Added sebald
      Carbon-Copy-=>Added godfrey
      Carbon-Copy-=>Added mtmiller

    Back to the top

    Powered by Savane 3.1-cleanup1