catoptions causes option clash with xcolor

Question

Look at the following example:

\documentclass{scrartcl}

\usepackage{filecontents}
\begin{filecontents}{my1.sty}
   \RequirePackage{xcolor}
   \RequirePackage{catoptions}
\end{filecontents}
\begin{filecontents}{my2.sty}
   \RequirePackage{xcolor}
\end{filecontents}


\usepackage[cmyk]{xcolor}
\usepackage{my1}
\usepackage{my2}

\begin{document}
   \rule{2cm}{2cm}
\end{document}

catoptions seems to cause an option clash if there is a \RequirePackage{xcolor} somewhere after it. Everything works fine if I load my2 before my1 but I can’t ensure that this won’t happen.

my1 is a place holder for my menukeys package, my2 is a place holder for any other package requiring xcolor.

From catoptions guide: "Packages that redefine LaTeX's native options processing internals may not work properly with catoptions package. I know that xcolor package redefines \@declareoption and the catoptions package has taken that fact into account, but there may be other packages that modify LaTeX's options processing internals that I am not aware of." -- not that this is a real answer, but it may point someone toward a better one. — Mike Renfro, Feb 26 '12 at 03:28

score 1 · Answer 1 · answered Feb 26 '12 at 01:54

It is possible to delay the loading of catoptions with etoolbox’ \AtEndPreamble but this doesn’t wokr in the real world since I need some functions of catoptions in my1 (i.e. menukeys)

\documentclass{scrartcl}

\usepackage{filecontents}
\begin{filecontents}{my1.sty}
   \RequirePackage{etoolbox}
   \RequirePackage{xcolor}
   \AtEndPreamble{\RequirePackage{catoptions}}
\end{filecontents}
\begin{filecontents}{my2.sty}
   \RequirePackage{xcolor}
\end{filecontents}


\usepackage[cmyk]{xcolor}
%\usepackage{my2}
\usepackage{my1}
\usepackage{my2}

\begin{document}
   \rule{2cm}{2cm}
\end{document}

Ahmed Musa · Accepted Answer · 2012-02-26T06:55:42.847

1

There is indeed an option clash for xcolor package in your code. It is easy to see that in your two (actually three) loading rounds of xcolor. Here is the error help:

? h
The package 'xcolor' has already been loaded with options:
  [cmyk].
There has now been an attempt to load it with no options. 
Adding the global options:
  'cmyk'
to your \documentclass declaration may fix this.

The catoptions redefines the LaTeX command \@onefilewithoptions to catch this type of situation. If you don't want it, then I would have to send you a patch. I will then create an option in catoptions to make strick option checking optional. However, I will be reluctant to do that. This is because the following definition by LaTeX isn't robust: when #2 is empty, nothing happens (LaTeX's \@for cannot process empty list).

\def\@if@pti@ns#1#2{%
  \let\reserved@a\@firstoftwo
  \@for\reserved@b:=#2\do{%
    \expandafter\in@\expandafter{\expandafter,\reserved@b,}{,#1,}%
    \ifin@\else\let\reserved@a\@secondoftwo\fi}%
  \reserved@a
}

edited Feb 26 '12 at 06:55

answered Feb 26 '12 at 05:48

Ahmed Musa

11,742

Thank you but I fear I don’t understand what you mean. I had a look at source2e but I can’t figure out what \@onefilewithoptions does. Could you explain it, please? Is you suggestion to solve my clash to use the global options to set cmyk? – Tobi Feb 26 '12 at 10:53
1

You first loaded xcolor with option cmyk and later without any option. That leads to an option clash that LaTeX can't catch. The catoptions package highlights it. One way out is to be consistent with option loading. Another one is to allow the user of your package to load xcolor, or allow him/her to pass options to xcolor. Modifying the strict option check by catoptions isn't the solution, as in reality all option clashes should be indicated. You can use catoptions's \AfterProcessOptions to load xcolor outside the options section (of your package) with the user's options. – Ahmed Musa Feb 26 '12 at 17:53
OK, thanks again! I think I’m happy with the global options way :-) and just mention this in the manual for other users, since there are some packages that clash like this ... – Tobi Feb 27 '12 at 01:47
3

@Tobi: Well I would wish you would drop catoptions. Loading babel twice after the package gives errors, using e.g. \PassOptionsToPackage{draft}{graphicx}\usepackage{graphicx}\usepackage{graphicx} gives option clash errors. I had to load menukeys in \AtEndPreamble to keep catoptions silent - and this is not something I want to explain to my customers. – Ulrike Fischer Dec 04 '13 at 09:45
@UlrikeFischer: At the moment it seems like I need catoptions but I plan a new implementation with LaTeX3 and hope that this makes catoptions superfluous for my package. At the moment we must live with these crude behavior :-( Sorry ;-) (PS: If you have further suggestions your welcome to send an e-mail (mail@tweh.de, in german or english ;-)) or use the GitHub repo (https://github.com/tweh/menukeys, in english) …) – Tobi Dec 04 '13 at 09:52
1

@Ulrike Fischer: Thank you. I will modify catoptions in this regard. – Ahmed Musa Dec 12 '13 at 15:29
1

@Tobi I second Ulrike Fisher's comment: I wish you'd drop catoptions too. – jub0bs Dec 13 '13 at 19:27
@AhmedMusa Can you estimate when a fixed version of catoptions will become available? BTW: The clsguide (offered by the LaTeX2e team) clearly says "If a package is always loaded with \RequirePackage... or \usepackage then, even if its loading is requested several times, it will be loaded only once." – Jun 29 '16 at 06:24
Related: https://sourceforge.net/p/latex-caption/tickets/40/ – Jun 29 '16 at 06:25

catoptions causes option clash with xcolor

2 Answers2

Linked