Inline math not rendered correctly

[ZhengYuan-Public]

Issue Summary

I have encountered several inline math rendering problems when using a Jekyll theme jekyll-theme-chirpy. I've posted an issue in that repo but the author thinks it's not relevant to that repo, so I'm trying to find some help here.

Steps to Reproduce

Here are several examples where my math equations were not rendered correctly.

The following markdown file summarizes the problems I encountered so far. It can be found here

---
comments: true
title: MathJax Problems
math: true
image:
  path: https://images.ctfassets.net/3viuren4us1n/1Ghw96A2tcYRfRezOwtmjx/e646778f3f53e50ea3e857e9cdb23120/Computer_vision.jpg?fm=webp&w=1920
date: 2023-09-20 12:00:00
categories: [machine-learning, computer-vision]
tags: [machine-learning, computer-vision]
---

## MathJax Problem
### No.1 - I found an unuseful fix
### When two inline equations are in the same line

For each RoI (also for each class), PS RoI pooling is applied to obtain *normalized* offsets $ \Delta \hat{p}_{i, j} $ and then transformed to the real offsets $ \Delta p_{i, j} $3

### When moving the 2nd to a new line

For each RoI (also for each class), PS RoI pooling is applied to obtain *normalized* offsets $ \Delta \hat{p}_{i, j} $ and then transformed to the real offsets 

$ \Delta p_{i, j} $

### No.2 - Still can't fix them

$ E = (b_{30}b_{29}...b_{23})_2 = (01111100)_2 = (124)_{10} \in \{1, ..., (2^8-1) - 1 \} = \{1, ..., 254\} $

$ (1.b_{22}b_{21} \dots b_{0})_2 = 1 + \sum_{i=1}^{23} b_{23 - i}2^{-i} = 1.25 $

$ (3 + 127)_{10} = (10000010)_2 = (b_{30}b_{29} \dots b_{23})_2 $

$ (1.b_{22}b_{21} \dots b_{0})_2 = (1.01011 \underbrace{0 \dots 0}_{18})_2 $


### No.3 - Found a fix, but shouldn't MathJax have consistent behavior?

Problem with `|` `{` `}`

#### When not escaping `|` `{` `}`

$ x_i \longrightarrow P(y | x_i; \Theta) \longrightarrow P^*(y | x_i) $

$ {C_2, C_3, C_4, C_5 } $

#### When escaping  `|` `{` `}` with a single `\`

$ x_i \longrightarrow P(y \| x_i; \Theta) \longrightarrow P^*(y \| x_i) $

$ \{C_2, C_3, C_4, C_5 \} $

#### When escaping `{` `}` with `\\`

$ \\{C_2, C_3, C_4, C_5 \\} $

---

This is what it looks like on the GitHub page, and a live version can be found here

(Strange behavior with No.1, can't render with No.2)

(Escape | with \ is working, but { and } need to be escaped with \\)

---

This is what it looks like on Typora (which also uses MathJax for rendering, check here),

(No.1 and No.2 have no problem with Typora)

(Typora requires escaping { and } but not |)

Technical details:

• MathJax Version: 3.2.2
• Client OS: Mac OS X 13.6 (22G120)
• Browser: Chrome 117.0.5938.88

(The MathJax configuration was copied from the inspect of this GitHub page)
I am using the following MathJax configuration:

<script> 
/* see: <https://docs.mathjax.org/en/latest/options/input/tex.html#tex-options> */ 
MathJax = 
{ 
  tex: { 
  /* start/end delimiter pairs for in-line math */ 
  inlineMath: [ ['$', '$'], ['\\(', '\\)'] ], 
  /* start/end delimiter pairs for display math */ 
  displayMath: [ ['$$', '$$'], ['\\[', '\\]'] ]
   }
 }; 
</script>

and loading MathJax via

<script id="MathJax-script" async="" src="https://cdn.jsdelivr.net/npm/mathjax@3.2.2/es5/tex-chtml.js"></script>

Summary and Questions

I'm not sure how to check the MathJax version that is being used on Typora, so I can't provide any useful information on that.

My questions are:

1. Can I expect Typora and my GitHub Page (powered by Jekyll) can have the same behavior in terms of math equation rendering since they are both using MathJax?
2. I think maybe it's a MathJax configuration problem, can anyone give me some tips on how to modify my GitHub page configuration to match them?

Thanks!

[dpvc]

This is due to an interaction between Markdown and LaTeX notation. In particular, the underscore, _, is used in Markdown to indicate italics, and you can see in your Jekyll output that portions of your un-typeset mathematics are in italics and certain underscores are missing. E.g., you have

$ (3 + 127){10} = (10000010)_2 = (b{30}b_{29} \dots b_{23})_2 $

in your output, which shows that the first and third underscores are being matched as the delimiters for italics, and have been removed by the Jekyll markdown engine and replaced by <emph>...</emph> or some other HTML to produce the italics. Because MathJax doesn't process math that contains HTML tags, this expression is not being typeset. Similarly for your other examples in your no. 1 and no. 2 sections, all of which have underscores that are being interpreted as italic delimiters. In your first example, were there are two in-line expressions, each containing an underscore, those two underscores cause <emph> and </emph> to replace them, and that means the closing dollar sign for the first expression and the opening one for the second are now inside <emph>...</emph>. That means MathJax doesn't find the closing dollar sign for the first expression and doesn't typeset it; instead, the two dollar signs inside the <emph> are found as math delimiters, and the words between them are interpreted as math (which is why they show in math italics with no spaces).

For your no. 3, it looks like Jekyll is interpreting the | characters as having meaning in Markdown. It looks like they might be indicating the break between table cells (you may have a table extension in use that is doing that). The second expression is properly typeset, since { and } are grouping symbols in TeX, so don't produce braces in the output. Both Jekyll and Typora produce the same output for these. You would want to use \{ and \} in TeX notation to produce actual braces in the output. But in Markdown, \ is an escape character used to prevent the usual meaning of the following character, so the backslash is removed (when the following character has special meaning in Markdown), and the following character is included literally in the HTML page. That is why the \| in Jekyll prevents the | from forming a table, and MathJax can then typeset it properly. On the other hand, \{ and \} are replaced by { and } by Jekyll, and MathJax gets $ {C_2, C_3, C_4, C_5 } $ as its input, which (as before) has the braces as grouping characters that are not output by MathJax (or TeX). On the other hand, when you use double backslashes, Markdown concerts this to a single one in the HTML, and so $ \\{C_2, C_3, C_4, C_5 \\} $ becomes $ \{C_2, C_3, C_4, C_5 \} $ in the HTML page, and so MathJax will get \{ and \} rather than { and }, which produce literal braces in the output.

All of these problems are due to the fact that Markdown engine you are using in Jekyll doesn't know anything about mathematical notation and is trying to interpret the LaTeX as Markdown commands. Since Markdown is being run on the server to produce the HMTL page that is sent to the browser, and MathJax runs in the browser, the damage to the mathematics is done long before MathJax sees it, and there is nothing MathJax can do about that.

Typora uses a markdown engine that knows about mathematical notation, and is able to protect the mathematics from being processed as Markdown, and that is why the results work properly for you there. This is not about the consistency of MathJax, but of the consistency of the Markdown processors in use. They are not the same, and don't handle the mathematics the same.

Here are some articles about using MathJax in Jekyll that might help you get a more consistent experience. I have not tested any of them.

• Creating a Mathematics Blog with Jekyll
• MathJax 3 in Jekyll and Kramdown
• Jekyll and Mathjax

[ZhengYuan-Public]

This is due to an interaction between Markdown and LaTeX notation. In particular, the underscore, _, is used in Markdown to indicate italics, and you can see in your Jekyll output that portions of your un-typeset mathematics are in italics and certain underscores are missing. E.g., you have

$ (3 + 127){10} = (10000010)2 = (b{30}b{29} \dots b_{23})_2 $

in your output, which shows that the first and third underscores are being matched as the delimiters for italics, and have been removed by the Jekyll markdown engine and replaced by <emph>...</emph> or some other HTML to produce the italics. Because MathJax doesn't process math that contains HTML tags, this expression is not being typeset. Similarly for your other examples in your no. 1 and no. 2 sections, all of which have underscores that are being interpreted as italic delimiters. In your first example, were there are two in-line expressions, each containing an underscore, those two underscores cause <emph> and </emph> to replace them, and that means the closing dollar sign for the first expression and the opening one for the second are now inside <emph>...</emph>. That means MathJax doesn't find the closing dollar sign for the first expression and doesn't typeset it; instead, the two dollar signs inside the <emph> are found as math delimiters, and the words between them are interpreted as math (which is why they show in math italics with no spaces).

For your no. 3, it looks like Jekyll is interpreting the | characters as having meaning in Markdown. It looks like they might be indicating the break between table cells (you may have a table extension in use that is doing that). The second expression is properly typeset, since { and } are grouping symbols in TeX, so don't produce braces in the output. Both Jekyll and Typora produce the same output for these. You would want to use \{ and \} in TeX notation to produce actual braces in the output. But in Markdown, \ is an escape character used to prevent the usual meaning of the following character, so the backslash is removed (when the following character has special meaning in Markdown), and the following character is included literally in the HTML page. That is why the \| in Jekyll prevents the | from forming a table, and MathJax can then typeset it properly. On the other hand, \{ and \} are replaced by { and } by Jekyll, and MathJax gets $ {C_2, C_3, C_4, C_5 } $ as its input, which (as before) has the braces as grouping characters that are not output by MathJax (or TeX). On the other hand, when you use double backslashes, Markdown concerts this to a single one in the HTML, and so $ \\{C_2, C_3, C_4, C_5 \\} $ becomes $ \{C_2, C_3, C_4, C_5 \} $ in the HTML page, and so MathJax will get \{ and \} rather than { and }, which produce literal braces in the output.

All of these problems are due to the fact that Markdown engine you are using in Jekyll doesn't know anything about mathematical notation and is trying to interpret the LaTeX as Markdown commands. Since Markdown is being run on the server to produce the HMTL page that is sent to the browser, and MathJax runs in the browser, the damage to the mathematics is done long before MathJax sees it, and there is nothing MathJax can do about that.

Typora uses a markdown engine that knows about mathematical notation, and is able to protect the mathematics from being processed as Markdown, and that is why the results work properly for you there. This is not about the consistency of MathJax, but of the consistency of the Markdown processors in use. They are not the same, and don't handle the mathematics the same.

Here are some articles about using MathJax in Jekyll that might help you get a more consistent experience. I have not tested any of them.

• Creating a Mathematics Blog with Jekyll
• MathJax 3 in Jekyll and Kramdown
• Jekyll and Mathjax

❤️❤️❤️ Thanks so much for your reply. Now I have direction on what to do next, and I'll post a possible fix after testing.

[ZhengYuan-Public]

As explained by @dpvc, the problem I had was due to the markdown engine kramdown. After reading the kramdown doc from here and doing some experiments, solutions for Jekyll with kramdown are:

• block math should be added with $$ math $$ with a blank line both before and after $$
• inline math (normal) should be added with $$ math $$ without any blank lines before or after $$
• inline math (in lists) should be added with \$$ math $$

Although I'm pretty confused why kramdown won't use the standard markdown syntax 💔 and I can't have consistent output with Typora or VSCode unless I can find a way to configure their markdown engine accordingly.