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

 
 

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

Submitted by:  Etienne Dechamps <edechamps>
Submitted on:  Sat 07 Oct 2017 05:06:18 PM UTC  
 
Category: Plotting with gnuplotSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Incorrect Result
Status: NoneAssigned to: None
Originator Name: Open/Closed: Open
Release: 4.2.1Operating System: GNU/Linux

Add a New Comment(Rich Markup)
   

You are not logged in

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

 

(Jump to the original submission 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>
Project 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

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

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:

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:

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>
Project 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:

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>
Project Administrator
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:

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:

The arrow position will be incorrect.

Another sign that something is wrong is the following:

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 File(s):
   
   
Comment:
   

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 dasergatskov (Posted a comment)
  • -unavailable- added by sebald (Posted a comment)
  • -unavailable- added by godfrey (Posted a comment)
  • -unavailable- added by mtmiller (Posted a comment)
  • -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):

     

     

    No Changes Have Been Made to This Item

    Back to the top


    Powered by Savane 3.1-cleanup1