\rotatebox breaks the color setting

[wtsnjp]

This can be a problem for dvipdfmx, but I believe it worth reporting here.

Brief outline of the bug

While using dvipdfmx, when I use \rotatebox, the color setting was broken.

The testing environment:

• macOS 10.15.7
• TeX Live 2021 pretest
• pdflatex (dvi output)
• LaTeX2e <2020-10-01> patch level 4 / L3 programming layer <2021-02-18>
• dvipdfmx Version 20210304

Minimal example showing the bug

\RequirePackage{latexbug}
\documentclass[dvipdfmx]{article}

\usepackage[T1]{fontenc}
\usepackage{color}
\usepackage{graphicx}

\begin{document}

\textcolor{red}{\rotatebox{0}{A}B}

\end{document}

When I process the above in the normal dvipdfmx flow, namely 1. latex, 2. dvipdfmx, it outputs "A" in red, but "B" in black, where "B" also should be output in red.

This does not happen with TeX Live 2020. This also does not happen if I comment out the following lines in divpdfmx.def:

\def\set@color{%
  \special{pdfcolorstack \@pdfcolorstack push (\convert@color\current@color)}%
  \aftergroup \reset@color
}
\def\reset@color{%
  \special{pdfcolorstack \@pdfcolorstack pop}%
}

Log file (required) and possibly PDF file

mwe.log

[josephwright]

The colour stack should work the same as in pdfTeX, where there is no 'macro magic' to allow for rotations. As such, this looks like a backend bug to me: I tried with both pdf:btrans rotate and x:rotate and got the same. I suspect this will also show for other transformations. I guess I'll need to report there using a plain TeX demo.

@davidcarlisle Thoughts? We can back out the change for the moment while we explore a backend fix, or we could 'kick the can' by setting a backend version that's not yet released, or we could just put up at present.

[davidcarlisle]

unless the binary can get changed already in TL2021, I suspect that we should make this work as well as possible at the macro layer.

[josephwright]

I think the only macro fix is to back out the use of colour stacks, either explicitly or by as I say requesting a driver version that doesn't actually exist. Easy enough to do, of course. (I suppose if we do I'll also adjust l3backend in the same way.)

[FrankMittelbach]

can we check out if it might get first for TL21 first? Seems better than waiting a year for an engine fix

[josephwright]

@FrankMittelbach dvipdfmx gets updated on Windows (at least) during the year, so it's not quite as bad as that

[FrankMittelbach]

so much the better then, in that case I would say first check if that can be and will be updated soon (and if so how soon) and if that is promised reasonably soon do nothing at our end

[josephwright]

Reported to the dvipdfmx list: https://tug.org/pipermail/dvipdfmx/2021-March/000254.html. Let's see what we get back there.

A back-out fix is easy so if necessary I'll do that before Karl freezes for TL'21 DVD - better than a broken colour situation in XeTeX!

[josephwright]

I have a macro-level fix for this now:

\makeatletter
\def\Grot@end{\special{pdf:etrans}\special{pdfcolorstack \@pdfcolorstack current}}
\let\Gscale@end\Grot@end
\makeatother

(plus possibly a line added to \GPT@clipbox for similar reasons). A similar change would be needed in the l3backend code: there it's a single location.

I think the above is safe with pgf as the latter uses raw pdf:literal q/Q pairs to create scope, and they don't have the 'interesting' colour behaviour.

I'll make the change and put in a PR: could people check?

[josephwright]

We have decided to disable using the new stacks for the present, and will try again later when we are away from the TeX Live freeze period.

[josephwright]

I've just submitted an update to CTAN: it simply bails out before even looking at the version of dvipdfmx/extractbb. That will restore the old behaviour for the present.

As outlined above, there is a plan for both being able to use the new stacks and avoid this issue, but we need to have more than a couple of days before DVD freeze to test out. So I will revisit it later.