has2k1 / gnuplot_kernel

A Jupyter/IPython kernel for gnuplot
BSD 3-Clause "New" or "Revised" License
83 stars 25 forks source link

Diverting output to file does not work #17

Closed esternin closed 4 years ago

esternin commented 5 years ago

Interactively, to generate a hardcopy of the currently displayed plot, one typically performs something like:

set output 'file.eps'
set terminal eps
replot
unset output
set terminal qt

I even have a print.gp file that does just that, so I load 'print.gp'.

Trying to do the same from inside a jupyter python 3 notebook, with gnuplot_kernel loaded does not seem to work. ``` %load_ext gnuplot_kernel ``` ``` %gnuplot inline pngcairo size 640,480 font "Palatino,16" ``` ``` %%gnuplot plot sin(x) set output 'gnuplot.eps' set terminal postscript eps size 6.4,4.8 replot ``` ``` %%bash ls -la gnuplot.eps ``` reports an empty file, i.e. file gets created but has zero size. In the attached PDF, note also the broken image file icon at that point in the output. On the other hand, ``` %gnuplot postscript eps size 6.4,4.8 ``` ``` %%gnuplot set output 'gnuplot.eps' plot cos(x) ``` works as expected, except, of course, there is no seeing the plot before producing a hardcopy. Is this as expected, or am I doing something wrong? [mozilla.pdf](https://github.com/has2k1/gnuplot_kernel/files/2784559/mozilla.pdf)

esternin commented 4 years ago

Uh... closing this issue implies the bug is fixed? - I could not verify that, even when I updated to the development version. Should I just wait for an update/release, as there seems to be a major bug-fixing effort under way? (Ubuntu LTS 20.04, gnuplot_kernel 0.3.0)

has2k1 commented 4 years ago

Yes it has been fixed, but not exactly as you tried to do it. replot uses the current terminal so if you plot a .eps to a file you have to change the terminal to one that allows inline images e.g. pngcairo. Or you could change to an interactive terminal like qt.

I have included an example in the gnuplot-kernel.ipynb.

I will make a release tomorrow.

On Tue, May 12, 2020, 1:27 AM esternin, notifications@github.com wrote:

Uh... closing this issue implies the bug is fixed? - I could not verify that, even when I updated to the development version. Should I just wait for an update/release, as there seems to be a major bug-fixing effort under way? (Ubuntu LTS 20.04, gnuplot_kernel 0.3.0)

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/has2k1/gnuplot_kernel/issues/17#issuecomment-626999154, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAF6QNOUX6LEOJX5HMAGAADRRB3VJANCNFSM4GRWEFFA .

esternin commented 4 years ago

Hmm....

%load_ext gnuplot_kernel
%gnuplot inline pngcairo size 640,480 font "Palatino,16"

followed by

%%gnuplot
plot sin(x)
set output 'gnuplot.eps' 
set terminal postscript eps size 6.4,4.8
replot

should produce the plot inline (the pngcairo settings in the first cell) - and it does. But then it should also produce a matching .eps file (the replot after the change of terminal type) which it does not - well, it produces a zero-size file. Which is exactly how it was originally.

What am I missing?

has2k1 commented 4 years ago

When you set terminal, the terminal for all plots is changed. So, you can save the current terminal, the set the one for the output file, after which you can get back the saved terminal. This is how you could do that.

%load_ext gnuplot_kernel
%gnuplot inline pngcairo size 640,480 font "Palatino,16"
%%gnuplot
set terminal push
set terminal postscript eps size 6.4,4.8
set output 'gnuplot.eps'
plot sin(x)
set terminal pop
replot

I think %gnuplot inline *** magic creates a confusion that once you use it then all the following plots that are not output to a file will be use the specified terminal for the inline plots. That is not the case. %gnuplot inline *** gets translated to set terminal *** and is executed immediately. The inline bit is to output plots to the notebook.

Now using both set terminal *** with %gnuplot *** may have some surprises where nothing or gabbage is printed to the notebook. e.g.

%load_ext gnuplot_kernel
%gnuplot inline pngcairo size 640,480 font "Palatino,16"
%%gnuplot
set terminal postscript eps size 6.4,4.8  # Set the terminal to eps for ALL subsequent plots
set output 'gnuplot.eps'
plot sin(x)
replot  # Tries to show an .eps file which Jupyter Notebook cannot do
esternin commented 4 years ago

I am sorry, I must be dumb or something, but to me your code example says one thing and your words say something else, so I am still confused.

Your last example is

%%gnuplot
set terminal postscript eps size 6.4,4.8  # Set the terminal to eps for ALL subsequent plots
set output 'gnuplot.eps'
plot sin(x)
replot  # Tries to show an .eps file which Jupyter Notebook cannot do

which cannot possibly "show the .eps file" ! The terminal setting between the plot and replot commands did not change, so the replot should continue to write out to the same .eps file. Now, depending on how "erase screen" command is implemented, it might reset the file pointer and overwrite the previously written .eps file, or simply continue writing to the same .eps file, which may append a second page, or produce invalid PostScript, I do not know.

But my point was that if you change the terminal between plot and replot, it produces an empty output file. The push/pop trick is neat, but it should only be required if generating the .eps is not the final task and you want to return to on-screen plotting in subsequent cells:

%%gnuplot
plot sin(x)  # on-screen plot, in whatever device jupyter is set to, like pngcairo

# set terminal push   # uncomment to return to on-screen plotting after hardcopy
set output 'gnuplot.eps' 
set terminal postscript eps size 6.4,4.8
replot   # produces file output, in a different terminal type; this is what fails
# set terminal pop     # uncomment to return to on-screen plotting

The last five lines could be made into a universal macro, @HARDCOPY, if that replot was working.

has2k1 commented 4 years ago

I am sorry, I must be dumb or something, but to me your code example says one thing and your words say something else, so I am still confused.

The last code is an example of what does not work.

The last five lines could be made into a universal macro, @HARDCOPY, if that replot was working.

It works, it was fixed by https://github.com/has2k1/gnuplot_kernel/commit/8163c7b5908ba69829d440feec59f0f5cd225a30.