[GRASS-dev] lib fn to convert int color number to RGB values?

[Glynn Clements]

Ivan Shmakov wrote:

>  > AFAIK, GRASS itself never sets errno.
> 
> 	But, IIUC, it doesn't prevent `errno' from being set by the
> 	standard library functions it calls?
> 
> 	Setting `errno' would make sense should there be a demand to use
> 	the standard C means of error reporting in the GRASS code.  And
> 	I can see a point in it.

I would rather have a separate grass_errno function (PROJ has
pj_errno), so that failures originating at the OS level (e.g. ENOSPC
or EPERM) can have the underlying cause determined.

>  >> If `struct color_rgb' is a ``public'' data type, then it might be
>  >> appropriate to code this function as:
> 
>  > The problem is that we have both color_rgb (colors.h) and RGBA_Color
>  > (gis.h) structures, and we should deprecate one of them (probably
>  > color_rgb).
> 
> 	Although I know no details, having two similar facilities
> 	usually implies having the code base doubled, with only a slight
> 	increase of functionality.
> 
> 	As for a generic color facility, I'd suggest looking at the
> 	following for the inspiration:
> 
> http://www-swiss.ai.mit.edu/~jaffer/slib_5#Color
> http://www-swiss.ai.mit.edu/~jaffer/Color/Color-Scheme

I'm inclined to think that supporting explicit colour spaces is
overkill for GRASS. The only one (apart from RGB) which might be
remotely useful is CMYK, and it's trivial to synthesise that from RGB
(C=1-R,M=1-G,Y=1-B,K=let PostScript calculate K itself).

Allowing colours to be specified in various spaces wouldn't be hard,
but the parser would just convert to RGB for internal use. Supporting
colours outside of the RGB gamut is too much effort for negligible
reward.

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