[metapost] rfc: consistent color values

[Taco Hoekwater]

Brooks Moses wrote:
> At 03:39 AM 4/11/2005, Taco Hoekwater wrote:
> 
> I do have a couple of questions with this, and a suggestion.  First, the 
> semantics are still slightly unclear.  Suppose I do the following (with 
> the relevant variables defined appropriately):
> 
>   truecolors :=1 ;
>   addto P doublepath path1 withcolor (-1, -1, -1) ;
>   for I in within P: show (redpart I) ; endfor;
>   truecolors :=0 ;
>   for J in within P: show (redpart J) ; endfor;
>   addto P doublepath path2 withcolor (.5, .5, .5) ;

swapping the fourt and fifth line would give identical results:

    truecolors :=1 ;
    addto P doublepath path1 withcolor (-1, -1, -1) ;
    for I in within P: show (redpart I) ; endfor;
    for J in within P: show (redpart J) ; endfor;
    truecolors :=0 ;
    addto P doublepath path2 withcolor (.5, .5, .5) ;

The color clipping is done/not done by each 'addto' command.

> Further, what does the show(redpart(J)) statement do?  It should not 
> actually change the value of P; 

It doesn't.

> however, one would expect that when 
> truecolors is zero, a redpart() function should return a value in the 
> [0,1] range.

I wouldn't expect that, actually. truecolors would be a drawing
option (a part of the graphics state, if you like), with no
relation to a read-only accessor function elsewhere.

> Finally, it seems to me that there is no need to introduce a 
> "truecolors" flag to get this functionality; we could equally well 
> define intrinsics "withtruecolor" and "redtruepart" (etc.), and write 
> the above example as:
> 
>   addto P doublepath path1 withtruecolor (-1, -1, -1) ;

This 'withtruecolor' is not needed, because in this scheme 'redpart'
needs to start doing boundary clipping anyway, removing the need for
color clipping at creation time.

>   for I in within P: show (redtruepart I) ; endfor;
>   for J in within P: show (redpart J) ; endfor;
>   addto P doublepath path2 withcolor (.5, .5, .5) ;
> 
> This is, I think, a better implementation.  It avoids the problems 
> associated with flags 

OTOH (and I'm point this out for the sake of argument), it also
looses the benefits of flags / macro languages. Among which:

   * flags are generally very fast
   * are easier to implement and document
   * ... the fact that the behavior of a given
     statement depends on a hidden mode that can be set in some
     completely different part of the program, and may even be
     set in some separate inputted package file that (completely
     unknown to the user) didn't include all of its truecolor:=1
     statements in groups.
     (no pun intended.)

Either solution can be done, but better not both, and personally
I favour the flag approach, somewhat.

Taco