xfrac package fails with mathsvg

[orbita2d]

trafficstars

latexml 0.8.8

Example

\documentclass{article}
\usepackage{xfrac}

\begin{document}
$$
\sfrac{1}{2}
$$
\end{document}

latexml --dest=test.xml test.tex latexmlpost --dest=test.html --mathsvg test.xml

What I expect to happen: Document is built, including an svg showing the fraction 1/2

What happens instead:

SVG conversion fails

Error:shell:latex LaTeX command 'latex ltxmlimg > ltxmlimg.ltxoutput' failed
        returned code 256 (!= 0):
        See /tmp/LaTeXMLWPvccD/ltxmlimg.log
        In Post::MathImages[@0x58826c143c00] ->generateImages
Warning:expected:image Couldn't find image for 'LaTeXML::Post::MathImages:svg:\beginDISPLAY \nicefrac{{1}}{{2}}\endDISPLAY'
        at /thesis/test.xml
        In Post::MathImages[@0x58826c143c00] ->convertNode

This happens as sfrac is converted to nicefrac by latexml, which is not understood by ltxmlimg

! Undefined control sequence.
l.63 \beginDISPLAY \nicefrac
                            {{1}}{{2}}\endDISPLAY\clearpage
The control sequence at the end of the top line
of your error message was never \def'ed. If you have
misspelled it (e.g., `\hobx'), type `I' and the correct
spelling (e.g., `I\hbox'). Otherwise just continue,
and I'll forget about whatever was undefined.

[dginev]

Thank you for the report. The macro definition of \sfrac in xfrac.sty.ltxml is currently internally expanding to a variant of \nicefrac, which causes the error in the raw latex call - which tries to typeset \nicefrac without nicefrac.sty loaded.

I'm curious what the best fix is here. The current implementation is expediently reusing some internal macros from the nicefrac binding, which leads to the reversion of \sfrac ending up incorrect (as in - missing dependencies).

Edit: And maybe it's also worth stating that this kind of fragility could be expected in any binding which has made the decision to require packages in the .ltxml file that are not required in the original .sty/.cls file. So there is a more general problem to solve beyond the (very nice!) minimal working example.

[orbita2d]

Workaround:

%\usepackage{xfrac}
\usepackage{nicefrac}
\newcommand{\sfrac}{\nicefrac}

[orbita2d]

I don't know the architecture to suggest anything, but it's not obvious to me why the pipeline for latex->xml would need to be the same as the one for rendering to svg.

The main benefit of using --mathsvg in my view is to be able to do math rendering with all the bells and whistles which latex allows (which MathML/latexml/whatever will not support). So the svg rendering process should be as transparent as possible.

[dginev]

@orbita2d

The main benefit of using --mathsvg in my view is to be able to do math rendering with all the bells and whistles which latex allows (which MathML/latexml/whatever will not support).

Well, maybe. But you also have the option to convert to MathML and then use MathJax to render that as SVG as a final step in the browser.

LaTeXML's primary math output format today is MathML, and most of our testing and development work is aimed there. I think the other formats are there for a good reason, but your expectation shouldn't be that they are/will always be better than MathML.

[orbita2d]

Sure, I'm happy to accept that my preferences are not shared.