extensions for XML/HTML executables

[dginev]

Motivation: A recent issue in the arXiv HTML experiment (https://github.com/arXiv/html_feedback/issues/258) requested some additional support for \pdfliteral for LaTeXML (CC-ing @brucemiller for the discussion).

While we can add some support for PDF-specific emulation on our end, I remembered that on occasion it is much more convenient for authors to create macros that target specific executables, so that a more structural alternative to \pdfliteral could be prescribed for LaTeXML use.

Next, I remembered that iftex.sty has provided some automatic support for the mainline executables. Intuitively, iftex would also be a natural home for a collection of new conditionals (all set to false) which can then be used by the many converters to structured formats. As a first suggestion:

• \ifhtml - intended as true in all structured markup converters (It's not always the actual output format, but it is an easy to remember mnemonic)
  • \iflatexml - true in LaTeXML
  • \ifhtlatex - true in tex4ht
  • \ifpandoc - true in pandoc
  • \iflwarp - true in lwarp
  • \iftralics - true in tralics
  • \ifplastex - true in plastex
  • \iflatextohtml - true in latex2html
  • \ifhevea - true in HeVeA

The idea being that iftex itself wouldn't try to auto-detect whether any of the structured markup converters is running, it will only offer the macro dialect for authors to use. Each structured markup converter would then have to implement support that sets \ifhtml to true, as well as its own dedicated conditional.

Currently, latexml provides such an \iflatexml conditional via its latexml.sty package, bundled with the latexml distribution. But this kind of mechanism would be nice to streamline, so that authors can easily switch between converters.

If there have been discussions in this direction and there were good reasons not to streamline this kind of support, of course feel free to close the issue.

[davidcarlisle]

hmm I will leave this open for others to comment but my initial reaction is that I'm not keen on this idea.

The suggested list of \if... is already quite long and would get longer as there wouldn't be any real basis for refusing a request to add more.

More importantly it seems to be encouraging what is (almost always) an antipattern.

before latex2e, documents would regularly go

\ifdvips
\special{postscript rotation}
\else
\ifpdflatex
\pdfliteral{pdf rotation
\else\ifdvipdf
\special{pdf rotation with different syntax}...
\fi\fi\fi

but 2e introduced a standard \rotatebox{...} with suitable backend code being added elsewhere.

So in almost all cases pdfliteral should not be in document level code or need guarding by an \if

That said, it's not that clear a case, latexml especially could be viewed as a tex implementation and have an \iflatexml` test that is automatically set as true/false if latexml is or is not being used.

convertors that first run a standard tex engine and then process the result fit far less easily into the existing design of iftex. This can be seen by the fact they would just have to be set to iffalse and require external code to over-ride the definition, which is not how any of the existing tests provided here work.

But I can see that there are use cases so I wouldn't rule this out comments welcome.....

[u-fischer]

Like @davidcarlisle I think that we shouldn't ask or encourage authors to use tests like \iflatexml, \ifhtlatex or \iflwarp. We can see the problems of such an approach with the pdf/dvi engines: packages are sprinkled with conditionals and backend files (in part for engines that are no longer used) and the set of supported engines differ a lot. We try therefore to provide abstracted commands built on top of a standard set of backend files (in l3backend and some other places) so that authors do not have to worry about the various engine differences.

A different question is the target output format. There is enough difference between producing a PDF and producing html/xml that I can imagine that a document level test like \ifhtml and \xml_XX commands (including something similar to \texorpdfstring) could be useful in future. But for this we would need at first a sensible way to detect that.

[dginev]

Interesting. I usually find it useful to clarify the control scope of different participants, when we encounter very different perspectives. The question we can answer in this issue is whether iftex.sty should have support for such conditionals, not whether they should exist in general, or whether people can be stopped from using them. That's beyond our control, just as I can not enforce that authors stop using \pdfliteral in arXiv.

My premise is that such conditional checks exist today, but they are system-specific and do not follow any streamlined organization. Variants are:

• I mentioned latexml.sty has \iflatexml, and yet that sty file isn't distributed in CTAN - it only comes via a latexml installation. We have had requests to change that [1]
  • \ifdefined\HCode for tex4ht [2]
  • {warpprint} and {warpHTML} for lwarp [3]
  • a DIY variant in tralics based on \tralicsversion [4]:

    \newif\iftralics\tralicsfalse
    \ifx\tralicsversion\undefined\else\tralicstrue\fi

  • \ifhevea is always provided (as true) in the latex support of HeVeA [5] [6]
  • I couldn't find an existing solution from pandoc, I think the expected control flow is completely external there, as documented by e.g. Quarto [7]
  • \ifplastex seems to be always available in plastex [8]
  • an {htmlonly} environment from a custom html.sty appears to be the solution for latex2html [9]

So, in aggregate, the usual evolutionary chaos. iftex.sty would be a nice vehicle to streamline some of that, if there is interest. Otherwise, if the need is sufficiently persistent, not acting on the question will likely just give rise to a new ifhtml.sty or such. To me that is more likely than entirely suppressing the HTML converters (and our users) from using this kind of mechanism. I agree with Ulrike that ideally it is a mechanism better suited to the more technical package authors, rather than document authors.

Btw, I entirely sympathize with how difficult the reliance on these checks is - LaTeXML is currently playing pretend with \ifpdftex and \ifetex switched to true (for arXiv), in order to match the source branches selected by arXiv's pdflatex builds. Which is a somewhat strange kind of "white lie", rooted in both the LaTeX packages and the source documents having been written without ever expecting HTML would be a potential target.

Edit: added plastex and latex2html mechanisms

[bdtc]

Hopefully the LaTeX socket mechanism will help with much of this.