# textpos clashing with TikZ externalize

Issue #6 new
Former user created an issue

Hey there,

I recently tried to place a logo on the title page of my thesis using the textpos-package with the absolute option. The placement was easy using the textblock* environment.

But I got a strange error in the following TikZ-pictures: My logo appeared in each one. Please note, that I have the externalization feature activated. Disabling externalization resolves the issue, but takes a very long time to compile the document.

After some research on the web I found this Question on TeX StackExchange addressing a similar issue and providing a possible solution.

Finally, I added a MWE as attachment and inline source.

\documentclass{report}

% Include textpos to place logo
\usepackage[absolute]{textpos}

% Include pgfplots needed for graphics
\usepackage{pgfplots}
% Enable externalization
\usetikzlibrary{external}
\tikzset{external/force remake}
\tikzexternalize

\begin{document}
% Place logo
\begin{textblock*}{0.9\paperwidth}(1cm, 1cm)
LOGO
\end{textblock*}

\begin{tikzpicture}
% Draw rectangle
\draw[red] (0, 0) rectangle (5, 2);
\end{tikzpicture}

\begin{tikzpicture}
% Draw rectangle
\fill[yellow] (0, 0) rectangle (5, 2);
\end{tikzpicture}

\begin{tikzpicture}
% Draw rectangle
\fill[green, fill opacity = 0.5] (0, 0) rectangle (5, 2);
\end{tikzpicture}
\end{document}

% Magic Comment for TeXstudio ------------------------------------
% TikZ-Externalize needs the option --shell-escape
% !TeX TXS-program:compile = txs:///pdflatex/[--shell-escape]


Sorry, didn't want to be shadowy... just forgot to create an account before creating the issue.

1. repo owner

Thanks, Michue, for the report and the MWE.

Can you confirm what it is I should expect to see in your MWE (I don't currently use TikZ)? I see 'LOGO' in the top-left corner, and in the first and third boxes (plain and green) but not the second (yellow). I should see it only in the top-left corner, yes?

Hmm: I understand the problem in outline, but not I think completely, because I only partly follow how TikZ externalize is using (or indeed missing) the contents of the extra box.

I've created an issue on PGF's bugparade to ask the maintainer there if there's anything obvious I/they/we should do.

Oh, stupid me. You got the correct result out of my MWE as shown in the picture below:

I made three boxes to illustrate, that the 'LOGO' is actually behind the boxes (first box is without fill, second filled and third with 50% opacity)

The expected/desired outcome is - as you stated - the 'LOGO' only within the textpos block and not in any TikZ picture:

2. repo owner

Excellent – thanks Michael!

3. repo owner

I've adjusted the textpos documentation to include a section on choosing between relative and absolute mode (the former evades this particular problem). I'll wait to hear if the PGF issue produces some suggestions, but this discussion may be helpful in future – this isn't the only odd interaction which absolute mode is associated with.

\subsection{Absolute or relative mode?}
\label{s:absrelmode}

The \Lopt{absolute} mode appears to be the obvious mode to choose:
the positions it specifies are independent of margins, spacing and
other offsets, and so easier to think with.  Because of the way
\Lopt{absolute} mode is implemented, however, it has some
interactions which may make \Lopt{relative} mode better in some
cases.

\Lopt{absolute} mode works by inserting a \TeX\ box into a page at
almost the last moment before the page is finalised for output (at
|\shipout| time, if you're a \TeX\ afficionado).  This is normally
robust, and in many ways it is an attractively simple solution, but
it may interact badly with other packages which
manipulate this shipout' box, or packages which juggle or inspect
boxes at or just before this late stage.  In particular, the Prosper
package manipulates the page just before this stage,
the Color package inserts material using |\shipout|, and the TikZ
package (or at least its externalize' support) examines the page at
a time which means it fails to spot the absolute-mode textpos
material.

These are discussed in a little more detail below, but in each of
these cases, using textpos in \Lopt{relative} mode will evade the
problem.  This solution will work in the cases where the
\Lenv{textblock} environment is at a more-or-less predictable
location on the page.

Textpos and Prosper\marginpar{textpos \& prosper} squabble because
Textpos in absolute mode places its text onto the page \emph{after}
Prosper has rotated the page from portrait to landscape format, so
that the \Lenv{textblock} contents end up at the correct position on
the portrait page, but the wrong position on the landscape
page\footnote{Thanks to Erik Van Eynde for the initial discussion of this}.
Since Prosper slides start at a consistent point,
however, you can fairly happily use Textpos in
relative mode as long as the \Lenv{textblock} environment is the
first thing on the slide.

There's a similar unfortunate interaction with the \texttt{color}
package\marginpar{textpos \& color}.  That package's |\pagecolor|
command, when used with
\texttt{pdflatex}, causes textpos absolute mode to behave
strangely\footnote{See the \texttt{comp.text.tex} thread Colour in
a0 poster' starting 2007 April 3}.  A fix may appear here in time, but
for the present, there are three workarounds.  The first is to place
the |\pagecolor{...}| command before |\begin{document}|, which
causes the redefinitions of |\shipout| to happen in a working
order.  If this is impossible for some reason, then (as with the
Prosper workaround above) you can use textpos in relative
mode: if the textblocks are the first printable material on the
page, then they're anchored at a fixed position, and you should be
able to use textblocks and |\pagecolor| with \texttt{pdflatex}
much as normal.  The final possibility is to use \texttt{latex},
\texttt{dvips} and \texttt{ps2pdf} to produce PDF, since the
dvips driver happens not to have this problem (thanks to Joris Vankerschaver
for the initial report, and to Heiko Oberdiek for one of the
workarounds).

The TikZ externalize' mechanism should ignore all text outside of
\texttt{tikzpicture} environments, which includes the text in the
textblock environment. However, the absolute-mode textpos |\shipout|
action works without TikZ knowing it, and thus ends up interfering
in the page' that externalize is trying to build.\footnote{This
by JLDiaz' \url{http://tex.stackexchange.com/a/66853} and a Textpos
bugreport by Michael H\"upkes.}

4. repo owner

Documentation: relative vs. absolute mode. Added discussion of the implementation difference between relative and absolute mode, and when one is preferable to the other. See issue #6

→ <<cset 226f6cd003fc>>

Hey Norman, I have seen that Christian and you are trying to figure out a way that TikZ can disable textpos. Is there anything new on this topic?

5. repo owner