Plot title is not initialized correctly following a plot with no valid data
Fixed in 6.1 Queued for 6.0.5
Plot title is not initialized correctly following a plot with no valid data
Plot title is not initialized correctly following a plot with no valid data
Plot title is not initialized correctly following a plot with no valid data
Yes, the behavior has changed since version 5. User feedback (a.k.a. "bug reports") suggested revisions to the empirical rules for log tic placement. See in particular the discussion attached to Bug #2717 https://sourceforge.net/p/gnuplot/bugs/2717/ Some users feel strongly that there must be at least three major (i.e. labeled) tic marks in order to make it immediately apparent that the axis is log-scaled. The output from 5.4 on plot #2 has only two labeled tic marks. In this particular case close...
Both plots show log scaling on y. The difference you notice is probably the choice of where to place major tics (labeled) vs minor tics (unlabeled). The program tries to choose a reasonable set of major and minor axis tics based on the total range. When placing log scaled major tics it currently uses heuristics like "there must be at least 3 but preferably not more than 10 major tics; do not place more than 10 minor tics between major tics; if the range would hold only 1 major tic promote the minor...
Full dashtype support for libgd terminals and improved antialiasing quality
Got it. Thanks very much.
I am truly impressed by the quality of the output. Let's go with this version. Could you provide one more patch to apply on top of this to give yourself credit at the top of gd.trm for this major revision (a line or two to summary the work very briefly)? Also it would be nice if you provide an overall description to use as a commit message when I add it to the git repository. I could write something myself but you obviously know better than I do how to properly describe it. What should the author...
yrange ignored in parametric mode
Yes there have been problems with thick lines all along. Left to itself, libgd does a really poor job with them. So gnuplot draws a thick line by filling a circular area around each point along the line. This is done by drawing the line with gdImageSetBrush() and a brush constructed to be the width requested for the line. And, as you say, this causes transparent thick lines to be way less transparent than requested because every single point leads to overlaps. So yes there is extra darkening at points...
No need to attach output. It's actually easier for me to test with kittycairo vs kittygd. That way I can run a test in side-by-side windows to compare the png and gd output rather than collecting and pairing up separate output files for display. I'll probably apply this version after going over the code to see if there's anything that can be tightened up or abstracted. The quality of the output is very good, with one exception that is not a deal-breaker. The algorithm used here has the imperfection...
gnuplot 6.0.4 ignores unset warnings
Thanks. There's a fix already in 6.1 and queued for 6.0.next
Dumb terminal doesn't show all data
As you say, increasing the range shows that in fact all 8 points are present. Since auto-scaling uses the extreme point coordinates to define the border, and the border of the plot is by default drawn after the points, it covers the two points with extreme coordinates. Try again with set border back to confirm.
The problem arises because your test script explicitly sets the tic format to '%h', but this is not correct for latex terminals. Here is the guidance from help set format: The length of the format string is restricted to 100 characters. The default format is "% h", except that LaTeX terminals use "$%h$". You can modify this to provide units or a different numeric format, for example 'set xtics format "%.2f MHz"'. "set format" with no following string will restore the default. I grant you that this...
Nice test figures!
Most, but not all, of the warnings issued by gnuplot were sent by a shared subroutine. The "unset warnings" command silences that shared mechanism. That leaves a few [a quick-and-dirty "grep" of the source tree finds about thirty] places in the source code that print the warning directly rather than going through the shared subroutine. Some of these should probably never by silenced, like the ones from the stats and fit commands that tell you the calculation was invalid or highly unreliable. Others,...
Update After a minor tweak to gnuplot's svg/domterm terminal driver, I can now run the WASI/WASM gnuplot executable by invoking wasmtime inside qtdomterm. See https://domterm.org/ and (somewhat old) https://opensource.com/article/18/1/domterminal. Domterm intercepts the SVG output and then renders it inside the widget. This gets me full graphics, fonts, etc., in a Qt widget. It's great. Screenshot attached. Here's what I don't understand, though. It also makes the history and readline functions work....
I have committed your original patchset and then committed a small modification to move the tempfile handling into a set of macros in syscfg.h rather than cluttering up the primary code with tests for #ifdef __wasi__. They also fix a memory leak that would have happened if an error is encountered while a tempfile is open. After a bit of fumbling I got the wasi-sdk installed and used that for testing. The only real problem I had is that I don't understand the mechanism for granting permission to access...
Another question: Is there a reason you use the sequence fclose(fp); fp = fmemopen(fbuf, fbuf_len, "r"); rather than simply rewind(fp);? The documentation says fseek is usable after open_memstream(), and rewind is documented as being equivalent to fseek(stream, 0L, SEEK_SET). Allowing the code to use rewind(fp) further simplifies the change and works for me in testing (not on WASI yet).
Now that I've looked at the patch, I wonder if 99% of it could be respun as "optional support for using memory-backed scratch space viafmemopen and open_memstream rather than using tempfiles. That seems like a perfectly reasonable option in any case, and it might then simplify WASI support into something like "you must select this option during configuration". Do I have that right? Thanks for the session output video. That gives me an idea of what you ended up with and what is missing. As to terminal...
I am potentially very interested in this, but I am very much not up to speed on the wasm ecosystem. Furthermore so far as I can tell, the linux systems I normally work on do not provide any of the relevant support packages, so I am at least one or two major steps away from being able to try this out. Maybe you can provide some guidance... Would it be more reasonable to work from the GitHub repository code and build it up the clang/wasm/wasi development tools from scratch or to start by installing...
Fails to build with lua 5.5
I don't have lua 5.5 yet, so this patch is just a guess based on the "changes" section of the README on their web site. Could you please try it?
Mouse coordinates in multiplots
Yay! Multiplots are now at long last now mouseable in 6.1 Well, except for some weird cases like non-linear axis mappings.
I am not able to reproduce this. Is your browser not able to display the SVG on-line demos? https://gnuplot.sourceforge.net/demo_svg_6.0/ What O/S and browser are you using? I would be happy to look a patch, but it will be hard to test and evaluate if I can't reproduce the problem.
logscale - Too many axis ticks requested
It turns out that the failure was due to round-off error in testing initial tickmark placement against the range endpoints. After adding an allowance for floating-point round-off to integer values everything seems to be working.
Hmm. OK. I saw something else initially but now I can reproduce your report. I don't know what is going on here.
The syntax is set xtics <start>,<increment>{,<end>}. For log scale axes the increment is multiplicative rather than additive. So to place major tics as you describe, the command would be set xtics 1.e6, 10 Which is what you get by default. Minor tics are a separate command, but what you describe (I thiink) is also what you get by default.
Version 6.0 patchlevel 3
But the error message is correct, right? What tick placement are you trying to obtain?
ReGIS output cleared after display
ps_fontfile_doc.pdf fails to build with texlive 20250308
empty cell in extra column makes data point disappear
This has been the behavior back at least as far as version 5.0 (11 years ago). The program assumes a uniform format for the input line, so when it sees 3 or more columns of data in the first line that sets an expectation that subsequent lines will provide the same. Lines will fewer columns are then flagged as containing "missing" data, which is why the point is omitted. You demonstrate this by providing only two values on the first line of data. Specifying using 1:2 tells the program explicitly that...
Back from vacation, looking at the patch now... I don't have any previous experience with AI-generated code, so I don't know how much paranoia to approach this with. First thoughts I get a couple of compiler warnings, but those are minor and I won't bother with them now. It seems like a lot of code. Maybe that's necessary. Major issue Unfortunately I don't think this implementation actually does what is needed. It fails to follow the continuous path of a line; instead it connects only line segment...
Here is a proper fix that avoids the missing characters.
Attached is a patch that removes the LASY10 column from the document. Does this work for you?
I can reproduce the error messages from texlive2025, but as you say the output pdf file seems correct. Switching to lualatex and font wasy yields similar error messages and a similar pdf output file. I take it you are invoking the "make pdf" from inside something else (rpmbuild?) Is there a way to tell it to ignore the error? Can you remove the .../docs/psdoc make target from your build script? I suspect that the entire mechanism being documented - embedding Type 1 fonts in a PostScript file output...
plot style "with labels" silently ignores "noenhanced" setting
I'm traveling and will have alook ar your patch when I return next week. In the meantime, just a question. IsYour code something that could be added to the libgd library itself? If so that would benefit not just gnuplot but all other users of the library. I have contributed fixes to libgd before so I know they are receptive. Thanks for your contribution.
displaying key sample in "with pm3d" style with explicit fillcolor
'set mouse mouseformat' directly passing user defined format to 'snprintf()'
sixeltek terminal: transparency and background options
In file included from term.h:170, from term.c:1311: ../term/tek.trm: In function ‘SIXEL_text’: ../term/tek.trm:817:57: warning: self-comparison always evaluates to true [-Wtautological-compare] 817 | if (n < b_xsize-1 || pc != '?' || k == k) { /* do not output empty lines */ | ^~ What is the intent here?
The clear screen escape sequence is sent by term_reset(), which is invoked when you either (1) made another plot, (2) change the terminal type or settings, or (3) exit the program. I believe the intent was that the plot would remain visible on your screen until you did one of those things. However the "set output" / "unset output" commands are treated as changed the terminal settings. term_reset() appends the clear screen sequence to the output file when it is closed. This is/was probably not ideal...
Improvement of datablock size retrieval performance
The difference will go away if you tell the program to treat a coordinate whose value is found to be NaN the same as a coordinate that is missing from the input data. set datafile missing NaN The next question is obviously "why does $2*$1/$1 evaluate to NaN while $2+10 apparently does not?". Good question. When reading in a line of data, the program returns an error flag DF_MISSING to indicate that a required coordinate is missing. The test for that condition is trivial if the coordinate is simply...
Sorry, that should have been commit 7f0dfb24
I had to wrap the character array in a new structure typedef struct data_array { struct array_header header; char **data; } data_array; Commit 42849f98 It was not too messy, although it introduces additional steps in initializing the data block. I think I found everywhere that need modification, but I almost missed a spot in the "test palette" code so I worry a bit that I might also have missed some other non-obvious case. Timing is now equivalent for your test cases: [~/git/gnuplot/src] ./gnuplot...
6.0.4 does not compile with BACKWARD_COMPATIBILITY
Thanks.
I was thinking about it the wrong way. The cairo terminals already convert all text to UTF-8. Either it was recognized as UTF-8 or it was run through g_convert to make it UTF-8. So at that point it is OK to expand the Unicode escape sequences \U+acbd into more UTF-8. I made that change, and it seems to work. Your EUC-JP strings can now include Unicode escape sequences if the locale is recognized, but only for the cairo terminals. I will look to see if any other terminals can do something similar....
I think I see an additional problem. How should we handle Unicode escape sequences? For example to create a label containing a Greek letter pi: 2π * x it should be possible to use an escape sequence set label "2\U+03C0 * x". The program knows how to convert this to a UTF-8 character sequence that would be accepted by the cairo terminals. But with this change in place the call to iconv would try to convert this byte sequence as if it were EUC-JP and give the error Unable to convert "2π": the sequence...
You are correct that g_utf8_validate() should not be called if the current character encoding is known to be something other than utf8. I will need your assistance to figure out how to test for this correctly so that it handles your situation. Short answer I have added an internal value S_ENC_EUCJP and attempted to modify the code for set encoding locale so that it detects EUC-JP as the current encoding. The change works under linux but I cannot test under Windows. The git commit is d2ee58da8b6....
You are correct that g_utf8_validate() should not be called if the current character encoding is known to be something other than utf8. I will need your assistance to figure out how to test for this correctly so that it handles your situation. Short answer I have modified added an internal value S_ENC_EUCJP and attempted to modify the code for set encoding locale so that it detects EUC-JP as the current encoding. The change works under linux but I cannot test under Windows. The git commit is d2ee58da8b6....
You are correct that g_utf8_validate() should not be called if the current character encoding is known to be something other than utf8. I will need your assistance to figure out how to test for this correctly so that it handles your situation. Short answer I have modified added an internal value S_ENC_EUCJP and attempted to modify the code for set encoding locale so that it detects EUC-JP as the current encoding. The change works under linux but I cannot test under Windows. The git commit is d2ee58da8b6....
</body></html> in the middle of gnuplot6.html in docs/html/
Yes, you are correct. Happy New Year!
mouse coordinate read-out in multiplot mode
unreadable label on y-axis in png output
Fixed in 6.1, but only confirmed for libgd version 2.4.0 and libraqm version 0.10.3 Some earlier versions of libgd also work, but only if they are configured to not use libraqm. I have not found any way to make gnuplot work around incompatible versions of libgd and libraqm. The libharfbuzz version may also be relevant (raqm uses it) but I did not pursue that.
Incorrect autoscale regression in polar plots
6.0.3: The `dt (n1,n2)` syntax makes it hard to use programmatically defined dashtype
[6.0.0] ticks broken with `set size ratio -1 1,1`
First question: is there a 'set loadpath' command in the file <filename>.gpthat you saved? Second question: When you later issue the load '<filename>.gp command and it fails, is that in the same gnuplot session as you were in when you originally saved it? If not, is the new gnuplot session being run from the same user directory as original session? What does the new (failing) session report for show loadpath?
Is there no "set loadpath" command at all in your save file, or is there a "set loadpath" command but it contains an incorrect path? It works under linux, but I don't have a Windows machine to test on, so I don't know if there is some Windows-specific problem with the save command.
windows: writing UTF-16 to a pipe is incorrect (was: pgf is unable to check gnuplot version
See also Bug #2747 https://sourceforge.net/p/gnuplot/bugs/2747/
'sample' keyword is not tolerated after a `plot for[]` iterator
These changes are now in 6.0.4, so I am marking this as "fixed". Nevertheless I think more could be done along these lines to reduce the number of cases where the "sample" keyword is needed.
Small glitch in User Guide (v.6.0)
As it happens, Najevi has taken on the task of cleaning up the User Manual and has created a linked git repository where that work is on-going: https://git.code.sf.net/u/najevi/gnuplot najevi-gnuplot I know that re-alphabetization is on the list of things Najevi is doing, so he's probably got this one covered. If you notice anything else of this sort, I suggest you send it his way rather than filing it as a bug report.
Ticket moved from /p/gnuplot/bugs/2735/ Can't be converted: _milestone: _priority:
windows: error in LaTeX + UTF8 encoding when gnuplot is used in pgfplots
gnuplot-6.0.x - qt terminal error "IFFChunk::innerFromDevice: unkwnown chunk"
Windows 6.03: 4 problems with `keyentry`
The extra text (the part not introduced by title) can use any of the properties parsed for labels. See set label. I have added this to the documentation.
Ticket moved from /p/gnuplot/bugs/2843/ Can't be converted: _milestone: _priority:
make error <QtCORE> not found
For time series data, Is it possible to plot/add 0 when the data set does not include it?
Problem with smooth bezier
install with linux terminal under linux
configure doesn't find libgd on Suse Leap 15
makewhatis awk complains about gnuplot-ja man page
Plotting just a part of a column
Gnuplot Team Support
plotting using with fortran90
wxt terminal fails to paint on launch + weird double drawing
Cannot get histogram plot to work with in-line function using "reasonable" guess at how
transparency of parts of 3D plot
Gnuplot won't run with current version of readline
MultiPlot