Closed esternin closed 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)
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 .
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?
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
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.
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.
Interactively, to generate a hardcopy of the currently displayed plot, one typically performs something like:
I even have a
print.gp
file that does just that, so Iload '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)