Re: Feature Request: define colour in relation to existing colour

[Hans Hagen <pragma@wxs.nl>]

On 8/21/2013 8:27 PM, Thangalin wrote:
> For context, here is the question on TeX.SE:
>
> http://tex..stackexchange.com/questions/129297/define-colour-transparency-in-relation-to-existing-colour
> <http://tex.stackexchange.com/questions/129297/define-colour-transparency-in-relation-to-existing-colour>
>
> I agree with Marco:
>
>     Are you sure it's a good idea to add another colour definition
>     mechanism? Then we have
>
>        \definecolor
>        \defineglobalcolor
>        \definenamedcolor
>        \definespotcolor
>        \definemultitonecolor
>        \defineprocesscolor

As said before:

\defineglobalcolor : probably no one (besided me) will use that
\definenamedcolor  : an historic synonym

so we have less commands. As spot and multitone colors are rather 
special, they have their own commands. In fact, you can stick to

\definespotcolor
\definemultitonecolor
\defineprocesscolor

if you like and forget about the rest.

MkIV: Much color related code sits at the Lua end and for some color 
spaces a bit extra info needs to be passed. Also, spot and multitone 
colors are always global. Combining all in one command is of course 
doable but deu to the fact that we end up with extra analysis at the tex 
end it would make the code more complex then I'd like with hardly any 
gain (and it would also make the command less efficient for local use). 
The average user will probably only use \definecolor and that one 
already has to take a lot into account, for instance mixed colors

\definecolor[whatever][.5(red,green)]

and some special tikz cases, which, in a combined command would mean 
that a second argument can be a parent color (needs to be resolved at 
the tex end before defining) or a mix specification or ...

MkII: the definition has been made efficient by assuming a limited set 
of known keys.

> That is a little confusing. I can understand a speed requirement, but
> surely that can be taken into consideration beneath the definition?
>
> \definecolor[A][r=1, g=0, b=0]
> \definecolor[B][A][a=1, t=0.5]
>
> That seems fairly reasonable. Also, why not embed colour spaces within
> the command?
>
>      \definecolor[A][colorspace=spot]
>      \definecolor[A][colorspace=multitone]
>      \definecolor[A][colorspace=pantone]

> One command to define a colour, rather than several commands for
> specific variations of defining colours.

Putting too much in one command makes it harder to extend and more 
difficult to implement. Maybe

\definecolor [colorspace] [A] ....

but again, it would be tricky to get that compatible. Maybe at some 
point \definecolor can become equal to the just introduced 
\defineprocesscolor ... but not now

Hans



-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
                                              | www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________