On Wed, 21 Aug 2013, Marco Patzer wrote:

> On 2013–08–21 Hans Hagen wrote:
>
>> On 8/21/2013 2:25 AM, Thangalin wrote:
>>> Hi,
>>>
>>> What would it take to extend \definecolor so that:
>>>
>>>   \definecolor[ColourA][ColourB][t=0.5, a=1]
>>>
>>> defines a new colour (ColourB) based on an existing colour (ColourA)?
>>>
>>> I know that \definespotcolor[ColourA][ColourB][t=0.5, a=1] works, but
>>> it seems like \definecolor would also be a natural fit.
>>
>> hm, afaik no one ever needed that (normally one defines colors once
>> on top of the document and there are seldom many of them)
>>
>> anyhow, as general inheritance is pretty fuzzy i.e. cloning a spot
>> color and changing some rgb component or cloning a cmyk color and
>> setting rgb components it will not be a feature of definecolor
>>
>> I've added \defineprocesscolor that cna be used as follows:
>
> Are you sure it's a good idea to add another colour definition
> mechanism? Then we have
>
>  \definecolor
>  \defineglobalcolor
>  \definenamedcolor
>  \definespotcolor
>  \definemultitonecolor
>  \defineprocesscolor
>
> This is getting a little confusing, in my opinion. If the only
> difference between \definespotcolor and \defineprocesscolor is the
> colour space check, can't that be dealt with using a key-value
> setting?
>
> Probably a little late to discuss this, but I also don't see why
> \definespotcolor got its own command. A simpler approach: If two
> arguments to \definecolor are provided you define a colour, if three
> arguments are provided you define a tint of a colour.

Its time for a `simplecolor` module and a `\definesimplecolor` command :)

Aditya