Did Github ever solicit feedback from the community for this feature? Was there ever a beta before they rolled it out?<p>Because some of these critiques really should have been dealt with beforehand and I'm concerned that we're now stuck with lousy defaults that they won't ever be able to change.<p>The visual font size problem seems particularly disastrous:<p>> <i>The math font is a really small,</i><p>> <i>MathJax’s default font MJXTEX-I and GitHub’s default text Helvetica have a different x-height/cap-height ratio.</i><p>I don't understand how Github could launch this feature with this problem unaddressed. LaTeX isn't just about getting formulas right, it's about communicating ideas.
This does seem like a remarkably poor implementation, especially given the alternatives: GitLab, mentioned; StackExchange also has a pretty decent implementation; many markdown-based static site generators also have good support
> advantages of KaTeX:<p>> It’s faster.<p>> You can copy-and-paste math.<p>Someone mentioned that you can theoretically copy-and-paste KaTeX output in an earlier thread about GitHub's new math rendering too. But I think calling that an "advantage" is crazy.<p>LaTeX will transform your one-dimensional textual formula specification into a two-dimensional graphical formula. The concept of copying and pasting the output as text is a category error. It isn't text and if you try to paste it, you'll get something other than what you wanted.<p>Just to be sure I'm not crazy, I tried copying the output of the demo on the KaTeX homepage. Here it is:<p>> f(x)=∫−∞∞f^(ξ) e2πiξx dξ<p>This is much, much, much worse, if you want a textual representation, than copying the LaTeX source:<p><pre><code> \f\relax{x} = \int_{-\infty}^\infty
\f\hat\xi\,e^{2 \pi i \xi x}
\,d\xi
</code></pre>
And it's worse even though the raw source includes the quirk that LaTeX isn't able to provide proper spacing for the differential over which an integral is being calculated, so you have to space it yourself with \, commands.
A source block type would have been a very natural fit, it’s surprising that isn’t how they chose to go.<p><pre><code> ```equation
e^{i\pi}+1\eq0
```
</code></pre>
feels like what i’d try to do right off the bat.
> The reason why I’m so excited about this feature is that, in combination with version control and the issues/discussions capabilities in GitHub, I can see tectonic changes in how we’re publishing science. At last, science can really reap the benefits of a connected internet by moving away from static PDFs to living, breathing repositories which render like PDFs and provide a central place where one can actually talk about the article. – And fix bugs!<p>I'm skeptical of this take. Gitlab has had math rendering support for quite a while now, so this is hardly novel and doesn't seem to have resulted in the utopia the author is hoping for.
One thing that the article gets wrong is accusing mathjax of being abandoned. Development has moved to a new repo for the next version.<p><a href="https://github.com/mathjax/MathJax-src/graphs/contributors" rel="nofollow">https://github.com/mathjax/MathJax-src/graphs/contributors</a>
Note also that TeX math can contain \text{..} which can itself contain $-delimited TeX math, e.g. $x = \text{my $y$}$. This currently breaks the GitHub implementation.
I tried all the examples using<p><pre><code> pandoc --from markdown --to html --mathjax
</code></pre>
i.e., using pandoc Markdown[1] with MathJax enabled, and it has none of the problems described in the article (see output[2]). The problem doesn't seem to be due to MathJax, and even using GitHub Flavored Markdown as the input format to pandoc produces the correct results.<p>[1]: <a href="https://pandoc.org/MANUAL.html#pandocs-markdown" rel="nofollow">https://pandoc.org/MANUAL.html#pandocs-markdown</a><p>[2]: <a href="https://gist.github.com/bewuethr/691b4870828d7b2261113f14eef56b5f" rel="nofollow">https://gist.github.com/bewuethr/691b4870828d7b2261113f14eef...</a>
I completely agree with the conclusions, GitHub repositories can really be the focal point of scientific publishing in years to come.<p>I always wondered why it took so long to implement math. There are better implementations out there for sure, it's weird they waited for so long and implemented something that is below the standard of alternatives.<p>The next step is to render citations from .bib files. I hope they get that right in the future.
I’m very happy they went with simple $..$ and $$…..$$<p>This is much more natural for anyone doing math or science and also makes it easy to copy and paste math from elsewhere<p>It’s better that the parser works harder than to force an inconvenient syntax on the user.
The author fails to mention MathML as an alternative choice. The options aren’t just MathJax and KaTeX, but also raw MathML. MathML gives you extremely fast rendering, more font choices, copy-paste, a11y, etc. out of the box. The only downside is that Chrome is lagging behind in implementation, for that they could use MathJaX as a polyfill—as MathJax understands and is able to transform MathML—and allow Safari and Firefox users the benefits of using browsers that can render math natively.
My theory is that there’s already a lot of existing content using $ and $$ that GitHub wants to start rendering without requiring any changes.<p>I agree the code block approach would be less ambiguous, but there is an advantage in going where people already are.
If you use a proper markdown plugin to parse math instead (such as <a href="https://github.com/goessner/markdown-it-texmath" rel="nofollow">https://github.com/goessner/markdown-it-texmath</a>), then the problems pointed out in this blog post go away.
The way to really solve this is unfortunately for every equation that you have on Github you need to generate a png for each equation and just insert it into the file until Github fixes the various issues.
This article should not be taken seriously, which has at least 2 fatal errors in its argument.<p>First about the choice of delimiter. It argues for the use of \(…\) and \[…\] instead of $…$ and $$…$$. They don’t even explain why, but cite an external link to, guess what, a reason why the former is better for LaTeX, not markdown.<p>Then they made a claim about why putting math inside code delimiters are better.<p>Detouring a little bit, my guess that GitHub chooses this delimiter is because they have prior collaboration with the author of pandoc to create the common mark spec. Their GFM parser is an extension of a common mark parser.<p>And since pandoc chooses the dollar sign delimiter as the math delimiter, it is natural for them to choose it too, just to have lesser variants.<p>Then why pandoc choose $ instead of \(…\) and \[…\]? And would that goes against the best practice of LaTeX?<p>The answer to the latter question is no, because the $ is the markdown delimiter, and when transpiled to LaTeX, it becomes the \(…\) and \[…\].<p>Answer to the first question is related to the fact that at least in pandoc, \[ means escaping the [. So to type \[ in markdown, it should be \\[, which is cumbersome. (There’s a special flag in pandoc that you can use bare \(…\) and \[…\] though.)<p>And since all this parsing is happening at the parser level, the code-delimiter argument is invalid. They are thinking more in terms of hacking an existing parser and render math as a post-processing step.<p>The second fatal error is comparing MathJax to KaTeX by showing the commit freq. and claim that MathJax is dead.<p>This is a really amateurish argument seen occasionally elsewhere in the open source community that if a software has no recent commit history it is dead.<p>In this particular instance, KaTeX is far behind MathJax in terms of coverage of rendering valid LaTeX math. This alone means they have a lot of catch up to do and no wonder a less mature software has more commit activity than a more mature one.<p>MathJax is backed by a lot of organizations/universities and they have commitment to maintain it. It is far from being dead.<p>KaTeX aims at being fast (MathJax 3 reclaim that territory a bit but AFAIK KaTeX is still king in that aspect.) If the math you use can be rendered by KaTeX, then use it. But it happened to me that I have to change a config to use MathJax instead of KaTeX because soon or later I’m going to use something KaTeX doesn’t support.<p>As GitHub doesn’t give you choice, choosing a default that has better coverage is no brainer.
> Its main advantage over MathJax is that it isn’t dead. Check out the repo activity on the two projects:<p>I know this is a common view, but
this is such a strange mindset to me. Unless you add scope, a project is eventually just mostly done. It's not that MathJax has zero commits, it just has fewer. That _in itself_ isn't a bad sign to me. It could just mean it's a mature project.