It looks like you're new here. If you want to get involved, click one of these buttons!

DavidTanzer
New

General question: what is the status of math rendering support in Vanilla 2.6?

I have a version of the MathJaxCDN plugin, which was written by Peregrine, which is successfully running on a Vanilla 2.1 installation.

I tried coping that over to a fresh installation of 2.6.4. But the plugin doesn't seem to be doing anything. Wondering if that's because the plugin API has changed since 2.1.

Thank you

0

## Comments

And I did enable the plugin. The version field in the plugin is set to 1.3.

Note I see commentary on the web about the CDN for MathJax having been shut down in 2017. However this plugin

isworking today on my Vanilla 2.1 installation on another host. And I see that the .js files on the mathjax cdn site are still present.I do not find a link to this plugin. If I could see some code I might be able to give advice...

Hi R_J, thanks for your offer.

I have attached a tgz file for the plugin.

To my knowledge, we're still supporting this addon: https://github.com/vanilla/addons/tree/master/plugins/MathJax

The downside of that addon is I'm fairly certain it will not work with the new Rich Editor in 2.8 and I'm not clear what timeline we'll be updating it on, if at all. Not hopeless, but very unclear what its future is today. For now, you can continue using the old editor which will stay minimally supported probably thru 2.9 (at least).

Thanks Linc. That is different code, so I will try it out!

Can you help me to understand the implications of your caveat about the Rich Editor. Since Latex is a plain text format, won't the users always be able to enter the Latex snippets in the forum contents, regardless of what the editor for input is? And then, since MathJax is a rendering component which kicks in after the contents have been stored, won't this Latex get correctly rendered, regardless of the editor for the input?

I am not too concerned about the Latex showing up as plain text in the editor, and about it not being rendered in the previewing tool. Integration of Latex rendering with an editor tool would be a nice to have -- but it sounds really complex and difficult to do, so I could see why it would be given a very low priority.

My concern is about building a forum and a community that depends on Latex to typeset complex math stuff, and then having to subsequently discontinue the language entirely.

From another point of view: consider a feature in which the user could dynamically select a non-default input editor. In the bare-bones version of this, the only non-default editor available would be a plaintext editor -- in which case there could just be a checkbox that says to use plain text.

Then rich mathematical typesetting via Latex could be confidently supported into the future. Mathematicians would just have to know how to kick the tires a bit: to check the plaintext box, and to live without a rich text editor or, possibly, an accurate preview tool.

I myself am okay with using plaintext + markdown + embedded Latex.

Thank you for considering my questions and suggestions!

I'm not really the expert to be going into detail on this. I don't

thinkRich Editor will effect support for Latex-as-plaintext. The issue would be whether the Javascript will work against it for special rendering. I doubt that it will. My hope/assumption is that someone will just need to update it a bit to continue support, but that might prove a bit tricky and I don't know on what timeline we'd do that if no one from open source takes it on. That's all my support comment was about.The framework underneath the editor won't be changing any time soon, so yes it will continue to be possible to swap editors on a per-post basis, theoretically at least. I feel like that's a more complicated solution than just updating the Javascript, however.

Also this entire problem is probably more than a year away from getting forced assuming you continue with Advanced Editor for now.

@DavidTanzer I've been doing the bulk of the work on Rich Editor so maybe I can shed some light here. There's 2 sides to this.

## Plain text to MathJax conversion

I'm not familiar with the way this particular plugin works, but if it works in the following manner, the existing plugin should work with rich editor.

## Rich Editor expression integration

Rich editor is based on quill. Quill has some built in integration with

`KaTeX`

expressions which can preview live in the editor. If you look at the demo on the quill homepage there, you can try it out.The actual implementation probably wouldn't take that long, it's mostly the UI integration that would need to be done. Although I don't have intention to champion the issue myself, if you start planning a feature on our issue tracker I could offer a bit of guidance on how the feature could be implemented.

MathJax specifically is also not ruled out (the actual quill blot implementation for KaTex is only 30 lines) The real work mostly lies in wiring up the UI properly.

@charrondev Thanks for this interesting information!

I project that that MathJax will work with any editor, because there is hardly any interaction between Vanilla and MathJax.

MathJax is founded on a huge javascript library that implements a substantial Latex rendering engine in the browser itself.

The MathJax plugin is a very small piece of code causes this code at the top of the rendered html:

<script src="/plugins/MathJaxCDN/js/redraw.js?v=1.3" type="text/javascript"></script>

<script src="/plugins/EnhancedComments/js/enhancedcomment.js" type="text/javascript"></script>

<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS_HTML"> </script> <script> MathJax.Hub.Config({ tex2jax: { // inlineMath: [$'\(','\)'$], // inlineMath: [ ['[math]','[/math]'], ['\(','\)'] ] // inlineMath: [ ['[math]','[/math]'] ] inlineMath: [ ['[math]','[/math]'], ['$','$'] ] // inlineMath: [ ['$$','$$'], ['\(','\)'] ] } }); </script>

So an embedded formula like $$x^2 + y^2 = 1$$ gets scanned and processed in the browser, and there is no way that Vanilla could treat this other than plain text.

The downside will be that the editor will not be able to show what the actual page looks like.

To me, this would not be a big deal.

In the mathjax plugin configuration, you define the escape characters for the embedded formulas. So, as long as you choose a different escape than what is used for KaTex, one should be able to freely mix KaTex and MathJax expressions in the same text.

KaTex does sound like an interesting competitor to MathJax. It will be worth keeping an eye on how the race evolves.

From a cursory review, the comparison seems to be as follows.

I personally have not experienced performance problems with MathJax on a Vanilla forum. Posts are small and generally do not cause a large footprint of MathJax to be downloaded. There were some complaints on my forum about MathJax performance, but those were one-time loading issues.

Oops, looks like I was missing the point of the caveat. Sure there's no interaction on the server between Vanilla and MathJax, but it seems the concern is about the client-side interactions between the javascript for the new editor and mathjax.

Here are a couple of relevant comments from the MathJax docs:

"you need to be careful that your mathematics doesn’t look like HTML tags to the browser (which parses the page before MathJax gets to see it)."

"The TeX input processor handles conversion of your mathematical notation into MathJax’s internal format (which is essentially MathML), and so acts as a TeX to MathML converter."

Not sure if the latter is encouraging or not.

@DavidTanzer you might have not seen the most interesting message here:

The version on GitHub still uses the old CDN but exchanging that link in the plugin is everything which is needed to make it work again.

@R_J Thanks for looking into this. It's still not working for me when I update the link. The mathjax script entry is being put in the page, but the formulas don't render. I wonder if I don't have the right link. Or if I'm not using the right delimiters.

Here are the script lines which get put into the rendered html:

<script src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?delayStartupUntil=onload&v=2.6.4"></script>

<script src="/plugins/MathJax/js/live.js?v=1.1"></script>

Is this the path that you are using? Does yours have the delayStartUpUntil=onload?

After that comes the MathJax.Hub.Config section, which I have pasted below. You can see that, as a test, I tried to use yyy, zzz as delimiters for inline math.

Then I tried all of the following as text in the discussion text -- still no rendering.

yyy x^2 zzz

$ x ^ 2 $

$( x ^ 2 $)

$\(x ^ 2 \)$

Can you give a sample of text that renders for you?

Thank you.

Text of the config entry:

<script src="/js/library/jquery.tokeninput.js?v=2.6.4"></script><script type="text/x-mathjax-config">

MathJax.Hub.Config({

jax: ["input/TeX","output/HTML-CSS"],

extensions: ["tex2jax.js","MathMenu.js","MathZoom.js"],

TeX: {

extensions: ["AMSmath.js","AMSsymbols.js","noErrors.js","noUndefined.js"]

},

tex2jax: {

inlineMath: [ ['$\(','\)$'], ['$','$'], ['yyy', 'zzz' ],

displayMath: [ ['$$\(','\)$$'] ],

processEscapes: true

},

"HTML-CSS": { availableFonts: ["TeX"] },

messageStyle: "none",

showProcessingMessages: false

});

I see in the MathJax docs that ordinarily, the config block needs to come before the load of MathJax.js. But the plugin puts the script of type text/x-mathjax-config after all the script blocks for javascript. So that would account for why the delayStartupUntil=onload is there.

I actually *once* saw the formula render. This makes me think there could be a race condition or some other problem with the onload signal reaching mathjax.

So perhaps my config block is never actually being processed by mathjax.

This whole concern would go away if the config entry would be loaded first. I tried switching these lines in the plugin code:

$sender->Head->addString($mathJaxConfig);

$sender->addJsFile("https://cdn.mathjax.org/mathjax/latest/MathJax.js?delayStartupUntil=onload");

But it didn't change anything -- all the JsFile entries go first.

This equation is beatifully rendered on my test forum:

`$$(x = {-b \pm \sqrt{b^2-4ac} \over 2a})$$`

It is this part of the plugin (line 41) which needs to be changed if you want other delimeters:

The back slash escapes the next character, therefore

`displayMath: [ ['$$\(','\)$$'] ],`

has to be read as "$$(" as the opening string an ")$$" as the closing string."Inline math" has to be escaped with "$(" and ")$".

If you want it to only use the "$$" it should work with

`displayMath: [ ['$$','$$'] ],`