Strange behaviour with pstricks/TikZ/center

Question

I'm working on a long document (written by someone else). The author has used a lot of pstricks pictures, and I'd like to compile the document using pdflatex (without doing the detour over dvi). The documentclass depends on TikZ, and I've noticed the following very strange behaviour.

Compliling

\documentclass{article}

%% Works if we don't load tikz
\usepackage{tikz}
\usepackage[pdf]{pstricks}

\begin{document}

% Works if we load tikz, but don't use center
\begin{center}
\begin{pspicture*}(-3.24,-1.49)(10.23,5.7)
\psline(-1,0)(6,0)
\end{pspicture*}
\end{center}

\end{document}

the auto-pst-pdf phase crashes with a Ghostscript error:

"-------------------------------------------------"
"auto-pst-pdf: Auxiliary LaTeX compilation"
"-------------------------------------------------"
This is pdfTeX, Version 3.14159265-2.6-1.40.15 (TeX Live 2014/W32TeX) (preloaded format=latex)
entering extended mode
Error: /typecheck in --div--
Operand stack:
   1   0   0.0   TeXcolorgray   65781.8
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1932   1   3   %oparray_pop   1931   1   3   %oparray_pop   1915   1   3   %oparray_pop   1803   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   --nostringval--   5   --nostringval--   %repeat_continue   --nostringval--
Dictionary stack:
   --dict:1180/1684(ro)(G)--   --dict:0/20(G)--   --dict:118/200(L)--   --dict:173/300(L)--
Current allocation mode is local
Last OS error: No such file or directory
Current file position is 91942
PDFCROP 1.38, 2012/11/02 - Copyright (c) 2002-2012 by Heiko Oberdiek.

!!! Warning: Empty Bounding Box is returned by Ghostscript!
!!!   Page 1: 0 0 0 0
!!! Either there is a problem with the page or with Ghostscript.
!!! Recovery is tried by embedding the page in its original size.

==> 1 page written on `basic-pics.pdf'.
"-------------------------------------------------"
"auto-pst-pdf: End auxiliary LaTeX compilation"
"-------------------------------------------------"

---

If I don't load TikZ, everything works ok. Weirdly, if I remove the \begin{center} and \end{center}, everthing works ok too.

This is running TexLive14 on a Windows machine, but the same thing happens on a recent version of MacTex on a Mac machine.

In the end, the center environment won't be there, and the problem will go away by itself. Nevertheless, I'd be interested in a fix or at least any ideas where to dig for the problem. I haven't used pstricks and auto-pst-pdf much myself.

---

Update Apparantly, center wasn't the full story. I redefined the center-environment into a dummy do-nothing, and all seemed (sort-of) well until I compiled the full document with the real documentclass. The documentclass builds on memoir, using the showtrims option. Without showtrims, everything is ok, but with it I get the same errors as above.

Is there a way to configure auto-pst-pdf to use a different document class for its temporary creation of figures?

Answer 1

It works for me if I add \leavevmode before \begin{pspicture*}.

I guess this has to do with the changes TikZ makes to some of the innards of LaTeX, but going through the details could be very challenging.

Since adding \leavevmode shouldn't be a concern, because direct inclusion in the vertical list is something that should be avoided in LaTeX anyway, you can add

\makeatletter
\@namedef{pspicture*}{\leavevmode\pspicture*}
\makeatother

to your document preamble.

Answer 2

Seems like I found a workable "solution". Patching the documentclass with

\RequirePackage{ifpdf}
\ifpdf
\LoadClass[a4paper,11pt,twoside,fleqn,showtrims]{memoir}
\else
\LoadClass[a4paper,11pt,twoside,fleqn]{memoir}
\fi

and a similar guard where TikZ is loaded

\ifpdf
\RequirePackage{tikz}
\fi

sorts everything out. The actual guarding is done via an option for the documentclass, so that TikZ still loads normally regardless of whether we're compiling to pdf or not when the workaround is not needed.