[GRASS5] Color prompt partially implemented, color confusion.

[Cedric Shock]

Fellow developers,

On Monday 17 April 2006 01:16, Glynn Clements wrote:
> Cedric Shock wrote:
> > I have partially implemented a color prompt. It works for the colors
> > recognized by G_str_to_color. The gisprompt for it is
> > "color,grass,color". (It also works for tcltk colors of the #RRGGBB
> > variety with the prompt "color,tcltk,color").
>
> There should be a single syntax for colours. Both libgis and Tcl/Tk
> should accept either form. The only situation which may need special
> handling is if anything is restricted to the standard colours (those
> listed in colors.h, which are defined automatically by the display
> drivers).

That's right-on from the user's standpoint. I musn't have been thinking 
clearly. I'll remove the tcltk prompt code.

>
> This is a non-issue, although adding explicit type casts should make
> the warnings go away.

It doesn't. It's quite strange; Searching I could only fund R_reset_color 
prototyped and implemented once, both as int R_reset_color (unsigned char, 
unsigned char, unsigned char, int). Explicit casts are used almost everywhere 
and the warning is still generated.

>
> Options which only accept a standard colour (are there any?) should
> use "opt->options = D_COLOR_LIST;". Options which accept either RGB or
> a named colour should preserve the distinction where possible (e.g.
> using R_standard_color() instead of adding a new colourmap entry).

Most of these use D_color_list().

>
> Consistency. I'm fairly sure that the differences between the two
> tables are a mistake, probably due to someone changing the definition
> in only one place.

Ok, change they shall.

>
> Colours which refer to the corners of the colour cube should have the
> correct values, so magenta should be 255,0,255. Arguably, gray/grey
> (do we need both spellings; the rest of GRASS uses US spellings
> consistently) should be 127/128 (the centre of the colour cube).

I use both grey and gray consistently. It doesn't cost us much of anything 
since they are using the same color table entry.

>
> It doesn't really matter about orange, indigo, violet, brown or aqua,
> as those don't have any obvious definition, although we should decide
> whether 50% is 127 or 128 and use one value consistently.

128. There it's decided. (Actually I went looking on the internet for any 
compelling reason to pick one over the other and found none.) 

>
> Cyan should either be removed from G_str_to_color() or added to the
> list of standard colours in the display architecture. Updating the
> display architecture is tricky, as there are quite a few places that
> would need to be changed. OTOH, it's the only corner which isn't in
> the list.

Let's add it, assuming it would get used enough that having it preallocated 
and thus more likely to be shared will tend to reduce color table size.

There's no reason we can't have two sets of color names, one that is to 
preallocated colors and one that is just many,many,many color names that only 
work as another way of specifying RGB tripples.

>
> If choose to add cyan to the list of standard colours, we may as well
> renumber them so that the corners use the indices from 1 to 8 (i.e.
> index = 1+r+2g+4b); zero is reserved for transparent in some contexts.

This doesn't really matter, but that'd be:

1 - Black
2 - Red 
3 - Green
4 - Yellow
5 - Blue
6 - Magenta
7 - Cyan
8 - White

I'm kind of partial to
1 - Black
2 - Red
3 - Green
4 - Blue
5 - Yellow
6 - Magenta
7 - Cyan
8 - White

I'm in favor of some more macros in colors.h somewhere along this vein:

#define BLACK_RGB 0, 0, 0
#define RED_RGB 255, 0, 0

These would slightly confuse the calls to color adding things. Even better 
would be another global like: (pardon the cheating c)

unsigned char standard_color_rgb[MAX_COLOR_NUM + 1][3] = {
  {   0,   0,   0}, /* This is a dummy entry to make lookup easier */
  {   0,   0,   0},
  {255,   0,   0}
 ...

Which would allow great simplifications to driver code of something like this:

for (colorindex = 1; colorindex <= MAX_COLOR_NUM; colorindex++) {
  LIB_assign_standard_color(colorindex, DRV_lookup_color(
    standard_color_rgb[colorindex][0],
    standard_color_rgb[colorindex][1],
    standard_color_rgb[colorindex][2]));	
}

If we also have standard_color_names[...] then we could eliminate almost all 
of the disparate code. I haven't looked at the postscript stuff yet.

--Cedric