Menu
▾
▴
#394 [external] Interaction of TikZ with Textpos
tikzexternalize appears to interact with the textpos package in a way which generates unexpected output.
I recently received a bugreport for textpos [1] (I'm the textpos maintainer) which references a StackExchange discussion about textpos+TikZ [2]. The analysis in the accepted answer suggests that this happens because textpos uses \shipout in a way which TikZ doesn't expect. That answer offers a hacky workaround, but while I'm happy in principle to include something like this in textpos, and document when it should be used, I'm not really happy in practice with doing that, since I'm not completely clear what TikZ is doing here (I don't myself use TikZ), so I'm therefore not sure whether such an addition would eventually cause more trouble than it fixes, or whether there's a smarter solution which would avoid the problem without hacks.
What textpos (see [3], current version 1.8) does with \shipout is as follows. In 'absolute mode', it assembles its output in a special box \TP@holdbox, and then uses the everyshi package's \EveryShipout to insert that box at the end of box 255.
Is it obvious to you how/why the two package are squabbling? Is it obvious what textpos could do differently or better, or indeed TikZ? Should tikzexternalize somehow check for the presence of the everyshi package, and produce a warning if that suggests that the user is playing around with \shipout? Or is the best thing to do simply adopt the hacky advice 'when using TikZ with textpos, call \cleartextposbox at ... what point?
Any ideas?
Best wishes,
Norman
[1] https://bitbucket.org/nxg/textpos/issues/6/textpos-clashing-with-tikz-externalize
[2] http://tex.stackexchange.com/questions/66804/unexpected-output-using-tikz-textpos
[3] http://nxg.me.uk/dist/textpos/
Discussion
Hi Norman,
thanks for bringing this to our attention.
The external library has a special mode of sorts "throw everything away except for the content of a selected picture". The purpose is to generate a pdf containing just this picture, nothing else.
To this end, it pipes everything into some box and silently throws it away -- unless it encounters "\begin{tikzpicture}". In this case, it will switch back to "normal processing mode", but with a modified \shipout routine.
The fact that the content of \TP@holdbox can still make its way into the shipout routine is unexpected in this context, of course. I have just extended the solution outlined at tex.sx in a way which clears the content of TP@holdbox as soon as the external lib starts to "really collect something". This works with the example in question, and I can commit it for PGF. Imho, it should do the job... do you see risk in the solution?
Kind regards
Christian
Christian, hello.
Yes, it looks to me as if that would work; the only problem I see is that it seems very specific to textpos (if I'm understanding your suggestion correctly). The 'problem' in this case is really the fact that textpos uses the everyshi package, so that the same behaviour might occur with any other package using everyshi.
Looking at the everyshi source code, a more general solution might be to detect everyshi, perhaps by testing whether \@EveryShipout@Org@Shipout is defined, and if it is, stomping on the redefined \shipout, or otherwise replacing \shipout in a way which doesn't pick up other material added by packages using everyshi.
Of couse, this won't pick up packages which redefine \shipout without using everyshi, but there's probably little can be done with such packages. Textpos uses everyshi, rather than doing the simple manipulations to do this 'by hand', in part so that it advertises its manipulation of \shipout in a way that can be detected and overridden if necessary.
Best wishes,
Norman
Hi Norman,
I agree that the solution would be very specific to textpos... and I see the point in your suggestion.
However, I also see that there is risk in it - risk of breaking packages which might rely on everyshi and which (might) work well with external. What if I break them by means of a more general solution?
The external lib hooks deep into the internals of (la)tex, and it is not unexpected that it poses "challenges" with respect to other packages which also modify the shipout routine. I believe that it is ok to look into each specific incompatibility and address them as best as possible - and I am fine with a very specific solutions.
I suggest to deal with other incompatibilities if they show up.
Kind regards
Christian
Christian, hello.
Wouldn't it be necessary to disable such other packages also, in TikZ's 'ignore everything' mode? But I don't know the internals of TikZ, so I'll defer to you, here.
Thinking of how best to interact with textpos here: one possibility would be to detect and empty \TP@holdbox, as you suggest, but on reflection it might be better if textpos defined and documented a 'disable textpos' control sequence or option. That would avoid exposing any of textpos's internals.
I'll have a think about this and make a suggestion for a mechanism (unfortunately I won't be able to do that before next week).
Best wishes,
Norman