\pdftex_if_engine:TF giving wrong result after 20110628 l3kernel update

[agrahn]

\pdftex_if_engine:TF always enters the true branch.

Test file:

\documentclass{article}
\usepackage{expl3}

\begin{document}

\ExplSyntaxOn
\pdftex_if_engine:TF{
\typeout{+++PDFMODE~+++}
}{
\typeout{+++DVIMODE~+++}
}
\ExplSyntaxOff

\end{document}

[josephwright]

That is the expected behaviour. This is a test for the engine in use, not the output mode. Thus the test is true for pdfTeX and false for XeTeX and LuaTeX, but says nothing about the output. It is intended for dealing with cases where the different engines require different code (for example, in the fontspec package).

[agrahn]

But yesterday the result was still different. Will I have to go back to package `ifpdf' ?

[agrahn]

BTW, to test for the other engines mentioned, we could use the dedicated booleans defined in l3, couldn't we?

[josephwright]

The definition has been tightened up, so the behaviour now is as-documented: the engine and the output are not the same thing. On the ways to test, you can also use the booleans, as you say.

[agrahn]

Ok. I will (temporarily) revert to ifpdf. Do you intend to provide an output testing boolean to replace ifpdf anytime soon? This would be great.

[josephwright]

We can certainly look at this. I need to think of an appropriate name (I guess \pdf_if_mode:TF, \pdf_if_output:TF and \output_if_pdf:TF are all possibles).

[blefloch]

We already use mode for \mode_if_math:TF or \mode_if_inner:TF. Perhaps \output_if_pdf:TF would be the most logical. And \pdftex_if_engine:TF really ought to be \engine_if_pdf:TF, though I'd be happier with one prefix for both output type and engine (and other things such as "is shell-escape enabled").

[josephwright]

I've argued (unsuccessfully) for \engine_if_pdftex:TF in the past. What you do need to remember is that a test for the engine is different from one for the output mode. For pdfTeX and LuaTeX, both DVI and PDF output are possible.

[wspr]

I hadn't considered what we should be calling \ifpdf in expl3, but if we do provide it, it should also allow a way to set the output mode. (Or we should choose not to offer that feature.) I think it's okay to have \mode_if_pdf, \mode_set_pdf, \mode_set_dvi, since there's no technical underlying rationale behind the word ‘mode’. If ‘mode’ distinguishes between math and horizontal and vertical, why not pdf/dvi as well? Okay, I admit it's a bit of a stretch.

By the way, just to explain the justification against \engine_if_pdftex, etc., was that for a while we were specifically trying to minimise the number of prefixes we defined in the kernel; having \engine_ with only three-odd functions seemed like a poor naming idea. Whether that was a good metric for us to use is rather philosophical, I think.

[blefloch]

To avoid prefix proliferation, I'd prefer a common prefix for all those constants/almost constants which have to do with the general framework in which the document is typeset. Something like \state_if_engine_pdftex, \state_if_output_pdf, \state_set_output_pdf. But then I can't think of a good word for that. Would anything else fit in that same box?

Otherwise, we could have something like \g_output_type_tl equal to either pdf or dvi, and \c_engine_tl equal to one of the various possibilities.

[josephwright]

I'm going to close here and open a new issue for the PDF output question.