Feature: XHTML output for EPUB

Is your feature request related to a problem? Please describe. I saw someone mentioning that math support in epub is in a sad state. A quick search shows that MathML is the current only method of doing so, but we all know how painful it is to write, and on top of that not every reader is capable of rendering it.

Now the obvious solution is to use some front-end to convert something easier-to-write to MathML and some fallback – precisely what KaTeX is designed to do. From some playing around on https://validator.nu, it looks like the only thing preventing validation with the XHTML + SVG 1.1 + MathML 3.0 schema (where the unversioned XHTML refers to “HTML5”) is a lack of xmlns on the <svg> element. Other asepcts of the generation are strict enough for XML as far as I can tell.

Describe the solution you’d like:

1. Add the attribute xmlns="http://www.w3.org/2000/svg" to generated <svg> elements. (Okay, that’s #2725.)
2. Preferably add a section in node.md talking about the XHTML usage.
3. (While we are at it, the demo and readme can use some mention on the MathML capability. Like #2881.)

Link to or name of a (La)TeX package that provides the same feature: Not applicable.

Describe alternatives you’ve considered: I originally considered requesting an HTML/XHTML output mode switch for (1), but the difference feels too small to justify it.

Additional context: The EPUB people at https://github.com/w3c/epub-specs/issues/845 are talking about the mathml situation too. KaTeX’s output fits into the fifth proposed method.

[edemaine]

@Artoria2e5 I finally merged #2725 – sorry for the delay. I checked that a simple document passed the XHTML + SVG 1.1 + MathML 3.0 schema. Would you like to write a PR to document this feature?

[universemaster]

Adding the svg namespace adds 0.4% to my uncompressed file size, which perhaps isn’t a big deal on its own, but for a fringe use case it seems contrary to the efforts and philosophy in https://github.com/KaTeX/KaTeX/issues/2194.

Epub production surely is not the majority use case of KaTex, surely almost all usage is for html in browsers.

The additional file size seems like death by 1000 papercuts.

I feel similarly about the mathml namespace - it’s just unnecessary bytes for almost all recipients of it - see https://github.com/ronkok/Temml/issues/3 .

My proposal: We add XHTML / epub compliment output as an option at https://katex.org/docs/options.html , and exclude the mathml and svg namespaces as default? Thoughts?