bugGNU Octave - Bugs: bug #52184, 'position' axes property value is...

 
 

bug #52184: 'position' axes property value is incorrect when using gnuplot toolkit

Submitter:  Etienne Dechamps <edechamps>
Submitted:  Sat 07 Oct 2017 05:06:18 PM UTC
   
 
Category:  Plotting with gnuplot Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  None Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * 4.2.1 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 07 Oct 2017 11:34:32 PM UTC, comment #10: 

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.

Michael Godfrey <godfrey>
Group Member
Sat 07 Oct 2017 08:55:03 PM UTC, comment #9: 

WRT comment #4:

You can try

xvfb-run -a -s '-screen 0 640x480x24' octave-cli

It works when I run it on my console.

https://en.wikipedia.org/wiki/Xvfb

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Sat 07 Oct 2017 08:10:57 PM UTC, comment #8: 

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

Etienne Dechamps <edechamps>
Sat 07 Oct 2017 07:54:02 PM UTC, comment #7: 

I simply meant what you stated.  There is no way to let gnuplot auto-adjust for minimal whitespace around the plot and then get back from gnuplot the Position that corresponds to.  I think we're going to end up matching what FLTK/Qt do for whitespace if we want Position to be responsive off the bat.

Note there is a related bug I reported a few days ago:

https://savannah.gnu.org/bugs/?52170

I'll post the question of data-relative annotation specification to the discussion list.

Dan Sebald <sebald>
Sat 07 Oct 2017 07:41:32 PM UTC, comment #6: 


> 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.

Etienne Dechamps <edechamps>
Sat 07 Oct 2017 06:56:23 PM UTC, comment #5: 

I'm surprised there is no 'units' specification that allows what you are attempting.  E.g.,:

WITH FLTK TOOLKIT

octave:21> graphics_toolkit fltk
octave:22> figure
octave:23> plot (-2:2,-2:2)
octave:24> h = annotation("line", [0,1], [0,1])
h = -231.34
octave:25> set(h,'units')
[ centimeters | characters | inches | {normalized} | pixels | points ]
octave:26> set(h,'units','points')
octave:27> set(h,'units')
[ centimeters | characters | inches | {normalized} | pixels | points ]


That last 'points' doesn't seem to do anything.  Perhaps that doesn't make sense for a line specification.  Nonetheless, there is no type of 'data'-relative specification.  Why?  I don't know.  It seems that would be useful thing to have.

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.

WITH GNUPLOT TOOLKIT


octave:29> graphics_toolkit gnuplot
octave:30> figure
octave:31> plot (-2:2,-2:2)
octave:32> h = annotation("line", [0,1], [0,1])
h = -274.29
octave:33> set(h,'units')
[ centimeters | {data} | inches | normalized | pixels | points ]


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.

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


graphics_toolkit('gnuplot');
figure
fplot(@(x) sin(x), [0 2*pi]);
position = get(gca(), 'position')
h = annotation('arrow', [position(1) position(1) + position(3)], [position(2) position(2) + position(4)]);
set(gca,'Position',position+[1 0 0 0])
set(gca,'Position',position)


It's as if the Position property doesn't affect anything until it is changed from the default.  That could be fixed probably.  gnuplot makes better use of the full window though.

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.

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?  There's no way to modify gnuplot manually within the plot and feed back coordinates to the toolkit.

Dan Sebald <sebald>
Sat 07 Oct 2017 06:43:43 PM UTC, comment #4: 


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.



Etienne Dechamps <edechamps>
Sat 07 Oct 2017 06:24:46 PM UTC, comment #3: 

Etienne,
Have you tried fltk?

What choices do you see for:
available_graphics_toolkits

The limitations of gnuplot cannot be fixed by Octave.

Michael Godfrey <godfrey>
Group Member
Sat 07 Oct 2017 05:55:20 PM UTC, comment #2: 

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?

Etienne Dechamps <edechamps>
Sat 07 Oct 2017 05:43:35 PM UTC, comment #1: 

I don't know enough about the gnuplot interface, but I suspect this is something that Octave simply cannot control about gnuplot. Gnuplot chooses how and where to draw its axes and legends. Octave maintains its own view of where it thinks the position of these things are, but I don't think it has the ability to influence how they are drawn in gnuplot.

See bug #51465 for another example having to do with the legend.

Mike Miller <mtmiller>
Group Member
Sat 07 Oct 2017 05:06:18 PM UTC, original submission:  

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.

Etienne Dechamps <edechamps>

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by efferre79
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by edechamps (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-02-18 efferre79 Carbon-Copy- Added efferre79

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code