gnuplot-beta — Developers and beta testers of new gnuplot code

Re: Qt terminal size settings

[Ethan A M. <me...@uw...>]

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

Re: What should "set key outside above right" do?

[Ethan A M. <me...@uw...>]

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

Qt terminal size settings

[m s. <mw...@us...>]

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

Re: What should "set key outside above right" do?

[Ethan A M. <me...@uw...>]

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

What should "set key outside above right" do?

[Dima K. <gn...@di...>]

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

Re: Is this a bug in Gnuplot or gdlib?

[Ethan A M. <me...@uw...>]

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

Is this a bug in Gnuplot or gdlib?

[m s. <mw...@us...>]

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

commit c407e30e texdraw: negative of unsigned int requires a cast

[Ethan A M. <me...@uw...>]

Probably not a big deal, but...
     I believe this commit to be incorrect.

It is not true that passing the negative of an unsigned int requires a cast.
Or if it is true, then something is wrong with the compiler.

If the function has a prototype (now required!) then arguments are promoted to
match the prototype.

fprintf() is a weird special case because it is a variadic function but nevertheless 
anything given a format specifier %d will be promoted to integer.

This is covered in section 6.5.2.2 of the ISO C standard (checked in draft dated 2007)

If for some reason there is a real problem here I would prefer to understand
what it is.   Did you get a compiler warning?  What compiler?
Do you have a test case where this commit actually makes a difference to the output?

If a change is necessary for some reason, I would rather consider
all of these structure fields to int rather than unsigned.

*diff --git a/src/term_api.h b/src/term_api.h* 
*index c836e19cd..f8898c0b5 100644* 
*--- a/src/term_api.h* 
*+++ b/src/term_api.h* 
@@ -290,7 +290,7 @@ typedef enum t_imagecolor { IC_PALETTE, IC_RGB, IC_RGBA } 
-    unsigned int xmax,ymax,v_char,h_char,v_tic,h_tic; 
+    int xmax,ymax,v_char,h_char,v_tic,h_tic; 


  best,
	Ethan

%% commit    c407e30e
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@@ -410,11 +410,11 @@ TEXDRAW_graphics()
 	/* enforce bounding box */
 	fprintf(gpoutfile, "\\move (0 0) \\rmove (%d %d)\n",
 		    term->xmax, term->ymax);
     } else {
 	fprintf(gpoutfile, "\\move (0 0) \\rlvec (%d 0) \\rlvec (0 %d) \\rlvec (%d 0) \\ifill f:%0.2f\n",
-		    term->xmax, term->ymax, -term->xmax,
+		    term->xmax, term->ymax, - (int) term->xmax,
 		    TEXDRAW_background);
     }
 
     TEXDRAW_last_type = 0;
     TEXDRAW_type = 0;
@@ -814,11 +814,11 @@ TEXDRAW_fillbox(int style,
 
     // outline box using relative moves
     fprintf(gpoutfile, "\\move (%d %d)", x1, y1);
     fprintf(gpoutfile, "\\rlvec (%d %d)", width, 0);
     fprintf(gpoutfile, "\\rlvec (%d %d)", 0, height);
-    fprintf(gpoutfile, "\\rlvec (%d %d)", -width, 0);
+    fprintf(gpoutfile, "\\rlvec (%d %d)", - (int) width, 0);
     // the polygon is closed automatically by fill
     fprintf(gpoutfile, "\\ifill f:%0.2f\n", gray);
 }
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Aw: Re: filenames on MS Windows: follow-up

[Bastian M. <bma...@we...>]

Another somewhat simplified variant of the code is now in the master branch.
It's been tested with MSVC, MinGW-w64, and OpenWatcom for console gnuplot
and wgnuplot.
We still translate the complete command line to UTF-8. I now think this is a 
desirable step, which enables using Unicode also for -e commands. As a next 
step, we should probably change the default encoding to UTF-8.  This 
backwards-incompatible change should have been made with 5.4 already.

   Bastian

> Gesendet: Freitag, 04. Dezember 2020 um 14:04 Uhr
> Von: "Allin Cottrell" <cot...@wf...>
> An: "Bastian Märkisch" <bma...@we...>
> Cc: "gnuplot-beta" <gnu...@li...>
> Betreff: Re: Aw: filenames on MS Windows: follow-up
>
> On Thu, 3 Dec 2020, Bastian Märkisch wrote:
> 
> > Dear Allin,
> >
> > sorry for being slow to work on this. There is a fundamental issue with
> > the approach, which I am working on how to resolve best. Translating all
> > the command line arguments to UTF-8 is a great step forward and the
> > loading of files works fine as you point out. But this change also
> > affects and potentially breaks the -e option (try e.g.
> > -d -e "print 'öäü'").
> 
> OK, I take your point: any non-ASCII stuff in a "-e" clause on the 
> command line is going to get mangled.
> 
> > The best step in my opinion might be to just change gnuplot's default
> > encoding to utf8. This will break backward compatibility, though. A
> > remedy could be new command line options -a/-u which choose the system's
> > default encoding ("ANSI") or the utf8 encoding.
> 
> I have one other thought, and I'll try experimenting. Besides 
> setting argv to the UTF-8 recoded argument array in winmain.c, we 
> could define (say) aargv to the "ANSI" version:
> 
> #define aargv __argv
> 
> then when iterating over the args in the test for interactivity 
> (around line 630 in winmain.c) add a clause such as:
> 
> if ((argv[i][0] == '-') && (argv[i][1] == 'e')) {
>      if (i < argc - 1) {
>          argv[i+1] = aargv[i+1];
>      }
> }
> 
> This would (I think) replace the UTF-8 follow-up to -e with the 
> original locale version, for passing to gnumain().
> 
> > Please find attached a simplified version of your patch, which also
> > works for console mode gnuplot and other compilers than MinGW.
> 
> Thanks.
> 
> Allin Cottrell

DOS/DJGPP and OS/2 binary release 5.4.1

[Bastian M. <bma...@we...>]

Binary releases for OS/2/eComStation/ArchaOS, as well as for DOS (DJGPP) are now available.

   Bastian

Windows binary release 5.4.1

[Bastian M. <bma...@we...>]

Dear gnuplotters,

Windows binary packages of version 5.4.1 as installer and in 7zip format are now available on SF.

Best, Bastian

Re: [bug] plot bins does not clip output to plot area

[Ethan A M. <me...@uw...>]

On Wednesday, 16 December 2020 22:35:17 PST ASSI wrote:
> Ethan A Merritt writes:
> > Since I envisioned it as a histogramming tool, it did not occur to
> > me that users would want to plot "with lines" rather than using
> > boxes or impulses.   Therefore I did not think about or test the
> > clipping behaviour.
> 
> That fix has rippled through to openSUSE now, the y axis clipping now
> works, but the x axis clipping has stopped getting applied…

  oops

	Ethan

Re: [bug] plot bins does not clip output to plot area

[ASSI <Str...@ne...>]

Ethan A Merritt writes:
> Since I envisioned it as a histogramming tool, it did not occur to
> me that users would want to plot "with lines" rather than using
> boxes or impulses.   Therefore I did not think about or test the
> clipping behaviour.

That fix has rippled through to openSUSE now, the y axis clipping now
works, but the x axis clipping has stopped getting applied…


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

gnuplot 5.4 for Windows

[Uwe S. <uwe...@un...>]

Hi,

for the current stable version 5.41, there is a message on 
https://sourceforge.net/projects/gnuplot/files/gnuplot/5.4.1/
"Binary packages for Windows to appear here eventually."

i tried the 5.4 windows testing version of gnuplot 5.4 
(gp540-win64-mingw.exe, 2020-09-19, 34.7 MB) from 
https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/
on an older computer with windows10 and it works well. Particularly, the 
spider plots are a nice feature of 5.4.

Is this version the best, I can use on windows?

Thanks,
Uwe

https://github.com/uwe-schneider/gnuplotxyz

Re: Aw: filenames on MS Windows: follow-up

[Allin C. <cot...@wf...>]

On Thu, 3 Dec 2020, Bastian Märkisch wrote:

> Dear Allin,
>
> sorry for being slow to work on this. There is a fundamental issue with
> the approach, which I am working on how to resolve best. Translating all
> the command line arguments to UTF-8 is a great step forward and the
> loading of files works fine as you point out. But this change also
> affects and potentially breaks the -e option (try e.g.
> -d -e "print 'öäü'").

OK, I take your point: any non-ASCII stuff in a "-e" clause on the 
command line is going to get mangled.

> The best step in my opinion might be to just change gnuplot's default
> encoding to utf8. This will break backward compatibility, though. A
> remedy could be new command line options -a/-u which choose the system's
> default encoding ("ANSI") or the utf8 encoding.

I have one other thought, and I'll try experimenting. Besides 
setting argv to the UTF-8 recoded argument array in winmain.c, we 
could define (say) aargv to the "ANSI" version:

#define aargv __argv

then when iterating over the args in the test for interactivity 
(around line 630 in winmain.c) add a clause such as:

if ((argv[i][0] == '-') && (argv[i][1] == 'e')) {
     if (i < argc - 1) {
         argv[i+1] = aargv[i+1];
     }
}

This would (I think) replace the UTF-8 follow-up to -e with the 
original locale version, for passing to gnumain().

> Please find attached a simplified version of your patch, which also
> works for console mode gnuplot and other compilers than MinGW.

Thanks.

Allin Cottrell

Aw: filenames on MS Windows: follow-up

[Bastian M. <bma...@we...>]

Dear Allin,

sorry for being slow to work on this. There is a fundamental issue with
the approach, which I am working on how to resolve best. Translating all
the command line arguments to UTF-8 is a great step forward and the 
loading of files works fine as you point out. But this change also 
affects and potentially breaks the -e option (try e.g. 
-d -e "print 'öäü'"). 

The best step in my opinion might be to just change gnuplot's default 
encoding to utf8. This will break backward compatibility, though. A
remedy could be new command line options -a/-u which choose the system's
default encoding ("ANSI") or the utf8 encoding.

Please find attached a simplified version of your patch, which also 
works for console mode gnuplot and other compilers than MinGW. It does
not yet address the issue discussed above, though.

Bastian

> Gesendet: Samstag, 14. November 2020 um 22:41 Uhr
> Von: "Allin Cottrell" <cot...@wf...>
> An: "gnuplot-beta" <gnu...@li...>
> Betreff: filenames on MS Windows: follow-up
>
> I'm attaching a patch against gnuplot git master which does what I 
> mentioned in 
> https://sourceforge.net/p/gnuplot/mailman/message/37141539/ That is, 
> it allows wgnuplot.exe to accept via the Windows command-line 
> unicode filenames that cannot be represented in the user's "system 
> codepage", and to successfully to open such files.
> 
> This iteration of my patch uses native win32 APIs to perform the 
> necessary recoding of filenames, as opposed to the previous 
> iteration which used GLib.
> 
> I gave evidence in 
> https://sourceforge.net/p/gnuplot/mailman/message/37143153/
> that the patch is not disruptive of gnuplot's ability to open files 
> named via the "load" command, in which case the encoding specified 
> in the gnuplot script must be respected.
> 
> The patch is activated only when compiling the program for Windows, 
> and then only when the symbol WIDE_ARGS is defined.
> 
> -- 
> Allin Cottrell
> Department of Economics
> Wake Forest University_______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Version 5.4.1 release tarball

[Ethan A M. <me...@uw...>]

Gnuplot version 5.4.1

This release contains bug-fixes and a few changes back-ported from the
development version.

The most notable fix is for a regression in the handling of parameters to 
"call", either from a script or on the command line (Bugs #2298 #2368)
Many of the other fixes are for error handling of odd input streams
found by fuzzing. 

I have placed a source tarball for 5.4.1 on SourceForge

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

Release Notes with new feature list

   http://gnuplot.info/ReleaseNotes_5_4_1.html

        cheers, and happy plotting

                Ethan

Re: SVG output without image smoothing

[Dima K. <gn...@di...>]

Yeah, I think I agree. It's really unfortunate that browsers can't agree
on this, but here we are. For my use case drawing each cell
independently as a rectangle is a bit much, so I'll just move to .png
figures.

Thanks for talking through this.

Re: SVG output without image smoothing

[Ethan A M. <me...@uw...>]

On Saturday, 14 November 2020 12:21:40 PST Dima Kogan wrote:
> Hi.
> 
> I'm seeing that currently our svg output produces blurred images. I'm
> attaching a patch to (sorta) fix this.
> 
> Demo script:
> 
>   set terminal svg standalone
>   set output "/tmp/tst.svg"
>   set view map
>   splot [0:10][0:10] '++' using 1:2:($1+$2) with image
> 
> The images before and after the patch are attached. Using firefox, you
> can see the before-patch image containing smoothed pixels, while the
> after-patch image contains pixels with crisp edges, which is what we
> want I think.

My feeling is that we should not even try to track browser-specific quirks.
We already have an options to guarantee those crisp edges that so
far as I know works on all platforms and viewers:
 
gnuplot> help pixels
 Some terminals use device- or library-specific optimizations to render image
 data within a rectangular 2D area.  This sometimes produces undesirable output,
 e.g. bad clipping or scaling, missing edges.  The `pixels` keyword tells
 gnuplot to use generic code that renders the image pixel-by-pixel instead.
 This rendering mode is slower and may result in much larger output files, but
 should produce a consistent rendered view on all terminals.
 Example:
       plot 'data' with image pixels

See also the 4th plot in
       http://gnuplot.sourceforge.net/demo_svg/heatmaps.html

> Unfortunate caveat: apparently firefox and chrome can't agree on what to
> call this property. Firefox wants "crisp-edges" to do this, while Chrome
> wants "pixelated". So today, this patch will do the right thing on
> Firefox, but not on Chrome. Anybody know how to make this work on both
> (and the others, I guess)?
> 
> I'm on the fence about whether patching gnuplot to work with just one of
> the two is better than keeping them both blurry in the same way.

Better to fix it at the stage of image generation than to try to
figure out browser-specific fixes.   And it could well be that for
some applications the smoothed version is preferable to the pixelated one.
You have the choice of adding the "pixels" keyword or not.

	Ethan

filenames on MS Windows: follow-up

[Allin C. <cot...@wf...>]

I'm attaching a patch against gnuplot git master which does what I 
mentioned in 
https://sourceforge.net/p/gnuplot/mailman/message/37141539/ That is, 
it allows wgnuplot.exe to accept via the Windows command-line 
unicode filenames that cannot be represented in the user's "system 
codepage", and to successfully to open such files.

This iteration of my patch uses native win32 APIs to perform the 
necessary recoding of filenames, as opposed to the previous 
iteration which used GLib.

I gave evidence in 
https://sourceforge.net/p/gnuplot/mailman/message/37143153/
that the patch is not disruptive of gnuplot's ability to open files 
named via the "load" command, in which case the encoding specified 
in the gnuplot script must be respected.

The patch is activated only when compiling the program for Windows, 
and then only when the symbol WIDE_ARGS is defined.

-- 
Allin Cottrell
Department of Economics
Wake Forest University

SVG output without image smoothing

[Dima K. <gn...@di...>]

Hi.

I'm seeing that currently our svg output produces blurred images. I'm
attaching a patch to (sorta) fix this.

Demo script:

  set terminal svg standalone
  set output "/tmp/tst.svg"
  set view map
  splot [0:10][0:10] '++' using 1:2:($1+$2) with image

The images before and after the patch are attached. Using firefox, you
can see the before-patch image containing smoothed pixels, while the
after-patch image contains pixels with crisp edges, which is what we
want I think.

Unfortunate caveat: apparently firefox and chrome can't agree on what to
call this property. Firefox wants "crisp-edges" to do this, while Chrome
wants "pixelated". So today, this patch will do the right thing on
Firefox, but not on Chrome. Anybody know how to make this work on both
(and the others, I guess)?

I'm on the fence about whether patching gnuplot to work with just one of
the two is better than keeping them both blurry in the same way.

Is there more than one Windows "help" system?

[Ethan A M. <me...@uw...>]

I can see the the gnuplot 5.4 Windows executables from the distribution
site provide "help" via a set of html files generated by
   .../docs/windows/doc2html

But I am also seeing reports or queries (E.g. Bug #2353) implying that
the Windows build process needs a texinfo version produced by
   doc2texi.el

Is that correct?  I thought we had deprecated texinfo output and
that the *.el file was not being maintained.  The copy in the repository
looks to be out of date with respect to supported terminals and recently
added keys in the *.doc file.

Does the Windows build use it anyhow, or does it assume
a more up-to-date copy obtained elsewhere?
If it isn't used, should we move it to .../docs/old/ 
and remove the texinfo target from the Makefile?

	Ethan

Re: Commands into datablocks

[Ethan A M. <me...@uw...>]

On Monday, 9 November 2020 15:24:19 PST Tait wrote:
> 
> Datablocks seem like a great way to avoid running slow commands 
> multiple times, as in:
>   plot $data using ..., '' using ..., '' using ...
> 
> instead of
>   plot '<cmd' using ..., '' using ..., '' using ...
> 
> But $data << '<cmd' obviously doesn't work, and the workaround 
> using load '<cmd' is hard to discover and requires modifying 
> cmd. Would it be straighttforward to add a way to populate a 
> datablock from a command the way '<' works for plot and load?

Two existing mechanisms come to mind.
Neither is a perfect match to what you ask but might serve
well enough either as-is or with a straightforward extension.

The first is the "volatile" keyword, which tells the program
not to reread the data file if the previously read values are
still available internally.  As of now it is only relevant to
"replot", but it might conceivably be extended to cover the
use of '' in a plot command.

The second works already, subject to some issues like loss of
precision and appropriate choice of string formats and/or 
field separators:

    set table $DATA
    plot "< some complicated command" using 1:2:3:4:5:(strcol(6)) with table
    unset table

    plot for [i=1:4] $DATA using 1:i with points, \
                     $DATA using 1:5:6 with labels


Does that work for your case?
If not, can you suggest ways in which the "with table" might be extended?

	cheers,

		Ethan

Commands into datablocks

[Tait <gnu...@t4...>]

Datablocks seem like a great way to avoid running slow commands 
multiple times, as in:
  plot $data using ..., '' using ..., '' using ...

instead of
  plot '<cmd' using ..., '' using ..., '' using ...

But $data << '<cmd' obviously doesn't work, and the workaround 
using load '<cmd' is hard to discover and requires modifying 
cmd. Would it be straighttforward to add a way to populate a 
datablock from a command the way '<' works for plot and load?

(Inspired by 
https://stackoverflow.com/questions/54600172/gnuplot-load-datafile-11-into-datablock 
and several similar questions. Using system() doesn't work the 
way you'd think either, as 
https://stackoverflow.com/a/60366832/11777995 mentions.)

Re: qt terminal behavior if no x11 is available

[Daniel J S. <dan...@ie...>]

On 11/8/20 4:27 AM, Dima Kogan wrote:
> Hi. Is anybody here familiar with the qt terminal init sequence? I'm
> observing that if you try to plot anything without DISPLAY defined, the
> qt terminal throws an error and hangs. It does NOT give us the prompt
> back. This confuses tools that use gnuplot to make plots.
> 
> There was a commit that changed the way this works:
> 
>    https://sourceforge.net/p/gnuplot/gnuplot-main/ci/c415285c230
> 
> Reverting that makes gnuplot give up after a few seconds. The x11 and
> wxt terminals figure it out immediately, but even a wait of several
> seconds is better than a forever hang we currently get. Is there a
> better way to handle errors in qt?
> 
> Thanks!
> 

https://doc.qt.io/qt-5/qlocalsocket.html#waitForConnected

https://doc.qt.io/qt-5/qlocalsocket.html#error

https://doc.qt.io/qt-5/qlocalsocket.html#LocalSocketError-enum

That polling loop approach isn't really what should be done.  By doing 
so it kind of obviates the error test.  In the least, what this polling 
loop should be doing checking the error() after the failure to connect 
and going to sleep to determine if the error was a 
QLocalSocket::SocketTimeoutError.  If it was some other type of error, 
don't continue waiting.

     QLocalSocket::LocalSocketError err = qt->socket.error();
     if (err != QLocalSocket::SocketTimeoutError)
         break;

and of course don't wait forever.

As for the comment:

	// The QLocalSocket::waitForConnected does not respect the time out 
argument when
	// the gnuplot_qt application is not yet started or has not yet 
self-initialized.
	// To wait for it, we need to implement the timeout ourselves

one just needs to figure out how to put this in the context of an event 
loop, i.e., start an event loop.  That could be done with threading and 
the exec() routine.

Dan