Hello Ethan, Thank you for your response. I missed the point in the documentation where the limitations of the plot style with table are clearly described. Now if I plot into a datablock using table mode and not using with table, all points are plotted including an additional column indicating whether they are in range or not. Example: set table $k plot [2:4] $data unset table outputs: # Curve 0 of 1, 5 points # Curve title: "$data" # x y type 1 1 o 2 2 i 3 4 i 4 8 i 5 16 o Can I somehow limit the...
Home
I filed this ticket. Obviously, one can file bug reports without being logged in. I did not know this.
"show linetype 0" fails with error message
Home
Thanks, setting this environment variable fixes this issue for me. 👍
Part of letters missing from ylabel/y2label
Part of letters missing from ylabel/y2label
Thanks, Ethan, for your suggestions. 👍 Those are surely viable solutions. Clearly, I could run gnuplot using WSL and an xserver to be able to use "grep" and I've done that before. However, I was hoping for a genuine gnuplot solution for all users, i.e., a solution that would also work in Windows cmd.exe where "grep" is not available and without having to compile gnuplot.
Thanks, Ethan, for your suggestions. 👍 Those are surely viable solutions. Clearly, I could run gnuplot using WSL and an xserver to be able to use "grep" and I've done that before. However, I was hoping for a genuine gnuplot solution for all Windows users, i.e., a solution that would also work in Windows cmd.exe where "grep" is not available and without having to compile gnuplot.
Home
Extract metadata from datafiles natively
Home
Thanks, Ethan, for providing a workaround so quickly. That's helpful.
replot of multiplot fails with "unexpected or unrecognized token:"
OK, my suggestion basically boils down to reduce the length of the commandline from gnuplot -c plot.gp data.txt foo.png to plot.gp data.txt foo.png on Windows. Reconsidering this suggestion, I now think this is not worth the hassle.
Dear Hiroki-san, Thank you for your contribution. Considering the complexity described by Ethan, I think yours is a simple, good and pragmatic solution. That will do. Best regards, Dan
OK, thanks for the explanation. I think my request boils down to be able to detect whether the script runs in an environment where the user can enter commands or not. For example if I execute gnuplot as follows: gnuplot -c plot.gp datafile.txt , the user cannot enter commands as there's no tty attached to the input. Compare this to executing gnuplot and then entering call "plot.gp" "datafile.txt". Here, obviously, the user is able to enter gnuplot commands as a tty is attached to gnuplots stdin and...
With "when the console is open" I mean that gnuplot offers a line input where the user can type in commands, e.g., when gnuplot is called without any options. Compare this to "batch mode" when gnuplot is called with a filename of a file containing gnuplot commands. Here, the use cannot type in any commands as no line input (my term: "console") is available. Does that explain what I mean with "interactive"?
Home
Detect (non-) interactive mode in script
Another alternative came to my mind: honor command line flags and options when called by a script, e.g., plot.gp -c data.txt foo.png Yet I don't even know if that is possible in Windows.
Home
Windows: Access to positional command-line arguments (ARGV/ARGC)
Home
See also this question on Stackoverflow: https://stackoverflow.com/questions/11058659/thicker-lines-in-the-legend-of-gnuplot There, you'll also find the "workarounds".
I'd like to second that feature request. I often plot all graphs using the same style. While small lines are advantageous in the plot, the color sometimes is unrecognizable in the key (legend) with small linewidths. This is even more so when using style dots, just try: plot sin(x) wi do, cos(x) wi do All workarounds I have seen so far are cumbersome. So it would be nice of the color of the plot would be more conspicuous in the key.
The set term qt command is inside the script. The script consists of the lines I quoted above.
Dear Ethan, I figured that this issue is triggered by using the terminal "qt". So this is the minimal code required to observe this behaviour: set term qt plot [-1:1] sin(x)/x I do not observe this behaviour when using term wxt.
Thanks, Ethan, pressing ctrl-C on the console does the trick.
Detect batch mode (or console mode) in script
This support ticket can be closed. I don't know how to do this.
If anybody is interested: this is my way to extract the script name from ARG0: start=1; while(1) { pos=strstrt(ARG0[start:], '\') ; if(pos==0) {break;}; start=start+pos; }; scriptname=ARG0[start:] print "script name='".scriptname."'" works on Windows.
Thanks a lot. That's helpful.
make script file name available to script code
Filed same issue as a bug #2662. Please close this feature request.
gnuplot keeps script file open after loading it
Mh, strange, this ended up as a feature request although I'd rather consider it a bug :-)
Screenshot of said message window. (I don't know how to insert an image inline, uploaded as an attachment instead)
gnuplot keeps script file open after loading it
SF support team solved this issue. 👍
Hello, I've been using gnuplot on Windows for many years. Everything was fine until I installed gnuplot 5.4.6 on a new Windows 10 PC. There, I don't get sans-serif font in terminal "wxt". See attached image. I wonder why this is. I tried to set the font manually using set term wxt font "Sans" but this only triggered a message while plotting: "warning: problem determining pango font metrics." and results in a plot that is unusuable because large black chunks are covering the graph. I also tried "Arial"...
Dear Matsuoka-san, I found out why the terminal "wxt" can use "sans" fonts on one computer and fails to use them on another: If I set the display scaling to 250% (or higher), the above mentioned behaviour occurs. If I reduce the scaling below 250%, everything works as expected: "sans" font is used automatically, gnuplot issues no warnings. If you consider this a bug, I'll happily file a ticket. Best regards, Daniel
Dear Matsuoka-san, I tried the commands. These are my observations: Up to (and including) a display scaling of 225%, I see a "sans" font in the plot window. With 250% display scaling, a "serif" font is used in the plot window. With 300% display scaling (which is the "recommended" value on my display), the plot is covered by huge letters and a warning message appears on the console. Please see the attached files for screenshots. Thanks. Daniel
Dear MATSUOKA-san, I'll happily file a new bug on this topic. See here: https://sourceforge.net/p/gnuplot/bugs/2611/
Home
Cannot enable sans-serif fonts for "wxt" on high display scaling
Strange, all earlier postings have been gone. I wonder why this discussion has been deleted. My screenshots are gone, also. To file a bug on this issue I planned to reuse text and screenshots from this thread. Now I would have to generate them from scratch. :-(
Strange, all earlier postings have been gone. I wonder why this discussion has been deleted. My screenshots are gone, also. To file a bug on this issue I planned to reuse text and screenshots from this thread. Now I'd have to generate them from scratch. :-(
Dear MATSUOKA-san, I'll happily file a new bug on this topic.
Dear Matsuoka-san, I tried the commands. These are my observations: Up to (and including) a display scaling of 225%, I see a "sans" font in the plot window. With 250% display scaling, a "serif" font is used in the plot window. With 300% display scaling (which is the "recommended" value on my display), the plot is covered by huge letters and a warning message appears on the console. Please see the attached files for screenshots. Thanks. Daniel
Home
Dear Matsuoka-san, I found out why the terminal "wxt" can use "sans" fonts on one computer and fails to use them on another: If I set the display scaling to 250% (or higher), the above mentioned behaviour occurs. If I reduce the scaling below 250%, everything works as expected: "sans" font is used automatically, gnuplot issues no warnings. If you consider this a bug, I'll happily file a ticket. Best regards, Daniel
Dear Matsuoka-san, That works. 👍 I didn't know that I could also drag'n'drop directory paths from explorer onto the gnuplot console window to change the working directory. This workflow provides a solution for my use case and is sufficiently smooth to be used during a presentation. Thanks. Daniel
Dear Matsuoka-san, Thank you for sharing this trick. I tried it and apparently this trick only works if I start wgnuplot.exe from the folder where the script file resides in or if I set the path manually to this folder. Otherwise gnuplot does not find the data files used in the plot command. I tried to "detect" the path of the script file using gnuplot commands but failed. Further, plot scripts and related data files are stored together in the same directory and I create a new directory for each...
Home
Dear Matsuoka-san, Thank you for your suggestions. I use gnuplot scripts for presentation purposes. For this use case closing the plot window, opening a text editor, changing the code, and replotting is possible but defeats the purpose of scripting plots in my opinion. Ethan Merrit mentioned a compile time option. Is the discussed behaviour (whether a console opens or can be opened when gnuplot is called from a script) a compile time option? If this is not a regression, please close this bug and...
Dear Matsuoka-san, Thank you for your suggestions. I use gnuplot scripts for presentation purposes. For this use case opening a text editor, changing the code, and replotting is possible but defeats the purpose of scripting plots in my opinion. Ethan Merrit mentioned a compile time option. Is the discussed behaviour (whether a console opens or can be opened when gnuplot is called from a script) a compile time option? If this is not a regression, please close this bug and I will happily file a feature...
Home
Home
Dear Matsuoka-san, I use gnuplot scripts for presentation purposes. For this use case opening a text editor, changing the code, and replotting is possible but defeats the purpose of scripting plots in my opinion. Ethan Merrit mentioned a compile time option. Is the discussed behaviour (whether a console opens or can be opened when gnuplot is called from a script) a compile time option? If this is not a regression, it's a new feature and I will file a feature request 😁
Thank you very much for your comments. I don't know why I see a different behavior than Matsuoka-san regarding gnuplot plot window. That's puzzling. However, suggesting to use pause was successful to enable interactivity. While pause -1 enables interactivity with the qt plot window, it also opens a small popup-window with the text "paused". That's superfluous and kind of annoying because I have to close it seperately and if I close it before I close the plot window I'll loose interactivity. Therefore...
Can not open gnuplot console window from plot window when started from script
term "qt": plot window not interactive when started from script file.
mouse zooming is broken in wxt: button has loose connection in wxt
Hello, I've been using gnuplot on Windows for many years. Everything was fine until I installed gnuplot 5.4.6 on a new Windows 10 PC. There, I don't get sans-serif font in terminal "wxt". See attached image. I wonder why this is. I tried to set the font manually using set term wxt font "Sans" but this only triggered a message while plotting: "warning: problem determining pango font metrics." and results in a plot that is unusuable because large black chunks are covering the graph. I also tried "Arial"...
Hello, I've been using gnuplot on Windows for many years. Everything was fine until I installed gnuplot 5.4.6 on a new Windows 10 PC. There, I don't get sans-serif font in terminal "wxt". See attached image. I wonder why this is. I tried to set the font manually using set term wxt font "Sans" but this only triggered a message while plotting: "warning: problem determining pango font metrics." and results in a plot that is unusuable because large black chunks are covering the graph. I also tried "Arial"...
Hello, I've been using gnuplot on Windows for many years. Everything was fine until I installed gnuplot 5.4.6 on a new Windows 10 PC. There, I don't get sans-serif font in terminal "wxt". See attached image. I wonder why this is. I tried to set the font manually using set term wxt font "Sans" but this only triggered a message while plotting: "warning: problem determining pango font metrics." and results in a plot that is unusuable because large black chunks are covering the graph. However, I see...
Hello, I've been using gnuplot on Windows for many years. Everything was fine until I installed gnuplot 5.4.6 on a new Windows 10 PC. There, I don't get sans-serif font in terminal "wxt". See attached image. I wonder why this is. I tried to set the font manually using set term wxt font "Sans" but this only triggered a message while plotting: "warning: problem determining pango font metrics." and results in a plot that is unusuable because large black chunks are covering the graph. However, I see...
Hello, I've been using gnuplot on Windows for many years. Everything was fine until I installed gnuplot on a new Windows 10 PC. There, I don't get sans-serif font in terminal "wxt". See attached image. I wonder why this is. I tried to set the font manually using set term wxt font "Sans" but this only triggered a message while plotting: "warning: problem determining pango font metrics." and results in a plot that is unusuable because large black chunks are covering the graph. However, I see sans-serif...
Hello, I've been using gnuplot on Windows for many years. Everything was fine until I installed gnuplot on a new Windows 10 PC. There, I don't get sans-serif font in terminal "wxt". See attached image. I wonder why this is. I tried to set the font manually using set term wxt font "Sans" but this only triggered a message while plotting: "warning: problem determining pango font metrics." and results in a plot that is unusuable because large black chunks are covering the graph. However, I see sans-serif...
Home
Home
Thanks!