For the Math users out there I have enabled the Discourse Math Plugin which allows for the use of MathJax and asciimath. The plug-in documentation notes that it will also do LaTeX but to what extent I don’t know.

This feature may be turned off so don’t rely on it for the the time being.

Enjoy

I am the Math plugin

I can display math inline by wrapping text with the $ symbol like so $E=MC^2$ which renders.

E=MC^2

I can display larger blocks of math by wrapping text in a double $$ sign. Like so:

$$
E=MC^2
$$

which renders

E=MC^2

All fonts and assets required to generate Math are embedded in the plugin.

Sorry for my very late reaction, I did not see this post.
Does this mean that this plugin could be used with a SWI-Prolog prover inside a script for an HTML page to render directly the result? It would be a very nice thing.
If the reply is “yes”, I would be happy to test it.

Thanks for your reply to my late intervention.
I have understood that it is a plugin for this Discourse forum. But suppose a Mathjax script inside an html webpage, why this plugin could not be used?

Thanks ! It is intesting indeed. The only problem for me is that I need Mathjax to use the very useful proof.sty implemented in MathJax 3. Unfortunately, the setup to get a dynamic Mathjax is not so easy…

Would you mind to try it together? I would isolate the stuff we have as a swipl pack until next week, then we can check if there are missing pieces (and if you like our approach at all).

(unsure if it’s obvious: The R package can also convert expressions to MathJax, not just MathML. The MathJax ist just less elegant, because it uses “format” instead of HTML pieces.

I did not know that The R package can also convert expressions to MathJax, not just MathML. I would be glad to test your work, of course. But I must be prevent you that I am very slow, I am not at all a computer scientist, my education was in philosophy and that means that I have a slow and weak brain. If you can be patient, of course, it would be nice for me to try it.

Les packages source téléchargés sont dans
‘/tmp/RtmphVPkBb/downloaded_packages’
Messages d'avis :
1: Dans install.packages("mathml") :
l'installation du package ‘rswipl’ a eu un statut de sortie non nul
2: Dans install.packages("mathml") :
l'installation du package ‘rolog’ a eu un statut de sortie non nul
3: Dans install.packages("mathml") :
l'installation du package ‘mathml’ a eu un statut de sortie non nul
>
Not so slow finally . I believe that all that I need to test your work is now installed.

Thats probably the hardest pill to ever swallow in software engineering,
that nothing stays the same, or as Heraclitus would say “Everything
flows” (Greek: πάντα ρει, panta rhei ).

Its also big challenge for planning and resource allocation. Especially
since not going with the flow can cost you money in the form of technical debt, i.e. the implied cost of future reworking when its

too late to resist. For example I would try to migrate from MathJax
v2 to MathJax v3, its a complete rewrite of MathJax in TypeScript,
and the authors are quite enthusiastic about it:

What’s New in MathJax v3.2
Although MathJax version 3 is already an order of magnitude faster
than version 2, with version 3.2 we offer a new extension that is
designed to make pages with large numbers of equations
perform even better. What’s New in MathJax v3.2 — MathJax 3.2 documentation

Just noticed that the SWISH example uses MathJax v2.7 in
a manner that cannot be used for MathJax v3.

Dislclaimer: The advise to not adopt old technology in new projects
is my personal opinion. Feel free to not agree. I don’t see that Prolog
would require old technology, can somebody explain?

For example it is now recommended to put the MathJax v3
loading into the head of the document and not into the end of
the document as the SWISH example shows. And I guess it can be

loaded with “async” attribute, in a separate task, like here:

/* put this in the head */
<script type="text/javascript" id="MathJax-script" async
src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-svg.js">
</script>

This has to do and is related to the so called “Hydration” problem:

When you have MathJax in the body synchronously the load
time is time(html)+time(bundle). If you have MathJax in the head
asynchronously quasi parallel, the load time is around max(time(bundle),

time(html)). which might give better user experience.