I use tikz (and tikzpicture) a fair bit, but files that used to compile fine before the latest slew of updates to pgf, and pstricks, no longer seem to do so (at least, on my MikTeX installation). The MWE (below) seems to compile correctly, but the DVI can't be rendered using yap, and dvi -> ps -> pdf fails (the dvi -> ps seems to be ok -- to the extent it isn't throwing errors), but ps2pdf fails miserably, with the following errors:

 Error: /undefined in XC@.
 Operand stack:
   --nostringval--   --nostringval--   --nostringval--   --nostringval--   - 
-nostringval--   --nostringval--
Execution stack:
%interp_exit   .runexec2   --nostringval--   --nostringval--   -- 
nostringval--   2   %stopped_push   --nostringval--   --nostringval--   -- 
nostringval--   false   1   %stopped_push   2045   1   3   %oparray_pop   
2044   1   3   %oparray_pop   2025   1   3   %oparray_pop   1884   1   3   
%oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval- 
-   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--
Dictionary stack:
  --dict:979/1684(ro)(G)--   --dict:1/20(G)--   --dict:87/200(L)--   -- 
  dict:182/300(L)--   --dict:58/200(L)--
  Current allocation mode is local
  Current file position is 99615
  GPL Ghostscript 9.26: Unrecoverable error, exit code 1

Here is the MWE:





% set up maximum and minimum x- and y-coordinates

% draw and label axes
   \draw[->,thick] (\xmin,0) -- (\xmax,0) node[below=8pt,near end] 
{\small{abundance ($N$)}};
  \draw[->,thick] (0,\ymin) -- (0,\ymax) node[above=12pt,near 
 start,rotate=90] { \small{birth rate ($b$)}};

% draw vertical reference line at K/2=50
  \draw[color=black, thick,  smooth] (0,20) -- (20,0) 
node[below=6pt,midway,rotate=-45] {\small{slope~$=a$}};

% draw circle around point where function intersects x-axis
\draw [red] (0,20)  ellipse (0.2cm and 0.2cm) node[right=3pt,black] {$b_0$};


  • Confirmed that its something about the new pgf and/or PSTricks (or interaction of the two). If I roll back to versions of both before the big January updates, MWE compiles and renders perfectly. – Johnny Canuck Jan 14 at 15:24
  • dvipdf throws also errors when running it on the generated dvi. (This may indicate that the ps is not the problem.) pstricks does not seem to be involved here. – user121799 Jan 14 at 15:25
  • Rather xcolor-related (I guess). – AlexG Jan 14 at 15:31
  • So in theory, then, if xcolor is the culprit, turing off all the colors in the MWE should 'solve the problem', correct? So, first I turned off all the colors in MWE. Then, I re-applied all the updates, including PSTricks, but left the pgf out of the loop. Compiled fine. Then, applied the pgf update. Compiled fine. Closing the loop, put the colors 'back into the MWE'. Problem re-occurs. So, problem is a nasty interaction of xcolor (presumably) and pgf? – Johnny Canuck Jan 14 at 15:51
  • @JohnnyCanuck: xcolor is loaded by default and all documents use at least one color: black or in xcolor notation XC@. – user2478 Jan 14 at 15:57

the dvips driver of pgf/tikz is buggy!

\special{ps: /XC@. {0 setgray } def }


  • OK -- but for us mere mortals, now what? ;-) Meaning, if this is a pug (in your estimation) should I file it as such with the pgf maintainers, or something else? – Johnny Canuck Jan 14 at 15:54
  • 1
    sure! tikz should pass the option prologue to xcolor if it detects that a dvi output will be created. – user2478 Jan 14 at 16:00
  • OK -- I'll file a bug. In the meantime, am I correct in interpreting your post that the 'workaround' solution in the interim is to use either \special or \PassOptions? – Johnny Canuck Jan 14 at 16:02
  • 2
    Danke -- I just posted a bug report with the pgf/tikz folks. – Johnny Canuck Jan 14 at 17:15
  • 1
    @Herbert Thank you! Merge is pending so the fix will be in the next release, which will hopefully be in TL pretest. – Henri Menke Jan 15 at 9:04

This is a bug in PGF. Unfortunately, it has been introduced right before the release of the last stable -- apparently in the middle of our final tests such that it passed unnoticed.

Please do not use the suggested workaround (with the prologue option) since it breaks all colors with spaces in their name. This includes pgfplots with its mapped color.

We are sorry for it and will release a hotfix release soon.

References: https://sourceforge.net/p/pgf/bugs/503/

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.