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

Re: Re: ps_symbols.ps procuded using gnuplot-5.5 is invalid

[Tatsuro M. <tma...@ya...>]

I have tested on Ubuntu-22.04 (WLS2) and Cygwin.
For both: ps_symbols.ps (5.5 )  1631 lines.

The phenomenon is windows specific and something is changed in the postscript terminal on gnuplot-5.5 on windows.
Is it better to file as a bug report?

Tatsuro
 

> ----- Original Message -----
> 
> From: "Tatsuro MATSUOKA via gnuplot-beta" <gnu...@li...>
> To: "Ethan A Merritt" <me...@uw...>; "gnu...@li..." <gnu...@li...>
> Date: 2022/09/01 木 14:49
> Subject: Re: ps_symbols.ps procuded using gnuplot-5.5 is invalid
> 
> 
> Thank you for your reply.
> 
> For me,two files are different
> ps_symbols.ps (5.4.4 )  1631 lines 
> ps_symbols.ps (5.5 )  1248 lines 
> 
> I have tested only on windows.
> I will try on Ubuntu-22.04 (WSL) and Cygwin and report later.
> 
> Tatsuro
> 
> > ----- Original Message -----
> > 
> > From: "Ethan A Merritt" <me...@uw...>
> > To: "gnu...@li..." <gnu...@li...>
> > Cc: "Tatsuro MATSUOKA" <tma...@ya...>
> > Date: 2022/09/01 木 14:34
> > Subject: Re: ps_symbols.ps procuded using gnuplot-5.5 is invalid
> > 
> > 
> > On Wednesday, 31 August 2022 22:23:41 PDT Tatsuro MATSUOKA via gnuplot-beta wrote:
> > > I cannot judge whether this is a bug or not.
> > > The file ps_symbols.ps which is generated from ps_symbols.gpi is invalid using gnuplot-5.5.
> > 
> > I cannot reproduce this.
> > I get identical postscript output files using either gnuplot 5.4 or 5.5,
> > differing only in the Creator and CreationDate header lines.
> > 
> > 	Ethan
> > 
> > 
> > > 
> > > $ gs ps_symbols.ps
> > > GPL Ghostscript 9.55.0 (2021-09-27)
> > > Copyright (C) 2021 Artifex Software, Inc.  All rights reserved.
> > > This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
> > > see the file COPYING for details.
> > > Loading NimbusSans-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusSans-Regular... 4410900 2897778 3914624 2616235 1 done.
> > > Error: /undefined in UL
> > > Operand stack:
> > >    1.0
> > > Execution stack:
> > >    %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1990   1   3   %oparray_pop   1989   1   3   %oparray_pop   1977   1   3   %oparray_pop   1833   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--
> > > Dictionary stack:
> > >    --dict:761/1123(ro)(G)--   --dict:0/20(G)--   --dict:81/200(L)--   --dict:51/256(L)--
> > > Current allocation mode is local
> > > Current file position is 19030
> > > GPL Ghostscript 9.55.0: Unrecoverable error, exit code 1
> > > 
> > > ps_symbols.ps which is generated from ps_symbols.gpi is valid using gnuplot-5.4.4.
> > > 
> > > $ gs ps_symbols.ps
> > > GPL Ghostscript 9.55.0 (2021-09-27)
> > > Copyright (C) 2021 Artifex Software, Inc.  All rights reserved.
> > > This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
> > > see the file COPYING for details.
> > > Loading StandardSymbolsPS font from /usr/share/ghostscript/9.55.0/Resource/Font/StandardSymbolsPS... 4377556 2802346 4217624 2918412 1 done.
> > > Loading NimbusSans-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusSans-Regular... 4427860 2963335 4278224 2968221 1 done.
> > > Loading NimbusMonoPS-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusMonoPS-Regular... 4554572 3182512 4338824 3002934 1 done.
> > > >>showpage, press <return> to continue<<
> > > 
> > > Tatsuro
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > gnuplot-beta mailing list
> > > gnu...@li...
> > > Membership management via: https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!lfjj4woyjQS0C329E_hSbTojwjm4tDa_6IUD8oxOjyhWUOWxpV1DM_dWL26-M_IuA4aMdhxxjRWIep0MvQqfxx42fS1lyQf3ZAFT$  
> > > 
> > 
> > 
> > 
> > 
> 
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: ps_symbols.ps procuded using gnuplot-5.5 is invalid

[Tatsuro M. <tma...@ya...>]

Thank you for your reply.

For me,two files are different
ps_symbols.ps (5.4.4 )  1631 lines 
ps_symbols.ps (5.5 )  1248 lines 

I have tested only on windows.
I will try on Ubuntu-22.04 (WSL) and Cygwin and report later.

Tatsuro

> ----- Original Message -----
> 
> From: "Ethan A Merritt" <me...@uw...>
> To: "gnu...@li..." <gnu...@li...>
> Cc: "Tatsuro MATSUOKA" <tma...@ya...>
> Date: 2022/09/01 木 14:34
> Subject: Re: ps_symbols.ps procuded using gnuplot-5.5 is invalid
> 
> 
> On Wednesday, 31 August 2022 22:23:41 PDT Tatsuro MATSUOKA via gnuplot-beta wrote:
> > I cannot judge whether this is a bug or not.
> > The file ps_symbols.ps which is generated from ps_symbols.gpi is invalid using gnuplot-5.5.
> 
> I cannot reproduce this.
> I get identical postscript output files using either gnuplot 5.4 or 5.5,
> differing only in the Creator and CreationDate header lines.
> 
> 	Ethan
> 
> 
> > 
> > $ gs ps_symbols.ps
> > GPL Ghostscript 9.55.0 (2021-09-27)
> > Copyright (C) 2021 Artifex Software, Inc.  All rights reserved.
> > This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
> > see the file COPYING for details.
> > Loading NimbusSans-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusSans-Regular... 4410900 2897778 3914624 2616235 1 done.
> > Error: /undefined in UL
> > Operand stack:
> >    1.0
> > Execution stack:
> >    %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1990   1   3   %oparray_pop   1989   1   3   %oparray_pop   1977   1   3   %oparray_pop   1833   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--
> > Dictionary stack:
> >    --dict:761/1123(ro)(G)--   --dict:0/20(G)--   --dict:81/200(L)--   --dict:51/256(L)--
> > Current allocation mode is local
> > Current file position is 19030
> > GPL Ghostscript 9.55.0: Unrecoverable error, exit code 1
> > 
> > ps_symbols.ps which is generated from ps_symbols.gpi is valid using gnuplot-5.4.4.
> > 
> > $ gs ps_symbols.ps
> > GPL Ghostscript 9.55.0 (2021-09-27)
> > Copyright (C) 2021 Artifex Software, Inc.  All rights reserved.
> > This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
> > see the file COPYING for details.
> > Loading StandardSymbolsPS font from /usr/share/ghostscript/9.55.0/Resource/Font/StandardSymbolsPS... 4377556 2802346 4217624 2918412 1 done.
> > Loading NimbusSans-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusSans-Regular... 4427860 2963335 4278224 2968221 1 done.
> > Loading NimbusMonoPS-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusMonoPS-Regular... 4554572 3182512 4338824 3002934 1 done.
> > >>showpage, press <return> to continue<<
> > 
> > Tatsuro
> > 
> > 
> > 
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > Membership management via: https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!lfjj4woyjQS0C329E_hSbTojwjm4tDa_6IUD8oxOjyhWUOWxpV1DM_dWL26-M_IuA4aMdhxxjRWIep0MvQqfxx42fS1lyQf3ZAFT$  
> > 
> 
> 
> 
> 

ps_symbols.ps procuded using gnuplot-5.5 is invalid

[Tatsuro M. <tma...@ya...>]

I cannot judge whether this is a bug or not.
The file ps_symbols.ps which is generated from ps_symbols.gpi is invalid using gnuplot-5.5.

$ gs ps_symbols.ps
GPL Ghostscript 9.55.0 (2021-09-27)
Copyright (C) 2021 Artifex Software, Inc.  All rights reserved.
This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
see the file COPYING for details.
Loading NimbusSans-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusSans-Regular... 4410900 2897778 3914624 2616235 1 done.
Error: /undefined in UL
Operand stack:
   1.0
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1990   1   3   %oparray_pop   1989   1   3   %oparray_pop   1977   1   3   %oparray_pop   1833   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--
Dictionary stack:
   --dict:761/1123(ro)(G)--   --dict:0/20(G)--   --dict:81/200(L)--   --dict:51/256(L)--
Current allocation mode is local
Current file position is 19030
GPL Ghostscript 9.55.0: Unrecoverable error, exit code 1

ps_symbols.ps which is generated from ps_symbols.gpi is valid using gnuplot-5.4.4.

$ gs ps_symbols.ps
GPL Ghostscript 9.55.0 (2021-09-27)
Copyright (C) 2021 Artifex Software, Inc.  All rights reserved.
This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
see the file COPYING for details.
Loading StandardSymbolsPS font from /usr/share/ghostscript/9.55.0/Resource/Font/StandardSymbolsPS... 4377556 2802346 4217624 2918412 1 done.
Loading NimbusSans-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusSans-Regular... 4427860 2963335 4278224 2968221 1 done.
Loading NimbusMonoPS-Regular font from /usr/share/ghostscript/9.55.0/Resource/Font/NimbusMonoPS-Regular... 4554572 3182512 4338824 3002934 1 done.
>>showpage, press <return> to continue<<

Tatsuro

Re: gnuplot latex documentation error with (MiKTeX 22.7)

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

On Thursday, 25 August 2022 21:06:33 PDT Tatsuro MATSUOKA via gnuplot-beta wrote:
> I have a situation to make gnuplot.pdf on windows (MinGW-w64) with MiKTeX 22.7
> 
> ************************************************************************************************.
>   :
>   :
> LaTeX Warning: Reference `set label' on page 70 undefined on input line 6036.
> 
> 
> LaTeX Warning: Reference `hypertext' on page 70 undefined on input line 6059.
> 
> 
> 
> pdfTeX warning: pdflatex.exe (file ./figure_labels2.pdf): PDF inclusion: found
> PDF version <1.7>, but at most version <1.5> allowed
> 
> ! LaTeX Error: Unicode character ∙ (U+2219)
>                not set up for use with LaTeX.


U+2219 is \bullet in LaTeX.
Perhaps the unicode support package included with MiKTeX 22.7 is incomplete?
The file .../texmf-dist/tex/generic/unicode-data/UnicodeData.txt
should contain a line

2219;BULLET OPERATOR;Sm;0;ON;;;;;N;;;;;


As a work-around, this thread 
  https://tex.stackexchange.com/questions/598469/package-inputenc-error-unicode-character-%E2%88%99-u2219

suggests it may be possible to say
    \usepackage{newunicodechar}
    \newunicodechar{^^^^2219}{\cdot}

but I think it would be better to figure out what is wrong with the MiKTeX
installation.


	Ethan

gnuplot latex documentation error with (MiKTeX 22.7)

[Tatsuro M. <tma...@ya...>]

I have a situation to make gnuplot.pdf on windows (MinGW-w64) with MiKTeX 22.7

************************************************************************************************.
  :
  :
LaTeX Warning: Reference `set label' on page 70 undefined on input line 6036.


LaTeX Warning: Reference `hypertext' on page 70 undefined on input line 6059.



pdfTeX warning: pdflatex.exe (file ./figure_labels2.pdf): PDF inclusion: found
PDF version <1.7>, but at most version <1.5> allowed

! LaTeX Error: Unicode character ∙ (U+2219)
               not set up for use with LaTeX.

See the LaTeX manual or LaTeX Companion for explanation.
Type  H <return>  for immediate help.
 ...

******************************************************************************************************


I have not met such error on MiKTeX 22.3.

Any suggestions are welcome.

Tatsuro 

Re: xyplane tics too large with orthogonal splot views

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

On Thursday, 11 August 2022 15:06:40 PDT Dima Kogan wrote:
> Hi. I just made some 3D plots from an orthogonal side view (set view
> 90,0). This has special-case logic in gnuplot to treat it like a 2D plot
> in some ways. It looks like the logic isn't completely right, though,
> and the tics on the xy plane end up larger than they should. And the
> tics appear on both sides of the plane, which isn't obviously right. Can
> somebody please take a look?

I think there is not an easy fix for this.
The original code assumes that the vertical axis is "y" just
about everywhere, and calculates various scale factors using
that assumption. A complete fix would have to handle all the
various possible projections and rotations as special cases
wherever it makes a difference.

Possibly the odd placement of mirrored tics can be repaired,
or tic mirroring ignored in this projection.  I'll look at that.

But the tic length - meh. You can fix it for any given plot using
"set xtic scale" so IMHO it's not a high priority to rework all the code
just for that. But if someone is inspired to do so, fine - go for it.
I suggest that you file this as a bug report on the tracker so it
isn't forgotten.

	Ethan

Re: xyplane tics too large with orthogonal splot views

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

On Thursday, 11 August 2022 18:10:44 PDT Dima Kogan wrote:

> > It's also a bit weird that "set xyplane at <foo>" is actually
> > acting as if it were "set xrange [ low : high + foo ].
> > I worry that setting <foo> to anything other than zero may
> > have other unexpected side effects.
> > 
> >         Ethan

> Something is being strangely proportional. If
> I make the same plot, but do so interactively, (without "set terminal"
> or "set output"), then I see the length of the tics change as I
> interactively move the xyplane (shift+button2+drag up/down).

That would be an example of "unexpected side effects" :-)

I think the tic lengths are changing due to the changing aspect ratio
of the plot.  I see the same effect just by changing the window size
by dragging a corner with the mouse.

There does seem to be a difference between gnuplot 4 and gnuplot 5,
so the change/bug/quirk/whatever probably dates back a few years.
I'll have a look but I'm working on other things right now.

	Ethan

Re: xyplane tics too large with orthogonal splot views

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

Thanks for looking, Ethan. Something is being strangely proportional. If
I make the same plot, but do so interactively, (without "set terminal"
or "set output"), then I see the length of the tics change as I
interactively move the xyplane (shift+button2+drag up/down).

Re: xyplane tics too large with orthogonal splot views

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

On Thursday, 11 August 2022 15:06:40 PDT Dima Kogan wrote:
> Hi. I just made some 3D plots from an orthogonal side view (set view
> 90,0). This has special-case logic in gnuplot to treat it like a 2D plot
> in some ways. It looks like the logic isn't completely right, though,
> and the tics on the xy plane end up larger than they should. And the
> tics appear on both sides of the plane, which isn't obviously right. Can
> somebody please take a look?

I'll have a look.

Meanwhile as you probably found, you can "fix" the output with

    set xtics nomirror scale 0.5

It's also a bit weird that "set xyplane at <foo>" is actually
acting as if it were "set xrange [ low : high + foo ].
I worry that setting <foo> to anything other than zero may
have other unexpected side effects.

	Ethan

> This happens with the latest gnuplot in git.
> 
> The script appears below, and the result is attached.
> 
> Thanks!
> 
> 
> 
> set view 90,0
> set xyplane at -0.1
> set xtics 0.5
> set ytics 0.5
> set view equal xyz
> set xlabel "x"
> set ylabel "y"
> set zlabel "z"
> 
> set terminal png size 600,1000
> set output "/tmp/tics-too-big.png"
> splot '-'   using 1:2:3:4:5:6 notitle with vectors , \
>       '-'   using 1:2:3:4:5:6 notitle with vectors
> 0.0 0.0 0.0 0.3333335701378377 0.0 0.0
> 0.0 0.0 0.0 0.0 0.3333335701378377 0.0
> 0.0 0.0 0.0 0.0 0.0 0.6666671402756754
> e
> -1.487915757943345 -0.8842424394390623 4.822904587742955 0.3295936234755228 -0.004829189464130801 0.04955795873753832
> -1.487915757943345 -0.8842424394390623 4.822904587742955 0.0054208354243061585 0.33327029824180776 -0.0035765673425567357
> -1.487915757943345 -0.8842424394390623 4.822904587742955 -0.09899347227801636 0.008684749800146774 0.6592191922953985
> e
> set output
> 
> 
> 


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

xyplane tics too large with orthogonal splot views

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

Hi. I just made some 3D plots from an orthogonal side view (set view
90,0). This has special-case logic in gnuplot to treat it like a 2D plot
in some ways. It looks like the logic isn't completely right, though,
and the tics on the xy plane end up larger than they should. And the
tics appear on both sides of the plane, which isn't obviously right. Can
somebody please take a look?

This happens with the latest gnuplot in git.

The script appears below, and the result is attached.

Thanks!



set view 90,0
set xyplane at -0.1
set xtics 0.5
set ytics 0.5
set view equal xyz
set xlabel "x"
set ylabel "y"
set zlabel "z"

set terminal png size 600,1000
set output "/tmp/tics-too-big.png"
splot '-'   using 1:2:3:4:5:6 notitle with vectors , \
      '-'   using 1:2:3:4:5:6 notitle with vectors
0.0 0.0 0.0 0.3333335701378377 0.0 0.0
0.0 0.0 0.0 0.0 0.3333335701378377 0.0
0.0 0.0 0.0 0.0 0.0 0.6666671402756754
e
-1.487915757943345 -0.8842424394390623 4.822904587742955 0.3295936234755228 -0.004829189464130801 0.04955795873753832
-1.487915757943345 -0.8842424394390623 4.822904587742955 0.0054208354243061585 0.33327029824180776 -0.0035765673425567357
-1.487915757943345 -0.8842424394390623 4.822904587742955 -0.09899347227801636 0.008684749800146774 0.6592191922953985
e
set output

x11 plotting into an existing window behaves badly if the window doesn't (yet) exist

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

Hi. I'm using the x11 terminal to plot into an existing window:

  set terminal x11 window XID

Overall it works really well. I'm seeing an issue when the requested
window doesn't exist: gnuplot simply ignores the request, and pops up a
new X window, as usual. This is never what the user intends, I think.

A less made-up scenario is what I actually encountered when trying to
use this feature: I made a new window, and asked gnuplot to plot into
it. This didn't work because my new target window hasn't been created
YET.

Trying to debug this, I added some more diagnostics to gplt_x11.c
(attached; these should be good-enough to merge). I see that the
failing sequence is:

- in pr_window() gplt_x11.c calls XGetWindowAttributes() on the
  requested window. This is the first time gnuplot does anything with
  the requested window

- If the window already exists, this succeeds, and we continue, happily.
  If not, the error handler is invoked instead. Here's the diagnostic
  output produced with DEBUG:

    gplt_x11.c:1655 psp->external_container = 0x2400005
    gplt_x11.c:6679 (pr_window) 
    gplt_x11.c:6683 was asked to plot externally...
    gplt_x11.c:4354 Received X error:  error_code=BadWindow request_code=X_GetWindowAttributes minor_code=0
    gplt_x11.c:7230 Add plot to remove FIFO queue called.
    gplt_x11.c:7269   -> Added an element to FIFO queue.
    gplt_x11.c:6692 making plot window
    gplt_x11.c:4354 Received X error:  error_code=BadWindow request_code=X_CreateWindow minor_code=0
    gplt_x11.c:7230 Add plot to remove FIFO queue called.
    gplt_x11.c:4354 Received X error:  error_code=BadWindow request_code=X_ChangeWindowAttributes minor_code=0
    gplt_x11.c:7230 Add plot to remove FIFO queue called.
    gplt_x11.c:7269   -> Added an element to FIFO queue.
    gplt_x11.c:4354 Received X error:  error_code=BadWindow request_code=X_ChangeProperty minor_code=0
    gplt_x11.c:7230 Add plot to remove FIFO queue called.
    gplt_x11.c:4354 Received X error:  error_code=BadWindow request_code=X_ChangeProperty minor_code=0
    gplt_x11.c:7230 Add plot to remove FIFO queue called.
    gplt_x11.c:4354 Received X error:  error_code=BadWindow request_code=X_ChangeProperty minor_code=0
    gplt_x11.c:7230 Add plot to remove FIFO queue called.
    gplt_x11.c:4354 Received X error:  error_code=BadWindow request_code=X_ChangeWindowAttributes minor_code=0
    gplt_x11.c:7230 Add plot to remove FIFO queue called.
    gplt_x11.c:4354 Received X error:  error_code=BadWindow request_code=X_ChangeWindowAttributes minor_code=0
    gplt_x11.c:7230 Add plot to remove FIFO queue called.
    gplt_x11.c:6795 term_number is -1
    gplt_x11.c:4778 Cursors reset
    gplt_x11.c:7321 Processed element in remove FIFO queue.
    gplt_x11.c:1209 Delete plot -1
    gplt_x11.c:1233 Destroy window 0x36000fe
    gplt_x11.c:7321 Processed element in remove FIFO queue.
    gplt_x11.c:7063 psp->external_container = None
    ...

  The line numbers are off, since I had some extra diagnostic code. We
  do see that X errors are received for every request that touches the
  not-yet-existing window, the error handler does some complex thing I
  don't yet understand, and eventually we psp->external_container =
  None, i.e. we give up on plotting to the requested window, and create
  a new one, as usual.


Would it not make more sense for gplt_x11 to retry
XGetWindowAttributes() call until the requested window exists? I'm not
familiar with Xlib error handling, and this doesn't look completely
trivial, so I wanted to ask here first. Anybody here have experience
with Xlib, and suggestions on the "right" way to implement that?

Thanks

Re: Gnuplot Version 5.4.4 Release

[Tatsuro M. <tma...@ya...>]

I have uploaded windows binary packages.

Tatsuro

> ----- Original Message -----
> Date: 2022/07/18 月 12:32
> Subject: Gnuplot Version 5.4.4 Release
> 
> 
> Release 5.4.4 is now available for download from SourceForge
> 
> Thanks to everyone who tested prior release and to everyone who sent
> bug reports or suggested changes.
> 
> Source tarball
> 
>     https://sf.net/projects/gnuplot/files/gnuplot/5.4.4/gnuplot-5.4.4.tar.gz
> 
> Release notes (10-Jul-2022)
> 
> This release contains bug fixes and a few changes back-ported from the
> development version.  Probably the most noticeable is modification to
> make page layout of 3D plots after "set view map; splot ..." more like
> the corresponding page layout of 2D plots, including display of x2 and y2
> axis labels.
> 
> Changes in 5.4.4
> ================
> * NEW plots can use arrow styles that specify "lc rgb variable" 
> * CHANGE make page layout of "set view map; splot" more like that of "plot"
> *        - honor "set rmargin" and "set tmargin" Bug #2484
> *        - display x2label and y2label Bug #2484
> *        - revised placement of color box Bug #2484
> *        - reconcile linked axis data and tic ranges Bug #2483
> *        - apply "set key invert" to splot Bug #2381
> * CHANGE cairo terminals: increase internal oversampling factor Bugs #2499 #2369
> * CHANGE fig: restore terminal option "pointsmax <N>" Bug #2509
> * CHANGE always add a space between items in a "print" command Bug #2488
> * CHANGE consistent ordering of input columns for "plot ... ps var pt var" Bug #2524
> * CHANGE gnuplot -c script.gp A B -C ... will pass A B -C ... without interpretation
> * CHANGE stricter error checks when promoting string to numeric value Bug #2527
> * CHANGE report GPVAL_TERM_XMIN and friends as floating point values
> * FIX handle combination of axis properties logscale + autoscale + reverse Bug #2347
> * FIX mis-handled arguments at start-up of "gnuplot -c script arg1 ..." Bug #2493
> * FIX windows: redirected output of printf() Bug #2490
> * FIX allow variable point style and point type in plot "with yerrorbars"
> * FIX plots "with labels point pt variable" were off-by-one in choosing point type
> * FIX contour "with labels" from binary data
> * FIX x/y fractional coordinate mouse readout for nonlinear axes Bug #2526
> * FIX Support combination of "set surface explicit; set hidden3d" Bug #2521
> 
> 
>         happy gnuplotting,
> 
>                 Ethan 
> 
> 
> 
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: Gnuplot Version 5.4.4 Release

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

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

> Release 5.4.4 is now available for download from SourceForge

Thanks for working on this, Ethan!

Gnuplot Version 5.4.4 Release

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

Release 5.4.4 is now available for download from SourceForge

Thanks to everyone who tested prior release and to everyone who sent
bug reports or suggested changes.

Source tarball

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

Release notes (10-Jul-2022)

This release contains bug fixes and a few changes back-ported from the
development version.  Probably the most noticeable is modification to
make page layout of 3D plots after "set view map; splot ..." more like
the corresponding page layout of 2D plots, including display of x2 and y2
axis labels.

Changes in 5.4.4
================
* NEW plots can use arrow styles that specify "lc rgb variable" 
* CHANGE make page layout of "set view map; splot" more like that of "plot"
*        - honor "set rmargin" and "set tmargin" Bug #2484
*        - display x2label and y2label Bug #2484
*        - revised placement of color box Bug #2484
*        - reconcile linked axis data and tic ranges Bug #2483
*        - apply "set key invert" to splot Bug #2381
* CHANGE cairo terminals: increase internal oversampling factor Bugs #2499 #2369
* CHANGE fig: restore terminal option "pointsmax <N>" Bug #2509
* CHANGE always add a space between items in a "print" command Bug #2488
* CHANGE consistent ordering of input columns for "plot ... ps var pt var" Bug #2524
* CHANGE gnuplot -c script.gp A B -C ... will pass A B -C ... without interpretation
* CHANGE stricter error checks when promoting string to numeric value Bug #2527
* CHANGE report GPVAL_TERM_XMIN and friends as floating point values
* FIX handle combination of axis properties logscale + autoscale + reverse Bug #2347
* FIX mis-handled arguments at start-up of "gnuplot -c script arg1 ..." Bug #2493
* FIX windows: redirected output of printf() Bug #2490
* FIX allow variable point style and point type in plot "with yerrorbars"
* FIX plots "with labels point pt variable" were off-by-one in choosing point type
* FIX contour "with labels" from binary data
* FIX x/y fractional coordinate mouse readout for nonlinear axes Bug #2526
* FIX Support combination of "set surface explicit; set hidden3d" Bug #2521


        happy gnuplotting,

                Ethan 

Re: Beta-testing version of 5.4.4

[Tatsuro M. <tma...@ya...>]

Thank you for your effort.

I did test build 5.4.4beta source on Windows (mingw64) and build and all.dem checks did well
I also confirmed bug #2532 was corrected on 5.4.3 on windows(mingw64).

Tatsuro

----- Original Message -----

From: "Ethan A Merritt" 
To: "Gnuplot Beta" 
Date: 2022/07/11 月 04:36
Subject: Beta-testing version of 5.4.4


I have placed a tarball for a beta-test version of gnuplot 5.4.3 on SourceForge.
Please report any problems,

There is nothing special in this minor release.
It mostly consists of small fixes back-ported from the development version.
The most visible change is that auto-layout of 3D plots after "set view map"
is more similar to the auto-layout of 2D plots, including display of x2 and y2
axis labels if they are present.
 
For a slightly more complete list of changes see the Release Notes.

 https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/gnuplot-5.4.4beta.tar.gz

My plan is to announce the 5.4.4 release in a week or so.

       happy gnuplotting,

               Ethan



_______________________________________________
gnuplot-beta mailing list
gnu...@li...
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Beta-testing version of 5.4.4

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

I have placed a tarball for a beta-test version of gnuplot 5.4.3 on SourceForge.
Please report any problems,

There is nothing special in this minor release.
It mostly consists of small fixes back-ported from the development version.
The most visible change is that auto-layout of 3D plots after "set view map"
is more similar to the auto-layout of 2D plots, including display of x2 and y2
axis labels if they are present.
 
For a slightly more complete list of changes see the Release Notes.

  https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/gnuplot-5.4.4beta.tar.gz

My plan is to announce the 5.4.4 release in a week or so.

        happy gnuplotting,

                Ethan

Re: Beta-testing version of 5.4.4

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

On Sunday, 10 July 2022 11:33:13 PDT Ethan A Merritt wrote:
> I have placed a tarball for a beta-test version of gnuplot 5.4.3 on SourceForge.
                                                                            
                              meh, that shoud of course read "gnuplot 5.4.4"

> Please report any problems,
> 
> There is nothing special in this minor release.
> It mostly consists of small fixes back-ported from the development version.
> The most visible change is that auto-layout of 3D plots after "set view map"
> is more similar to the auto-layout of 2D plots, including display of x2 and y2
> axis labels if they are present.
>  
> For a slightly more complete list of changes see the Release Notes.
> 
>   https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/gnuplot-5.4.4beta.tar.gz
> 
> My plan is to announce the 5.4.4 release in a week or so.
> 
>         happy gnuplotting,
> 
>                 Ethan

Re: ABI mismatch erorr on wxt terminal on the current msys2-windows build (GCC 12) and workaound

[Tatsuro M. <tma...@ya...>]

----- Original Message -----
Date: 2022/05/27 金 02:24
Subject: Re: ABI mismatch erorr on wxt terminal on the current msys2-windows build  (GCC 12) and workaound


On Wednesday, 25 May 2022 22:03:57 PDT Tatsuro MATSUOKA wrote:
> I updated msys2-mingw64 recently and GCC is upgraded to version 12.
> I tried to build gnuplot for windows using GCC 12 and tried to use the wxt terminal.
> gnuplot> set terminal wxt
> gnuplot> pl x
>
> Error windows poped up.
> URL of the Screenshot http://tmacchant33.starfree.jp/Files/wxt_ABI_mismatch.png
>
> Fatal Error
> Mismatch between the program and library build version
> detected.
> The library used 3.0(wchar_t,complier with C++ ABI 1016, wx
> containers, compatible with 2.8),
> and your program used 3.0 (wchr_t,compiler with C++ ABI
> 1017, wx containers, compatible with 2.8).

That is an unfortunate bug/mis-design introduced by the some runtime library support.
I do not know whether something in gcc 12 is the cause, or whether the change from
gcc 11 to gcc 12 coincidentally happened at the same time.

I now get similar error messages when running programs compiled before the change
For example:
 [] gnuplot_5.2.8 -e 'plot x' 
 Warning: Mismatch between the program and library build versions detected. 
 The library used 2.8 (no debug,Unicode,compiler with C++ ABI 1014,wx containers,compatible with 2.6), 
 and your program used 2.8 (no debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible with 2.6).
 [] gnuplot_5.4.2 -e 'plot x'   
 Warning: Mismatch between the program and library build versions detected. 
 The library used 3.0 (wchar_t,compiler with C++ ABI 1014,wx containers,compatible with 2.8), 
 and wxNet used 3.0 (wchar_t,compiler with C++ ABI 1013,wx containers,compatible with 2.8).
These executables were built in 2019 and 2021. The C compiler used at the
time would not have been gcc 12. The programs executed correctly when they were
built and continue to execute correctly now.
But now they emit this annoying warning message.
 
 > Workaround is to insert " #define __GXX_ABI_VERSION 1016"
> at the top of src/wxt_gui.cpp
> --- a/src/wxterminal/wxt_gui.cpp   2022-05-26 12:37:23.464908700 +0900
> +++ b/src/wxterminal/wxt_gui.cpp   2022-05-26 13:10:10.970037600 +0900
> @@ -88,6 +88,8 @@
>  * or multi-threaded operation.
>  */
> 
> +/* avoid mismatch message C++ ABI number*/
> +#define __GXX_ABI_VERSION 1016

I don't think that is a good idea.

That work-around is likely to work only on a machine that happens to use
that specific version of the runtime library.
As soon as you run the executable on a machine with a newer or older runtime
then it will probably complain about a mismatch between 1016 and some other
version number.  I'm pretty sure it is the warning message that is bogus,
not the program.

Having said that, however, your report claims a fatal error. My machines
are only printing this as a warning. Perhaps the mismatch between versions
1016 and 1017 really is more serious?  But then hiding it by lying about the
true version would not fix it. The program may crash later on when it hits the
incompatible ABI feature, whatever that is.

I found some reports on the web that suggest the true problem is an improper
configuration flag used to build the wxgtk library. However, that doesn't make
sense to me, since the error message has only started to appear recently
even though both the wxgtk library and the executable that links to it are
several years old. I suspect rather that the linker/loader has become overly
paranoid about comparing compiler versions reported by libraries and programs.
I do not know how to fix that.

   Ethan

Today I updated the msys2-mingw64. The wxWidgets package was updated.
The new wxWidgets libraries seemed to be re-built with gcc-12.
The ABI mismatch issue is disappeared.

Thank you for your detailed comments and explanations.

Tatsuro

Re: ABI mismatch erorr on wxt terminal on the current msys2-windows build (GCC 12) and workaound

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

On Wednesday, 25 May 2022 22:03:57 PDT Tatsuro MATSUOKA wrote:
> I updated msys2-mingw64 recently and GCC is upgraded to version 12.
> I tried to build gnuplot for windows using  GCC 12 and tried to use the wxt terminal.
> gnuplot> set terminal wxt
> gnuplot> pl x
> 
> Error windows poped up.
> URL of  the Screenshot http://tmacchant33.starfree.jp/Files/wxt_ABI_mismatch.png
> 
> Fatal Error
> Mismatch between the program and library build version 
> detected.
> The library used 3.0(wchar_t,complier with C++ ABI 1016, wx
> containers, compatible with 2.8),
> and your program used 3.0 (wchr_t,compiler with C++ ABI
> 1017, wx containers, compatible with 2.8).

That is an unfortunate bug/mis-design introduced by the some runtime library support.
I do not know whether something in gcc 12 is the cause, or whether the change from
gcc 11 to gcc 12 coincidentally happened at the same time. 

I now get similar error messages when running programs compiled before the change
For example:
  [] gnuplot_5.2.8 -e 'plot x' 
  Warning: Mismatch between the program and library build versions detected. 
  The library used 2.8 (no debug,Unicode,compiler with C++ ABI 1014,wx containers,compatible with 2.6), 
  and your program used 2.8 (no debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible with 2.6).
  [] gnuplot_5.4.2 -e 'plot x'    
  Warning: Mismatch between the program and library build versions detected. 
  The library used 3.0 (wchar_t,compiler with C++ ABI 1014,wx containers,compatible with 2.8), 
  and wxNet used 3.0 (wchar_t,compiler with C++ ABI 1013,wx containers,compatible with 2.8).
These executables were built in 2019 and 2021.  The C compiler used at the
time would not have been gcc 12. The programs executed correctly when they were
built and continue to execute correctly now.
But now they emit this annoying warning message.


> Workaround is to insert " #define __GXX_ABI_VERSION 1016" 
> at the top of src/wxt_gui.cpp
> --- a/src/wxterminal/wxt_gui.cpp	2022-05-26 12:37:23.464908700 +0900
> +++ b/src/wxterminal/wxt_gui.cpp	2022-05-26 13:10:10.970037600 +0900
> @@ -88,6 +88,8 @@
>   * or multi-threaded operation.
>   */
>  
> +/* avoid mismatch message C++ ABI number*/
> +#define __GXX_ABI_VERSION 1016

I don't think that is a good idea.

That work-around is likely to work only on a machine that happens to use
that specific version of the runtime library.
As soon as you run the executable on a machine with a newer or older runtime
then it will probably complain about a mismatch between 1016 and some other
version number.   I'm pretty sure it is the warning message that is bogus,
not the program.

Having said that, however, your report claims a fatal error.  My machines
are only printing this as a warning.  Perhaps the mismatch between versions
1016 and 1017 really is more serious?   But then hiding it by lying about the
true version would not fix it. The program may crash later on when it hits the
incompatible ABI feature, whatever that is.

I found some reports on the web that suggest the true problem is an improper
configuration flag used to build the wxgtk library.  However that doesn't make
sense to me, since the error message has only started to appear recently
even though both the wxgtk library and the executable that links to it are
several years old.  I suspect rather that the linker/loader has become overly
paranoid about comparing compiler versions reported by libraries and programs.
I do not know how to fix that.

	Ethan

ABI mismatch erorr on wxt terminal on the current msys2-windows build (GCC 12) and workaound

[Tatsuro M. <tma...@ya...>]

I updated msys2-mingw64 recently and GCC is upgraded to version 12.
I tried to build gnuplot for windows using  GCC 12 and tried to use the wxt terminal.
gnuplot> set terminal wxt
gnuplot> pl x

Error windows poped up.
URL of  the Screenshot http://tmacchant33.starfree.jp/Files/wxt_ABI_mismatch.png

Fatal Error
Mismatch between the program and library build version 
detected.
The library used 3.0(wchar_t,complier with C++ ABI 1016, wx
containers, compatible with 2.8),
and your program used 3.0 (wchr_t,compiler with C++ ABI
1017, wx containers, compatible with 2.8).

Workaround is to insert " #define __GXX_ABI_VERSION 1016" 
at the top of src/wxt_gui.cpp


--- a/src/wxterminal/wxt_gui.cpp	2022-05-26 12:37:23.464908700 +0900
+++ b/src/wxterminal/wxt_gui.cpp	2022-05-26 13:10:10.970037600 +0900
@@ -88,6 +88,8 @@
  * or multi-threaded operation.
  */
 
+/* avoid mismatch message C++ ABI number*/
+#define __GXX_ABI_VERSION 1016
 
 /* define DEBUG here to have debugging messages in stderr */
 /* #define DEBUG */





Tatsuro

Re: Trouble with contours and binary arrays

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

Thank you very much Ethan. The contour label workaround is really
helpful. If you weren't concerned about breaking existing scripts, would
supporting generic 'using' expressions be a simple tweak, or would it
involve lots of code? It's really annoying that ascii arrays work the
way you'd expect, but binary ones don't. So maybe supporting both the
compatibility path and the "expected" path would still make sense.

Thanks

Re: Trouble with contours and binary arrays

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

On Monday, 16 May 2022 15:39:25 PDT Dima Kogan wrote:
> Hi. I'm having trouble with contoured plots, and I'm guessing there's at
> least one gnuplot bug here. Can I please get some pointers?
> 
[snip]
> 
> But if I add the transform, it is ignored by the contours. THIS doesn't work:
> 
>   set view map
>   set contour base
>   splot "sincos.float32" binary array=(90,100) format="%float" using ($1+100) with lines nosurface

I was focused on explaining why normal using specifiers don't work for
binary array data.

What I didn't think to point out was that for the specific case of a
constant offset, as in your example, you don't need a using specifier:

  splot "sincos.float32" binary array=(90,100) format="%float" origin=(0,0,100) with lines 

	Ethan

Re: Trouble with contours and binary arrays

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

On Monday, 16 May 2022 15:39:25 PDT Dima Kogμan wrote:
> Hi. I'm having trouble with contoured plots, and I'm guessing there's at
> least one gnuplot bug here. Can I please get some pointers?
> 
> I make a binary data file. This is an regular matrix of 32-bit floats:
> 
>   perl -E 'for $i (0..99) { for $j (0..89) { $f=sin($i/30.)+cos($j/5.); print pack("f",$f); }}' > /tmp/sincos.float32
> 
> For convenience I'm attaching this data.
> 
> I can successfully plot a heatmap:
> 
>   splot "sincos.float32" binary array=(90,100) format="%float" with image


[snip]


> Second issue. I'd like to plot boxed contour labels. This works OK with
> ASCII matrix data, but with binary data it doesn't work. I run this
> gunplot script:
> 
>   set view map
>   set contour base
>   splot "sincos.float32" binary array=(90,100) format="%float" with labels boxed nosurface
> 
> And I see this:
> 
>   "cmd" line 3: warning: Couldn't slurp 72000 bytes (return was 36000)
> 
>   splot "sincos.float32" binary array=(90,100) format="%float" with labels boxed nosurface
>                                                                                           ^
>   "cmd" line 3: All points x value undefined
> 
> For whatever reason it's trying to read 8 bytes per point instead of 4.
> Some brief debugging tells me it thinks there're two values to read from
> each point, when in reality there's just one.
> 
> Thoughts?


This second issue is a simple bug.  The default number of input columns is taken as 2
(z value + label text) but for contour labels there is no separate second input column.
You can work around this by giving an explicit "using <foo>" in the splot command:

   splot "sincos.float32" binary array=(90,100) format="%float" using ("foo") with labels boxed nosurface

That gets you auto-generated labels that correspond to the input binary z values.
As before, however, those values are taken as-is.
You still cannot modify the z values via a using specifier.

	Ethan

Re: Trouble with contours and binary arrays

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

(apologies if you see this twice)

On Monday, 16 Mμay 2022 15:39:25 PDT Dima Kogan wrote:
> Hi. I'm having trouble with contoured plots, and I'm guessing there's at
> least one gnuplot bug here. Can I please get some pointers?
> 
> I make a binary data file. This is an regular matrix of 32-bit floats:
> 
>   perl -E 'for $i (0..99) { for $j (0..89) { $f=sin($i/30.)+cos($j/5.); print pack("f",$f); }}' > /tmp/sincos.float32
> 
> For convenience I'm attaching this data.
> 
> I can successfully plot a heatmap:
> 
>   splot "sincos.float32" binary array=(90,100) format="%float" with image
> 
> I can also transform the data and plot:
> 
>   splot "sincos.float32" binary array=(90,100) format="%float" using ($1+100) with image


Image data is treated as a special case, so keep that in mind as we continue through this.


> This all works. Without the transform, I can also plot contours:
> 
>   set view map
>   set contour base
>   splot "sincos.float32" binary array=(90,100) format="%float" with lines nosurface
> 
> But if I add the transform, it is ignored by the contours. THIS doesn't
> work:
> 
>   set view map
>   set contour base
>   splot "sincos.float32" binary array=(90,100) format="%float" using ($1+100) with lines nosurface
> 
> There's no error message. It just produces the untransformed data.


Let's simplify by  just plotting the surface rather than contouring.
We find that
*     splot "sincos.float32" binary array=(90,100) format="%float" with lines*
works as expected.


However
*     splot "sincos.float32" binary array=(90,100) format="%float" using ($1+100)*
seemingly ignores the using spec.  This is the same thing you ran into with contouring.


Why?  
The handling of binary array/matrix data is really weird.  
I hate it, but what happens is this:


1) The program uses the "binary array=(x,y)" clause to fill in the x and y coordinates


2) The program uses the plot type to fill in the z coordinate directly from the data
    provided by the format specifier "%float".


Now it gets weird


3) The program advances the count of data columns consumed by 2 ("plot") or 3 ("splot").


4) Only now does the program look at the using specifier.  But since it advanced the 
    column count in step (3), the column numbers in the using spec are now off by either
    2 or 3 depending on whether it's a "plot" or "splot" command.   
    This means that the operation ($1+100) is actually used to stuff data value 4
     rather than data value 1 (which is x) or z (which was stuffed in data value 3).


5) If there are additional using specs, they are used for data values 5, 6, ... and so on.


The upshot is that the using specifiers _can_ affect the plot, but not as x/y/z coordinates.
For instance you could do:


*    splot "sincos.float32" binary array=(90,100) format="%float" using ($1*$1) lc variable*


The x/y/z coordinates of the surface will be exactly the same as before.
However the variable color is taken from data value 4 so the using spec can now be seen
to have an actual effect.


Where does that leave us?
If we were designing the binary input code starting now, I would argue for
doing it very differently.  But redesign of the existing commands would completely
break backwards compatibility so I don't think that's an option.
Introducing a new binary input syntax in parallel while keeping the old 
one sounds just as unattractive.  So I am at a loss how to improve things.


The image handling code also plays fast and loose with the data columns,
although that is a separate code path.  It is not currently possible, for example,
to make a 3D histogram plot of the Green component of a color image.
Exactly analogous to your matrix contouring case, you cannot re-assign the
x/y/z coordinates based on image pixel values.


> Second issue. I'd like to plot boxed contour labels. 


I have not looked at this one yet.
It may or may not come down to the same thing.


    Ethan


> This works OK with
> ASCII matrix data, but with binary data it doesn't work. I run this
> gunplot script:
> 
>   set view map
>   set contour base
>   splot "sincos.float32" binary array=(90,100) format="%float" with labels boxed nosurface
> 
> And I see this:
> 
>   "cmd" line 3: warning: Couldn't slurp 72000 bytes (return was 36000)
> 
>   splot "sincos.float32" binary array=(90,100) format="%float" with labels boxed nosurface
>                                                                                           ^
>   "cmd" line 3: All points x value undefined
> 
> For whatever reason it's trying to read 8 bytes per point instead of 4.
> Some brief debugging tells me it thinks there're two values to read from
> each point, when in reality there's just one.
> 
> Thoughts?
> 
> Thanks!
> 
> 


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

Re: Trouble with contours and binary arrays

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

On Monday, 16 Mμay 2022 15:39:25 PDT Dima Kogan wrote:
> Hi. I'm having trouble with contoured plots, and I'm guessing there's at
> least one gnuplot bug here. Can I please get some pointers?
> 
> I make a binary data file. This is an regular matrix of 32-bit floats:
> 
>   perl -E 'for $i (0..99) { for $j (0..89) { $f=sin($i/30.)+cos($j/5.); print pack("f",$f); }}' > /tmp/sincos.float32
> 
> For convenience I'm attaching this data.
> 
> I can successfully plot a heatmap:
> 
>   splot "sincos.float32" binary array=(90,100) format="%float" with image
> 
> I can also transform the data and plot:
> 
>   splot "sincos.float32" binary array=(90,100) format="%float" using ($1+100) with image

Image data is treated as a special case, so keep that in mind as we continue through this.

> This all works. Without the transform, I can also plot contours:
> 
>   set view map
>   set contour base
>   splot "sincos.float32" binary array=(90,100) format="%float" with lines nosurface
> 
> But if I add the transform, it is ignored by the contours. THIS doesn't
> work:
> 
>   set view map
>   set contour base
>   splot "sincos.float32" binary array=(90,100) format="%float" using ($1+100) with lines nosurface
> 
> There's no error message. It just produces the untransformed data.

Let's simplify by  just plotting the surface rather than contouring.
We find that
*     splot "sincos.float32" binary array=(90,100) format="%float" with lines*
works as expected.

However
*     splot "sincos.float32" binary array=(90,100) format="%float" using ($1+100)*
seemingly ignores the using spec.  This is the same thing you ran into with contouring.

Why?  
The handling of binary array/matrix data is really weird.  
I hate it, but what happens is this:

1) The program uses the "binary array=(x,y)" clause to fill in the x and y coordinates

2) The program uses the plot type to fill in the z coordinate directly from the data
    provided by the format specifier "%float".

Now it gets weird

3) The program advances the count of data columns consumed by 2 ("plot") or 3 ("splot").

4) Only now does the program look at the using specifier.  But since it advanced the 
    column count in step (3), the column numbers in the using spec are now off by either
    2 or 3 depending on whether it's a "plot" or "splot" command.   
    This means that the operation ($1+100) is actually used to stuff data value 4
     rather than data value 1 (which is x) or z (which was stuffed in data value 3).

5) If there are additional using specs, they are used for data values 5, 6, ... and so on.

The upshot is that the using specifiers _can_ affect the plot, but not as x/y/z coordinates.
For instance you could do:

*    splot "sincos.float32" binary array=(90,100) format="%float" using ($1*$1) lc variable*

The x/y/z coordinates of the surface will be exactly the same as before.
However the variable color is taken from data value 4 so the using spec can now be seen
to have an actual effect.

Where does that leave us?
If we were designing the binary input code starting now, I would argue for
doing it very differently.  But redesign of the existing commands would completely
break backwards compatibility so I don't think that's an option.
Introducing a new binary input syntax in parallel while keeping the old 
one sounds just as unattractive.  So I am at a loss how to improve things.

The image handling code also plays fast and loose with the data columns,
although that is a separate code path.  It is not currently possible, for example,
to make a 3D histogram plot of the Green component of a color image.
Exactly analogous to your matrix contouring case, you cannot re-assign the
x/y/z coordinates based on image pixel values.


> Second issue. I'd like to plot boxed contour labels. 

I have not looked at this one yet.
It may or may not come down to the same thing.

	Ethan

> This works OK with
> ASCII matrix data, but with binary data it doesn't work. I run this
> gunplot script:
> 
>   set view map
>   set contour base
>   splot "sincos.float32" binary array=(90,100) format="%float" with labels boxed nosurface
> 
> And I see this:
> 
>   "cmd" line 3: warning: Couldn't slurp 72000 bytes (return was 36000)
> 
>   splot "sincos.float32" binary array=(90,100) format="%float" with labels boxed nosurface
>                                                                                           ^
>   "cmd" line 3: All points x value undefined
> 
> For whatever reason it's trying to read 8 bytes per point instead of 4.
> Some brief debugging tells me it thinks there're two values to read from
> each point, when in reality there's just one.
> 
> Thoughts?
> 
> Thanks!
> 
>