Re: [NTG-context] Feature Request: define colour in relation to existing colour

2013-08-21 Thread 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


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
___

Re: [NTG-context] Feature Request: define colour in relation to existing colour

2013-08-21 Thread Thangalin 
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.
___
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: [NTG-context] Feature Request: define colour in relation to existing colour

2013-08-21 Thread Aditya Mahajan 


On 2013-08-21, at 11:18 AM, Hans Hagen  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: [NTG-context] Feature Request: define colour in relation to existing colour

2013-08-21 Thread 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: [NTG-context] Feature Request: showframe debugging

2013-08-21 Thread Marco Patzer 
On 2013–08–20 Thangalin wrote:

> \showframe
> [
>   labels=on,
>   measurements=on,
>   color=red,
> ]
> 
> Would produce an image similar to the attached, but with the black
> lines drawn in the specified colour.
> 
> Using labels=on would show the names of the items that can be changed
> with \setuplayout.
> Using measurements=on would show the values for each of the items.
> 
> I don't know if there is any value separating the measurements from the 
> labels.

Some years ago I visualised the layout elements for a cheat sheet. The code can 
be
found here:

  https://gist.github.com/mpfusion/4635387

It could be extended to visualise the layout dimensions as well. But
that complicates the code, since you don't know where the labels end
up and you need to check for overlapping labels.

Marco


signature.asc
Description: Digital signature
___
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: [NTG-context] Feature Request: showframe debugging

2013-08-21 Thread Aditya Mahajan 

On Tue, 20 Aug 2013, Thangalin wrote:


Hi,

\showframe
[
 labels=on,
 measurements=on,
 color=red,
]

Would produce an image similar to the attached, but with the black
lines drawn in the specified colour.

Using labels=on would show the names of the items that can be changed
with \setuplayout.
Using measurements=on would show the values for each of the items.

I don't know if there is any value separating the measurements from the labels.


There was also the layout module[1] by Patrick that visualizes the layout, 
but it has not been tuned to work for MkIV.


[1]: http://modules.contextgarden.net/t-layout

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: [NTG-context] Feature Request: define colour in relation to existing colour

2013-08-21 Thread Aditya Mahajan 

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___
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: [NTG-context] Feature Request: define colour in relation to existing colour

2013-08-21 Thread 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: [NTG-context] Feature Request: define colour in relation to existing colour

2013-08-21 Thread Marco Patzer 
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


signature.asc
Description: Digital signature
___
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: [NTG-context] Feature Request: showframe debugging

2013-08-21 Thread Hans Hagen 

On 8/21/2013 6:49 AM, Thangalin wrote:

Hi,

\showframe
[
   labels=on,
   measurements=on,
   color=red,
]

Would produce an image similar to the attached, but with the black
lines drawn in the specified colour.

Using labels=on would show the names of the items that can be changed
with \setuplayout.
Using measurements=on would show the values for each of the items.

I don't know if there is any value separating the measurements from the labels.


You can use:

\starttext

\showlayout

% \showlayout[cc,cm,mm,bp]

\stoptext

the problem with visualizing is that values can be zero so visualizing 
becomes messy


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: [NTG-context] Feature Request: define colour in relation to existing colour

2013-08-21 Thread 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
___