Hiroki Motoyoshi

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'...