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