# ghostscript gives undefined in --execute— when using color.tex with pstricks on plain tex

Assume the following plain TeX file:

\input pstricks
\input color
\pscircle{1.5}
\bye


Compiling using eTeX works fine, dvips too. However the resulting PS file can't be processed using gs, I'll post the error message if needed. When not using the color package, the processing flow works OK. The difference between the two generated Postscripts files is:

<  0.8 SLW 0. setgray   0.0 0.0 2 copy moveto 42.67911 0 CLW mul round
< sub dup 0 rmoveto 0 360 arc closepath  gsave 0.8 SLW 0. setgray  1.
< .setopacityalpha   0  setlinejoin 0  setlinecap stroke  grestore end
---
>  0.8 SLW gray 0   0.0 0.0 2 copy moveto 42.67911 0 CLW mul round sub
> dup 0 rmoveto 0 360 arc closepath  gsave 0.8 SLW gray 0  1. .setopacityalpha
>   0  setlinejoin 0  setlinecap stroke  grestore end


i.e. one time "0. setgray" is used, the other time "gray 0". I tried to clarify, if "gray" is a valid Postscript command, according to what I found, the usual way to define a color is "setxxx".

Still I'm not 100% if this is an issue in color.sty or an issue in ghostscript. Could you give me a short hint? Thanks!

• What version of Ghostscript are you using? – egreg Aug 9 '19 at 10:52
• This is Debian unstable: 9.27~dfsg-3 – Hilmar Preuße Aug 9 '19 at 12:09
• I can at least reproduce this. Also in Debian; same version of gs. – David Purton Aug 9 '19 at 14:49

PSTricks needs at least the defined color black, which itself is internally defined as \black which itself expands to 0 setgray. But only if it is defined. However, this works:

\input pstricks
\input color
\newgray{black}{0}
\pscircle{1.5}
\bye


the problematic part is in color.sty:

\ifx\color@gray\@undefined
\ifx\color@rgb\@undefined
\else
\definecolor{black}{rgb}{0,0,0}
\definecolor{white}{rgb}{1,1,1}
\fi
\else
\definecolor{black}{gray}{0}
\definecolor{white}{gray}{1}
\fi


For some historical reasons, PSTricks defines by default the color \black. \color@gray is not defined so color does a \definecolor{black}{gray}{0} which is passed into the ps file instead of 0 setgray. However, there is no real need for using package color. One can set the colors with the PSTricks macros for plainTeX.

It's not a gs issue (the generated PostScript is error)

It works in latex as (I think) xcolor is loaded in that case even if not explicitly

\documentclass{article}
\usepackage{pstricks}
\usepackage{color}
\begin{document}

\pscircle{1.5}

\end{document}


Grayscale colours work in plain normally as well

\special{color push gray 0.5}
on two
\special{color pop}
three four

\bye


the dvips special (with the arguments coming after the color command) gets converted to the PostScript

0.5 TeXcolorgray


which is more or less just the primitive PostScript call

 0.5 setgray


The way the color package works is that normally it holds the internal color in "driver-specific special syntax" so gray is gray 0.5 black is gray 0 etc and when needed latex will do \special{color push \current@color} and the right code is generated.

But here the interface to convert to pstricks internal form so pstricks is outputting black as gray 0 instead of calling the infamous command \c@lor@to@ps which always showed up as undefined if you tried to use pstricks with pdflatex .

\c@lor@to@ps gray 0 here would call \c@lor@ps@gray 0 which expands to 0 setgray which would work.

• see my edited answer. No real need to change anything in color or PSTricks ... – user187802 Nov 24 '19 at 14:03
• @user187802 thanks for the investigation. – David Carlisle Nov 24 '19 at 14:23