[metapost] rfc: consistent color values

[Taco Hoekwater]

Daniel H. Luecking wrote:
> On Mon, 11 Apr 2005, Taco Hoekwater wrote:
> 
> 
>>Thank you Dan, Hans,
>>
>>It is much clearer now. If I understand correctly, you are both
>>just being lazy and do not want to do boundary folding yourselves,
>>right? :-)
> 
> I wouldn't have to do it now. Why would I want to increase my work?

True enough. ;-)

> Anyway, I have no problem with Jacko's proposal except that it
> slightly increases the number of variables that might have to
> be checked.

It can easily be argued that allowing 'supercolors' in images
would make picture iteration postprocessing (as done by e.g. metafun,
and presumably your macros as well), even more flexible than it is
currently, yes?

Anyway, since default behaviour would remain as-is, perhaps you
don't really need to make the check, but instead just document
it as 'unexpected results are possible'.

> Speaking of which, does anyone know what a PS interpreter is supposed to
> do if an rgb color has out-of-range components? (I'm wondering how
> important it would be for a macro package to know the value of the
> proposed truecolors and program around it.)

The PS specification says:

   setrgbcolor                              red green blue setrgbcolor –

   sets the current color space in the graphics state to DeviceRGB and
   the current color to the component values specified by red, green, and
   blue. Each component must be a number in the range 0.0 to 1.0. If any
   of the operands is outside this range, the nearest valid value is
   substituted without error indication.

but I would personally not trust the 'without error indication' to work
when e.g. importing a file into a drawing program. I am not so sure that
truecolors:=2 is a good idea.

Taco