On 13/05/2017 12:49, Philip Taylor wrote:
>
>
> John Was wrote:
>> Even if PS-Tricks and Tikz do clash, it doesn't seem to be PS-Tricks
>> specifically that's causing this issue (I've tried commenting it out) -
>> suspicion currently falls on Edmac, which I use for cropmarks and sometimes
>> for other purposes (e.g. automatic line numbering of texts when required). I
>> don't really mind doing without tikz (at least for now), but it would be
>> good to know the cause of the weird behaviour!
> Then I think you will have to strip down your fault-provoking code to
> something manageable, John; "necessary and sufficient" is the key -- you have
> provided the necessary, now it is surely incumbent on you to strip it down to
> the necessary if others are to be able to help you in finite time.
>
> Philip Taylor
A minimal example is
\input ulem.sty
\input tikz
\tikzpicture
\path[draw=red] (0,0) -- (1,1) -- (2,1) circle (10pt);
\endtikzpicture
\bye
with the first piece of text pointing to ifpdf: the issue is not limited
to TikZ. (It doesn't help though that TikZ's emulation of a minimal
LaTeX set up isn't 'self-contained': the load order cannot be reversed
here.)
This allows us to isolate the issue: ulem.sty does
\expandafter\ifx\csname ProvidesPackage\endcsname \relax
which leaves \ProvidesPackage as \relax in plain (there is no grouping).
That's an issue for any code that tests 'quickly' for \ProvidesPackage,
for example in ifpdf.sty
\ifx\ProvidesPackage\undefined
The most obvious solution is to get rid of the problematic definition:
\input ulem.sty
\let\ProvidesPackage\undefined
\input tikz
\tikzpicture
\path[draw=red] (0,0) -- (1,1) -- (2,1) circle (10pt);
\endtikzpicture
\bye
Joseph
--------------------------------------------------
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
