[metapost] greypart and other color queries.
taco at elvenkind.com
Fri May 29 22:02:51 CEST 2009
Dan Luecking wrote:
> This works:
> draw (0,0)--(10,10) withcolor .6;
> show greypart currentpicture;
> and shows 0.6.
> But, contrary to mpman (section 6.3, page 20), this does not
> numeric C; C:=0.6;
> show greypart C;
> When C is a greyscale color (i.e., a numeric), it always
> shows 0. Have I misunderstood something?
That is easy to explain, it is simply a bug. A fix is in
the SVN repository already.
> The documentation of defaultcolormodel is rather unclear.
> What is the effect of changing it? As near as I can tell,
> every drawing object that lacks a withcolor clause is
> preceded in the output by setting the color to black in the
Yes. And that is relevant only because not all color models
agree on the value of 'black'.
> Are there any other effects?
> The table on page 30 mysteriously maps "withcolor true" to
> "<current default color model>" which is not any kind of
> with-operator at all. What does "draw p withcolor true;"
> As near as I can determine from tests it does
> absolutely nothing.
Correct. It just is very determined about doing nothing, which
can be helpful in a macro that is to be used after 'withcolor'.
draw p withcolor true;
are functionally the same.
> It seems it _ought_ to cancel a previous
> "withcolor false" according to this quote:
> "the last withcolor, withrgbcolor, withcmykcolor,
> withgreyscale or withoutcolor specification sets the
> color model for any particular object"
> but it doesn't.
But it does! It explicitly sets the normally implicit default
color model. The polymorphism of the withcolor command is
such that you can do everything with withcolor that you could
also do with other means:
p withcolor <cmyk> => p withcmykcolor
p withcolor <rgb> => p withrgbcolor
p withcolor <numeric> => p withgreycolor
p withcolor false => p withoutcolor
p withcolor true => p
> Is this a bug? If it is intended, the table
> ought to say it is mapped to <empty> and the text should
> explain that the above quote doesn't apply.
It is indeed mapped to <empty>, and of course <empty> itself
is mapped to 'black' in the current default color model.
> Paradoxically (for those who think of black-and-white pictures
> as being without color):
> draw p withcolor red;
> draw q withcolor true;
> produces q in black, while
> draw p withcolor red;
> draw q withoutcolor;% or withcolor false
> produces q in red.
I think this at least is documented quite clearly: "withoutcolor"
(and "withcolor false") do not output a color selection command to
the generated ps/svg code. A "withoutcolorcommandoutputinthebackend"
command would have been more than a bit too long :)
More information about the metapost