# MSC2191: Proposal for using LaTeX for maths display #2191

Open
wants to merge 2 commits into
from

## Conversation

Member

### uhoreg commented Jul 26, 2019 • edited

 Rendered This proposal is related to vector-im/riot-web#1945, and is a counter-proposal to #1722

### uhoreg added some commits Jul 26, 2019

 add proposal for using LaTeX for maths display 
 d2a9d87 
 rename to match MSC number 
 64e3626 

### turt2live changed the title add proposal for using LaTeX for maths displayMSC2191: Proposal for using LaTeX for maths displayJul 26, 2019

referenced this pull request Jul 26, 2019
Contributor

### Half-Shot commented Jul 27, 2019 • edited

 (FYI, matrix-org/matrix-react-sdk#3251 just arrived)

Member

### KitsuneRal left a comment

 While I don't have a conclusive "ship it!" opinion about this I certainly believe we should pursue the LaTeX path rather than the MathML one. To alleviate the mentioned issues it may make sense to select the allowed subset of LaTeX - ultimately it's a language for document preparation, not just math rendering, so has much more than necessary to facilitate math chatting.
 ## Potential issues ### "LaTeX" as a format is poorly defined

#### KitsuneRal Jul 27, 2019

Member

And yet we use some flavour of Markdown in the ecosystem - that admits inline HTML.

#### uhoreg Jul 28, 2019

Author Member

Clients use Markdown as an input format. Markdown is never specified as being part of the message format. If we tried using Markdown as the message format, then we would run into the same problem of it being poorly defined.

#### KitsuneRal Aug 1, 2019

Member

Fair enough. Continuing the analogy, the way it's solved for Markdown now is to make HTML out of it on the client side before sending the event. With MathML support among browsers to be pretty much a mixed bag, and PNG being no more than a fallback, I wonder if we should endorse/assume a particular LaTeX dialect instead, while leaving room for alternatives (so that the protocol wouldn't stand in the way of those who'd like to support other dialects as well).

 filtered using a whitelist rather than blacklist. In general, LaTeX places a heavy burden on client authors to ensure that it is processed safely.

#### KitsuneRal Jul 27, 2019

Member

We already have the same problem with HTML+CSS, and the solution is to whitelist the supported language subset works pretty well, it seems?

#### uhoreg Jul 28, 2019

Author Member

Yes, but with HTML, the number of elements that need to be supported is reasonably small. However, with LaTeX, the number of commands that one might want to be supported is rather large. For example, the commands that MathJax supports is at https://docs.mathjax.org/en/latest/tex.html#supported-latex-commands, and the commands that KaTeX is aware of is at https://katex.org/docs/support_table.html (showing what commands are supported, and some unsupported commands). How do we decide which subset to support? If we nail down a subset to support, we might either limit the math rendering libraries that can be used (if a certain library doesn't support a command that was whitelisted, then it can't be used), or else we limit the math that people can enter.

That's why I think the only way to handle it is to say that it's up to the client to decide what to support, and if they don't support something, then to just use the fallback.

#### thosgood Jul 29, 2019

I agree with this. Even if converting the LaTeX/MathJax to HTML before sending, the number of new HTML tags that have to be whitelisted is really quite a lot. The safest/most sensible way really does seem to place all the burden of rendering on the client, and have a "good" choice of fallback. At the moment the relevant pull request just sends the raw LaTeX code (as entered by the user) as fallback, but maybe in the future we could look at whitelisting a small amount of LaTeX and actually processing this in the fallback, and over time (eventually, maybe), increase the amount supported natively. But either way, yes, I think the client should be in charge of this.

#### KitsuneRal Jul 29, 2019

Member

Ok, can we at least blacklist obvious abusers like \newcommand?

 This proposal presents a format using LaTeX, in contrast with a [previous proposal](https://github.com/matrix-org/matrix-doc/pull/1722/) that used MathML.

#### KitsuneRal Jul 27, 2019

Member

To me the very fact that those people using an odd language also have been using LaTeX for a few decades tells that clients better provide them with ability to enter LaTeX and, well, have it immediately rendered, in the same way "laymen" use Markdown. Now if LaTeX is used for input it's just logical to reuse it for rendering, rather than convert it to MathML. And you will never see mathematicians en masse entering MathML by hand, for obvious reasons.

### thosgood commented Jul 28, 2019

 (FYI, matrix-org/matrix-react-sdk#3251 just arrived) @Half-Shot This pull request should be compatible with either proposal choice, but tends more towards this one than the other.

Member

### turt2live left a comment

 This is not my sphere of knowledge at all, but LaTeX seems like the better of the options.
 ### Lack of libraries for displaying mathematics see the corresponding section in [MSC1722](https://github.com/matrix-org/matrix-doc/pull/1722/)

#### turt2live Aug 1, 2019

Member

A direct reference would be nice

 should not be supported. Different LaTeX-rendering libraries support different sets of commands. This proposal suggests that the receiving client should render the LaTeX

#### turt2live Aug 1, 2019

Member

Although we can't reasonably pick a version for people to use, we should at least stick a recommendation in. Similar to how the HTML support in Matrix is handled, we recommend that people use \$version but acknowledge that others may be in the wild.