gnuplot-beta Mailing List for gnuplot (Page 18)

I don't know anything about this code, so feel free to tell me 
I'm misdirected but...

In ConsoleGetch(), _get_osfhandle is used on stdin. MS cautions 
[1] this might not be valid, and ConsoleGetch() does not check 
h!=-2. GetStdHandle or CreateFile [2] might be a better choice?

MsgWaitForMultipleObjects is described as a "very tricky" API 
[3]. Although nothing else seems to fall afoul of [4]'s 
recommendations, I don't know why WaitForSingleObject isn't used 
instead, or just plain ReadFile. MS notes fread locks out other
threads [5]. Is the writer ever another thread?

As an incidental note, pipes created from cmd like in bug 2412 
appear to be anonymous pipes and those do not support 
asynchronous read/write. [6] I don't think this matters here, 
but I mention it in case anybody thought they were going to get 
clever.

[1] https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/get-osfhandle?view=msvc-160
[2] https://docs.microsoft.com/en-us/windows/console/console-handles
[3] https://docs.microsoft.com/en-us/archive/blogs/larryosterman/things-you-shouldnt-do-part-4-msgwaitformultipleobjects-is-a-very-tricky-api
[4] https://devblogs.microsoft.com/oldnewthing/20050217-00/?p=36423
[5] https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/fread?view=msvc-160
[6] https://docs.microsoft.com/en-us/windows/win32/ipc/anonymous-pipe-operations

(Dropped CCs because this isn't about the Python problem anymore.)

Ethan A Merritt <me...@uw...> said (on 2021/06/19):
> ...
> My understanding is that this is a known problem when combining specifically
> gnuplot version 5.4 and Windows version 10.
> 
> Issue tracker here
>    https://sourceforge.net/p/gnuplot/bugs/2412/

You are operating on Windows 10?
I had hoped you would get a response from someone more familiar with
Windows than I am, but it seems rather quiet here lately.

My understanding is that this is a known problem when combining specifically
gnuplot version 5.4 and Windows version 10.

Issue tracker here
   https://sourceforge.net/p/gnuplot/bugs/2412/

There is a suggestion there that reverting commit 651af626
may fix the problem, or at least return it to the same behavior
as gnuplot 5.2.   If you are able to build gnuplot from the
git source and confirm that reverting that commit works, that
would be very useful information.

    best,

	Ethan


On Thursday, 17 June 2021 02:48:15 PDT hua...@si... wrote:
> Dear developers of gnuplot,First I want to thank you very much for developing such powerful tool.
> I use gnuplot 5.4 in my own python program to check the results of some searching process.
> the related code is like follows:
> from subprocess import *  gnuplot= Popen(r"C:/Progra~1/gnuplot/bin/wgnuplot_pipes.exe", stdin = PIPE, stderr=PIPE,stdout=PIPE)  gnuplot.stdin.write(b"set terminal windows \n")  gnuplot.stdin.write(b"plot(sin(x)) \n")  gnuplot.stdin.flush()
> input('Press the Return key to quit: ')  #pause gnuplot.stdin.close()  
> In the above code, after Popen, the main gnuplot window is successfully launched.However, there is no any response for the next instructions, and nothing has happened.My Python version is 3.8.5
> So how to solve the problem ?
> Best regards,Wendong 
> 

Dear developers of gnuplot,First I want to thank you very much for developing such powerful tool.
I use gnuplot 5.4 in my own python program to check the results of some searching process.
the related code is like follows:
from subprocess import *  gnuplot= Popen(r"C:/Progra~1/gnuplot/bin/wgnuplot_pipes.exe", stdin = PIPE, stderr=PIPE,stdout=PIPE)  gnuplot.stdin.write(b"set terminal windows \n")  gnuplot.stdin.write(b"plot(sin(x)) \n")  gnuplot.stdin.flush()
input('Press the Return key to quit: ')  #pause gnuplot.stdin.close()  
In the above code, after Popen, the main gnuplot window is successfully launched.However, there is no any response for the next instructions, and nothing has happened.My Python version is 3.8.5
So how to solve the problem ?
Best regards,Wendong 

Dear Ethan,

thanks for responding four orders of magnitude faster than me.

No, there were no test cases in your initial mail. I would
be very interest to see my implementation fail. My newly
added tests vary gamma/sigma from 1e-180 to 1e+180. Are the
problematic values sparse in this interval? Or do the
problems only arise for sigma != 1?

Anyway, it will be much better to have an algorithm that
is proven to converge. Thanks for sharing your code. I could
adapt it easily, but I am even more glad to accept your offer
that you submit the necessary changes to libcerf as a merge
request. I will then release 1.16 within days.

Best regards, Joachim

Joachim:

It is good to hear that you are looking into this.
It was pretty easy to trigger the non-convergence error from gnuplot;
did I not send test cases?  
Testing these functions in gnuplot is really easy because you can
sample any desired domain in the complex plane (or in this case [sigma,gamma])
with a single command and plot the result.  Glitches or non-convergence or
outright errors and crashes show up immediately.
Sample plots using functions from libcerf are shown here:
    http://gnuplot.sourceforge.net/demo_5.5/cerf.html

Some time after I sent you that original note, I went ahead and re-implemented
the function directly in gnuplot.  I attach the code to this mail.
Note that it uses a different optimization algorithm (regula falsi)
that unlike the code in libcerf at that time is guaranteed to converge.

This code is from the file libcerf.c in the gnuplot project git repository.
You are welcome to adapt it for inclusion in libcerf, or I would be
willing to do so myself and contribute it.

	best regards,

		Ethan


On Thursday, 10 June 2021 07:18:03 PDT Joachim Wuttke wrote:
> Dear Ethan,
> 
> thank you very much for the kind mail you wrote me more than a year ago.
> 
> Today, finally, I looked into the issue.  I wrote a new test that computes
> voigt_hwhm for 100'000 different ratios gamma/sigma.  As expected, the Newton
> algorithm did not fail a single time.  The deviation of the final result from
> the initial estimate is always smaller then 1E-2.  The cases I had guarded
> with messages to stderr and an exit statement will never happen.  Therefore
> I converted them to assert statements.  These improvements are available
> in the freshly released v1.15.
> 
> Sorry for not answering earlier.
> 
> Kind greetings, Joachim
> 
> 
> 
> On 25/02/2020 20.03, Ethan A Merritt wrote:
> > In response to a gnuplot feature request, I added a wrapper in
> > gnuplot to find the width of the Voight profile by calling libcerf function
> > voigt_hwhm().
> > 
> > However on further evaluation this has turned out to be problematic.
> > The current libcerf source for this function deals badly with out-of-range
> > input.  It prints to stderr (problematic by itself) and then either
> > - returns an incorrect value
> > - calls exit(-1)
> > 
> > A call to exit() from a library routine is almost never a good thing to 
> do,
> > since it prevents error-handling and possible recovery by the calling
> > program.  Limiting error reporting to a message on stderr also prevents
> > detection and recovery by the calling program.
> > 
> > I suggest that it would be preferable to return NaN whenever the
> > input is out of range or the function does not converge.
> > 
> > Alternatively libcerf could provide an error-check routine or status variable,
> > but then you would run into issues of thread-safety and so on.
> > 
> > I am hoping that the libcerf function can be improved in a subsequent
> > version, but for now I will consider implementing equivalent code
> > directly in gnuplot.
> > 
> > 	Ethan
> > 
> > 
> 
> 


-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742

Dear Ethan,

thank you very much for the kind mail you wrote me more than a year ago.

Today, finally, I looked into the issue.  I wrote a new test that computes
voigt_hwhm for 100'000 different ratios gamma/sigma.  As expected, the Newton
algorithm did not fail a single time.  The deviation of the final result from
the initial estimate is always smaller then 1E-2.  The cases I had guarded
with messages to stderr and an exit statement will never happen.  Therefore
I converted them to assert statements.  These improvements are available
in the freshly released v1.15.

Sorry for not answering earlier.

Kind greetings, Joachim



On 25/02/2020 20.03, Ethan A Merritt wrote:
> In response to a gnuplot feature request, I added a wrapper in
> gnuplot to find the width of the Voight profile by calling libcerf function
> voigt_hwhm().
> 
> However on further evaluation this has turned out to be problematic.
> The current libcerf source for this function deals badly with out-of-range
> input.  It prints to stderr (problematic by itself) and then either
> - returns an incorrect value
> - calls exit(-1)
> 
> A call to exit() from a library routine is almost never a good thing to 
do,
> since it prevents error-handling and possible recovery by the calling
> program.  Limiting error reporting to a message on stderr also prevents
> detection and recovery by the calling program.
> 
> I suggest that it would be preferable to return NaN whenever the
> input is out of range or the function does not converge.
> 
> Alternatively libcerf could provide an error-check routine or status variable,
> but then you would run into issues of thread-safety and so on.
> 
> I am hoping that the libcerf function can be improved in a subsequent
> version, but for now I will consider implementing equivalent code
> directly in gnuplot.
> 
> 	Ethan
> 
> 

Release 5.4.2 is now out

Source tarball

    https://sf.net/projects/gnuplot/files/gnuplot/5.4.2/gnuplot-5.4.2.tar.gz

Release Notes

    http://gnuplot.sourceforge.net/ReleaseNotes_5_4_2.html

The release contains lots of little fixes.  The biggest one from my
perspective is that the single-threaded version of the wxt terminal
is now usable again under linux.  Also fixed is the problem that
"set term qt persist" could leave zombie gnuplot_qt processes.

On the other hand, there are known issues under Windows 10
    Piped command input does not work reliably (Bugs #2204 #2412)
    Export to EMF file from toolbar may not work
So Windows 10 users may want to stick with version 5.2 for now.
When these problems are fixed I figure to put out a version 5.4.3
immediately that may be relevant only to Windows users.

	happy gnuplotting,

		Ethan 

Release 5.4.2 is now out

Source tarball

    https://sf.net/projects/gnuplot/files/gnuplot/5.4.2/gnuplot-5.4.2.tar.gz

Release Notes

    http://gnuplot.sourceforge.net/ReleaseNotes_5_4_2.html

The release contains lots of little fixes.  The biggest one from my
perspective is that the single-threaded version of the wxt terminal
is now usable again under linux.  Also fixed is the problem that
"set term qt persist" could leave zombie gnuplot_qt processes.

On the other hand, there are known issues under Windows 10
    Piped command input does not work reliably (Bugs #2204 #2412)
    Export to EMF file from toolbar may not work
So Windows 10 users may want to stick with version 5.2 for now.
When these problems are fixed I figure to put out a version 5.4.3
immediately that may be relevant only to Windows users.

	happy gnuplotting,

		Ethan 

I have placed a tarball of version 5.4.2 SourceForge for testing:

https://sf.net/projects/gnuplot/files/gnuplot/testing/gnuplot-5.4.2beta.tar.gz

Known issue:
    Piped command input does not work reliably under Windows 10

Have I described this problem correctly?  

The discussion under Bug #2412 suggests that it can be fixed
by reverting commit 651af6267b0270a71c6e0c0c2345f2c01a68eea6
Would it be possible to do that revert for the 5.4.2 release
and note that the problem (slow response) in Bug #2204 still
needs a permanent fix?


	cheers,
		Ethan 

On 3/30/2021 8:18 PM, Ethan A Merritt wrote:
> On Tuesday, 30 March 2021 16:35:36 PDT m sutton wrote:
>> Hi all,
>>
>> Here is the script
>>
>> set yrange [-2:2]
>> set y2tics -1,1,1
>> set y2tics add ("top" 1,"middle" 0, "bottom" -1)
>>
>> plot sin(x)
>>
>>
>>
>>
>>
>> The commands place the desired y2axis tics in V5.2.8 and
>>        earlier.  However, I don't get any y2axis tics in V5.4.1 with
>>        either the X11 or QT terminals.  I do get this warning message
>>        "warning: y2 axis range undefined or overflow".
>>
>> show y2range yields:
>>
>>
>> set y2range [ * : * ] noreverse writeback  # (currently
>>          [1.00000e+308:-1.00000e+308] )
> You have no data or plot displayed to y2, and no range set,
> so the error message is correct.

This construct has worked for a long time.  I just wanted to make sure
something wasn't broken as I upgrade my plotting scripts to V5.4.

>
>> What am I missing?
> Either
>      plot sin(x) axes x1y2       # y1 axis is not used at all; autoscale y2
> or
>      set link y2                 # y2 replicates range and scaling from y1
>      plot sin(x)
>
>
My initial thought was to explicitly set y2range, but the set link y2
looks to be more flexible.

Thanks,

MikeS

On Tuesday, 30 March 2021 16:35:36 PDT m sutton wrote:
> Hi all,
> 
> Here is the script
> 
> set yrange [-2:2]
> set y2tics -1,1,1
> set y2tics add ("top" 1,"middle" 0, "bottom" -1)
> 
> plot sin(x)
> 
> 
> 
> 
> 
> The commands place the desired y2axis tics in V5.2.8 and
>       earlier.  However, I don't get any y2axis tics in V5.4.1 with
>       either the X11 or QT terminals.  I do get this warning message
>       "warning: y2 axis range undefined or overflow".
> 
> show y2range yields:
> 
> 
> set y2range [ * : * ] noreverse writeback  # (currently
>         [1.00000e+308:-1.00000e+308] )

You have no data or plot displayed to y2, and no range set,
so the error message is correct.
 
> What am I missing?

Either 
    plot sin(x) axes x1y2       # y1 axis is not used at all; autoscale y2
or
    set link y2                 # y2 replicates range and scaling from y1
    plot sin(x)


	Ethan
> 
> Regards,
> 
> MikeS
> 
> 
> 


-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hi all,</p>
    <p>Here is the script</p>
    <blockquote>
      <p><font face="Courier New, Courier, monospace">set yrange [-2:2]<br>
          set y2tics -1,1,1<br>
          set y2tics add ("top" 1,"middle" 0, "bottom" -1)<br>
          <br>
          plot sin(x)<br>
        </font></p>
    </blockquote>
    <p><br>
    </p>
    <p>The commands place the desired y2axis tics in V5.2.8 and
      earlier.  However, I don't get any y2axis tics in V5.4.1 with
      either the X11 or QT terminals.  I do get this warning message
      "warning: y2 axis range undefined or overflow".</p>
    show y2range yields:<br>
    <blockquote>
      <p>set y2range [ * : * ] noreverse writeback  # (currently
        [1.00000e+308:-1.00000e+308] )</p>
    </blockquote>
    <p>What am I missing?</p>
    <p>Regards,</p>
    <p>MikeS</p>
    <p><br>
    </p>
  </body>
</html>

On Thu, 25 Mar 2021, Mojca Miklavec wrote:

> On Wed, 24 Mar 2021 at 00:42, Allin Cottrell wrote:
>>
>> Just wondering: has anyone produced a Mac package of gnuplot
>> targetting OS 11 ("Big Sur") with M1 processor?
>
> There is a package inside package managers (for example in MacPorts, I
> guess it's present in others as well), but that probably doesn't
> count?
> (There might be some issues with wx, but I need to check.)

There are issues with wx. I've built wxWidgets 3.0.5 for arm64, but 
I had to drop the dataObject module because it calls on QuickTime 
APIs, which are removed in macOS 11. And that means that I had to 
hack the gnuplot wxterm code to disable copy-to-clipboard, which 
depends on dataObject. There may be a way of performing surgery on 
dataObject but I haven't attempted that yet.

So I now have an arm64 build of gnuplot 5.4.1 with wx, but I don't 
have access to an M1 Mac so I don't know yet if it actually works.

Allin Cottrell

On Wednesday, 24 March 2021 22:48:34 PDT Mojca Miklavec wrote:
> On Wed, 24 Mar 2021 at 00:42, Allin Cottrell wrote:
> >
> > Just wondering: has anyone produced a Mac package of gnuplot
> > targetting OS 11 ("Big Sur") with M1 processor?
> 
> There is a package inside package managers (for example in MacPorts, I
> guess it's present in others as well), but that probably doesn't
> count?
> (There might be some issues with wx, but I need to check.)
> 
> I tried to create a nice standalone .app years ago, but the fact that
> this requires the terminal to start makes it somewhat annoying for
> bundling.
> (I would find it much easier to bundle it if there was some wx or
> qt-based simplistic terminal available as well.)

Not sure I understand.

You mean run you would like to run gnuplot from, e.g., qterminal
instead of xterm or whatever terminal emulator you have now?
I think it might even be possible to have "set term qt widget <id>"
direct the plot output to a tab of qterminal, but I don't have any
idea how to determine what the widget id would be.

If svg output is acceptable, you can definitely do this using
domterm and telling gnuplot "set term domterm".  For that matter
there's a qt version of domterm and I have used it to run gnuplot
with output back to the window it is running in.
So yeah, it's possible.

	Ethan

> I know there are workarounds, but I never found the existing bundle
> particularly friendly to use, so I keep using the packager where it's
> also a lot easier to keep the software up to date.
> 
> Mojca
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 


-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742

On Wed, 24 Mar 2021 at 00:42, Allin Cottrell wrote:
>
> Just wondering: has anyone produced a Mac package of gnuplot
> targetting OS 11 ("Big Sur") with M1 processor?

There is a package inside package managers (for example in MacPorts, I
guess it's present in others as well), but that probably doesn't
count?
(There might be some issues with wx, but I need to check.)

I tried to create a nice standalone .app years ago, but the fact that
this requires the terminal to start makes it somewhat annoying for
bundling.
(I would find it much easier to bundle it if there was some wx or
qt-based simplistic terminal available as well.)
I know there are workarounds, but I never found the existing bundle
particularly friendly to use, so I keep using the packager where it's
also a lot easier to keep the software up to date.

Mojca

Just wondering: has anyone produced a Mac package of gnuplot 
targetting OS 11 ("Big Sur") with M1 processor?

I have need of such, but would be glad to piggy-back if there's 
something already available. If not, I'll see what I can come up 
with.

-- 
Allin Cottrell
Department of Economics
Wake Forest University

On Tuesday, 2 March 2021 15:36:12 PST m sutton wrote:
> On 2/24/2021 11:59 PM, Ethan A Merritt wrote:
> > On Wednesday, 24 February 2021 18:50:51 PST m sutton wrote:
> >> Hi All,
> >>
> >> I have used the X11 terminal forever.  I'm looking to use the Qt
> >> terminal with my switch to version 5.4.
> >>
> >> One thing I can't seem to do is set the default plot window size. With
> >> X11 you could do this through the Xresource mechanism.
> >>
> >> I can set it with the 'set term qt' command, but I would like to be able
> >> to set in the Qt settings dialog.  Then it could be saved with the settings.

> > I do this by setting the environmental variable GNUTERM
> > in my login profile:
> >
> >      setenv GNUTERM "qt size 700,440 font 'ArnoPro,12'"
> >
> > 	Ethan
> 
> I guess I didn't realize the GNUTERM could contain terminal options. 
> Until now I never had the need to have options in GNUTERM.
> 
> 
> >
> >> I also noticed that the 'set term qt' command doesn't support a
> >> rounded/norounded option for line drawing.  This can only be done via
> >> the Qt settings dialog.
> >>
> >> So here is my idea.  Add window width and height inputs to the Qt
> >> settings dialog to set a default terminal size. Add rounded/norounded
> >> (aka butt) option to the 'set term qt' command.

> Any thoughts on extending the 'set term qt' to have options like
> rounded/norounded and antialias on/off capability?  I would really like
> to set these on the fly without my users having to open the settings dialog.

Only that it would be harder than you might think.  Remember that there
are two separate programs involved.  Command line input goes to gnuplot
but the display is being managed by gnuplot_qt, which looks at the 
saved settings in ~/.config/gnuplot_qtrc and changes made via the dialog.

	Ethan   

On 2/24/2021 11:59 PM, Ethan A Merritt wrote:
> On Wednesday, 24 February 2021 18:50:51 PST m sutton wrote:
>> Hi All,
>>
>> I have used the X11 terminal forever.  I'm looking to use the Qt
>> terminal with my switch to version 5.4.
>>
>> One thing I can't seem to do is set the default plot window size. With
>> X11 you could do this through the Xresource mechanism.
>>
>> I can set it with the 'set term qt' command, but I would like to be able
>> to set in the Qt settings dialog.  Then it could be saved with the settings.
> I do this by setting the environmental variable GNUTERM
> in my login profile:
>
>      setenv GNUTERM "qt size 700,440 font 'ArnoPro,12'"
>
> 	Ethan

I guess I didn't realize the GNUTERM could contain terminal options. 
Until now I never had the need to have options in GNUTERM.


>
>> I also noticed that the 'set term qt' command doesn't support a
>> rounded/norounded option for line drawing.  This can only be done via
>> the Qt settings dialog.
>>
>> So here is my idea.  Add window width and height inputs to the Qt
>> settings dialog to set a default terminal size. Add rounded/norounded
>> (aka butt) option to the 'set term qt' command.
Any thoughts on extending the 'set term qt' to have options like
rounded/norounded and antialias on/off capability?  I would really like
to set these on the fly without my users having to open the settings dialog.

MikeS

On Wednesday, 24 February 2021 18:50:51 PST m sutton wrote:
> Hi All,
> 
> I have used the X11 terminal forever.  I'm looking to use the Qt
> terminal with my switch to version 5.4.
> 
> One thing I can't seem to do is set the default plot window size. With
> X11 you could do this through the Xresource mechanism.
> 
> I can set it with the 'set term qt' command, but I would like to be able
> to set in the Qt settings dialog.  Then it could be saved with the settings.

I do this by setting the environmental variable GNUTERM
in my login profile:

    setenv GNUTERM "qt size 700,440 font 'ArnoPro,12'"

	Ethan

> 
> I also noticed that the 'set term qt' command doesn't support a
> rounded/norounded option for line drawing.  This can only be done via
> the Qt settings dialog.
> 
> So here is my idea.  Add window width and height inputs to the Qt
> settings dialog to set a default terminal size. Add rounded/norounded
> (aka butt) option to the 'set term qt' command.
> 
> If these ideas seem worthwhile, I'm willing to work on coding it up.
> 
> MikeS

On Wednesday, 24 February 2021 19:08:45 PST gnu...@li... wrote:
> Ethan A Merritt <me...@uw...> writes:
> 
> > The one combination I do know how to use, I remember by thinking of it as
> > "place the bottom/top left/right corner of the key at position x,y"
> > You can use any coordinate for the x,y position so it works to place the
> > key inside or outside of the plot.
> >
> > In your case would be something like
> >
> >   set key bottom right at graph 1.0, 1.0
> 
> That works! Thank you very much. Some sort of note in the docs would be
> good. Should I send out a patch?


Sure.
	Ethan

Hi All,

I have used the X11 terminal forever.  I'm looking to use the Qt
terminal with my switch to version 5.4.

One thing I can't seem to do is set the default plot window size. With
X11 you could do this through the Xresource mechanism.

I can set it with the 'set term qt' command, but I would like to be able
to set in the Qt settings dialog.  Then it could be saved with the settings.

I also noticed that the 'set term qt' command doesn't support a
rounded/norounded option for line drawing.  This can only be done via
the Qt settings dialog.

So here is my idea.  Add window width and height inputs to the Qt
settings dialog to set a default terminal size. Add rounded/norounded
(aka butt) option to the 'set term qt' command.

If these ideas seem worthwhile, I'm willing to work on coding it up.

MikeS

On Wednesday, 24 February 2021 10:49:52 PST Dima Kogan wrote:
> Hi.
> 
> I'd like a plot with the legend sitting outside the plot, above the
> top-right. Like this:
> 
>             window
> ---------------------------------
> |                               |
> |                               |
> |                               |
> |                     legend    |
> |  -------------------------    |
> |  |                       |    |
> |  |                       |    |
> |  |         plot          |    |
> |  |                       |    |
> |  |                       |    |
> |  -------------------------    |
> |                               |
> |                               |
> |                               |
> ---------------------------------

I personally have never understood the keywords associated with key placement.

The one combination I do know how to use,  I remember by thinking of it as
    "place the bottom/top left/right corner of the key at position x,y"
You can use any coordinate for the x,y position so it works to place the
key inside or outside of the plot.

In your case would be something like

         set key bottom right at graph 1.0, 1.0

I.e, place the bottom right corner of the key just above the top right corner of the plot.

	Ethan



> 
> 
> If we set a square aspect ratio, then the plot doesn't fill the window,
> and there's a lot of empty space. This isn't a problem in itself (and
> gnuplot doesn't control the window size, so it can't "fix" it), but it
> looks like the legend attaches itself to the corner of the window
> instead of the corner of the plot, which looks very strange: there's a
> huge gap between the plot and the legend. I get this:
> 
> 
>             window
> ---------------------------------
> |                         legend|
> |                               |
> |                               |
> |                               |
> |  -------------------------    |
> |  |                       |    |
> |  |                       |    |
> |  |         plot          |    |
> |  |                       |    |
> |  |                       |    |
> |  -------------------------    |
> |                               |
> |                               |
> |                               |
> ---------------------------------
> 
> I'm hesitant to call this a "bug", but this feels wrong. Am I just
> giving it incorrect commands? Demo script:
> 
>   set key outside above right
>   set size ratio -1
>   plot x/10
> 
> 
> Thanks

Hi.

I'd like a plot with the legend sitting outside the plot, above the
top-right. Like this:

            window
---------------------------------
|                               |
|                               |
|                               |
|                     legend    |
|  -------------------------    |
|  |                       |    |
|  |                       |    |
|  |         plot          |    |
|  |                       |    |
|  |                       |    |
|  -------------------------    |
|                               |
|                               |
|                               |
---------------------------------


If we set a square aspect ratio, then the plot doesn't fill the window,
and there's a lot of empty space. This isn't a problem in itself (and
gnuplot doesn't control the window size, so it can't "fix" it), but it
looks like the legend attaches itself to the corner of the window
instead of the corner of the plot, which looks very strange: there's a
huge gap between the plot and the legend. I get this:


            window
---------------------------------
|                         legend|
|                               |
|                               |
|                               |
|  -------------------------    |
|  |                       |    |
|  |                       |    |
|  |         plot          |    |
|  |                       |    |
|  |                       |    |
|  -------------------------    |
|                               |
|                               |
|                               |
---------------------------------

I'm hesitant to call this a "bug", but this feels wrong. Am I just
giving it incorrect commands? Demo script:

  set key outside above right
  set size ratio -1
  plot x/10


Thanks

On Thursday, 4 February 2021 16:39:13 PST m sutton wrote:
> I was checking out v5.4.1 on centos 7.2 with gdlib 2.3.0.  I
>       simplified the problem down to this script.
> 
> unset grid
> set nokey
> set clip two
> 
> set title "GD Line Bug"
> set size 1,1
> set term png small truecolor butt size 500,400 
> unset border
> unset tics
> set output 'mike.png'
> set xr [0:6];
> 
> set yr [0:2]
> 
> plot '-' u 1:2 notitle w l lt 1 lw 9
> 2.0   1.0
> 5.0   1.0
> e
> 
> 
> I get a small, but noticeable dash at the beginning of the
>       plotted line.  The larger the linewidth the more noticeable it
>       becomes.

I have not looked at the libgd internals for a long time.
I remember that back in the day (2004-ish) the libgd support for
linewidth greater than 1.0 was really bad.

To work around this, gnuplot does not use 
	gdImageSetThickness()
to draw thick lines; instead it defines a brush with a finite
square or circular nib and draws using brush strokes.
This approach is acceptable for lines with end property "square" or "round",
but is not compatible with line end property "butt".  

So when the option for "set term png butt" was added, the corresponding
code went back to using the built-in gdlib gdImageSetThickness().
And it is apparently still really bad.

The relevant changes to the gnuplot source code appear to be:

%%%%%%
commit e69e5d055ac94a949e8cfcce87f0bebfbee301cf
Author: Mike Sutton <mw...@us...>
Date:   Thu Jan 6 21:34:33 2005 -0800
    New terminal option {rounded|butt}
%%%%%
%%%%%
commit 9a83ae5a4d653f179554045876d37a482f745a74
Author: Mike Sutton <mw...@us...>
Date:   Sat Nov 25 14:09:53 2006 -0800
    Fix off-by-one error in specifying line widths
%%%%%

So I refer you to the author of the code 😉 😉 😉

I seriously suggest to bail on using gdlib and instead use
"set term pngcairo".   



> I inserted a print statement in the PNG_vector function in
>       gd.trm.  What I see are two calls to PNG_vector.  The first call
>       tries to plot a line of zero length.  The second call plots the
>       correct line. 
> 
> 
> So why is the zero length line plotted?

You can see this in the generic code for plot_lines (graphics.c:1257).
There is a grand loop over all points in the data set.  Each one generates
a new line segment if either end is INRANGE. The very first point thus
generates a zero-lenght line segment.   It's been that way since forever.
My guess is that the original idea was that any INRANGE point should be
visible in the plot, even if the points on either side were undefined or
out of range.

	cheers,

		Ethan

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>I was checking out v5.4.1 on centos 7.2 with gdlib 2.3.0.  I
      simplified the problem down to this script.</p>
    <blockquote>
      <p>unset grid<br>
        set nokey<br>
        set clip two<br>
        <br>
        set title "GD Line Bug"<br>
        set size 1,1<br>
        set term png small truecolor butt size 500,400 <br>
        unset border<br>
        unset tics<br>
        set output 'mike.png'<br>
        set xr [0:6];</p>
      set yr [0:2]<br>
      <br>
      plot '-' u 1:2 notitle w l lt 1 lw 9<br>
      2.0   1.0<br>
      5.0   1.0<br>
      e<br>
    </blockquote>
    <p>I get a small, but noticeable dash at the beginning of the
      plotted line.  The larger the linewidth the more noticeable it
      becomes.</p>
    <p>I inserted a print statement in the PNG_vector function in
      gd.trm.  What I see are two calls to PNG_vector.  The first call
      tries to plot a line of zero length.  The second call plots the
      correct line. <br>
    </p>
    <p>So why is the zero length line plotted?</p>
    <p>MikeS</p>
    <p><br>
    </p>
  </body>
</html>