PSTricks and Tikz in plain TeX

I would create both pstricks and tikz picture in my plain TeX documents. If I try, I get an error, maybe caused by the use of the xcolor package. The error is the following: \\color@black ->\xcolor@ and so on for the others color (black and gray in particular). I think that if I don't allow tikz to load xcolor package, I get no errors. Is it right? If it is, how can I order tikz to don't load that package too? This is an example

    \input pstricks
\input tikz

\pspicture(0,0)(1,1)
\psline{->}(0,0)(1,1)
\endpspicture
\bye

-
Hi! You've asked 11 questions before, so you might know that Minimal (non-)Working Example is quite necessary for questions like this one. –  yo' Oct 21 '13 at 11:50
Disabling tikz will work. –  kiss my armpit Oct 21 '13 at 12:26
I would use tikz environment too! –  Lorenzo Oct 21 '13 at 12:28
Note that the input above works correctly in LaTeX (with \begin{pspicture}...\end{pspicture}, of course), and I can insert the same picture in tikz. So, my aim is only to force tikz to don't invoke xcolor package. –  Lorenzo Oct 24 '13 at 9:40
if tikz has a \RequirePackage{xcolor} instruction, and includes commands defined in xcolor, then it will be necessary to patch tikz to get rid of them. trying to use plain tex instead isn't a solution; it will only make solving the problem more difficult. –  barbara beeton Nov 2 '13 at 11:32

Despite the lack of response to my comments I'll post an answer here anyway, as I seem to have a working solution. I'm very tentative about this one, as the packages pstricks and tikz are so large that there may well be some other interactions I know nothing about. I have to say that if your objective is the simplicity of plain TeX then using both of these packages at the same time appears to be a recipe for a headache.

The error about the undefined colour macro occurs because tikz redefines the colour commands used by pstricks, so \\color@black (note the extra \) gets mapped to \xcolor@{}{}{rgb}{0,0,0} and \\color@blue to \xcolor@{}{}{rgb}{0,0,1} etc.

But neither pstricks nor tikz defines an \xcolor@ command, so you get an error.

IMHO the best way to fix this would be not to use tikz here, but since you want to try using both, here is a "reverse-engineered" fix that works at least for this simple example, and might form the base for further development.

\input pstricks
\input tikz
{\catcode\@=11
\gdef\dec@mma#1,#2,#3{#1 #2 #3}
\gdef\xcolor@#1#2#3#4{\dec@mma#4 set#3color}
}

Lorem

\psset{linecolor=blue}
\pspicture(0,0)(2,1)
\psline{->}(0,0)(2,1)
\endpspicture

Ipsum

\tikzpicture
\path[draw=red] (0,0) -- (1,1) -- (2,1) circle (10pt);
\endtikzpicture

Dolor

\psset{linecolor=black}
\pspicture(0,0)(2,1)
\psline{<-}(0,0)(2,1)
\endpspicture


The only colour space name used by TikZ appears to be "rgb", so we could have written \gdef\xcolor@#1#2#3#4{\dec@mma#4 setrgbcolor}` without loss of function. The other possible colour space names include "gray" and "cmyk", but to support these properly we would need to cope with a variable number of arguments - gray needs just one number, cmyk needs four - which would make things more complicated.