Menu

#82 (x)dvipdfmx problem: btrans inside bcontent incorrect

Future
open
nobody
None
5
2021-03-09
2013-08-27
Till Tantau
No

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.

Discussion

  • Till Tantau

    Till Tantau - 2013-08-27

    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.

     
  • Just A. Man

    Just A. Man - 2020-07-13

    Feeding xelatex with

    \documentclass{minimal}
    \begin{document}
    (
    \special{pdf:bcontent}
    1
    \special{pdf:btrans scale 2}
    2
    \special{pdf:etrans}
    3
    \special{pdf:econtent}
    )
    \end{document}
    

    on 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
  • Anonymous

    Anonymous - 2021-01-21

    The ChangeLog entry 2020-07-02 of dvipdfmx says

            * pdfdoc.c, spc_pdfm.c: Possible fix for a bug that pdf:btrans
            inside pdf:bcontent and pdf:econtent does not work correctly.
    
     
  • Just A. Man

    Just A. Man - 2021-03-09

    The same (presumably erroneous) output with XeTeX, Version 3.14159265-2.6-0.999992 (TeX Live 2020/Debian) (preloaded format=xelatex 2020.10.26) and dvipdfmx Version 20200315. If anyone can test a later version after 2020-07-02, please feel free.

     

Anonymous
Anonymous

Add attachments
Cancel