Activity for Hiroki Motoyoshi
-
Hiroki Motoyoshi posted a comment on ticket #2835
Thank you for the explanation. It gave me a good understanding of how gnuplot has struggled to handle complex numbers since before IEEE 754 became widespread. The issue with Inf and NaN in Complex that I reported was actually a behavior I discovered while testing the display of complex numbers with the print command, as I was concerned about "Minor issue 2" (which had already been fixed). Therefore, this is a long-standing behavior and may not require immediate correction. I hope an optimal solution...
-
Inconsistent handling of complex numbers with infinity components
-
Enable 'smooth bezier' for 'with filledcurves between' style
-
Thanks for committing an improved implementation — much appreciated!
-
Handle split contour lines as one continuous curve
-
Thank you for the explanation. After applying the patch, I was able to set the border color for circles. By combining it with "set style fill", the interior of the circles can also be filled in the specified color. Looking at hidden3d.c, it seems that only the "circles" style is treated specially to allow set style fill to apply a fill style. I'm fully satisfied with this fix.
-
To provide some background, what I wanted to achieve with this feature was to hide the rendering of the far side of a sphere, as in the following script. At the same time, I wanted to indicate the extent of the sphere using a color instead of white. set angles degrees set parametric set mapping spherical set isotropic set xyplane relative 0 set title "3D version using spherical coordinate system" set dummy u, v set urange [ -90.0000 : 90.0000 ] noreverse set vrange [ 0.00000 : 360.000 ] noreverse...
-
Thank you for reply. I wasn't interested in the behavior when adding nohidden3d; the real issue was that the fillcolor setting wasn’t working as expected. So I found the following workaround: set hidden3d offset 0 front set style fill solid 1 splot $data using 1:2:3:4:(rgbcolor("green")) with circles, \ -2 with lines lc "blue" This produced the expected result. I would be satisfied if this behavior could be achieved using the inline option with circles fc "green" fs solid 1. That said, like you,...
-
fillcolor setting ignored in "splot with circles" when using "set hidden3d"
-
If the implementation with gprintf format support turns out to be too complicated, perhaps it would be better to recommend using 'set mouse mouseformat function ...' in scenarios where gprintf is desired. set mouse mouseformat function sprintf("%s,%s",gprintf("%h",x),gprintf("%h",y))
-
Thank you for your considerations. On the other hand, I do not buy the argument that deliberately malformed format strings are a "vulnerability" for an application like gnuplot. I'm not entirely sure whether this constitutes a true vulnerability in gnuplot. However, I can point out that it is an incorrect usage of the 'snprintf' function. Because, the behavior is undefined if the number of format specifiers in the format string exceeds the number of arguments provided, and depends on the implementation...
-
'set mouse mouseformat' directly passing user defined format to 'snprintf()'
-
Thank you for the series of commits related to the handling of colorspec. The commit 7879f3e32 does not include the fix for the following lines. vplot.c:325: quad[0].c = plot->lp_properties.pm3d_color.lt; vplot.c:362: quad[0].c = plot->lp_properties.pm3d_color.lt; A patch for them should be as follows: diff --git a/src/vplot.c b/src/vplot.c index e15ecc1aa..253c38969 100644 --- a/src/vplot.c +++ b/src/vplot.c @@ -322,7 +322,7 @@ tessellate_one_cube( struct surface_points *plot, int ix, int iy, int...
-
The following lines need explict type conversions using '(unsigned int)'. graph3d.c:4348: quad[0].c = plot->lp_properties.pm3d_color.lt; graphics.c:5260: quad[0].c = this_object->lp_properties.pm3d_color.lt; graphics.c:5275: quad[0].c = face.pm3d_color.lt; plot3d.c:1278: color = lptmp.pm3d_color.lt; pm3d.c:727: cb1 = cb2 = cb3 = cb4 = fillcolorspec.lt; pm3d.c:962: gray = fillcolorspec.lt; pm3d.c:970: gray = style.pm3d_color.lt; vplot.c:325: quad[0].c = plot->lp_properties.pm3d_color.lt; vplot.c:362:...
-
transparent color rendering error using "with pm3d fc ls N" on ARM-based Mac
-
What compiler and hardware are you using? I'm using MacOS Sequoia on Apple M2 chip and the compiler is clang included in standard Apple Xcode. I confirmed that the latest two commits resolved this issue on such that environment.
-
Sorry for the confusion. My patch was based on the assumption (perhaps mistaken) that CRD_COLOR could have negative values when treated as an ARGB value via a signed int. But since it's ensured that CRD_COLOR always holds only positive values within the unsigned int range for ARGB, I think the original approach you suggested will work fine for both boxes and polygons. There is one bug caused by this ARM compiler issue, so I'll open a separate ticket for that.
-
You may find this hard to believe, but the following approach does not work as expected on ARM-based systems: plot->lp_properties.pm3d_color.lt = (unsigned) points[i].CRD_COLOR; If points[i].CRD_COLOR holds a negative value, a round-toward-zero conversion may occur on ARM-based systems. For example, if the color value #8000ff00 (which is -2147418368 as a 32-bit signed int) is stored in CRD_COLOR as -2147418368.0, casting it to a 32-bit unsigned int may result in 0 on ARM-based systems! This behavior...
-
Incorrect ARGB interpretation of color column in splot's boxes and polygons styles
-
unexpected colorbox with "with polygons fc variable" in development version
-
Thank you for the explanation. I noticed that "with polygons fc variable" displays the colorbox by default. Since this seems unrelated to this topic, I will report it as a separate issue.
-
Sorry, I should have explained it more clearly. I noticed that the relevant part of "misc.c" differs between the Release and Development versions, so I'm not sure which one reflects the intended behavior. If both versions behave the same, then I believe there's no issue. In 6.0.3 if ((destination_class == LP_NOFILL || destination_class == LP_ADHOC) && (equals(c_token,"fc") || almost_equals(c_token,"fillc$olor")) && (!almost_equals(c_token+1, "pal$ette")) && (!almost_equals(c_token+1, "var$iable"))...
-
Would you mind also reviewing the changes introduced in commit 7ab7aff4 (Aug, 2024), in relation to the differences between the release and development versions in the corresponding section of misc.c? The commit message says "move check for "palette <colormap-name>" from lp_parse to parse_colorspec".</colormap-name>
-
If we revert the following section from commit fc98188b, the previous behavior regarding named palettes is restored. Would this help in understanding the cause of the bug? diff --git a/src/misc.c b/src/misc.c index 25b970c11..a9320b26a 100644 --- a/src/misc.c +++ b/src/misc.c @@ -1072,10 +1072,8 @@ lp_parse(struct lp_style_type *lp, lp_class destination_class, TBOOLEAN allow_poly) * fc colorspec as a line property. We need to parse it later as a * _fill_ property. Also prevents "plot ... fc <col1>...
-
Named colormap rendering do not work in the development version
-
Thank you very much for applying it so promptly. Since "fillcolor rgb variable" does not require a key sample, I modified the condition used to determine whether to draw the key sample accordingly. Next, I added code to draw two-colored key samples for the special case of "fillcolor ls N". In this case, the top and bottom colors are represented on the upper and lower halves of a rectangle divided along the diagonal. This diagonal representation is simply a matter of personal preference, so if you...
-
displaying key sample in "with pm3d" style with explicit fillcolor
-
I'll throw in another comment .... It mentioned the possibility of introducing reference counting, not as a Feature Request currently. I don’t intend to perform linear algebra or image processing using arrays in gnuplot either. Rather, I have in mind use cases where each element of an array represents structured records (e.g., [x, y], [time, value, label], etc.). That said, assigning one array to another would require new syntax, and using such arrays as input data for plot would also require changes...
-
Thank you for the new fix. The new reference counting and interlocking using LOCK/UNLOCK look promising. I hadn't thought of the LOCK/UNLOCK approach myself. I think this mechanism could also be useful for enabling pass-by-reference for arrays in function block parameters. This may be unrelated to function parameters, so I’m not sure if this is the right place to bring it up, but ... let me just point out one pattern that your latest fix doesn't seem to cover: function $index() <<end A=1 return 1...
-
Thank you for your reply. 1) You're right, my apologies — they are typo. 2) It's natural that the script in the original post does not trigger a memory error on versions prior to 6.0.2. This is because the issue in commit 4e3d9cc8 ("invalid stack underflow") causes evaluation to stop before reaching the problem described in this issue. Therefore, the original script only runs correctly starting from commit 4e3d9cc8 or later. Below is another version of the script that works even with versions prior...
-
Thank you for your reply. 1) You're right, my apologies — they are typo. 2) It's natural that the script in the original post does not trigger a memory error on versions prior to 6.0.2. This is because the issue in commit 4e3d9cc8 ("invalid stack underflow") causes evaluation to stop before reaching the problem described in this issue. Therefore, the original script only runs correctly starting from commit 4e3d9cc8 or later. Below is another version of the script that works even with versions prior...
-
Memory error in arrays passed as function parameters
-
I'm sorry. The modification to parse_array_constant() in the patch 0002_parse_array_constant.patch was insufficient. An improved patch file is attached. Please apply it after the commit [aa95c30]. There was a bug in the section that copies data from the temporary array elements to array->v.value_array. I have modified it to perform an accurate copy using the number of elements from the initializer on the right-hand side. Additionally, there was another location where free(elements) was necessary...
-
I'm sorry. The modification to parse_array_constant() in the patch 0002_parse_array_constant.patch was insufficient. An improved patch file is attached. Please apply it after the commit [aa95c30]. There was a bug in the section that copies data from the temporary array elements to array->v.value_array. I have modified it to perform an accurate copy using the number of elements from the initializer on the right-hand side. Additionally, there was another location where free(elements) was necessary...
-
Apologies, I overlooked the deallocation of 'elements' in the event of an error in the "0002_parse_array_constatnt.patch". Thank you for fixing and applying it. I have found another case for this issue, which is triggered by function instead of function block after Patch#827. Case 6 setup(dummy) = (A=1) array A[3] = [1,2,3] f(dummy) = (A[1]=setup(1)) print f(1) The issue in Case.6 can be avoided within the f_assign() function by detecting variable substitution, just as we have done in previous cases....
-
Cases 1 and 4 seem to involve essentially the same problem. I have created a patch that addresses both. The issue lies in how the "parse_array_constant()" function handles array initialization. In the current implementation, each right-hand-side value is evaluated and assigned directly to the destination array one by one. This can cause unexpected behavior if the destination array is modified during the evaluation. A safer approach would be: Build the entire result in a temporary C array. After construction,...
-
Let's call the original post’s situation Case 1 and your situation Case 2. These two cases are handled by different functions. Case 1 is "parse_array_constant()", and Case 2 is "is_array_assignment()". I created a patch to fix for Case 2 by modifing the function 'is_array_assignment()'. In the following command, A[2] = $line_ab(x) after evaluating the right side, the fixed version detects whether the variable A is no longer an array or whether the original array pointer has been changed. The following...
-
Invalid "stack underflow" error in variable assignment expression
-
Memory error caused by redefining an array with the same name during its initialization
-
Thank you. Your approach is preferable because it uses only the function itself, independent of the function block. I’ve also found that redefining or undefining an array within a function block in the array initialization causes the segmentation error (accessing freed memory) with a similar logic. However, this might need to be reported as a separate ticket.
-
Thank you. Your approach is preferable because it uses only the function itself, independent of the function block. I’ve also found that redefining or undefining an array within a function block in the array initialization causes a similar logic (accessing freed memory). However, this might need to be reported as a separate ticket.
-
Option 3) Although this would expand the scope of restriction, I would like to propose disallowing function definitions inside a function block if that block may be called from within a function. To implement this behavior, I suggest introducing two flags (tentative names): A flag in the fblock structure: called_from_function A global variable: prohibit_function_definition These names are provisional — please feel free to suggest better, more appropriate names. The processing logic using these flags...
-
Option 3) Although this would expand the scope of restriction, I would like to propose disallowing function definitions inside a function block if that block may be called from within a function. To implement this behavior, I suggest introducing two flags (tentative names): A flag in the fblock structure: called_from_function A global variable: prohibit_function_definition These names are provisional — please feel free to suggest better, more appropriate names. The processing logic using these flags...
-
Option 3) Although this would expand the scope of restriction, I would like to propose disallowing function definitions inside a function block if that block may be called from within a function. To implement this behavior, I suggest introducing two flags (tentative names): A flag in the fblock structure: called_from_function A global variable: prohibit_function_definition These names are provisional — please feel free to suggest better, more appropriate names. The processing logic using these flags...
-
Case 3 may have caused some confusion as an example. I believe the following simpler reproduction script is easier to understand: (3') function $setup() <<end f(x) = 1 return 0 end f(x) = 1 + $setup() print f(1) I hardly imagine anyone else would write such a script, but it is a new behavior brought about by the introduction of the function block. It is not necessary to prohibit all function definitions inside a function block. What should be prohibited, I believe, is the redefinition of a function...
-
Case 3 may have caused some confusion as an example. I believe the following simpler reproduction script is easier to understand: (3') function $setup() <<end f(x) = 1 return 0 end f(x) = 1 + $setup() print f(1) Of course, I don’t expect anyone would actually write such a script, but it is clear that this behavior is a result of the new function block mechanism. It is not necessary to prohibit all function definitions inside a function block. What should be prohibited, I believe, is the redefinition...
-
In conclusion, Case 3 is also a bug (accessing freed memory). This occurs because f(x) is redefined during its own evaluation, causing the original action table (AT) of f(x) to be deallocated via "free_at()". With typical "free(3)" behavior, the memory block is often left unchanged immediately after being freed. As a result, the evaluation of the original f(x)'s AT may continue without immediate issues, even though it has already been deallocated. The reason this bug becomes apparent on macOS is:...
-
You're right! There is another place where the format string for the standard C "*printf()" functions is directly specified by the user: set mouse mouseformat For example, on my macOS environment, the following script results in a "Bus error: 10". Since the implementation of "*printf()" may differ between operating systems or development environments, this may not reproduce on other systems. NARGS=10000 set term wxt fmt = ""; do for [k=1:NARGS] {fmt = fmt."%x" } set mouse mouseformat fmt plot 0 pause...
-
The warn command has also uncontrolled format string problem. For example, warn "%p %g %i %lf". This also comes from giving input from the user to the format string in "warn_command()" and should be corrected.
-
Here is the LLDB output from the PC (macOS on arm64) where a SEGV occurs in Case 3. Note: On other PC (macOS on intel x86_64 built with MacPort library), case 3 doesn't cause SEGV.
-
Indeed, Case 4 caused a SEGV independently of the function block, simply due to exit error. It seems the issue is that a NULL value is being passed to "int_error(NO_CARET, try_to_get_string());". I think it would be better if "exit_command()" checked the return value of "try_to_get_string()" and for example, passed an empty string ("") if it is NULL. Also, since the second argument of int_error() is a format string, I believe it should be restricted to a string format such as "%s". Otherwise, unexpected...
-
function block: SEGV occurs due to invalid context call in a function block
-
Perhaps what the original poster of this ticket truly wants is not to know whether the current state of gnuplot is interactive, but rather to be able to specify at startup whether the script being executed should behave interactively or not. If that's the case, how about adding the following lines at the beginning of your script? if ( ARGC >= 1 && ARGV[1] eq "-i" ) { interactive = 1 } if ( exist("interactive") ) { <Actions in Interactive Mode> } else { <Actions in Not-Interactive Mode> } You can...
-
I think the proposed new command is addressing a need that doesn't really exist. I can't think of any type of real-world data presentation that would need them. Can you point to an example of one, maybe a figure in a published paper or textbook? For example, Particle Data Group Collaboration 2024, 'Review of particle physics', Physical Review D, vol. 110, no. 3, 030001. https://doi.org/10.1103/PhysRevD.110.030001 [Open Access] -> Fig. 11.4 (P.228), Fig. 19.2 (P.390), Fig. 37.1 (P.680) Fig 37.3 (P.681)...
-
As you said, this may be a rarely used feature, but, as for me, there are cases where minor tics are too densely packed, and users may want to emphasize only the value 5, for example. The key point of this proposal is that minor tics should be placed precisely at the user-specified positions. Since the implementation would likely be complex, and I've also found that it's easy to achieve the same result using the method in the emulation script, I think it would be understandable if the proposal were...
-
Thank you for reply. The presence of minor tics with no corresponding major tics was, in fact, one of the complaints in Bug 2717. Well, I guess that’s true. The length of the "1" tic in mylogtics is the same as that of the major tics OK, this is not a very important point. I may have been asking for too much, so I’ll take it back. Reviced Proposed Syntax Ver.2 set mylogtics m1 m2 m3 ... This command would generate minor tics at positions such as 'm1* 10^k', 'm2 * 10^k', 'm3 * 10^k' between each major...
-
set command to specify minor tics on logarithmic axes
-
Hmm, that brings us back to the original discussion. Just as an example, would it be possible to introduce a third option to the set xtics command, something like autologscale? autologscale: Switches between logscale and noloscale based on the number of major tics (default) logscale: Forces logarithmic tics nologscale: Forces additive (linear) tics
-
I observed the bug reported by the original poster may not be fully resolved yet. If the test script's "set xtics ... logscale" is changed to "set xtics ... nologscale", a similarly broken plot is still produced. When the plot size is reduced, as in the following script, it becomes more apparent that grid lines are drawn outside the intended plot area. This behavior is also reproducible in the older version 5.2.8, so it appears to be a long-standing issue. set size 0.5,0.5 set origin 0.2,0.1 set...
-
hsteps: Enable "set boxwidth" when the bins filter is applied
-
But I can totally see how providing a string constant in parentheses would seem like it would substitute for a real fourth column just the way providing a numerical constant in parentheses substitutes for numerical values in a real data column. Your explanation really cleared things up for me. In a plot command such as: plot $data using (1):2:(0.5):("A") with boxplot the fourth column, ("A"), can be interpreted as indicating that every record belongs to the category (or factor) "A". Anyhow, that's...
-
Actually, I had assumed that the original poster's syntax should work as intended. This is because the "help boxplot" documentation contains the following description regarding x-axis labels: You can place an identifying label at this position under the boxplot by adding an xticlabel specifier in the plot command (two or three column syntax) or by providing it as a string in a separate data column (four column syntax). While the latter part of the documentation mentions that the fourth field can...
-
I'm not the original poster, but I was able to reproduce the issue. In the following script: $data <<EOD 1 1 2 8 3 6 4 6 5 5 6 8 7 9 8 7 9 6 10 5 1 4 2 3 3 4 4 5 5 6 6 6 7 7 8 2 9 3 10 5 EOD set yrange [0:*] set offset 0,0,1,1 unset key plot $data using (1):2:(0.5):("A") every :::0::0 with boxplot, \ $data using (2):2:(0.5):("B") every :::1::1 with boxplot pause -1 set xrange [-1000:3] replot pause -1 Label "A" is placed correctly, but label "B" is placed at x = -999 instead of its expected position....
-
It is the definition isnan(X) = (X==X)?0:1 that is incorrect. I believe this function definition is actually working as intended. isnan(x) = x==x ? 0 : 1 f(x) = (x==0)? NaN : x print "isnan(1)", isnan(1) # => 0 print "isnan(NaN)", isnan(NaN) # => 1 print "isnan(f(1))", isnan(f(1)) # => 0 print "isnan(f(0))", isnan(f(0)) # => 1 $data <<EOD 1 NaN 3 NaN 5 EOD s = "" plot $data using (0):(s=s.sprintf("%d %d\n",isnan($1),valid(1)),0) print s # => # 0 1 # 1 0 # 0 1 # 1 0 # 0 1 To me, it seems that the...
-
Figures are attached here.
-
The script compares the values in the second and third columns, and plots the valid and larger one. Attached are the outputs from gnuplot 6.0.2 and gnuplot 6.1.0 with patch [commit "3e1f93bd" & my patch]. These two figures match the expected changes resulting from the patch. In "case1" and "case2", all input data is referenced using "column(N)". This is the usage pattern addressed by this ticket. Case1 involves reading missing data and is therefore unaffected by the patch. In contrast, case2 involves...
-
I think your plot isn’t working as expected due to two key points that need a small adjustment. 1. Use of "rgbcolor variable": To specify point colors, you should use the linecolor option (abbreviated as lc) together with "rgbcolor variable". So make sure your plot command includes something like: lc rgbcolor variable 2. Handling of the fourth column in "using": In your data, the fourth column appears to be a hexadecimal color code in double quotes, like "0xFF0000". Gnuplot treats this as a string....
-
Thank you for looking into this so quickly. If you have further thoughts on the matter, please attach them here or raise the issue for discussion on the gnuplot-beta mailing list. Here is how I think missing and invalid data should be handled in the using specification. Handling of Missing and Invalid Data in Parentheses Evaluation in the using Specification Missing Data When missing data is referenced using $N or column(N), the evaluation of the parentheses is determined as missing, even during...
-
Apply 'if filter' to 'xticlabels()' as well
-
hsteps: Support for width specification via 'set boxwidth'
-
I'm sorry. Correction to the third table. No. start : end result ------------------------------ 14 0.0 : 0.1 nothing is drawn 15 0.0 : 0.2 arc 16 90.0 : 90.1 nothing is drawn 17 90.0 : 90.2 arc 18 -90.1 : -90 arc ? 19 -90.2 : -90 arc
-
Determining when an arc forms a full circle in do_arc()
-
Sectors: Fix range checks in 'with sectors units xx (or yy)'
-
Bins filter: Treats bins without data as UNDEFINED when binvalue=avg
-
Add Outline Hinting Option to the Cairo-Based Raster Terminals
-
Thank you for your comment. This is a file that brings together functions that were originally scattered in various places, such as graphics.c, so I think it is reasonable that it has the same license as those files. Furthermore, the functions in marks.c rely heavily on gnuplot routines, so it is not particularly useful to use them in programs other than gnuplot, so there is no positive reason to add BSD or GPL licenses.
-
I would like to thank you for reorganizing the source code related to marks in the 'commit '6f281ed23ccbde5300aa7b598215f53a929e1a7a' and for including the manual and demo in subsequent commits. I was worried that the marks-related functions were scattered across several source files, so this is a great help.
-
If the input data for the 'splot' command is gridded data, there is not much difference from the case of plotting a function. If the grid data is sparse, you can use the ‘interpolation’ option for ‘set pm3d’ to make it smoother.
-
If you can use gnuplot version 6.0.0 or later, you might want to consider using the ‘zclip’ option for the 'splot' command. Alternatively, you could also use ‘with contourfill’, which was also introduced in version 6.0.0. Note: The ‘zclip’ option is marked as ‘Experimental’ in the gnuplot documentation. Here is an example using the 'zclip' option for splot command. set term qt f(x,y) = x**2+(x/2.0+y)**2 threshold = 0.6 set view map # for 2D plot set isotropic # aspect ratio set xrange [-1:1] set...
-
Thank you for confirming about the 205 patch. mark's border drawing rule Deciding whether or not to draw a border is a bit more complicated, but it is possible to establish a consistent rule that 'mode', 'mark border style', and 'parent border style' have priority in that order, as shown in 'DrawModeRules.pdf'. Your commit “5af9157bcc6c85a91564464b08e090f86888c280” gives top priority to the 'noborder' directive in 'parent border style', which conflicts with the rule proposed here. If you agree with...
-
Thank you for confirming about the 205 patch. mark's border drawing rule Deciding whether or not to draw a border is a bit more complicated, but it is possible to establish a consistent rule that 'mode', 'mark border style', and 'parent border style' have priority in that order, as shown in 'DrawModeRules.pdf'. Your commit “5af9157bcc6c85a91564464b08e090f86888c280” gives top priority to the 'noborder' directive in 'parent border style', which conflicts with the rule proposed here. If you agree with...
-
Are you sure? This change would mean that you cannot modify the fillstyle of an object that contains a mark. I think the current initialization to FS_DEFAULT is correct. That tells it to inherit the fillstyle of the object that contains it. Yes, I'm sure. The 205 patch simply modifies the object mark's default fillstyle. My test code is like this, $box <<EOD 0 0 0 1 1 1 1 0 0 0 EOD set mark 1 $box using ($1-0.5):($2-0.5) set mark 1 append $box set xrange [-1:2] set yrange [-1:2] set label at 0,1.2...
-
Thank you for refactoring set_mark(). Here are two small patches, after your commit. 204_disable_append_in_first_set_mark.patch More fixes to set_mark. Includes the following. [Fix] set mark 1 append $data when none of the marks are defined is not acceptable [Refactoring] Eliminate MARK_ACTION_CREATE and MARK_ACTION_APPEND macro variables 205_modify_default_fillstyle_of_object_mark.patch The default fillstyle of "mark" object was "fs solid 1", but it should be changed to "fs empty" as well as "plot...
-
Patch for fixes to 'set_mark()' This patch contains the following Fixes and Modifications [Fix] Correct rejection of pseudo file "++" [Modification] 'set mark N empty' should accept 'title', 'fc', 'fs' options [Modification] 'set mark N append' should not accept 'title', 'fc', 'fs' options (raises error) [Modification] 'append' for undefined mark tag should be an error to avoid confusing [Modification] macro variable MARK_ACTION_UNDEFINED is removed by refactoring With this patch, the syntax of the...
-
Another concerns about the current implementation of the main branch on SourceForge. ** border color selection for 'fc variable' ** If the 'fc variable' is specified and the border color is not, the border line is drawn as a black line. It should be matched with the variable fillcolor. The patch is attached, and the test script is here. $box << EOD 0 0 0 1 1 1 1 0 0 0 EOD set mark 1 $box $data << EOD 0 0 0 1 1 0 1 1 EOD set xrange [-1:3] set yrange [-1:3] plot $data using 1:2:($0+1) with marks mt...
-
If you replace the code snippet 'using 1:0:2' in the 'with labels' section with 'using 1:(0):2', does the output match your expectations? The 'using 1:0:2' is functionally equivalent to 'using ($1):($0):($2)'. Here, '$0' serves as a pseudocolumn, initiating at 0 and incrementing by 1 for each valid point read. This likely affects the y-axis offset of the labels in your figure, causing it to increase by 1. If, despite the replacement, the y-axis offset of the labels in your figure still increases,...
-
After much consideration, I have given up on introducing color and fillstyle columns, as I do not have enough material to convince you at this time. Even without introducing color and fillstyle columns, the 'marks' style would be a new feature that expands gnuplot's expression. So, please proceed with the current direction of the main branch of SourceForge. I have the following concerns about the current implementation of the main branch on SourceForge, and I hope you will consider them. 'fillcolor'...
-
After much consideration, I have given up on introducing color and fillstyle columns, as I do not have enough material to convince you at this time. Even without introducing color and fillstyle columns, the 'marks' style would be a new feature that expands gnuplot's expression. So, please proceed with the current direction of the main branch of SourceForge. I have the following concerns about the current implementation of the main branch on SourceForge, and I hope you will consider them. 'fillcolor'...
-
After much consideration, I have given up on introducing color and fillstyle columns, as I do not have enough material to convince you at this time. Even without introducing color and fillstyle columns, the 'marks' style would be a new feature that expands gnuplot's expression. So, please proceed with the current direction of the main branch of SourceForge. I have the following concerns about the current implementation of the main branch on SourceForge, and I hope you will consider them. 'fillcolor'...
-
Since there is no 4th vertex property, you can't switch colors in the middle of a mark definition. On the other hand, the fill and stroke colors can be different from the start. It would not be that much work to add back a vertex color if needed. In my opinion, it is more valuable to be able to switch colors in the middle of a mark definition. By doing so, fill and stroke can be superimposed as separate definitions, and as a result, the border color can be specified separately. This is the case for...
-
Since there is no 4th vertex property, you can't switch colors in the middle of a mark definition. On the other hand, the fill and stroke colors can be different from the start. It would not be that much work to add back a vertex color if needed. In my opinion, it is more valuable to be able to switch colors in the middle of a mark definition. By doing so, fill and stroke can be superimposed as separate definitions, and as a result, the border color can be specified separately. This is the case for...
-
Thank you for the patch. This feature gives us a hint as to the shape, which we can't know from the number alone.
-
This may be wandering off topic. I do think it is a good idea to make all gnuplot terminals consistent with regard to the winding attribute, but that may not actually achieve what you want. Do you have a real-world example of a polygon shape with holes in it that you want to draw? Is the trick of connecting interior "hole" shapes to the overall perimeter via a zero-width line (as in your example) sufficient? Marks does not yet have an actual example, but a 'with polygons' style example would be the...
-
Thanks for the information on the Fill-Rule for each terminal. It is very helpful. I understand that it is possible to paint with a single stroke polygon, like the star shape in your example. Apparently, the Fill-Rule setting is not the only essential thing for drawing holes. For example, whether the Fill-Rule is nonzero or even-odd, we should be able to represent a hole by drawing the outer polygon clockwise and the inner polygon counter clockwise. If we call the inner polygon a subpath of the outer...
-
One issue I came across was whether a "marktype 0" should be accepted. I can see that it makes the nice windbarbs example simpler. But all the other gnuplot entities created by set <something> <tag> ... require that tag > 0. (linetypes, objects, labels, pixmaps, arrow,...) and treat tag=0 as an error.</tag></something> My intention is that the marktypes that the user can set with set mark are 0 and positive number. I want to reserve the negative number marktype for internal use, built-in marks, etc....
-
I had assumed that only the final code would be committed to the main branch once the discussion and specification work here had settled down. I apologize for the haste in getting things done. I also apologize for the sending many patch files in incomplete states. Thank you for reviewing codes deeply and committing the modified codes. 014_show_mark was a misunderstanding of what I tried to say earlier. I apologize for the confusion. The point I was trying to make was that gnuplot's show commands...
-
Some updates were made. 021_show_marks_datablock_handling.patch The handling of output to datablock in the 'show_mark()' function was corrected with reference to the 'new_block()' function. 022_save_marks_uses_pseudo_file.patch "save marks" output changed to use pseudo file as follows. set mark 1 '-' x1 y1 ... x2 y2 ... : : : e 023_careful_comparison_of_fillstyle_type.patch Changed to use '(style & 0xf)' for comparison with FS_EMPTY in response to changes made by 'commit 83e4eadb78c8e7a4a41ff9805d9052d42daa0ad3'....
-
Some updates were done. 021_show_marks_datablock_handling.patch The handling of output to datablock in the 'show_mark()' function was corrected with reference to the 'new_block()' function. 022_save_marks_uses_pseudo_file.patch "save marks" output changed to use pseudo file as follows. set mark 1 '-' x1 y1 ... x2 y2 ... : : : e 023_careful_comparison_of_fillstyle_type.patch Changed to use '(style & 0xf)' for comparison with FS_EMPTY in response to changes made by 'commit 83e4eadb78c8e7a4a41ff9805d9052d42daa0ad3'....
-
The show_mark() function introduced in ‘014_show_mark.patch’ had a bug regarding the initialization of the datablock variable. A patch to fix this bug is attached. 019_BUGFIX_initializing_datablock_in_show_mark.patch EDIT Sorry, it is found that this patch can't fix the bug. SEGV was occurring when loading a lot of data into set mark. The cause of the bug was that the fillstyle member of the mark_data struct was not properly handled in the mark's reallocation when loading data in set mark. The attached...
-
The show_mark() function introduced in ‘014_show_mark.patch’ had a bug regarding the initialization of the datablock variable. A patch to fix this bug is attached. 019_BUGFIX_initializing_datablock_in_show_mark.patch EDIT Sorry, it is found that this patch can't fix the bug.
1 >
