Feature Request: define colour in relation to existing colour
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.
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 -----------------------------------------------------------------
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
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 -----------------------------------------------------------------
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
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 -----------------------------------------------------------------
On 2013-08-21, at 11:18 AM, 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.
I understand, and I was joking. Aditya
For context, here is the question on TeX.SE: http://tex.stackexchange.com/questions/129297/define-colour-transparency-in-... 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.
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... http://tex.stackexchange.com/questions/129297/define-colour-transparency-in-...
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 -----------------------------------------------------------------
participants (4)
-
Aditya Mahajan -
Hans Hagen -
Marco Patzer -
Thangalin