[metapost] rfc: consistent color values
taco at elvenkind.com
Mon Apr 11 18:22:43 CEST 2005
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,
> 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
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.
More information about the metapost