TeX in the message list

[gnprice]

Zulip's Markdown flavor supports TeX for mathematical notation, using KaTeX. This will be one of the more complex message-content features for us to support.

The way this works for web and for the existing RN-based mobile client is:

• KaTeX consists of some JavaScript code to convert TeX into HTML, and then some CSS to style that HTML. The KaTeX-generated HTML also has some per-element style attributes.
• The server takes care of the conversion to HTML, by running the KaTeX JS code on Node. That HTML goes into the message's HTML content.
• Then the web and RN-mobile clients ship with KaTeX's CSS, and include that in their styles.
• Those clients also ship with the KaTeX JS code. They use that for local echo.

What I think we'll want to do in Flutter is:

• Skip TeX for local echo, and just show the source TeX. That seems fine.
  • If we implement a "preview" feature for before sending a message, then it'll be important to get the actual rendering there… but even the web app relies on the server for its preview feature. So we'll do the same.
• Then we'll consume KaTeX HTML and convert it into Flutter widgets, just like we consume other kinds of Zulip content HTML and convert it into Flutter widgets, in lib/model/content.dart and lib/widgets/content.dart.

Converting the HTML to Flutter widgets will involve having code in lib/widgets/content.dart that is written to correspond to the KaTeX CSS, just like much of the existing code there is written to correspond to the Zulip markdown-content CSS.

That CSS is a few hundred lines of code. It's written in Less; but looking at the compiled output, it's not much longer than that source, and most of the difference is highly repetitive. So the real amount of information there is about what's in that one source file. That file is also highly stable over time — just as one might hope, given that TeX itself is famously extremely stable — with the last non-NFC change 20 months ago, in 2021-07.

So while this won't be a small subproject, it's one where I'm pretty confident we can do it well.

[chrisbobbe]

We got a request for this as beta feedback in the Google Play Console:

Looks like there's no Latex support yet. This makes it a non-starter for our purposes unfortunately. Are there plans to bring that in soon?

[chrisbobbe]

And again today:

Math doesn't work, glitches with links. I'll try again another time (love Zulip generally).

[chrisbobbe]

In the Lean community we asked how disappointed people would be if the app were rolled out to all users before full support for TeX.

One user answered "heavily disappointed"; others reacted to that message suggesting they disagree.

A different user "wouldn't mind" the current state, and another added:

I mean, I'm old enough to remember when people wrote latex in sci.math.research in their posts and it was just displayed like that anyway.

[chrisbobbe]

See discussion with an idea from Tim:

So I think it would be possible to write the Flutter app logic to convert MathML into display rather than working with the HTML.

[gnprice]

It's looking like we won't have all the features of KaTeX covered before we launch the new app in a few weeks (#mobile-team > Flutter beta timeline @ 💬). I think we can still cover most usage of it, though, with a respectable fallback behavior. Then we can pursue the remaining KaTeX features as follow-up issues.

Details in chat: #mobile > TeX formatting #F46 @ 💬

[gnprice]

An update on this issue's status, since it's an M5a launch blocker issue and launch is imminent:

As planned above, the version we'll be launching with (release v30.0.258) has partial support for TeX, with a respectable fallback behavior for expressions it can't yet handle. In addition to the initial support merged as #1408, the release includes #1452, #1559, and commit https://github.com/zulip/zulip-flutter/commit/91531fe7657dc2d58a676d522458009e9b8ff9ec which turns on the flag for KaTeX support. All of those changes have been included in the releases since v0.0.31 last week.

There are some key features of KaTeX's formatting we have still in progress which will let us render a much wider swath of LaTeX expressions. For details, see chat: #mobile > TeX formatting #F46 @ 💬.

I plan to file specific issues for those (as well as for the less-common features we know of), and then close this issue in favor of tracking the remaining work there. I hope to get to that later this week.

[gnprice]

Update since the last comment above:

• We did a survey of some public TeX-using Zulip messages (#mobile-team > KaTeX survey results @ 💬), to see what constructs remain to be covered. The launch release v30.0.258, with the functionality described above, handled about 45% of those messages.
• In the release after that, v30.0.259, we added another then-unmerged PR: #1601 which expanded the coverage to 80%. (#mobile-team > KaTeX survey results @ 💬) (… Actually more than that — the 80% figure was from before we added the mathdefault class to that PR.)
• Since then, we've merged to main several PRs for parts of the already-shipped KaTeX support: #1609 (which represents part of #1452) #1601 #1600

At this point, our to-do list for further TeX support is:

• First, two PRs that were shipped in the last few releases remain with some work for us to do to finish and merge them: #1452 #1559
• From digesting those survey results, we prepared a list (starting at #mobile-team > KaTeX survey results @ 💬) of the most common constructs remaining.
• I plan to go file issues for those now.
• Some of those also have open PRs already. So after completing the two older unmerged PRs, our next priority will be to finish those, merge them, and ship them.

[gnprice]

OK, filed 8 issues based on the survey results:

• #1671
• #1672
• #1673
• #1674
• #1675
• #1676
• #1677
• #1678

I filed issues only for items that occurred in at least 1% of surveyed TeX-containing messages. There were a number of lower-frequency items in the survey results, too. Some of those will naturally get fixed as part of the work addressing the higher-frequency items; so after we've done all or most of the issues above, we can rerun the survey to get a clearer picture of what items remain.

Also filed one issue based on a user request:

• #1679

I'll close this issue now, reflecting the 80+% KaTeX support we've had since the v30.0.259 release. We'll track ongoing work in specific issues, including those I just filed.

[gnprice]

Also created the "a-tex" label to help group those and other issues for further KaTeX support.

[gnprice]

The TeX support that we've had in recent releases is now all merged to main, finishing with #1720. So this issue is now fixed in main too.