[Discussion/suggestion] Wrong driver selection results in incorrect PDF - forcibly use correct driver?

[norbusan]

Not a bug but a discussion/suggestion:

If a user forces a certain graphics driver with

\usepackage[dvipdfm]{graphicx}

and the actual file is compiled with pdflatex (because it includes png/pdf/whatever),
the generated PDF is not standards conform.
Example document:

\documentclass{article}
\usepackage[dvipdfm]{graphicx}
\usepackage{pgf}
\begin{document}
Hello World
\end{document}

Compiling this with pdflatex produces a PDF that contains invalid code, from the uncompress pdf:

stream
1 0 0 1 -72 720 cm
obj @pgfcolorspaces <<>>
put @resources << /ColorSpace @pgfcolorspaces >>
put @pgfcolorspaces <<  /pgfprgb [/Pattern /DeviceRGB]  >>

(see lengthy discussion here pdfminer/pdfminer.six#947)

Using the correct driver for pdflatex, or using latex/dvipdfmx produces correct PDF.

Of course, this is a user error! The question is, can we do something better here? Overriding the selected driver when it is obviously wrong?

[davidcarlisle]

Yes, this will I think get better if we can eventually move graphics and color to use l3backend rather than the driver specific code here in graphics-def, it's harder to get the wrong backend in that case.

Allowing the driver to be set via a package option, and in particular allow it to be set differently on different packages, was not the best choice, but it was hard to get every choice right before anyone had used any package options, and it's worked "well enough" over the years....

The document you show is not in itself an error just run on the wrong engine but there are worse cases that are essentially unrecoverable

\usepackage[pdftex]{color}
\usepackage[dvips]{graphics}

can not end well.

Loading dvipdfm option with pdftex isn't nececessarily an error as (in theory) the document may be about to do \pdfoutput=0 and switch to dvi mode, similarly loading pdftex option in (dvi)latex. So an alternative view would be not to class it as an error but a failing in the back end .def file to set the right backend. If the dvi driver files such as dvipdfmx.def set \pdfoutput (or \outputmode) to dvi mode and pdftex.def and luatex.def set pdf mode then your original example would not be an error but would make dvi, which is logically consistent but may upset some IDE or overleaf etc if they are expecting to find a pdf.

[norbusan]

Thanks David for your answer. Yeah, one can shoot oneself very easily with these options, as we see again and again.

What really puzzles me is that we do create incorrect pdfs, which is a bad outcome I think. I agree that loading dvipdfm(x) as driver in pdflatex and then switch to dvimode, but if this does not happen, LaTeX / pdflatex / whoever should not continue and prodcue incorrect PDF.

Not sure this can be achieved easily, though.

[davidcarlisle]

we can do something, it's just that, as you will know, making something an error that has not been an error for the previous 30 years will break someone's pipeline, somewhere. There will be people patching in code to force things through.

I'm a bit wary of making the options silently switch to dvi mode but it would be relatively easy for dvipdfmx.def and other dvi-only back end files to have an

\AtBeginDocument{
if the engine is not making dvi at this point die with a sensible error message
}

and similarly pdftex.def could complain if not in pdf mode by begin{document}

I'd have to worry a bit about the plain tex support in graphics-pln, but that wouldn't be the first time.

[norbusan]

I'm a bit wary of making the options silently switch to dvi mode

Yes, agreed, that doesn't sound like a good idea.

but it would be relatively easy for dvipdfmx.def and other dvi-only back end files to have an [...]

That sounds like a good idea, at least for me.

[FrankMittelbach]

agreed, abort then with an explanation why and how to fix