[GRASS5] Color prompt partially implemented, color confusion.

[Glynn Clements]

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

> In command line interactive mode the prompt is ignored 
> and entry works as before.
> 
> There is much disparity in the code relating to colors in the display modules, 
> enough to generate compiler warnings. Display module option colors come in at 
> least three flavors:
> 
> * red green and blue specified via G_str_to_color
> These programs use G_str_to_color to parse colors. They then either look for 
> the color in the color table or possibly add it. I added gisprompts of the 
> form "color,grass,color" for all of these.
> d.graph
> d.mapgraph
> d.path
> d.vect
> d.vect.chart
> 
> These generate the warnings:
> warning: passing argument 1 of -F‘R_RGB_color’ with different width due to -A
> prototype (d.graph, d.vect, d.vect.chart)
> warning: passing argument 1 of -F‘R_reset_color’ with different width due to -A
> prototype (d.mapgraph, d.path, d.vect)

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

> * An already allocated, named color via D_translate_color.
> These are probably best served by the options list.
> 
> * either red:green:blue or the name of an already allocated, named color.
> There programs usually allocate a color for each option, implement their own 
> parsers for red:green:blue colors and define that color to be the result of 
> parsing, or if a named color is used replace the reference to their allocated 
> color with the number of the named color (gotten via D_translate_color).
> 
> These might be well served by another color prompt, say "color,display,color". 
> They might also be better off looking for an existing matching color and 
> using it if it exists, otherwise adding a new color, and if that fails 
> picking the closest existing color. This could (and might already be) all 
> bound up in a single procedure that takes a string for a color and returns an 
> index into the color table to the most appropriate color.

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

> These also tend to use R_reset_color and generate warnings. 
> 
> 
> The main issue boils down to the following: Is it better to have consistent 
> color names between D_translate_color and G_str_to_color, or to have the 
> color names currently used have the same meanings they did in the past. If 
> consistency is more important then the color tables should be made to match 
> and a single prompt should be used for both. If backwards compatibility is 
> more important then we should have multiple prompts.

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.

In 5.3, XDRIVER uses 127 for grey while the PNG driver uses 175. Both
have the wrong value for magenta.

> Differences in named color definitions:
> 
> G_str_to_color ignores case.
> D_translate_color is case sensitive
> 
> name      D_translate_color    G_str_to_color
> red          255 0 0                 same
> orange     255 128 0             255 127 0
> yellow      255 255 0             same
> green       0 255 0                 same
> blue         0 0 255                 same
> indigo      0 128 255             0 127 255
> violet       255 0 255             same    (this is a strange violet)
> black       0 0 0                      same
> white      255 255 255         same
> gray        175 175 175         127 127 127
> brown     180 77 25              same
> magenta 255 0 128              255 0 255  (D_ has a very strange magenta)
> aqua       100 128 255          100 127 255
> grey        lookup to gray         127 127 127
> cyan        doesn't exist           0 255 255
> 
> How should we straighten out these colors?

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

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.

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.

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.

-- 
Glynn Clements <glynn at gclements.plus.com>