Sat 17 Sep 2011 12:03:44 AM UTC, comment #21:
Since there has been no response, I'm closing this.
|
Mon 12 Sep 2011 01:59:48 AM UTC, comment #20:
As the OpenGL backends were introduced (in part) to avoid gnuplot limitations that result in problems such as this one, I'm changing the status to "Wont Fix".
I'll leave it open for now to allow for more discussion.
|
Thu 01 Sep 2011 05:45:56 PM UTC, comment #19:
For Matlab type behavior, please use the FLTK backend.
The problem with the gnuplot backend is well understood by the developers. Several of us have worked on improving this particular aspect, but ultimately gave up (it is much more complicated that it first appears).
The basic problem is there exists no method to reliably determine the textextents when using gnuplot. Some reasonable approximation can be made in common situations, but they fail miserably when using TeX style strings.
Also it is important to understand that gnuplot will often substitute a font it one is requested that it doesn't recognize. In addition, each of gnuplot's terminal types are responsible for the positioningin of text. Meaning x11, wxt, aqua, postscript, pdf, png, gif, etc ... each place the tick labels and axes labels a different distance from the plot box (and that the postion of these labels are not available to us).
For this particular problem, I recommend a work around. Which is to switch the activepositionproperty for each axes to the "outerpostion". This allows gnuplot to handle the details. Take a loot at ...
However, this will not work well when using plotyy.
|
Thu 01 Sep 2011 05:18:04 PM UTC, comment #18:
Thanks Ben, glad you were finally able to hear what I have been saying since #6 about the label placement issue.
For the spacing, which was the main point here, the output is frankly unusable. As a solution I would suggest at least some padding in the table of subplots. This could probably be an accessible property.
More rigorously, there needs to be at least an attempt at evaluating the text extents, notwithstanding the limitations of gnuplot here. It appears currently to be using zero as the extent.
At some stage running this subplot I got a temporary vertical and horezontal line visible as it rendered each subplot. The x1,y1 tickmarks and labels were outside of this crosshair.
This would seem to be the way Mathlab works. My impression from seeing this happen is that the text extent is simple not being taking into account or the way it is evaluated is returning zero in under gnuplot.
As can be seen for the attachments to #4 the fltk plot has wide spacing that easily accommodates the labels etc.
My guess is that the code is not getting the correct values back in evaluating text extents with gnuplot.
If this really is technically impossible (which I doubt) then a decent guess would be better than zero.
|
Thu 01 Sep 2011 03:38:08 PM UTC, comment #17:
I've pushed a change for the ylabel problem.
http://hg.savannah.gnu.org/hgweb/octave/rev/d0dccc6dd4e7
Octave doesn't have control or knowledge of the position or extents of the tick and axes labels produced by gnuplot. Without that info, I don't think a solution to the orignal bug report is possible.
Unless someone can provide a technical approach, I'm inclined to change the status to "Wont Fix", and close this entry.
|
Thu 01 Sep 2011 03:01:18 PM UTC, comment #16:
I found the problem. Consider a simpler case.
In each case, the current axes after calling subplot should be the same as it was prior to subplot. Octave gets this wrong on the first call. On the other hand, Matlab produces the same result each time. With Matlab the ylabel is blue and on the left side since it is applied to pre-exiting axis in each case.
If the "axis" command is not used, then the ylabel shows up on the right side in each case.
This looks like a minor bug in plotyy.m. I'll prepare a changeset.
|
Wed 31 Aug 2011 11:51:05 PM UTC, comment #15:
# demonstrate octave.plotyy() overlay errors with gnuplot
# call this script simple_overlap_err.m
y=x=[1:10];
for rc=[3:6]
subplot (3,3,rc);
axis([0,10,0,10]);
plotyy(x,y,x,y);
title("title");
ylabel("ylabel");
xlabel("xlabel");
end; # for rc
Call this script twice: first call produces the plot with ylabels on the RHS, the second on the LHS.
Maybe that is yet another undocumented feature but it seems inconsistent to me.
If that is expected behaviour please explain why.
(file #23915, file #23916)
|
Wed 31 Aug 2011 11:11:06 PM UTC, comment #14:
A simple example ...
|
Wed 31 Aug 2011 11:01:55 PM UTC, comment #13:
Ben, could you please define what ylabel is supposed to do after a call to plotyy() ? That way I can say in what way I see it differ from whatever the undocumented feature involves and provide an image of what I get and a code snippet as test case.
Does it label the y2 axis in the colour of the y2 tickmarks?
Is the text of the label supposed to be to the left or the right of the axes region?
Is it supposed to stay on the same side if the plotyy call is repeated?
|
Wed 31 Aug 2011 07:51:18 PM UTC, comment #12:
Please provide a graphic of the problem for the FLTK backend, and a short script that will reproduce the same result for us.
The scripts that have been posted, thus far, all work and the output which has been provide indicate the correct result.
|
Wed 31 Aug 2011 07:40:28 PM UTC, comment #11:
> Please stop wasting my time.
Ok, I'll stop.
|
Wed 31 Aug 2011 04:37:51 PM UTC, comment #10:
Please stop wasting my time. At least read what I submit and try to address the issues otherwise you may as well close down bug reporting.
I post a bug against "plotting with gnuplot" and you ask what back-end I'm using.
I report twice that the label is actually MOVING from one side to the other and post code to reproduce it. You tell me it seems OK and it's me not understanding what plotyy() is supposed to do.
None of these oddities are documented so if you want to pretend they are features you'd could deal with that.
It would make more sense to say (or actually document) what it should do than to ask me what I expect.
There is also the issue of the overcrownding and axis labels comming out on top of tickmarks. Frankly this output is an unusable mess.
Are you interested if fixing that or are you intent on pretending nothing is wrong?
If you don't want bug reports shut down public access and keep the bug tracker as your owm private note book.
Octave is a pretty powerful program and has a lot of merit. I'm prepared pay back something to improve it but not waste my time in a futile to and fro of unrelated comments if you don't want to read what is submitted.
|
Wed 31 Aug 2011 01:48:13 PM UTC, comment #9:
I'm not sure you understand what plotyy is supposed to do. It seems to be putting the ylabel correctly, but contrary to your expectations.
I asked you before, can you please show us finished plots or at least mockups of the type of plots you're trying to do? I get the impression you're trying to fit a square peg into a round hole and filing bug reports over the squareness of the peg.
|
Wed 31 Aug 2011 12:13:31 PM UTC, comment #8:
Huh?
I don't know how you normally plot data but I usually like to see the ylabel on YAXIS , not on the other side of the paper.
You also ignore the fact that I also pointed out , that if you redraw it it swaps sides !! (and colour).
[Your second comment about font metrics has absolutely nothing to do with this bug. ]
If you still think ylabel should be on the righthand side please explain why plot() puts it on the left.
x=y=[0:10]
ylabel("ylabel")
plot(x,y)
Help ylabel makes no mention of the "feature". It seems more accident than design.
This is yet another bug in plotyy that suggests it is a quick solution to providing a y2 capability that has not been thoughtfully designed.
I suggested elsewhere that it may make more sense to integrate this in plot(). If not plotyy() needs some bug fixing.
|
Wed 31 Aug 2011 01:36:04 AM UTC, comment #7:
The ylabel is "right" side of each subplot which is correct.
There have been attempts to have Octave handle the font metrics for gnuplot, but they have not been successful (to make things more complicated each gnuplot terminal places the axis ticklabels and axis labels in slightly different positions).
|
Sun 28 Aug 2011 08:23:04 AM UTC, comment #6:
This is not just a gnuplot bug !
Look at the fltk plot our posted. The ylabel is on the WRONG SIDE.
I did not notice this at first since I was replotting my test case. On a subsequent run the ylabel is on the right side but the spacing is still wrong.
In fact this is two bugs. One common to both front ends as noted here. I suspect if you fix this one gnuplot will produce acceptable output although it will be more cramped than fltk.
Comparing your two plots I'd say the spacing you are calculating to pad the separate plots is evaluating to zero in your use of gnuplot.
Both should be easily fixed.
|
Sun 28 Aug 2011 08:10:00 AM UTC, comment #5:
This clearly a difference between the two backends but I'm not sure this can be attributed to gnuplot uncertainly in text extents as I earlier suggested. Such errors tend only to be around 10% in extent.
What I see here is misplacement of successive graphs in the ensemble. Note y2 label is totally on top of next y1 ticmarks.
This suggests that the size and presence of y2 label is not accounted for. I also notice, as it draws, that the layout and plots are up before the y2 labels are added. Spacing would be correct if there was no y2. This again suggests y2 is not taken into account in planning the subplot layout.
Similarly , as I reported, though not in my example plot , xlabel overwrites the next graph's title.
This definitely looks like an octave bug in using gnuplot rather than inaccuracy in gnuplots calculated text extents.
# demonstrate octave.plotyy() overlay errors with gnuplot
y=x=[1:10];
for rc=[3:6]
subplot (3,3,rc);
axis([0,10,0,10]);
plotyy(x,y,x,y);
title("title");
ylabel("ylabel");
xlabel("xlabel");
end; # for rc
|
Sat 27 Aug 2011 06:23:03 PM UTC, comment #4:
Okay, so this appears to be a problem with plotyy and gnuplot. I've retitled the bug accordingly. The fltk backend doesn't have this problem. Attached are the results produced with fltk and gnuplot.
(file #23885, file #23886)
|
Sat 27 Aug 2011 06:20:37 PM UTC, comment #3:
This may be a short-coming in gnuplot . It is known to lack precision in estimation of text dimensions. When using it directly I frequently add some extra space around the legend box , for example to insure the text does not over run. Apparently this is a problem due the wide range of "terminals" of differing capabilities that it supports through a common api.
Is there some property I can set to add some padding around each plot in the subplot array? That would fix (work around) the issue.
thx.
|
Sat 27 Aug 2011 06:12:02 PM UTC, comment #2:
for rc=[3:6]
subplot (3,3,rc);
y=x=[1:10];
axis([0,10,0,10]);
plotyy(x,y,x,y);
ylabel("ylabel");
xlabel("xlabel");
end; # for rc
As per original bug report:
Category: Plotting with gnuplot
|
Sat 27 Aug 2011 03:26:32 PM UTC, comment #1:
Can you please post some sample code that exhibits your problem? I don't see a problem with subplot. Also, tell us if you're using the default gnuplot plotting engine or the new OpenGL engine.
|
Sat 27 Aug 2011 10:21:46 AM UTC, original submission:
using subplot() the plot areas are overlapping.
on 2x2 xlabel is overlapping title of plots in row below by a few pixels.
on 3x3 overlap is worse, xlabel text touches the upper limit of the axis area on the rows below.
similar overlay in horezontal dir with y2label and ylabel and tick marks.
overlap is same row1:row2 as row2:row3 , it is not cumulatively worse but is worse as R,C is increased in subplot().
|