#503 tikzpicture and xcolor throw PS errors

[Johhny Canuck]

I use tikz (and tikzpicture) a fair bit, but files that used to compile fine before the latest big update to pgf 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 a slew of PS errors.

[Herbert Voss pointed out a solution or two, which in the process points out the bug. They are embedded in the MWE, but commented out. See https://tex.stackexchange.com/questions/470077/tikzpicture-wont-render-usable-ps-code].

In Herbert's words: "tikz should pass the option prologue to xcolor if it detects that a dvi output will be created." Apparently this isn't happening. His proposed workarounds work, but this does seem to be a nasty bug (in that anyone using colors in a tikzpicture might have problems rendering a PDF fromm the PS file).

\documentclass[12pt,letterpaper,oneside]{article}

%\PassOptionsToPackage{prologue}{xcolor}

\usepackage{tikz}
 \usetikzlibrary{decorations,shapes,arrows,matrix,positioning}

\begin{document}

The following compiles and generates renderable PS only if the 'special' command (before the tikzpicture is begin) is in place.

\begin{center}
%\special{ps: /XC@. {0 setgray } def }
\begin{tikzpicture}[x=0.175cm,y=0.175cm,scale=1]

% set up maximum and minimum x- and y-coordinates
\def\xmin{0}
  \def\xmax{23.5}
  \def\ymin{0}
  \def\ymax{23.5}

% 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$};

\end{tikzpicture}
\end{center}

\end{document} 

[Henri Menke]

That's a known bug. The manual also doesn't typeset with dvips. Help is appreciated because I don't speak Postscript and cannot fix it.

[Johhny Canuck]

I'm a bit confused -- the MWE compiles perfectly using older (late 2018) pgf/tikz. It simply no longer compiles using the latest pgf/tikz. So, something in 'new pgf/tikz' breaks something that used to work. How could that be a 'known bug'? Wouldn't it be more accuratre to say 'new bug'?

[Henri Menke]

By “known bug” I mean that it was known to me before the 3.1 release. I'm not trying to say that it is not a bug, but I don't know how to fix it, so we shipped it.

[Stefan Pinnow]

Thank you for reporting. This should be fixed now.

[Johhny Canuck]

Indeed -- thanks for getting it fixed. Any timeframe before a new version is uploaded to CTAN?

[Henri Menke]

Not before TeX Live 2019 pretest.

[Christian Feuersänger]

Reopening: I found the root cause for the regression and I believe that we can fix it without resorting to the breaking change of the 'prologue' option.

[Christian Feuersänger]

The root cause is the fix for https://sourceforge.net/p/pgf/bugs/362/ . Reverting it repairs this issue and the dvips manual compiles -- almost fine.

I also fixed the dvips manual - another unrelated issue prevented its final conversion to PDF.

For now, I will revert the fix for bug 362 (and the preliminary fix for this ticket) and release a hotfix release of PGF soon.

[Henri Menke]

Do I understand it correctly that reverting the “fix” for #362 fixed this bug? Can we close it again?

[Stefan Pinnow]

See https://github.com/pgf-tikz/pgf/issues/502