Etienne,
This may not be useful, but you do not need to actually
draw plots when using fltk.

figure (hf, "visible", "off")
prevents plots being made visible.

Looks like we're on the same page. By the way, apologies, I went ahead and filed a feature request before I saw your reply: https://savannah.gnu.org/bugs/index.php?52185

> Nonetheless, there is no type of 'data'-relative specification. Why? I don't know. It seems that would be useful thing to have.

I wholeheartedly agree :) It would directly solve my original problem and remove the need for that data_annotation() function that I tried to write.

> But I will point out that 'data' isn't probably the best nomenclature for that because there can be multiple axes on a plot, so the question is what "data" are we referring to if the axes are totally different scale and range? So, rather than "data", maybe a type 'axes' makes more sense with some reference to the axes object.

Sure. Honestly, the function that I presented is just something I hacked together in a few minutes so that I can get stuff done; I'm well aware it would have problems with more... "exotic" plot types. If it were to be done more seriously, it would certainly have to be made more generic and flexible with regard to a variety of scenarios.

> It's already set for 'data', but as I see it, it's acting like "normalized" in the plot. So, gnuplot toolkit has a 'data' units option, but it doesn't seem to be working right now.

Oh, interesting. Maybe I should file a separate bug to sort this stuff out.

> What's funny is that your fail-example can be made to work in gnuplot toolkit with the following:

Yep, that's the workaround I was referring to: explicitly overriding the position, i.e. pulling gnuplot out of "auto" mode (or whatever it's called) and specifying coordinates manually. You'll notice that as soon as you do that then gnuplot is not "smart" when it comes to the use of canvas space - when left to its own devices it will fill out as much as the figure space as possible, but that stops as soon as you specify a position manually.

> Anyway, let me know your thoughts on the annotation specification relative to an "axes". Such an internal code addition seems the easiest route to me, i.e., all toolkits have the property.

A thousand times yes, that would make my life so much easier. (I know from experience that this is something that gnuplot supports when operating gnuplot directly, by the way.)

> It seems the bug here is simply that you want the gnuplot plot box position to look similar to the smaller width/height of the FLTK and Qt plots. Correct?

Well, no. gnuplot's behavior with respect to where it draws the axes is perfectly fine and it does an excellent job at using all the available space when left to figure this stuff out on its own. I do not want to change that.

What I would have liked is for the 'position' property of the axes to give a correct answer when using gnuplot, even when it is not set explicitly. But it looks like that's not going to happen.

> There's no way to modify gnuplot manually within the plot and feed back coordinates to the toolkit.

I'm not sure I understand what you mean by that.

octave:1> available_graphics_toolkits
ans =
{
  [1,1] = gnuplot
}

I can only use gnuplot because I am running Octave on a headless machine as part of an automated workflow. (The graphs are written to SVG images, they are not displayed in windows.) The prospect of running a (grossly overkill) X server for the sole purpose of generating image files terrifies me, and it would not end well.

But that's neither here nor there; I guess I'll just pick some appropriate position values, set them explicitly, and call it a day. It's a hacky workaround, but if it works, then so be it.

Thanks for your reply. I suspected as much. To give more context (and at the risk of getting a bit off-topic), here's what I was trying to achieve when I came across this bug:

% Draws an annotation using coordinates referred to the data axes,
% as opposed to normalized figure coordinates.
function h = data_annotation(name, x, y)
        % Normalize coordinates relative to data limits
        x = (x - xlim()(1)) / diff(xlim());
        y = (y - ylim()(1)) / diff(ylim());

        axes_position = get(gca(), 'position');
        axes_x = axes_position(1);
        axes_y = axes_position(2);
        axes_width = axes_position(3);
        axes_height = axes_position(4);

        % Translate normalized axis coordinates to figure coordinates
        x = x * axes_width + axes_x;
        y = y * axes_height + axes_y;

        h = annotation(name, x, y);
endfunction

I suspect that because of the present bug, the function above is impossible to implement correctly when using the gnuplot toolkit, unless one manually sets the axes position in stone before calling the function. Which I don't want to do, but at this point it doesn't look like I have a choice. Any suggestions?

On Debian Sid, octave 4.2.1-4+b1, gnuplot 5.0.7+dfsg1-1:

  octave:1> graphics_toolkit('gnuplot');
  octave:2> fplot(@(x) sin(x), [0 2*pi]);
  octave:3> position = get(gca(), 'position')
  position =

     0.13000   0.11000   0.77500   0.81500

That position vector is wrong. One of the easiest ways to prove that it is wrong is to try to draw an arrow from one corner of the axes to the other:

  octave:4> annotation('arrow', [position(1) position(1) + position(3)], [position(2) position(2) + position(4)]);

The arrow position will be incorrect.

Another sign that something is wrong is the following:

  octave:5> set(gca(), 'xtick', []);
  octave:6> position = get(gca(), 'position')
  position =

     0.13000   0.11000   0.77500   0.81500

The reported position did not change even though the actual axes position did visually change (to fill the space left by the removed ticks). Clearly the position property is out of sync with the actual position of the axes.

I was able to find a workaround: if I manually set the position property to something other than its default value using set(gca(), 'position', ...), then the new axes will accurately follow the new position. The problem is, that's not a good solution for me because I want the axes to automatically adopt the optimal size and position, not set it manually.