driver overwrite added

[komascript]

I quite often see users loading graphics or graphicx with totally wrong driver options. The most common case is that (superfluous) option pdftex is used and then this is overlooked when switching to XeLaTeX or LuaLaTeX. In both cases, this leads to error messages which the user can usually do little with.

I have therefore created a modification of graphics.cfg which basically deactivates the wrong driver options so that only a suitable warning is issued. Instead of a warning, a suitable error message could of course also be output — similar to the hyperref package. Which is better is IMHO more a matter of taste.

[josephwright]

That's the same approach the expl3 layer takes: it just ignores the user if the option is wrong. Seems reasonable to me.

[davidcarlisle]

I think the idea is sound, a couple of English comments have been made inline but we would need to address color as well since they share back end files.
If just graphics.cfg is modified as here then

\documentclass{article}

\usepackage[dvips]{color}
\usepackage[dvips]{graphicx}

\begin{document}

\end{document}

runs without error but loads both dvips.def and graphics.def which is not a good combination.

You could copy graphics.def to color.def (and optionally change {graphics} to {color} in the Packagewarning. That fixes things for color but unfortunately that breaks xcolor and

\documentclass{article}

\usepackage[dvips]{xcolor}
\usepackage[dvips]{graphicx}

\begin{document}

\end{document}

gives

! LaTeX Error: \RequirePackage or \LoadClass in Options Section.

Probably easy to fix, but I can't look until later.

[komascript]

xcolor uses a completely different option handling with key-value options. So handling this with the same color.cfg would need detection of which package loads color.cfg. Maybe this would be the chance to use a different cfg for xcolor or even add the automatic driver selection into xcolor.

[komascript]

As a first workaround I've made a color.cfg, that uses the deactivation code, but not with xcolor loaded. So xcolor would still load dvips.def in your example, which indeed isn't good.

[komascript]

And the new version of color.cfg also handles xcolor. For example using pdflatex

\documentclass{article}

\usepackage[dvips]{xcolor}
\usepackage[dvips]{graphicx}

\begin{document}

\end{document}

results in:

Running `LaTeX' on `test' with ``pdflatex  -file-line-error   --synctex=1 -interaction=nonstopmode test.tex''
This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023) (preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode
(./test.tex
LaTeX2e <2023-11-01> patch level 1
L3 programming layer <2024-02-20>
(/usr/local/texlive/2023/texmf-dist/tex/latex/base/article.cls
Document Class: article 2023/05/17 v1.4n Standard LaTeX document class
(/usr/local/texlive/2023/texmf-dist/tex/latex/base/size10.clo))
(/usr/local/texlive/2023/texmf-dist/tex/latex/xcolor/xcolor.sty (./color.cfg)

Package xcolor Warning: Explicit driver option dvips ignored,
(xcolor)                because detected engine does not support it.
(xcolor)                We recommend to remove the explicit driver option.
(xcolor)                Still staying with driver pdftex.def.

(/usr/local/texlive/2023/texmf-dist/tex/latex/graphics-def/pdftex.def)
(/usr/local/texlive/2023/texmf-dist/tex/latex/graphics/mathcolor.ltx))
(/usr/local/texlive/2023/texmf-dist/tex/latex/graphics/graphicx.sty
(/usr/local/texlive/2023/texmf-dist/tex/latex/graphics/keyval.sty)
(/usr/local/texlive/2023/texmf-dist/tex/latex/graphics/graphics.sty
(/usr/local/texlive/2023/texmf-dist/tex/latex/graphics/trig.sty)
(./graphics.cfg)

Package graphics Warning: Explict driver option dvips ignored,
(graphics)                because detected engine does not support it.
(graphics)                We recommend to remove the explicit driver option.
(graphics)                Still staying with driver pdftex.def.

)) (/usr/local/texlive/2023/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def) (./test.aux)
(/usr/local/texlive/2023/texmf-dist/tex/context/base/mkii/supp-pdf.mkii
[Loading MPS to PDF converter (version 2006.09.02).]
) (/usr/local/texlive/2023/texmf-dist/tex/latex/epstopdf-pkg/epstopdf-base.sty
(/usr/local/texlive/2023/texmf-dist/tex/generic/infwarerr/infwarerr.sty)
(/usr/local/texlive/2023/texmf-dist/tex/latex/grfext/grfext.sty
(/usr/local/texlive/2023/texmf-dist/tex/generic/kvdefinekeys/kvdefinekeys.sty)) (/usr/local/texlive/2023/texmf-dist/tex/latex/kvoptions/kvoptions.sty
(/usr/local/texlive/2023/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty)
(/usr/local/texlive/2023/texmf-dist/tex/latex/kvsetkeys/kvsetkeys.sty))
(/usr/local/texlive/2023/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty
(/usr/local/texlive/2023/texmf-dist/tex/generic/iftex/iftex.sty))
(/usr/local/texlive/2023/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg))
(./test.aux) )
No pages of output.
Transcript written on test.log.

TeX Output finished at Wed Feb 28 11:19:13

[komascript]

BTW: I've also corrected build.lua, because the original one resulted in

...ocal/texlive/2023/texmf-dist/scripts/l3build/l3build.lua:181: too many C levels (limit is 200) in main function near '"

and did not install color.cfg.

[davidcarlisle]

@komascript this errors with the graphics-pln plain tex support

\input{color}

\color{red} x

\bye

gives

! Undefined control sequence.
\Gin@DeclareEngineClash ...fnum \@ifpackageloaded 

it would of course be possible to add more guards here or add a definition of \@ifpackageloaded to miniltx.ltx but color.cfg seems to be getting over complicated.

I'm wondering about a different approach:
For engines where only one backend .def is possible instead of looping through all the "wrong" options, simply \input the required def

then add a guard in each of the def files so they warn if a different def has already been loaded, and \endinput in that case (or if they have been loaded)

[komascript]

I've just tried to do it without changing of color.sty, xcolor.sty, graphics.sty or all the *.def. (And I also just wanted to change graphics.cfg, because I almost never see driver options used with color or xcolor, but very often with graphicx.) But if you prefer this, please do it. I would even suggest to move the engine detection in this case also to the sty files (and maybe use iftex for it) – analogous to hyperref.

BTW: IMHO you don't need \@ifpackageloaded in miniltx.tex, because miniltx.tex does already ignore options. You just need to detect miniltx and then drop the whole option redefinition. I've also cleaned-up the code a little bit.

[komascript]

BTW: There is also a branch with test files currently only for my own convenience.

[davidcarlisle]

thanks I'll look at the weekend..

I should never have allowed color and graphics to both load back end files into the same document, there should have been guards in place from the start but maybe you are right and it's 30 years too late to fix that design error.