textpos clashing with TikZ externalize

Create issue
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.


% Include textpos to place logo

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

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

      % Draw rectangle
      \draw[red] (0, 0) rectangle (5, 2);  

   % Draw rectangle
   \fill[yellow] (0, 0) rectangle (5, 2);  

   % Draw rectangle
   \fill[green, fill opacity = 0.5] (0, 0) rectangle (5, 2);  

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

Comments (10)

  1. Michael Hüpkes

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

  2. Norman Gray 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.

  3. Michael Hüpkes

    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:


  4. Norman Gray 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?}
    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
    \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
    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
    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
    explanation is mildly adapted from an excellent Stackoverflow answer
    by `JLDiaz' \url{http://tex.stackexchange.com/a/66853} and a Textpos
    bugreport by Michael H\"upkes.}
  5. Norman Gray 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>>

  6. Michael Hüpkes

    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?

  7. Log in to comment