Feature Request: define colour in relation to existing colour

Feature Request: define colour in relation to existing colour

[Thangalin]

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.

Kind regards.
___________________________________________________________________________________
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
___________________________________________________________________________________

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

[Hans Hagen]

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:

\starttext

\defineprocesscolor[red][r=.5]

\blackrule[color=red,width=\hsize,height=1cm]

\defineprocesscolor[redish][red][a=1,t=.5]

\blackrule[color=redish,width=\hsize,height=1cm]

\stoptext

But ... as there is some checking of the preferred color space (in 
context each defined color has a preferred color space and there is also 
a current colorspace that gets applied) you need to be aware of this:

\starttext

\defineprocesscolor[red][r=.5]

\blackrule[color=red,width=\hsize,height=1cm]

\defineprocesscolor[redish][red][a=1,t=.5]

\blackrule[color=redish,width=\hsize,height=1cm]

\defineprocesscolor[yellowish][red]

\blackrule[color=yellowish,width=\hsize,height=1cm]

\defineprocesscolor[yellowish][red][a=1,t=.5,y=.5]

\blackrule[color=yellowish,width=\hsize,height=1cm]

\defineprocesscolor[cyan][c=.5]

\defineprocesscolor[yellowish][cyan][y=.5]

\blackrule[color=yellowish,width=\hsize,height=1cm]

\stoptext

Now .. as you requested it, you're also the one who's going to wikify 
it. I'll upload a beta later.

Hans

ps. Transparency operates independently of colors but I never figured 
out a decent way to let that cooperate with existing colors that have 
transparency specs without breaking compatibility so it might never 
happen (in fact we have: current color space, current color, current 
transparency).

-----------------------------------------------------------------
                                           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
___________________________________________________________________________________

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

[Marco Patzer]

[-- Attachment #1.1: Type: text/plain, Size: 1530 bytes --]

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

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[-- Attachment #2: Type: text/plain, Size: 485 bytes --]

___________________________________________________________________________________
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
___________________________________________________________________________________

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

[Hans Hagen]

On 8/21/2013 1:11 PM, 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

the one i use

>    \defineglobalcolor

the one no-one uses

>    \definenamedcolor

just a sort of synonym one might forget about (compatibility)

>    \definespotcolor
>    \definemultitonecolor

special color spaces

>    \defineprocesscolor

the one users might use

> 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?

some are made for speed (when one changes colors a lot in local / 
grouped cases)

> 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.

well, more checking etc .. also some historic reasons as spot colors are 
rather special in the sense that they have to built on others .. seldom 
used anyway i guess


-----------------------------------------------------------------
                                           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
___________________________________________________________________________________

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

[Aditya Mahajan]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1695 bytes --]

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

[-- Attachment #2: Type: text/plain, Size: 485 bytes --]

___________________________________________________________________________________
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
___________________________________________________________________________________

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

[Hans Hagen]

On 8/21/2013 4:23 PM, Aditya Mahajan wrote:

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

Well, I suppose most users use just \definecolor as spot colors are 
something one only will use in special cases, in which the color setup 
only uses spot colors then. Also, inheritance has never been requested 
before so that's why I made a separate command, if only to avoid side 
effects.

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
___________________________________________________________________________________

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

[Aditya Mahajan]

On 2013-08-21, at 11:18 AM, Hans Hagen <pragma@wxs.nl> wrote:

> On 8/21/2013 4:23 PM, Aditya Mahajan wrote:
> 
>> Its time for a `simplecolor` module and a `\definesimplecolor` command :)
> 
> Well, I suppose most users use just \definecolor as spot colors are something one only will use in special cases, in which the color setup only uses spot colors then. Also, inheritance has never been requested before so that's why I made a separate command, if only to avoid side effects.

I understand, and I was joking.

Aditya 
___________________________________________________________________________________
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
___________________________________________________________________________________

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

[Thangalin]

[-- Attachment #1.1: Type: text/plain, Size: 913 bytes --]

For context, here is the question on TeX.SE:

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

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.

Kind regards.

[-- Attachment #1.2: Type: text/html, Size: 1444 bytes --]

[-- Attachment #2: Type: text/plain, Size: 485 bytes --]

___________________________________________________________________________________
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
___________________________________________________________________________________

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

[Hans Hagen]

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
___________________________________________________________________________________