#446 Add color control of main tics/axis, e.g., set tics lc 'green'

[Dan Sebald]

The color of tic text can be set with

set xtics textcolor 'green'

but not the tics themselves or the associated axis. I wanted such a feature for Octave, so ended up do a manual construction but that sort of thing doesn't roam with the tics when rotating 3D plots. (I tried using some type of gnuplot programming based upon z_rot and x_rot, to no avail.) The behavior was something like the demos in rgb_variable.dem that use {xyz}zeroaxis. The lines are in front of objects and not part of the hidden3d code, as far as I know.

It seems logical that if tic annotation can be set to a color, so should the tics. In fact, since "set border" doesn't lend itself to more versatile control of axis properties (the bit number field rules it out), it's reasonable to have the axis of the color tics always the same color. So, I've implemented a change in which

set xtics linecolor rgb '0xFF00FF'

and family can control the tic/axis color. It works pretty well.

The patch also fixes a few bugs I noticed in the way set/unset xtics didn't follow what the documentation indicated as far as going back to defaults. There is also a bug fix for rotating the x angle so far the bottom of the 3D space appears at the top...the axis and annotations were appearing within the interior space.

There remains a similar bug in the 'borders.dem' demo titled 'Parameterized Color Sphere'. Rotating x angle greater than 90 causes the wrong choice of base axes to display. I could fix that one as well (this bug seems familiar from far back for some reason), but it seemed something slightly outside of tics and color control. Basically, this bug can be illustrated with

set border 21
splot x*y

then rotate x angle greater than 90.

Oh, and there are some new plots in the borders.dem demo to illustrate the border colors with some neat examples where the axis represents a color component based off of the 'param.dem' and 'rgb_variable.dem' demos. I added color tics and text to a couple of the demos within 'rgb_variable.dem' as contrast.

[Dan Sebald]

I forgot to update the documentation. Also, in rereading, this

@@ -4836,7 +4836,7 @@ set_tics()

     if (END_OF_COMMAND) {
    for (i = 0; i < AXIS_ARRAY_SIZE; ++i)
-       axis_array[i].tic_in = TRUE;
+       reset_tics(&axis_array[i]);
     }

     while (!END_OF_COMMAND) {

was not a bug, so I've taken that out. But I've not updated the patch yet because I've run into a bug in the set tics and unset tics code of the current repository version. I'll add a bug report for that.

[Dan Sebald]

This "unset tics" turning into a can of worms. I set out simplifying the reseting of tics as follows:

/* {{{  reset_tics */
/* Used in both set.c and reset.c
 */
void
reset_tics(struct axis *this_axis)
{
    static struct ticdef default_ticdef = DEFAULT_AXIS_TICDEF;

    /* Clear ticdef memory */
    if (this_axis->ticdef.font)
        free(this_axis->ticdef.font);
    free_marklist(this_axis->ticdef.def.user);
    /* Put ticdef back to default state */
    this_axis->ticdef = default_ticdef;
    if (this_axis->index >= PARALLEL_AXES)
        this_axis->ticdef.rangelimited = TRUE;

    /* Put other tic-related params back to default state */
    this_axis->tic_rotate = 0;
    /* gridmajor ? */
    /* gridminor ? */
    /* minitics ? */
    /* mtic_freq ? */
    this_axis->ticscale = 1.0;
    this_axis->miniticscale = 0.5;
    /* ticstep ? */
    this_axis->tic_in = TRUE;
    this_axis->manual_justify = FALSE;  /* Is this tic related? */

    /* Deactivate tics */
    this_axis->ticmode = TICS_ON_BORDER;
}
/* }}} */

and the use of DEFAULT_AXIS_TICDEF works nicely. But then there are a number of other tic-related variables which I've added with comment characters around that don't get set to anything. Have they been added over the years and overlooked? Perhaps we should put all of those into a structure to simplify resetting defaults as well. Then there is this "manual_justify", which should probably have "tic" somewhere in its name if it is tic-related.

Then go down further in the list of axis structure of axis.h and there is this element:

    char *ticfmt;       /* autogenerated alternative to formatstring (needed??) */

Is this possible cruft?

Should I break this simplification of "unset"/"set" and related bugs into a separate ticket?

[Dan Sebald]

Just noting I have several changes for the patch, but I'm going to wait on the outcome of this bug ticket

https://sourceforge.net/p/gnuplot/bugs/1810/

before updating the attachment here.