bugGNU Octave - Bugs: bug #34148, Subplots with gnuplot overlap with...

 
 

bug #34148: Subplots with gnuplot overlap with plotyy

Submitter:  None
Submitted:  Sat 27 Aug 2011 10:21:46 AM UTC
   
 
Category:  Plotting with gnuplot Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Wont Fix Assigned to:  bpabbott
Originator Name:  Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 3.4.0
Operating System:  * GNU/Linux Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 17 Sep 2011 12:03:44 AM UTC, comment #21: 

Since there has been no response, I'm closing this.

Ben Abbott <bpabbott>
Group Member
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.

Ben Abbott <bpabbott>
Group Member
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 ...


demo ("subplot", 1)
set (findall (gcf, "type", "axes"), "activepositionproperty", "outerposition")


However, this will not work well when using plotyy.

Ben Abbott <bpabbott>
Group Member
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.

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

Ben Abbott <bpabbott>
Group Member
Thu 01 Sep 2011 03:01:18 PM UTC, comment #16: 

I found the problem. Consider a simpler case.


y = 1:10;
x = y;
figure (1)
clf

subplot (1, 1, 1);
axis ([0, 10, 0, 10])
ca1 = gca ();
ax1 = plotyy (x, y, x, y);
title ('title')
ylabel ('ylabel')
xlabel ('xlabel')

subplot (1, 1, 1)
axis ([0, 10, 0, 10])
ca2 = gca ();
ax2 = plotyy (x, y, x, y);
title ('title')
ylabel ('ylabel')
xlabel ('xlabel')


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.

Ben Abbott <bpabbott>
Group Member
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)

Anonymous
Wed 31 Aug 2011 11:11:06 PM UTC, comment #14: 

A simple example ...


x = 0:0.1:10;
[ax, h1, h2] = plotyy (x, sin(x), x, cos(x));
ylabel ylabel2
axes (ax(1));
ylabel ylabel1
xlabel xlabel
print -dpdfwrite plotyy.pdf
-verbatiim-

I've attached the resulting pdf (plotyy.pdf).

You asked if the ylabel supposed to stay on the same side if the plotyy call is repeated. If plotyy is repeated all axis label should be erased. Which is what happens when I repeat the plotyy command.


(file #23914)

Ben Abbott <bpabbott>
Group Member
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?

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


Ben Abbott <bpabbott>
Group Member
Wed 31 Aug 2011 07:40:28 PM UTC, comment #11: 


> Please stop wasting my time.


Ok, I'll stop.

Jordi Gutiérrez Hermoso <jordigh>
Group Member
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.

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

Jordi Gutiérrez Hermoso <jordigh>
Group Member
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.

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


Ben Abbott <bpabbott>
Group Member
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.

Anonymous
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

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


Jordi Gutiérrez Hermoso <jordigh>
Group Member
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.

Anonymous
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

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

Jordi Gutiérrez Hermoso <jordigh>
Group Member
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().

Anonymous

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #23918:  simple_overlap_err_1.png added by None (8KiB - image/png - uploader mangled the plots, so let's try again.)
file #23919:  simple_overlap_err_2.png added by None (7KiB - image/png - uploader mangled the plots, so let's try again.)
file #23915:  phpUAblXJ added by None (8KiB - application/octet-stream - sample plots to demonstrate label shift)
file #23916:  phpXYk8PJ added by None (7KiB - application/octet-stream - sample plots to demonstrate label shift)
file #23914:  plotyy.pdf added by bpabbott (4KiB - application/pdf)
file #23885:  gnuplot.png added by jordigh (28KiB - image/png)
file #23886:  fltk.png added by jordigh (34KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bpabbott (Posted a comment)
  • -email is unavailable- added by jordigh (Posted a comment)
  • -email is unavailable- added by None (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.

     

    Follow 15 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-09-17 bpabbott Open/ClosedOpen Closed
    2011-09-12 bpabbott StatusNone Wont Fix
    2011-09-01 bpabbott StatusIn Progress None
    2011-09-01 bpabbott StatusWorks For Me In Progress
        Assigned toNone bpabbott
    2011-09-01 None Attached File- Added simple_overlap_err_1.png, #23918
        Attached File- Added simple_overlap_err_2.png, #23919
    2011-08-31 None Attached File- Added phpUAblXJ, #23915
        Attached File- Added phpXYk8PJ, #23916
    2011-08-31 bpabbott Attached File- Added plotyy.pdf, #23914
    2011-08-31 bpabbott StatusNeed Info Works For Me
    2011-08-27 jordigh Attached File- Added gnuplot.png, #23885
        Attached File- Added fltk.png, #23886
        Summarysubplot overcrowding Subplots with gnuplot overlap with plotyy
    2011-08-27 jordigh StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code