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

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.
–
LorenzoOct 24 '13 at 9:40

2

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 beetonNov 2 '13 at 11:32

1 Answer
1

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.

Notes:
On line 3 above we open a group and set the catcode of "@" to be 11, which makes TeX treat it like an ordinary letter, so we can use it in a control sequence name. On line 4,
we define a "dec@mma" command that takes an argument "{a,b,c}" and produces "a b c". The name is meant to sound like "de-comma". On line 5 we define the missing "xcolor@" command. We define it to expect four arguments. We ignore arguments #1 and #2; we expect #3 to be a colour space name - well actually we expect it to be "rgb" to be honest; and we expect #4 to be three numbers separated by commas. We call "decomma" to get rid of the commas. One line 6 we close the group.

The commands use "gdef" rather than "def" so that they are visible outside the local group.

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.