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.

Marco