Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSC2191: Proposal for using LaTeX for maths display #2191

Open
wants to merge 2 commits into
base: master
from

Conversation

@uhoreg
Copy link
Member

commented Jul 26, 2019

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

@turt2live turt2live changed the title add proposal for using LaTeX for maths display MSC2191: Proposal for using LaTeX for maths display Jul 26, 2019

@Half-Shot

This comment has been minimized.

Copy link
Contributor

commented Jul 27, 2019

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

@KitsuneRal
Copy link
Member

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

This comment has been minimized.

Copy link
@KitsuneRal

KitsuneRal Jul 27, 2019

Member

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

This comment has been minimized.

Copy link
@uhoreg

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.

This comment has been minimized.

Copy link
@KitsuneRal

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.

This comment has been minimized.

Copy link
@KitsuneRal

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?

This comment has been minimized.

Copy link
@uhoreg

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.

This comment has been minimized.

Copy link
@thosgood

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.

This comment has been minimized.

Copy link
@KitsuneRal

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.

This comment has been minimized.

Copy link
@KitsuneRal

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

This comment has been minimized.

Copy link

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.

@turt2live turt2live self-requested a review Aug 1, 2019

@turt2live
Copy link
Member

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/)

This comment has been minimized.

Copy link
@turt2live

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

This comment has been minimized.

Copy link
@turt2live

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.