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

Re: bug in 5.4rc2 X11 terminal

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

On Wednesday, 24 June 2020 10:20:48 PDT Dima Kogan wrote:
> Ethan A Merritt <me...@uw...> writes:
> 
> > Back when people cared about x11, the tools and fonts necessary to set
> > up utf8 support were maintained, albeit difficult to use. Now I cannot
> > get it to work at all. I imagine it is still possible but I cannot
> > point to a recipe for how to do it.
> >
> > I think the best advice is "don't use the x11 terminal".
> 
> Yeah, that's too bad, but I think we can do better than that advice
> suggests.
> 
> I use the x11 terminal almost exclusively for one reason: it's
> dramatically faster and lighter than all the alternatives. The
> difference is very noticeable when X-forwarding or when repeatedly
> replotting (interactively rotating a 3D plot, using feedgnuplot
> --stream, etc).
> 
> So I really would like to keep this working reasonably. If we currently
> have a unicode problem that makes tic mark labels render improperly, an
> easy "fix" would be to not feed unicode to the x11 terminal.

That is exactly what "set encoding XXX" does, for any XXX that is not utf8.

Or did you mean that <x11 terminal + non-ascii encoding> would be
a special case when generating tic labels? 
We generally try to keep terminal-specific tests out of the core code,
but we do have tests for TeX-based terminals so it's not an absolute
prohibition.

> If somebody
> has the time and motivation to fix it properly, that'd be awesome of
> course, but just sending ascii across would solve the 99% case in the
> meantime.
> 
> But I can't reproduce the issue in this report, and until that happens,
> there's nothing to "fix".

For a long time now utf8 has been the default on linux.
So I would expect that most linux users would have to deal with this
when using the x11 terminal with their default locale.  

	Ethan

Re: bug in 5.4rc2 X11 terminal

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

Ethan A Merritt <me...@uw...> writes:

> Back when people cared about x11, the tools and fonts necessary to set
> up utf8 support were maintained, albeit difficult to use. Now I cannot
> get it to work at all. I imagine it is still possible but I cannot
> point to a recipe for how to do it.
>
> I think the best advice is "don't use the x11 terminal".

Yeah, that's too bad, but I think we can do better than that advice
suggests.

I use the x11 terminal almost exclusively for one reason: it's
dramatically faster and lighter than all the alternatives. The
difference is very noticeable when X-forwarding or when repeatedly
replotting (interactively rotating a 3D plot, using feedgnuplot
--stream, etc).

So I really would like to keep this working reasonably. If we currently
have a unicode problem that makes tic mark labels render improperly, an
easy "fix" would be to not feed unicode to the x11 terminal. If somebody
has the time and motivation to fix it properly, that'd be awesome of
course, but just sending ascii across would solve the 99% case in the
meantime.

But I can't reproduce the issue in this report, and until that happens,
there's nothing to "fix".

Re: bug in 5.4rc2 X11 terminal

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

On Wednesday, 24 June 2020 09:04:32 PDT Dima Kogan wrote:
> Pieter-Tjerk de Boer <p.t...@ut...> writes:
> 
> > So, somehow, Debian's native gnuplot sets encoding to default even in
> > the C.UTF-8 locale, while 5.4rc2 only does that in the C locale.
> >
> > Thanks for the help; this provides me with sufficient ways to
> > circumvent the problem.
> 
> For what it's worth, my local environment is set to use C instead of
> UTF-8, which is probably why things consistently work here.
> 
> I tried to set the locale environment in various ways to reproduce the
> issue you saw, and I can't. IF gnuplot 5.4 has this issue with the x11
> terminal (requiring the user to explicitly turn off unicode), then I
> think we should fix it in some way.
> 
> But I can't reproduce the problem, so maybe there isn't anything to fix?
> Can anybody else see this issue?

Back when people cared about x11, the tools and fonts necessary to
set up utf8 support were maintained, albeit difficult to use.
Now I cannot get it to work at all.  I imagine it is still possible but
I cannot point to a recipe for how to do it.

I think the best advice is "don't use the x11 terminal".

	Ethan
  

Re: bug in 5.4rc2 X11 terminal

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

Pieter-Tjerk de Boer <p.t...@ut...> writes:

> So, somehow, Debian's native gnuplot sets encoding to default even in
> the C.UTF-8 locale, while 5.4rc2 only does that in the C locale.
>
> Thanks for the help; this provides me with sufficient ways to
> circumvent the problem.

For what it's worth, my local environment is set to use C instead of
UTF-8, which is probably why things consistently work here.

I tried to set the locale environment in various ways to reproduce the
issue you saw, and I can't. IF gnuplot 5.4 has this issue with the x11
terminal (requiring the user to explicitly turn off unicode), then I
think we should fix it in some way.

But I can't reproduce the problem, so maybe there isn't anything to fix?
Can anybody else see this issue?

Re: bug in 5.4rc2 X11 terminal

[Pieter-Tjerk de B. <p.t...@ut...>]

On Tue, Jun 23, 2020 at 10:43:32PM -0700, Dima Kogan wrote:
> I use Debian and the x11 terminal routinely, and have never seen this
> issue.
> 
> Ethan: if there's some sort of utf-8 issue as you suspect, would it show
> up in "show encoding"? I see this on my machine:
> 
>   gnuplot> show encoding
> 
>           nominal character encoding is default
>           however LC_CTYPE in current locale is C

In Debian's native gnuplot 5.2pl6 I get:

  gnuplot> show encoding
          nominal character encoding is default
          however LC_CTYPE in current locale is C.UTF-8

while in 5.4rc2 I get:

  gnuplot> show encoding
          nominal character encoding is utf8
          however LC_CTYPE in current locale is C.UTF-8

Setting encoding to "default" rather than "utf8" indeed fixes the problem
I had in the x11 terminal on 5.4rc2.

> I guess the locale being "C" means I'm not doing unicode, and that's why
> things work for me?

Ah, interesting: if I start gnuplot 5.4rc2 with LC_CTYPE set to C, I get
the same as you:

  gnuplot> show encoding
          nominal character encoding is default
          however LC_CTYPE in current locale is C

So, somehow, Debian's native gnuplot sets encoding to default even in
the C.UTF-8 locale, while 5.4rc2 only does that in the C locale.

Thanks for the help; this provides me with sufficient ways to circumvent
the problem.

Regards,
  Pieter-Tjerk

Re: bug in 5.4rc2 X11 terminal

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

I use Debian and the x11 terminal routinely, and have never seen this
issue.

Ethan: if there's some sort of utf-8 issue as you suspect, would it show
up in "show encoding"? I see this on my machine:

  gnuplot> show encoding

          nominal character encoding is default
          however LC_CTYPE in current locale is C

I guess the locale being "C" means I'm not doing unicode, and that's why
things work for me?

Re: bug in 5.4rc2 X11 terminal

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

On Tuesday, 23 June 2020 13:17:19 PDT Pieter-Tjerk de Boer wrote:
> Hello,
> 
> Something goes wrong with fonts or character encodings on the x11 terminal.
> See the attached which is the result of simply  
>   plot 1e6
> The vertical labels have a few unintended characters instead of multiplication
> signs (crosses).
> 
> Debian's stock gnuplot 5.2pl6 version displays the multiplication sign
> correctly on the x11 terminal, as does 5.4rc2 with the Qt terminal.
> 
> Any idea what this could be? Any test I could do to help debug it?

Most likely your gnuplot session is operating with encoding utf8,
but your x11 terminal font handling is not set up to handle it.
It is possible to set it up, but it's a horrible pain and depends on exactly
what fonts you have available.   Either switch to
     set encoding iso_8859_15    (probably)
or switch to another terminal that has kept up with the modern world
and knows how to handle utf8.  I long ago switched to from x11 to qt
for daily use, but wxt or even sixel might fit your environment better.

If you stick with x11  and iso_8859_15, remember to switch the
encoding back to utf8 for output to pdf or TeX.

	Ethan

> 
> Regards,
>   Pieter-Tjerk
> 

Re: Bug in 5.4.rc2

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

On Tuesday, 23 June 2020 11:24:24 PDT Dima Kogan wrote:
> I finished a patch just as you wrote this. The patch is attached. I
> tried several operations, and it appears to do what I want, and not
> break anything. The code has a lot of confusion about the meaning of
> xlow/xhigh/ylow/yhigh in arguments to store2d_point() and again, in the
> *cp structure this function fills. The previous code was passing the x,y
> extents to store2d_point(), but if you do that, you run out of
> arguments, and can't pass the y extents even if you wanted to. This
> patch computes the extents inside store2d_point(), so there are
> arguments left over. 

That won't work.
The eventual extent of a cicle along the y axis will not be known
until after the scaling on both x and y is complete.  For an auto-scaled
plot that will not be true until all the plot components, including functions,
have been processed.  There is not enough information yet at the time
store2d_point() is called.

"with circles" is not the only plot style for which autoscaling must
be delayed till later.  That is the reason for the extra routines
box_range_fiddling()  impulse_range_fiddling() histogram_range_fiddling()
and so on.   However for those plot styles the extra routine can
be called following the individual plot component "with <whatever>".
To handle circles you'd have to wait until _all_ plot components had
contributed to the autoscaling.  That could be done, but it would introduce
a new stage of processing that has not been needed before this.
And even so it would be imprecise, because if you must increase
the y range to fit the circles that will itself increase the y-radius of
the circles so you would need to iterate or estimate the asymptote.

So not impossible, but more difficult than autoscaling other plot styles.

	Ethan

Re: Bug in 5.4.rc2

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

On Tuesday, 23 June 2020 11:33:13 PDT Dima Kogan wrote:
> Dima Kogan <gn...@di...> writes:
> 
> > I finished a patch just as you wrote this.
> 
> So I just played with the patched code a bit more, and it's plotting the
> circles as circles even if the aspect ratio is not square. So it's
> clearly insufficient. Hmm

Indeed. That is the purpose of the style.  It _always_ draws circles,
regardless of aspect ratio and regardless of y scaling.

Sounds like your plot wants to use  "with ellipses".

	Ethan

bug in 5.4rc2 X11 terminal

[Pieter-Tjerk de B. <p.t...@ut...>]

Hello,

Something goes wrong with fonts or character encodings on the x11 terminal.
See the attached which is the result of simply  
  plot 1e6
The vertical labels have a few unintended characters instead of multiplication
signs (crosses).

Debian's stock gnuplot 5.2pl6 version displays the multiplication sign
correctly on the x11 terminal, as does 5.4rc2 with the Qt terminal.

Any idea what this could be? Any test I could do to help debug it?

Regards,
  Pieter-Tjerk

Re: set nonlinear for secondary axis

[Achim G. <Str...@ne...>]

Ethan A Merritt writes:
> Good idea.  Done.

Thank you very much.


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

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: Bug in 5.4.rc2

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

Dima Kogan <gn...@di...> writes:

> I finished a patch just as you wrote this.

So I just played with the patched code a bit more, and it's plotting the
circles as circles even if the aspect ratio is not square. So it's
clearly insufficient. Hmm

Re: Bug in 5.4.rc2

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

I finished a patch just as you wrote this. The patch is attached. I
tried several operations, and it appears to do what I want, and not
break anything. The code has a lot of confusion about the meaning of
xlow/xhigh/ylow/yhigh in arguments to store2d_point() and again, in the
*cp structure this function fills. The previous code was passing the x,y
extents to store2d_point(), but if you do that, you run out of
arguments, and can't pass the y extents even if you wanted to. This
patch computes the extents inside store2d_point(), so there are
arguments left over. This patch also documents the meanings of
xlow/xhigh/ylow/yhigh.



Ethan A Merritt <me...@uw...> writes:

> On Monday, 22 June 2020 23:11:41 PDT Dima Kogan wrote:
>
> Autoscaling on y for "with circles" is not a well-defined operation.
> The whole point of the style is that the circle radius depends only on
> x. It will accommodate any yrange by adjusting the extent on y taking
> into account the aspect ratio of the plot.

Maybe I'm abusing the intent of the style here, but in my intended
usage, the meaning is well-defined, and the existing behavior highly
surprising. I want a circle in the x and y coordinates of the plot. If
the aspect ratio is square, it will look like a circle. If the aspect
ratio isn't square, it will look like an ellipse. Is "with circles" not
the proper style? Do I want "with ellipses"? I do see that what you're
saying is spelled-out in the "with circles" documentation; I guess I
thought the meaning of "circle" was clear-enough such that I didn't need
to read that page :)

And regardless of the answer to that question, the user expectation is
that the autoscaling would cause everything in the plot to be visible.
So given that, we shouldn't be cutting off any of the plotted circle.

Thanks

Re: Bug in 5.4.rc2

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

On Monday, 22 June 2020 23:11:41 PDT Dima Kogan wrote:
> I just hit a bug in 5.4.rc2. I'm guessing this isn't a new bug, but it'd
> be nice to fix it before the release. To reproduce:
> 
>   set size ratio -1
>   plot '-'   using 1:2:3 notitle with circles lw 2
>   0 0 2.5
>   e
> 
> It looks like when "with circles" data is used for autoscaling, the
> edges of the circles are used for the x-axis autoscaling, but only the
> centers for the y-axis autoscaling. So in the plot above, most of the
> one circle gets cut off.

Autoscaling on y for "with circles" is not a well-defined operation.
The whole point of the style is that the circle radius depends only on x.
It will accommodate any yrange by adjusting the extent on y taking
into account the aspect ratio of the plot.

	Ethan  


> 
> I can debug and come up with a patch, but some of you can do that MUCH
> faster than me.
> 
> If yall are busy, let me know, and I can produce a patch.
> 
> Thanks!

Bug in 5.4.rc2

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

I just hit a bug in 5.4.rc2. I'm guessing this isn't a new bug, but it'd
be nice to fix it before the release. To reproduce:

  set size ratio -1
  plot '-'   using 1:2:3 notitle with circles lw 2
  0 0 2.5
  e

It looks like when "with circles" data is used for autoscaling, the
edges of the circles are used for the x-axis autoscaling, but only the
centers for the y-axis autoscaling. So in the plot above, most of the
one circle gets cut off.

I can debug and come up with a patch, but some of you can do that MUCH
faster than me.

If yall are busy, let me know, and I can produce a patch.

Thanks!

Re: set nonlinear for secondary axis

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

On Monday, 22 June 2020 11:32:27 PDT Achim Gratz wrote:
> 
> I've recently started using "set nonlinear" more and more and finally
> got to the point where I wanted to have both the primary and secondary
> axis nonlinear.  I promptly fell into the trap that the axis is now
> called x2 (or y2 or z2), but the dummy variable still needs to be given
> as plain x, y, z for the dummy variable in the function setup.  Could
> the documentation be augmented to have at least one example of using a
> secondary axis so that this becomes more clear?
> 
> Regards,
> Achim.

Good idea.  Done.

	Ethan

set nonlinear for secondary axis

[Achim G. <Str...@ne...>]

I've recently started using "set nonlinear" more and more and finally
got to the point where I wanted to have both the primary and secondary
axis nonlinear.  I promptly fell into the trap that the axis is now
called x2 (or y2 or z2), but the dummy variable still needs to be given
as plain x, y, z for the dummy variable in the function setup.  Could
the documentation be augmented to have at least one example of using a
secondary axis so that this becomes more clear?


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

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: palette plus extra color?

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

On Sat, 13 Jun 2020, Ethan Merritt wrote:

> On Saturday, 13 June 2020 12:07:02 PDT Ethan A Merritt wrote:
>> On Saturday, 13 June 2020 11:25:46 PDT Allin Cottrell wrote:
>>> The following doesn't work (not surprising) but I'm wondering if
>>> there's any real gnuplot syntax that'll do what it's trying to do:
>>>
>>> plot for [i=0:*] 'polygons.dat' index i with filledcurves \
>>>   fc ($3 < 0 ? 'gray' : palette)
>>>
>>> The datafile contains several datasets representing polygons; the
>>> first 2 columns hold the coordinates of vertices and the third a
>>> value to be colorized (if >= 0) or shown as missing (gray) if
>>> negative.
>>
>> Define the palette such that cb=0 is gray, the rest whatever you want.
>>
>>      set palette defined (-0.001 "gray",   0 "first palette color", ..., 1 "last palette color")
>>      set cbrange [0:*]
>
> Ah, sorry. I missed the normal color for ( >= 0) requirement.
>         set cbrange [-0.001:*]

Thanks, Ethan. I'd actually tried "set palette defined" plus "set 
cbrange" but I failed to get it right.

Allin

Re: palette plus extra color?

[Ethan M. <eam...@gm...>]

On Saturday, 13 June 2020 12:07:02 PDT Ethan A Merritt wrote:
> On Saturday, 13 June 2020 11:25:46 PDT Allin Cottrell wrote:
> > The following doesn't work (not surprising) but I'm wondering if 
> > there's any real gnuplot syntax that'll do what it's trying to do:
> > 
> > plot for [i=0:*] 'polygons.dat' index i with filledcurves \
> >   fc ($3 < 0 ? 'gray' : palette)
> > 
> > The datafile contains several datasets representing polygons; the 
> > first 2 columns hold the coordinates of vertices and the third a 
> > value to be colorized (if >= 0) or shown as missing (gray) if 
> > negative.
> 
> Define the palette such that cb=0 is gray, the rest whatever you want.
> 
>      set palette defined (-0.001 "gray",   0 "first palette color", ..., 1 "last palette color")
>      set cbrange [0:*]

Ah, sorry. I missed the normal color for ( >= 0) requirement.
         set cbrange [-0.001:*]

	Ethan

Re: palette plus extra color?

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

On Saturday, 13 June 2020 11:25:46 PDT Allin Cottrell wrote:
> The following doesn't work (not surprising) but I'm wondering if 
> there's any real gnuplot syntax that'll do what it's trying to do:
> 
> plot for [i=0:*] 'polygons.dat' index i with filledcurves \
>   fc ($3 < 0 ? 'gray' : palette)
> 
> The datafile contains several datasets representing polygons; the 
> first 2 columns hold the coordinates of vertices and the third a 
> value to be colorized (if >= 0) or shown as missing (gray) if 
> negative.

Define the palette such that cb=0 is gray, the rest whatever you want.

     set palette defined (-0.001 "gray",   0 "first palette color", ..., 1 "last palette color")
     set cbrange [0:*]
 

	Ethan

palette plus extra color?

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

The following doesn't work (not surprising) but I'm wondering if 
there's any real gnuplot syntax that'll do what it's trying to do:

plot for [i=0:*] 'polygons.dat' index i with filledcurves \
  fc ($3 < 0 ? 'gray' : palette)

The datafile contains several datasets representing polygons; the 
first 2 columns hold the coordinates of vertices and the third a 
value to be colorized (if >= 0) or shown as missing (gray) if 
negative.

-- 
Allin Cottrell
Department of Economics
Wake Forest University

Re: 5.4.rc2 second release candidate for gnuplot version 5.4

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

I ran gp54rc1-win64-mingw.exe downloaded from SF.

The wxt, qt, libgd-png, and libcairo-png terminal output is not
affected by the text display scaling in my test. The 100% and
225% plots are identical to each other. The mouse coordinate
display and the Window title -- where it says "Gnuplot (window
id : 0)" do change based on text display scaling. Perhaps it's
an optional configuration in cairo's build? On one of the two
machines I tested (but not the other) there is a significant
difference in the default text size between pngcairo and
(gd)png.

As an aside, the gnuplot console text is unaffected, although
the menus, etc. are affected. That will make gnuplot difficult
to use (i.e. tiny) on high-resolution displays.

There are at least two other scaling options available in
Windows that I did not adjust (Scale and Layout in Display, Text
Display in Ease-of-Access, and Make Everything Bigger in
Ease-of-Access). I'm running this in Windows Sandbox to ensure a
pristine default install, and Sandbox won't let me adjust those
other settings.

I wanted to try the Windows terminal, too, but it hangs for a
few seconds and then crashes, seemingly no matter what I try to
plot.


Ethan A Merritt <me...@uw...> said (on 2020/06/06):
> I have placed a tarball for 5.4.rc2 on SourceForge
>    https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/gnuplot-5.4.rc2.tar.gz/download
> 
>  Release Notes date: 04-Jun-2020
> ...
> Can someone comment on this issue - is it reproducible?
>     Bug #2261 Text Size Depends on Windows Scale and Layout Setting
>     https://sourceforge.net/p/gnuplot/bugs/2261/
> 
> Any other known issues?

Re: Cygwin + Qt and/or wxt [was Re: OK to put out an -rc2 for version 5.4?]

[Achim G. <Str...@ne...>]

Ethan A Merritt writes:
> If you can spare the time...

I'll see if I get to it on the weekend or so…

> Here is a small diagnostic patch for the qt terminal.
> It tests the hypothesis that qt connection failure on Cygwin is due to
> horribly slow font initialization.  With the patch in place font handling
> is disabled until the first plot has completed.

Font initialization _is_ slow, I usually even get a warning that tells
me exactly that.


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

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Cygwin + Qt and/or wxt [was Re: OK to put out an -rc2 for version 5.4?]

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

On Sunday, 7 June 2020 00:48:14 PDT Achim Gratz wrote:
> 
> The thing is that the call _should_ work and since this is deep inside a
> Qt library that is happily used by other Qt applications without any
> reported problems indicates that there is some other condition that
> makes it not work work for gnuplot_qt specifically (an initialization
> that's missing or something like that).
> 
> Regards,
> Achim.

If you can spare the time...

Here is a small diagnostic patch for the qt terminal.
It tests the hypothesis that qt connection failure on Cygwin is due to
horribly slow font initialization.  With the patch in place font handling
is disabled until the first plot has completed.

This is guaranteed to mess up layout of the first plot, but if it makes
the connection succeed we can sort out font initialization later.

	Ethan

Re: 5.4.rc2 second release candidate for gnuplot version 5.4

[Erik L. <eri...@gm...>]

Hi Ethan,

Just to report that compilation of 5.4.rc2 on OS X works fine. Note that I
use the x11 terminal (and in addition to the standard terminals I also
include the pdf, gif, jpg, and png terminals), as described here
https://csml-wiki.northwestern.edu/index.php/Binary_versions_of_Gnuplot_for_OS_X
(one
day I will find time for cairo, but x11 serves my purposes).

Best,

Erik


On Sat, Jun 6, 2020 at 12:16 AM Ethan A Merritt <me...@uw...> wrote:

> I have placed a tarball for 5.4.rc2 on SourceForge
>
>
> https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/gnuplot-5.4.rc2.tar.gz/download
>
>  Release Notes date: 04-Jun-2020
>
> * Changes between -rc1 and -rc2
>         o faster response to piped input on Windows (Bug #2204)
>         o "splot with boxes" failed to recognize "fc palette" in -rc1
>         o repair several problems with parallel axis plots (Bug #2294)
>         o minor changes to dumb.trm, pixmap handling
>         o -rc1 failed to act on "with labels rotate by <ang>" (Bug #2264)
>         o \n _not_ stripped from string returned by backquoted shell
> command
>         o fix autoscaling of boxplots
>         o new function palette(z) returns packed RGB representation
>         o lua/tikz terminal applies alpha channel to point symbols
>
> Can someone comment on this issue - is it reproducible?
>     Bug #2261 Text Size Depends on Windows Scale and Layout Setting
>     https://sourceforge.net/p/gnuplot/bugs/2261/
>
> Any other known issues?
>
>         Ethan
>
>
>
>
>
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>