Re: plot using cbticlabels: an unfinished and undocumented feature

[Ethan A M. <sf...@us...>]

On Sunday, July 29, 2018 10:37:49 PM PDT sfeam via gnuplot-beta wrote:
> On Saturday, 28 July 2018 22:35:00 Juhász Péter wrote:
> > Hello,
> > 
> > I wanted to create a graph where tics on the colorbox are dynamically
> > generated from data. I vaguely recalled that there was a feature for
> > that, and it seemed logical that if there is {x|y}[2]ticlabels() to
> > place tics on the main axes, there should be a cbticlabels to do the
> > same for the colorbox.
> > 
> > It seems that this is valid syntax, as the parser accepts it, and I've
> > found the code responsible for it in the source, but it appears to be
> > undocumented, and there are no demos for it either.
> > 
> > It also appears to be either half-finished or buggy. 
> 
> All true.  "cbticlabels" was added for completeness when the other
> ticlabels variants were introduced, but it was never fully thought
> out or documented. 
> 
> [snip]
> > See the attached data file and gnuplot script for a self-contained
> > example.
> > 
> > The fix, at least from the user's perspective, seems simple: make
> > cbticlabels use the same column that is used for the color data itself.
> > From the developer's perspective, I realize that this might be hard,
> > because we don't yet know which column to use at the time of parsing
> > the using spec, because an unknown number of `xxx variable` statements
> > may come later.
> > 
> > Or - `help pointsize variable` states that variable color is alwasy
> > taken from the last additional column. That we do know.
> 
> Yes.  I think that would be sufficient to cover all your test cases
> in 2D plots. Like this:
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> diff --git a/src/datafile.c b/src/datafile.c
> index 8baf1d5..208ca3a 100644
> --- a/src/datafile.c
> +++ b/src/datafile.c
> @@ -2059,7 +2059,7 @@ df_readascii(double v[], int max)
>                             break;
>                         case CT_CBTICLABEL:
>                             axis = COLOR_AXIS;
> -                       axcol = 3;
> +                     axcol = df_no_use_specs - 1;
>                             break;
>                     }
>                     /* Trap special case of only a single 'using' column */
> @@ -5315,7 +5315,7 @@ df_readbinary(double v[], int max)
>                         break;
>                     case CT_CBTICLABEL:
>                         axis = COLOR_AXIS;
> -                   axcol = 2;
> +                 axcol = df_no_use_specs - 1;
>                         break;
>                 }
>                 if (a.type == STRING) {
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> 
> However that fix doesn't work so well for 3D plots, where there is always
> a z coordinate and that is usually (but not always) where the color comes
> from.  The code in datafile.c is shared by both 2D and 3D plots so it 
> would be tricky to make it work for both.
> 
> 	Ethan

I commited that change for 5.3 and added a documentation section noting
that it is EXPERIMENTAL and that the 3D heat map case does not work as it
probably should.    

	Ethan