

Hi,
I am using GNU Octave 3.2.4 on Windows XP x64 SP2 with GNU plot 4.4. Unfortunately, I can't upgrade to a newer version of either due to IT restrictions (I don't have admin priviledges either on my machine). I have noticed that when trying to insert a (boxed) legend, made up of a cell array of strings in combination with hold on, the size of the legend is incorrect in the sense that it's far too big compared to the size of the text it's supposed to encase. Here is a simple example that replicates the issue:
x = 0:0.01:10;
plot(x,x);
hold on
plot(x,x.*x);
plot(x,2*x.*x);
legend_str{1}='first line';
legend_str{2}='second line';
legend_str{3}='third line';
legend(legend_str)
legend('boxon')
grid on
This gives the following result in GNU plot:
In my real application, the strings are somewhat longer and the problem is compounded, with the legend taking almost all of the width of the figure. Is this something that can be fixed?
I should also say that I changed the __next_line_color__ function as per this post to overcome the issues with hold on and line colours.
Any suggestions welcome.
Many thanks in advance,
Arnaud


You don't need admin rights to install mingw builds. As long as you can write to a path that has no spaces in, it should be fine. On Monday, 20 February 2012, am304 < [hidden email]> wrote:
> Hi, I am using GNU Octave 3.2.4 on Windows XP x64 SP2 with GNU plot 4.4. Unfortunately, I can't upgrade to a newer version of either due to IT restrictions (I don't have admin priviledges either on my machine). I have noticed that when trying to insert a (boxed) legend, made up of a cell array of strings in combination with hold on, the size of the legend is incorrect in the sense that it's far too big compared to the size of the text it's supposed to encase. Here is a simple example that replicates the issue:
> > x = 0:0.01:10; > plot(x,x); > hold on > plot(x,x.*x); > plot(x,2*x.*x); > legend_str{1}='first line'; > legend_str{2}='second line'; > legend_str{3}='third line';
> legend(legend_str) > legend('boxon') > grid on > > This gives the following result in GNU plot: In my real application, the strings are somewhat longer and the problem is compounded, with the legend taking almost all of the width of the figure. Is this something that can be fixed? I should also say that I changed the
> > __next_line_color__ > > function as per this post to overcome the issues with hold on and line colours. Any suggestions welcome. Many thanks in advance, Arnaud > ________________________________
> View this message in context: Boxed legend not correct size > Sent from the Octave  General mailing list archive at Nabble.com. >  /* andy buckle */
_______________________________________________
Helpoctave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/helpoctave


On Monday, 20 February 2012, Andy Buckle < [hidden email]> wrote: > You don't need admin rights to install mingw builds. As long as you can write to a path that has no spaces in, it should be fine.
> > > > On Monday, 20 February 2012, am304 < [hidden email]> wrote: >> Hi, I am using GNU Octave 3.2.4 on Windows XP x64 SP2 with GNU plot 4.4. Unfortunately, I can't upgrade to a newer version of either due to IT restrictions (I don't have admin priviledges either on my machine). I have noticed that when trying to insert a (boxed) legend, made up of a cell array of strings in combination with hold on, the size of the legend is incorrect in the sense that it's far too big compared to the size of the text it's supposed to encase. Here is a simple example that replicates the issue:
>> >> x = 0:0.01:10; >> plot(x,x); >> hold on >> plot(x,x.*x); >> plot(x,2*x.*x); >> legend_str{1}='first line'; >> legend_str{2}='second line';
>> legend_str{3}='third line'; >> legend(legend_str) >> legend('boxon') >> grid on >> >> This gives the following result in GNU plot: In my real application, the strings are somewhat longer and the problem is compounded, with the legend taking almost all of the width of the figure. Is this something that can be fixed? I should also say that I changed the
>> >> __next_line_color__ >> >> function as per this post to overcome the issues with hold on and line colours. Any suggestions welcome. Many thanks in advance, Arnaud >> ________________________________
>> View this message in context: Boxed legend not correct size >> Sent from the Octave  General mailing list archive at Nabble.com. >> > >  > /* andy buckle */ > Apologies for top posting. Using a mobile device, and quite forgot myself.
 /* andy buckle */
_______________________________________________
Helpoctave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/helpoctave


Thanks for the response. I believe I already have mingw installed. Is there a way to check? I am not sure how this would help with the legend issue though. Sorry if this sounds trivial, I am relatively new to Octave (I am more used to MATLAB).
Thanks again,
Arnaud


On 20 February 2012 21:02, am304 < [hidden email]> wrote:
> Thanks for the response. I believe I already have mingw installed. Is there
> a way to check? I am not sure how this would help with the legend issue
> though. Sorry if this sounds trivial, I am relatively new to Octave (I am
> more used to MATLAB). Thanks again, Arnaud
the mingw toolchain (compilers etc) comes with octave. I only mention
it, as there are alternatives. I assume you have downloaded octave for
windows from sourceforge. these builds do not need admin rights to be
installed.

/* andy buckle */
_______________________________________________
Helpoctave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/helpoctave


Just to update: I moved to GNU Octave 3.6.0 and gnuplot 4.4.4 and that hasn't solved the problem. In fact it's created some more with the labelling of the axes and the display of the grid lines, see my other post).
Trying to put the legend in the nw location also doesn't put it in the top let corner, but somewhere in the middle of the plot (but still at the top). The space it takes (when boxed) remains the same though.
Thanks,
Arnaud


It seems that although the display in gnuplot is wrong, the result when using the print djpg command is correct, so the issue seems to be with how gnuplot displays the results. Is there anywhere that we can report these issues for gnuplot?
Thanks,
Arnaud

Administrator

On Feb 24, 2012, at 6:16 AM, am304 wrote:
> It seems that although the display in gnuplot is wrong, the result when using the print djpg command is correct, so the issue seems to be with how gnuplot displays the results. Is there anywhere that we can report these issues for gnuplot? Thanks, Arnaud
Thanks for the update. It appears the problem is with Gnuplot's windows terminal.
If you have X11 installed, you can try the x11 terminal.
close all
setenv GNUTERM x11
plot (rand (3))
legend ({"first", "second", "third"}, "location", "northwest")
Ben
_______________________________________________
Helpoctave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/helpoctave

Administrator

On Feb 24, 2012, at 6:07 AM, am304 wrote:
> Just to update: I moved to GNU Octave 3.6.0 and gnuplot 4.4.4 and that hasn't solved the problem. In fact it's created some more with the labelling of the axes and the display of the grid lines, see my other post). Trying to put the legend in the nw location also doesn't put it in the top let corner, but somewhere in the middle of the plot (but still at the top). The space it takes (when boxed) remains the same though. Thanks, Arnaud
> View this message in context: Re: Boxed legend not correct size
For Octave 3.6.x, you may be happier using the FLTK toolkit for graphics.
close all
graphics_toolkit fltk
plot (rand (3))
legend ({"first", "second", "third"}, "location", "northwest")
Ben
_______________________________________________
Helpoctave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/helpoctave


Thanks. That indeed fixes all the issues I have been having with gnuplot, namely legend display, ylabel and zalbel text orientation, and grid display. However, It does introduce another substantial issue. Something that looks like this with gnuplot (which is correct):
looks like this with fltk (which is incorrect):
I don't know if this has anything to do with the fact that the xaxis is displayed using datetick, but that's the reason why I have been using gnuplot rather than fltk.
Thanks again,
Arnaud

Administrator

On Feb 24, 2012, at 8:58 AM, am304 wrote:
> Thanks. That indeed fixes all the issues I have been having with gnuplot, namely legend display, ylabel and zalbel text orientation, and grid display. However, It does introduce another substantial issue. Something that looks like this with gnuplot (which is correct): looks like this with fltk (which is incorrect): I don't know if this has anything to do with the fact that the xaxis is displayed using datetick, but that's the reason why I have been using gnuplot rather than fltk. Thanks again, Arnaud
The fltk toolkit uses OpenGL which is single precision. I've seen examples where the xdata or ydata range is small enough to produce this sort of effect. But the displayed ranges are quite large. So this shouldn't be a problem.
Can you provide a simple example that I can reproduce ?
Ben
_______________________________________________
Helpoctave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/helpoctave


The following sort of gives an idea. I think the problem is to do with the NaN present in the data, maybe in conjunction with the use of dates.
xdata = datenum(2012,02,22,18,00,00):0.01:now;
ydata = sin(xdata);
ydata(2:2:end) = NaN;
plot(xdata(~isnan(ydata)),ydata(~isnan(ydata)))
datetick('x',13)
Which gives with fltk:
and with gnuplot:
Thanks,
Arnaud

Administrator

On Feb 24, 2012, at 9:40 AM, am304 wrote:
Thanks. The problem is with single precision.
median (diff (xdata) ./ median (xdata))
ans = 1.3607e08
eps single
ans = 1.1921e07
You can work around it by ...
xtick = get (gca, "xtick");
xticklabel = get (gca, "xticklabel");
limits = axis ()  median (xdata) * [1, 1, 0, 0];
xtick = xtick  median (xdata);
xdata = xdata  median (xdata);
plot (xdata (~isnan (ydata)), ydata (~isnan (ydata)))
set (gca, "xtick", xtick, "xticklabel", xticklabel)
axis (limits)
Ben
_______________________________________________
Helpoctave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/helpoctave


Thanks a lot, it seems like we're getting nearer to a solution!! However, by changing the xdata (xdata = xdata  median (xdata);), the displayed date & time will be wrong when plotting, will it not?
Arnaud

Administrator

On Feb 24, 2012, at 10:35 AM, am304 wrote:
> Thanks a lot, it seems like we're getting nearer to a solution!! However, by
> changing the xdata (xdata = xdata  median (xdata);), the displayed date &
> time will be wrong when plotting, will it not?
>
> Arnaud
That's why I changed the xticklabel
Ben
_______________________________________________
Helpoctave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/helpoctave


Thanks, I managed to implement it. It was a bit tricky to do with the actual data because I am plotting in a for loop with hold on, so I needed to figure out at which point to get the ticks, replot and set the axes properties. Anyway, I got there in the end.
Thanks again,
Arnaud

