#880 plot '-' with binary : gnuplot for windows

[Tatsuro MATSUOKA]

Hello

The attached file zipped gnuplot script, which was obtained from octave on cygwin.
I have modified the terminal from x11 to png.

In the script one can find,
plot "-" binary format='%float64' record=161 using ($1):($2) axes x1y1 title "" with lines linestyle 1 \ ;
(binary data)

If I execute this script gnuplot-4.5 on cygwin,

gnuplot> load 'gnuplotstream.gp'
gnuplot> set out

or
From the shell,
$ gnuplot gnuplotstream.gp

gives correct output

However, gnuplot for windows (both 4.4.0 and 4.5)
the above operation gives an empty png file.

Interestingly, the script passed via the pipe, the script gives a correct png file even on the gnuplot for windows
d:\xxx\xx> type gnuplotstream.gp | gnuplot

I have a quick look into the source codes but I cannot figure out which code is to be concerned the phenomena.

Reference: this topic comes from octave threads
See
http://n4.nabble.com/Gnuplot-scripts-as-output-td1680624.html#none

Regards

Tatsuro

[Tatsuro MATSUOKA]

[Petr Mikulik]

I've just tried it, and it seems the problem is this one:
set palette file "-" binary record=64 using 1:2:3:4
but not
plot "-" binary format='%float64' record=161 ...

[Tatsuro MATSUOKA]

gdb trace (around set_palette_file () at set.c:2780).

[Tatsuro MATSUOKA]

>>it seems the problem is this one:
set palette file "-" binary record=64 using 1:2:3:4

Indeed the file attached is a part of the gdb traces (around set_palette_file () at set.c:2780). From some reason, the binary data seems not to be read correctly on windows.

[Tatsuro MATSUOKA]

>it seems the problem is this one:
>set palette file "-" binary record=64 using 1:2:3:4

Indeed the file attached is a part of the gdb traces (around set_palette_file () at set.c:2780).
From some reason, the binary data seems not to be read correctly on windows.

[Tatsuro MATSUOKA]

palette cut script and two snapshots

[Tatsuro MATSUOKA]

>it seems the problem is this one:
>set palette file "-" binary record=64 using 1:2:3:4

Looking into graph in detail, the above seemed not to be right.
The gpcut.zip includes
gpcut.gp : plot steam file, set palette part is cut.
viapipe.png : plot generated by 'type gpcut.gp | gnuplot'
Frombatch.png : plot generated by gnuplot gpcut.gp
The same as Frombatch.png obtained by load 'gpcut.gp' at gnuplot prompt.
Apparently Frombatch.png lacks of some data.
I suspect that end part of data were omitted in reading binary data via '-' from the file but not pipe on gnuplot on windows.

[Bastian Märkisch]

The problem is that script files are opened in text mode, which interferes with binary data due to the CR/LF translation. Adding
if (fp) _setmode(fileno(fp), _O_BINARY);
at the end of loadpath_fopen() in misc.c solves this particular problem, but does seem to have side-effects for text inline data.

[Ethan Merritt]

Could we open the file twice, so that there are two fps available - one for reading text and one for reading binary? The program knows when it is expecting binary data, so it could use the appropriate fp for the read operation.
I guess what I'm asking is whether the fseek() implementation for Windows returns identical offsets for parallel text and binary streams.

[Bastian Märkisch]

According to docs, it does not seem to be possible (or portable) to keep an ascii fp and binary fp in sync. Current CVS now always opens files in binary mode on Windows. If that should actually turn out to have side effects, there should still be enough time to fix them before the release.

[Bastian Märkisch]

I have tested this with MinGW/gcc and the result depends on the eol style of the text file. With CRLF line endings, ftell() on the ascii file gives the correct position for feek() on the binary file - but with LF only line endings it does not. Documentation tells us that this does not necessarily has to be that way for other compilers.