13

colorleak page one colorleak page two

The text at the bottom of page 2 is red, despite the fact that the color change in the code below originates from \color{red}\normalcolor within the multicols within the figure and should naively not have had such an impact. No effect is seen if either:

  1. one comments out the \begin{multicols} and \end{multicols} lines,

  2. one comments out the \begin{figure*} and \end{figure*} lines.

My question is why does this happen? (I expect to hear about some kind of whatsit subtlety).

and is there a work-around ? (in my context I have \color{red} and later \normalcolor before the text, more or less as here, and I can not change that, so the solution should not change anything to the inside of the multicols and the only customizing possibility would be to add extra stuff either before or after the multicols environment or both).

Update David's proposal to add a group or brace pair inside the multicols cures the problem (I initially thought I had no access to these contents, but I had forgotten my own hooks) and another way is to add \normalcolor or even \color{green} (sic) inside the figure* environment before the multicols environment. This second medicine avoids to have to insert anything inside the multicols.

\documentclass{article}
\usepackage[paperheight=6cm]{geometry}
\usepackage{multicol}
\usepackage{color}
% COLOR LEAK IF COLOR WITHIN MULTICOLS WITHIN FIGURE
\begin{document}
Hello World World World World World World World
World World World World World World World
World World World World World World World
World World World World World World World
World World
World World World 
World World World World World World World
World World World World World World World
World World World World World World World
World World World World World World World
World World
\begin{figure*}[ht!]
  \begin{multicols}{2}
    \color{red}\normalcolor
    Hello. World World World
    World World World World World World
    World World World World World World
    World World World World World World
    World World World World World World
    World World World World World World
    World World World World
    World World World World World World
    World World World World World World
    World World World World World World
    World World World World World World
    World World World World World\par
  \end{multicols}
\end{figure*}
World World World 
World World World World World World World
World World World World World World World
World World World World World World World
World World World World World World World
World World
World World World 
World World World World World World World
World World World World World World World
World World World World World World World
World World World World World World World
World World
World World World 
World World World World World World World
World World World World World World World
World World World World World World World
World World World World World World World
World I AM RED, WHY?

\end{document}
3
  • forgot to say that the images were produced via dvipng but compilation via pdflatex gives the same output.
    – user4686
    Oct 14, 2013 at 12:07
  • adding \normalcolor within figure* after \end{multicols} does not modify anything.
    – user4686
    Oct 14, 2013 at 12:10
  • I say in the text that I have no easy access to the multicols contents, but I had forgotten my own hooks precisely designed for that. So I could solve my real life problem following David's advice and using the hooks to put the entire stuff from inside the multicols within a group inside the multicols.
    – user4686
    Oct 14, 2013 at 13:51

2 Answers 2

7

David's suspicion is correct: multicol is at fault here. When the environment detects that it is used inside a box (e.g., in a float in this case) it will collect its material inside a vertical box and then applies its balancing routine by splitt the box into columns. It does this by using \setbox in a way that is not "color safe".

As a result the first color change in the sequence \color{red}\normalcolor (or more precisely the second last color change) will be misinterpreted by the surrounding float environment as the outer color to be restored after the float as it remains on the "color stack".

A possible patch for this would look as follows:

\usepackage{etoolbox}
\makeatletter
\patchcmd{\mult@@cols}{\vbox\bgroup}{\vbox\bgroup\color@setgroup}{}{\PATCHerror}
\patchcmd{\endmulticols}{\egroup}{\color@endgroup\egroup}{}{\PATCHerror}
\makeatother 

but obviously that should be properly integrated into the multicol package. A nice example of the fact that this part of the multicol code predates LaTeX2e and quite interesting that it took this bug 20 years to surface.

Update

Just for the record this patch has been integrated in multicol for a while so this problem should no longer happen.

2
  • 1
    \PATCHerror...?
    – Werner
    Nov 1, 2013 at 21:26
  • 1
    @Werner, well if the patch fails for some reason it will execute \PATCHerror which his undefined ... ok I was a little lazy Nov 1, 2013 at 21:31
10

Interesting:-)

As it's an interaction between color and multicol then it's probably something to do with some code of mine or Frank's. Obviously I suspect Frank:-)

No time to debug now but such problems are usually fixed by adding an extra group, and adding {} as here, fixes it in this case.

  \begin{multicols}{2}
    {\color{red}\normalcolor
    Hello. World World World
    World World World World World World
    World World World World World World
    World World World World World World
    World World World World World World
    World World World World World World
    World World World World
    World World World World World World
    World World World World World World
    World World World World World World
    World World World World World World
    World World World World World\par}
8
  • I had tried the group or braces to encapsulate multicols and that didn't work. Unfortunately I can't easily (I could with some effort) follow your tip in my real life case; the whole \multicols is created by some macro, and basically I can only prefix or postfix it ... so ... I'll wait before moving your rep closer to the 1M mark...
    – user4686
    Oct 14, 2013 at 12:22
  • @jfbu Wouldn't \begingroup...\endgroup instead of {...} do it's job as well?
    – yo'
    Oct 14, 2013 at 12:55
  • @tochecz David's fix can be applied indeed with \begingroup...\endgroup, the problem is that this is inside the multicols. I do not have easy access to this, and as I said if I put the whole multicols with its contents inside a group or a brace pair, this doesn't resolve anything.
    – user4686
    Oct 14, 2013 at 13:30
  • @tochecz Actually I had entirely forgotten in my real-life case that I have at my disposals hooks (this is my own package, I had prepared these hooks but rarely use them) to put things inside the multicols before and after its contents. Something like \def\hookbefore{\begingroup} and \def\hookafter{\endgroup} or with \bgroup and \egroup is a way to put David's proposal to work in my real life problem. This cured indeed the color leak. OK, so now the thing remaining is to understand the source of the problem!
    – user4686
    Oct 14, 2013 at 13:44
  • @jfbu look for a discussion of "colo[u]r safety" in grfguide and color package documentation, which explains why extra groups are a good thing. Oct 14, 2013 at 14:17

You must log in to answer this question.