RGB colour model for plain TeX users

[hmenke]

From the mailing list:

Hi,

In Section 15.2 of the manual it says (under the "For plain TeX users"
paragraph)
        Only the two color models gray and rgb are supported.

In .../texmf-dist/tex/generic/pgf/utilities/pgfutil-plain.def it
defines the macros
        \pgfutil@emu@rgb#1#2,#3,#4\@nil
and
        \pgfutil@emu@gray#1#2,#3,#4\@nil

I have used the following to implement the RGB model:

\def\pgfutil@emu@RGB#1#2,#3,#4\@nil
{
    \pgfmathsetmacro{\@red@}{#2/255}%
    \pgfmathsetmacro{\@green@}{#3/255}%
    \pgfmathsetmacro{\@blue@}{#4/255}%
    \expandafter\edef\csname\string\color@#1\endcsname
        {\noexpand\xcolor@ {}{}{rgb}{\@red@,\@green@,\@blue@}}
}

and it works in all the cases I have tried.

Is there any chance of having this code (or better, but equivalent code)
added to pgfutil-plain.def, and the note in Section 15.2 of the manual
updated?

Thanks.

                                Jim

[Ndolam]

Hi again Henri,

I will also put this on github, but a couple of minutes of playing
around gave me

\def\pgfutil@emu@cmyk#1#2,#3,#4,#5\@nil
{
    \pgfmathsetmacro{\@red@}{(1 - #2) * (1 - #5)}%
    \pgfmathsetmacro{\@green@}{(1 - #3) * (1 - #5)}%
    \pgfmathsetmacro{\@blue@}{(1 - #4) * (1 - #5)}% 
    \expandafter\edef\csname\string\color@#1\endcsname
    {\noexpand\xcolor@ {}{}{rgb}{\@red@,\@green@,\@blue@}}
}

I realize that converting cmyk to rgb is a lot more contentious than
converting RGB to rgb, but in case anyone aside from me thinks this is
more useful than harmful, ...

Cheers.
Jim

[hmenke]

Hmmm... Conversion of RGB to CMYK depends on the used color profile. I don't know what xcolor does but your proposal seems a bit too naive.

[Ndolam]

On Sat, Nov 9, 2019 at 20:53 (-0800), Henri Menke wrote: Hmmm... Conversion of RGB to CMYK depends on the used color profile. I don't know what `xcolor` does but your proposal seems a bit too naive.

It is naive, in some sense. It is also (as far as I can tell) what ghostscript does with the -dUseFastColor argument. In some respects, this is the right thing to do for on-screen viewing, since all the colour profiles that I have seen do weird things to many of the colours when displayed on-screen. For example, looking at the visualtikz document on my screen, the red, green and blue on page 36 are output as #FF0200, #5FFF00 and #1B3BFF by acroread. Intuitively, I would expect the colour red to be rendered as #FF0000, green #00FF00, and blue #0000FF. And this is what gs displays on the screen when I use -dUseFastColor. (I used xmag to read the pixel values.) I haven't looked at xcolor's code, but I believe if a colour is specified with cmyk, the colour spec saved into the PDF file (at least with pdflatex) is in cmyk, and then the PDF viewer gets to apply its chosen colour profile when it displays the PDF file on the screen. (I have no idea what happens with other TeX engines or with dvi output.) Ultimately, plain TeX users can not (currently) use cmyk colours with TikZ anyway, so we (currently) have no hope of getting any colour profile, much less something "sensible" or "non-naive". But the benefit of that function is that with it plain TeX users can successfully compile sample code taken from various and sundry examples. I suppose the real solution is for TikZ to implement cmyk for plain TeX users. But I have no idea whether that is a month's work for someone familiar with the internals or 1/2 hour work for someone who has never looked at the PGF implementation. I suspect it is somewhere in the middle, but I have no gut feeling for where. Thanks for listening.

[hmenke]

Support for RGB has been added. 8a558df