Hi,
there is a problem in (x)dvipdfmx (also in plain dvipdfmx): When a transformation special like
\special{pdf:btransform scale 2}
is encountered inside a block surrounded by \special{pdf:bcontent} and \special{pdf:econtent}, the result is an incorrect transformation.
Here is a minimal example:
\documentclass{minimal}
\begin{document}
(
\special{pdf:bcontent}
1
\special{pdf:btrans scale 2}
2
\special{pdf:etrans}
3
\special{pdf:econtent}
)
\end{document}
What happens is that the "2" is shown somewhere "off", while it should be in the middle between 1 and 3.
When the bcontent and econtent specials are removed, the placement of the 2 is correct.
The reason for this bug is that \special{pdf:btrans scale 2} always produces the same output in the PDF stream and does not take into account that \special{pdf:bcontents} actually changes the origin (interestingly, nested bcontents works, they take the changed origin into account; the same is true for image inclusion). I presume this is because the latter special was added later and the btrans code was not updated.
Unfortunately, this bug causes the inclusion of scaled graphics in tikz pictures to become incorrect in xelatex. The reason is that the inclusion of graphics uses \scalebox internally in xetex and this uses btrans, which clashes with the fact that the backend driver of tikz uses bcontent. I will try to step around this problem in the driver somehow, but it would be better it this were fixed directly in (x)dvipdfmx.
Anonymous
Ah, once more thing: This problem could also be fixed by patching the scaling code in xetex.def and dvipdfmx.def from the latex sources: Replace the use of
\special{pdf:btrans xscale \Gscale@x\space yscale \Gscale@y} % dvipdfmx.def
or
\special{x:gsave}\special{x:scale \Gscale@x\space\Gscale@y} % xetex.def
in the definition of \Gscale@start
by
\special{pdf:bcontent}\special{pdf:code \Gscale@x\space 0 0 \GScale@y\space 0 0 cm}
The definition of \Gscale@end should just be
\special{pdf:econtent}
Similarly, the \Grot@start should be patched to use bcontent and the pdf:code as above, but with the necessary rotations.
Feeding
xelatex
withon TeX Live 2019/Debian results in the file in the attachment. The output doesn't look right to me, though it is unclear on what "the right position" in https://www.tug.org/TUGboat/tb30-1/tb94cho.pdf should be.
Last edit: Just A. Man 2021-03-09
The ChangeLog entry 2020-07-02 of dvipdfmx says
The same (presumably erroneous) output with
XeTeX, Version 3.14159265-2.6-0.999992 (TeX Live 2020/Debian) (preloaded format=xelatex 2020.10.26)
anddvipdfmx Version 20200315
. If anyone can test a later version after 2020-07-02, please feel free.