Tikz patterns and cmyk color model

Consider the following example.

\documentclass{standalone}
\usepackage[cmyk]{xcolor}
\usepackage{tikz}
\usetikzlibrary{patterns}
\begin{document}
\begin{tikzpicture}
\tracingall
\draw [pattern = north west lines] circle [radius = 2cm];
\end{tikzpicture}
\end{document}


xcolor is loaded with cmyk option so all colors should be defined in terms of cmyk color model (analysis below shows it is the case, so xcolor is ok). But, the lines inside the circle (the pattern) are black, but this black is defined with the rgb color model.

Going through the code and the log, I found the explanation (\pgf@tempcolor, cmyk black, is converted to rgb via \pgfutil@convertcolorspec). See extract below.

% pgfcorepatterns.code.tex
\def\pgf@set@fillpattern#1#2{%
\pgfutil@ifundefined{pgf@pattern@name@#1}{%
\pgferror{Undefined pattern #1'}}
{%
\csname pgf@pattern@instantiate@#1\endcsname%
\expandafter\global\expandafter\let\csname pgf@pattern@instantiate@#1\endcsname=\relax%
\pgf@ifpatternisinherentlycolored{#1}{%
\pgfsys@setpatterncolored{\csname pgf@pattern@name@#1\endcsname}%
}{%
\pgfutil@colorlet{pgf@tempcolor}{#2}%
\pgfutil@ifundefined{applycolormixins}{}{\applycolormixins{pgf@tempcolor}}%
\pgfutil@extractcolorspec{pgf@tempcolor}{\pgf@tempcolor}%
% *** EXPLANATION HERE ***
\expandafter\pgfutil@convertcolorspec\pgf@tempcolor{rgb}{\pgf@rgbcolor}%
\expandafter\pgf@set@fill@patternuncolored\pgf@rgbcolor\relax{#1}%
}%
}%
}


This conversion seems to be needed by this other piece of code (I run pdftex).

% pgfsys-pdftex.def
\def\pgfsys@setpatternuncolored#1#2#3#4{%
\pgfsysprotocol@literal{/pgfprgb cs #2 #3 #4 /pgfpat#1\space scn}%
}


Is there a way to change this behaviour (my editor does not want any rgb-coded figures) ?

Update

Here is what I tried so far (it does not work).

\pdfcompresslevel=0
\pdfobjcompresslevel=0
\documentclass{standalone}
\usepackage[cmyk]{xcolor}
\usepackage{tikz}
\usetikzlibrary{patterns}

\makeatletter
% from pgfsys-pdftex.def
\def\pgfsys@setpatternuncolored#1#2#3#4#5{%
\pgfsysprotocol@literal{/pgfpcmjk cs #2 #3 #4 #5 /pgfpat#1\space scn}%
}

\def\pgf@sys@pgf@resource@list@colorspaces{} % Empties all reference
% to RGB

\pgfutil@addpdfresource@colorspaces{ /pgfpcmyk [/Pattern /DeviceCMYK] }

% from pgfcorepatterns.code.tex
\def\pgf@set@fillpattern#1#2{%
\pgfutil@ifundefined{pgf@pattern@name@#1}{%
\pgferror{Undefined pattern #1'}}
{%
\csname pgf@pattern@instantiate@#1\endcsname%
\expandafter\global\expandafter\let\csname pgf@pattern@instantiate@#1\endcsname=\relax%
\pgf@ifpatternisinherentlycolored{#1}{%
\pgfsys@setpatterncolored{\csname pgf@pattern@name@#1\endcsname}%
}{%
\pgfutil@colorlet{pgf@tempcolor}{#2}%
\pgfutil@ifundefined{applycolormixins}{}{\applycolormixins{pgf@tempcolor}}%
\pgfutil@extractcolorspec{pgf@tempcolor}{\pgf@tempcolor}%
% Modified (hum)
\expandafter\pgfutil@convertcolorspec\pgf@tempcolor{cmyk}{\pgf@cmykcolor}%
\expandafter\pgf@set@fill@patternuncolored\pgf@cmykcolor\relax{#1}%
}%
}%
}

\def\pgf@set@fill@patternuncolored#1,#2,#3,#4\relax#5{%
\pgfsys@setpatternuncolored{\csname pgf@pattern@name@#5\endcsname}{#1}{#2}{#3}{#4}%
}

\begin{document}
\begin{tikzpicture}
\draw [pattern = north west lines] circle [radius = 2cm];
\end{tikzpicture}
\end{document}


Evince tells me (4 times):

Error: Bad color space 'pgfpcmjk'
Error (478): Bad color space (fill)
Error (509): Incorrect number of arguments in 'scn' command


Here are some extract of the raw pdf file. Reading it, I don't understand why pgfpcmjk would be a bad color space since it is defined via /DeviceCMYK.

4 0 obj <<
/Type /Pattern /PatternType 1 /PaintType 2 /TilingType 1 /BBox [-0.99628 -0.99628 3.9851 3.9851] /XStep 2.98883 /YStep 2.98883 /Resources << >>
/Length 48
>>
stream
q 0.3985 w 0.0 2.98883 m 3.08846 -0.09962 l S Q
endstream
endobj
7 0 obj <<
/Length 532
>>
stream
0 0 0 1 k 0 0 0 1 K
0 g 0 G
0 0 0 1 k 0 0 0 1 K
0 0 0 1 k 0 0 0 1 K
0 0 0 1 k 0 0 0 1 K
1 0 0 1 56.892 56.892 cm
q
0 0 0 1 K
0 0 0 1 k
0.3985 w
q
q
/pgfpcmjk cs 0 0 0 1 /pgfpat4 scn
56.69363 0.0 m
56.69363 31.31142 31.31142 56.69363 0.0 56.69363 c
-31.31142 56.69363 -56.69363 31.31142 -56.69363 0.0 c
-56.69363 -31.31142 -31.31142 -56.69363 0.0 -56.69363 c
31.31142 -56.69363 56.69363 -31.31142 56.69363 0.0 c
h
0.0 0.0 m
B
Q
Q
n
Q
0 0 0 1 k 0 0 0 1 K
0 0 0 1 k 0 0 0 1 K
0 0 0 1 k 0 0 0 1 K
0 0 0 1 k 0 0 0 1 K
endstream
endobj
6 0 obj <<
/Type /Page
/Contents 7 0 R
/Resources 5 0 R
/MediaBox [0 0 113.784 113.784]
/Parent 8 0 R
>> endobj
5 0 obj <<
/ColorSpace 3 0 R /Pattern 2 0 R /ExtGState 1 0 R
/ProcSet [ /PDF ]
>> endobj
1 0 obj
<<>>
endobj
2 0 obj
<< /pgfpat4 4 0 R>>
endobj
3 0 obj
<<  /pgfpcmyk [/Pattern /DeviceCMYK] >>
endobj
8 0 obj <<
/Type /Pages
/Count 1
/Kids [6 0 R]
>> endobj
9 0 obj <<
/Type /Catalog
/Pages 8 0 R
>> endobj

• You have a typing error here: \pgfsysprotocol@literal{/pgfpcmjk cs #2 #3 #4 #5 /pgfpat#1\space scn}. If I replace pgfpcmjk by pgfpcmyk I get no error message. – Stephan Lehmke Dec 13 '13 at 9:45
• Well, @StephanLehmke you deserve the reward :). I spent two days on that typo. Thank you so much. – cjorssen Dec 13 '13 at 9:52
• @StephanLehmke I'll blame my French speaking editor for that :). He kept on telling me "les hachures en rvb, ça va pas, il les faut en cmjk"... Joke apart, can you turn your comment to an answer. Would you mind detailing a bit how patterns work in pdf? – cjorssen Dec 13 '13 at 10:10
• That's exactly the problem. I know nothing about that. I tried to make a test file and noticed the typo in this moment. I think it would be better (for other people finding your question) if you'd self-answer (unless you can find someone else). – Stephan Lehmke Dec 13 '13 at 10:19

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.

• +500 for taking up the duty :-) – cjorssen Dec 18 '13 at 11:17