It seems that pgf does not have any built-in support for cmyk when using ConTeXt. As a result, the macro \pgfutil@registercolor, which chooses colour models, is hard-coded not to try anything other than rgb and gray. Thus we need alter that macro and provide the necessary internal conversion:
\usemodule[tikz]
\definecolor[c][c=1]
\starttext
\unprotect
\def\pgfutil@registercolor#1{%
\edef\pgf@temp{\PDFcolor{#1}}%
\edef\pgf@marshal{\noexpand\pgfutil@in@{g}{\pgf@temp}}%
\pgf@marshal
\ifpgfutil@in@
\expandafter\pgfutil@context@parse@gray\pgf@temp\pgf@stop{#1}%
\else
\edef\pgf@marshal{\noexpand\pgfutil@in@{rg}{\pgf@temp}}%
\pgf@marshal
\ifpgfutil@in@
\expandafter\pgfutil@context@parse@rgb\pgf@temp\pgf@stop{#1}%
\else
\edef\pgf@marshal{\noexpand\pgfutil@in@{k}{\pgf@temp}}%
\pgf@marshal
\ifpgfutil@in@
\expandafter\pgfutil@context@parse@cmyk\pgf@temp\pgf@stop{#1}%
\else
\PackageError{pgf}{Color #1 has an unsupported color model.}{}%
\pgfutil@definecolor{#1}{gray}{0}%
\fi
\fi
\fi
}
\def\pgfutil@context@parse@cmyk#1 #2 #3 #4k#5\pgf@stop #6{%
\pgfutil@definecolor{#6}{cmyk}{#1,#2,#3,#4}%
}
\def\pgfutil@emu@cmyk#1#2,#3,#4,#5\@nil{%
\expandafter\def\csname\string\color@#1\endcsname
{\xcolor@{}{}{cmyk}{#2,#3,#4,#5}}%
}
\protect
\tikz\node[c]{t};
\stoptext
Original answer (to a slightly different question!)
Two things are going on here. First, pgf does not support ConTeXt's \definecolor: there is a note to the effect in the manual. So you need to use \pgfutil@definecolor instead. Secondly, there is no built-in code for a cmyk model when working with ConTeXt. However, this does not seem to be too hard to emulate:
\usemodule[tikz]
\unprotect
\def\pgfutil@emu@cmyk#1#2,#3,#4,#5\@nil{%
\expandafter\def\csname\string\color@#1\endcsname
{\xcolor@{}{}{cmyk}{#2,#3,#4,#5}}%
}
\pgfutil@definecolor{c}{cmyk}{1,0,0,0}
\protect
\starttext
\tikz\node[c]{t};
\stoptext
The problem of the OP was already solved by Stephan Lehmke in a comment. It was as simple as a typographic error, (a y changed by a j). I have to say that I was unable to see the error, although it was the first thing which I thought, and I inspected carefully the two strings, failing to see any difference (?).
So, trying to discover what the problem was, I read the PDF specification about color spaces and patterns, and learnt some things. Since the OP asked in a comment for clarification about these issues, I decided to write this short answer. I don't go after the 500 bounty, which I think I don't deserve :-)
In page 181 of the PDF specification, the "Uncoloured Tiling Patterns" are described. These are the kind of patterns used by TikZ, so this is the relevant part of the specification.
These kind of patterns do not include information about the color in which the pattern strokes or fills have to be drawn. They only define "how to draw" the pattern, but not "in which colour". Instead, the colours of the fills and strokes have to be specified when the pattern is used. This allows to the define the pattern once, and then apply it to different parts of the document with different colour.
To specify the color in wich the pattern has to be drawn, the operation SCN is required, to set the color of the strokes, and/or scn for the color of the non-strokes (fills). This operation requires two parameters, the first one being a tuple of components which specify the color (three components for a RGB model, four for a CMYK model), and the second one is the name of a "Pattern colour space", which has to be defined before.
In the code provided by the OP, the "Pattern Colour Space" is /pgfpcmyk. However this is an internal variable which can have any name we like. This variable is defined as a Pattern Colour Space in:
/pgfpcmyk [/Pattern /DeviceCMYK]
which specifies that this particular pattern color space uses CMYK and it is an "uncoloured pattern" (because /Pattern is defined as "Type 1" and "Paint type 2" in the code generated by TikZ).
Once this pattern colour space is defined, it can be used as argument of csn like this, for example:
/pgfpcmyk cs 0 0 0 1 /pgfpat4 scn
This sets first the non-stroking colourspace to /pgfpcmyk (this is done by cs operator), which was defined above as a pattern colour space, and then the value of the non-stroking colour called /pgfpat4 (used later to paint one particular instance of the pattern) as the value 0 0 0 1 (which is black in CMYK).
If the pattern colour space would be using RGB (as TikZ does by default by inserting the definition /pgfprgb [/Pattern /DeviceRGB], then the above line would have to specify the color using only three numbers, for the R,G,B components.
Also note that the particular name of the variables /pgfpcmyk or /pgfprgb do not imply that those pattern colour spaces use CMYK or RGB, respectively. It all depends how they are defined before.
Best Answer
A general answer to your question would be to study the
xcolordocumentation. The package allows for all sorts of colour mixing.Specific to your inquiry, read the introductory section 1.1 Purpose of this package (p 4):
As such,
red!75!blackwould be 75% red and 25% black. A darker red colour.