[GRASSLIST:2601] Re: [GRASS5] RE: RE: d.area: areas filled with various colors

[Glynn Clements]

Eric G. Miller wrote:

> > > > With respect to the new vector format expected in Grass5.1(?), I was
> > > > wondering if this automatic color filling is planned.  When dealing with
> > > > very large vector maps we need some way to do this.  At present I just
> > > > convert my map to raster and create categories.  This does not create too
> > > > many problems but certainly working directly with the vectors will be
> > > > better.
> > > 
> > > This is more a limitation imposed by the GRASS display architechture than
> > > anything with the vector data representation.
> > 
> > This is a limitation imposed by vector layers not having colour
> > tables.
> 
> So your saying if I used R_color() to set a color, and then
> subsequently performed a vector drawing command that the display
> drivers would do the right thing?  I was under the impression that
> vector and text graphics were limited to the named colors.

You would first need to call R_reset_color() to associate an RGB value
with a colour index.

Basically:

R_reset_color() sends RESET_COLOR, receipt of which calls

	Reset_color() -> _fixed_Reset_color() -> assign_fixed_color()

which sets an entry in the {pos,neg}_color_lookup arrays.

R_reset_colors() is similar.

R_color sends COLOR, receipt of which calls

	Color() -> _get_color_index() -> get_fixed_color()

which gets an entry from the {pos,neg}_color_lookup arrays, and makes
this colour "current" for subsequent single-colour drawing operations
(i.e. not rasters) via the (driver-specific) color() function.

Raster operations also use the {pos,neg}_color_lookup arrays, via
_get_color_index_array().

The standard colours are initialised at driver startup, by the driver
calling assign_standard_color() directly, which sets an entry in the
standard_colors array.

R_standard_color() sends STANDARD_COLOR, receipt of which calls

	Standard_color() -> get_standard_color()

which gets an entry from the standard_colors array, and makes this
colour "current" for subsequent single-colour drawing operations (i.e. 
not rasters) via the (driver-specific) color() function.

Also, the driver startup initialises the fixed colour indices 1-13
(corresponding to the constants in colors.h) to the standard colours
so that, unless subsequently changed, R_color() has the same effect as
R_standard_color() for the indices 1-13.

> programming manual:
> 
> 16.9 Colors 
> 
> int D_reset_colors (struct Colors *colors) 
>   Turns color information provided in the colors structure into color
>   requests to the graphics driver. These colors are for raster graphics,
>   not lines or text. See 12.10.3 Raster Color Table (p. 116) for GIS 
>   Library routines which use this structure.

This function doesn't seem to exist. At least, not in
src/libes/display/*.c or src/include/display.h.

D_set_colors() does exist with that prototype; that calls
R_reset_colors(), which would affect the RGB colour selected by calls
to R_color(). However, this function probably isn't appropriate for
anything other than raster graphics.

> int D_translate_color (char *name)
>   Takes a color name in ascii and returns the color number for that color.
>   Returns 0 if color is not known. The color number returned is for lines
>   and text, not raster graphics.

This translates the string "red" to the constant RED etc. The return
values can be passed to R_standard_color(), or to R_color() provided
that the colours haven't been changed from their initial setting (but
this shouldn't be relied upon).

-- 
Glynn Clements <glynn.clements at virgin.net>