Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Math on GitHub: The Good, the Bad and the Ugly

nschloe.github.io

Post reply on HN
Print view View original

61–70 of 71 posts

Re: Math on GitHub: The Good, the Bad and the Ugly

#61

Post by nschloe »

patrick451 wrote: post #32

> 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 tal…

Author here.

You're right, the big dreams always turn out smaller in real life when they come true, right? I'm hoping that the popularity of GitHub will aid a shift of publication style though. :)

Re: Math on GitHub: The Good, the Bad and the Ugly

#62

Post by nschloe »

KolenCh wrote: post #55

This article should not be taken seriously, which has at least 2 fatal errors in its argument. 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. Then they made a claim about why putting math inside code delimiters are better. Detouring…

Author here.

Thanks for all the great input!

I don't mean to argue for \(...\) and \[...\] in Markdown; it was just a side note I had added to satisfy the LaTeX purists such as myself. :) I hope I've clarified this in the text now.

> And since all this parsing is happening at the parser level, the code-delimiter argument is invalid.

Well, you're right in that they have to modify their parser to protect the $-$$ blocks. The issue is that they don't do that yet, and the fact that they don't have that that ready at release date makes me think it's hard to do. A smart way around all these problems would be tp use codeblocks for math since you don't have to modify the parser for this at all. That's what GitLab does anyway.

Let's just hope they'll adapt the parser.

> The second fatal error is comparing MathJax to KaTeX by showing the commit freq. and claim that MathJax is dead.

Thanks also for this comment! Another user pointed it out to me as well, and I've adapted the text accordingly. Having worked extensively with both MathJax and KaTeX, I found KaTeX has many advantages still. Some of those stem from the fact that it's far younger and built upon younger design principles, leading to better modularity for example. Anyway, apart from load times this doesn't affect the user so ultimately it's GitHub's choice.

Thanks again for taking the time for such a thorough review.

Re: Math on GitHub: The Good, the Bad and the Ugly

#63

Post by disgruntledphd2 »

patrick451 wrote: post #36
Beldin wrote: post #33

Earlier quoted context omitted.

I had the same feeling for a different reason: I don't think this reduces friction enough compared to sharing LaTeX files (on github or overleaf), which we can already do. So I don't think this will usher in a new era. I realise this could very well become the next "dropbox comment" - and I'll be happy to be proven wrong.

It would be cool if they would just render entire latex manuscripts that are part of the repo. It sort of sucks that you need to duplicate what you wrote a paper submission into markdown to get github to render it.

They do this for org mode files, but that's a much simpler format than LaTeX.

Re: Math on GitHub: The Good, the Bad and the Ugly

#64

Post by bewuethr »

I tried all the examples using

  pandoc --from markdown --to html --mathjax
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.

[1]: https://pandoc.org/MANUAL.html#pandocs-markdown

[2]: https://gist.github.com/bewuethr/691b4870828d7b2261113f14eef...

Re: Math on GitHub: The Good, the Bad and the Ugly

#65

Post by [deleted] »

nvrspyx wrote: post #39
auggierose wrote: post #25

Earlier quoted context omitted.

Given that the main point of using LaTeX in Markdown is familiarity of users, using $ and $$ is actually the ONLY proper choice. But yeah, it leads to problems, which is why I would not use Markdown in the first place, but some Markdown inspired format which mixes better with $ and $$.

This is why I prefer AsciiDoc. It's consistent because there's only one implementation, it's less ambiguous, and more predictable. Although it takes a bit longer to remember all the syntax, it's not difficult, especially if you're only going to use the same subset of features that markdown supports since it supports most of the markdown syntax as well. I also much prefer the flexibility with tables compared to markdo…

[deleted]

Re: Math on GitHub: The Good, the Bad and the Ugly

#66

Post by nschloe »

bewuethr wrote: post #64

I tried all the examples using pandoc --from markdown --to html --mathjax 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. [1]: https://pandoc.org/MANUAL.html#pandocs-markdown [2]: https://gist.g…

The difference between GitHub and pandoc with GitHub-flavored Markdown as input is that pandoc doesn't sanitize as aggressively as GitHub does. For example, pandoc doesn't remove the backslash-escapes before non-letters as in `\{`.

Not sure if GitHub will compromise here, though.

Re: Math on GitHub: The Good, the Bad and the Ugly

#67

Post by nschloe »

nmalaguti wrote: post #14

My theory is that there’s already a lot of existing content using $ and $$ that GitHub wants to start rendering without requiring any changes. I agree the code block approach would be less ambiguous, but there is an advantage in going where people already are.

Author here.

I've been a managing editor for scientific journals for a number of years, and I can tell that -- while $ is still popular -- (almost) nobody uses $$ anymore. So I wouldn't say this is "where people already are".

Re: Math on GitHub: The Good, the Bad and the Ugly

#68

Post by nschloe »

williamstein wrote: post #49

If you use a proper markdown plugin to parse math instead (such as https://github.com/goessner/markdown-it-texmath ), then the problems pointed out in this blog post go away.

Author here.

That is interesting! Have you tried it on the examples in the blog post? I'd be curious to see.

Re: Math on GitHub: The Good, the Bad and the Ugly

#69

Post by nschloe »

runarberg wrote: post #19

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 Fi…

Author here. Thanks for the comment!

The main problems pointed out in the blog post are problems in _parsing_ the Markdown+TeX pages. The output could be MathML indeed, but this is an issue they could always fix later.

Re: Math on GitHub: The Good, the Bad and the Ugly

#70

Post by kmill »

nschloe wrote: post #57
edflsafoiewq wrote: post #18

Earlier quoted context omitted.

Small font size seems the easiest to fix. Kerning seems worse since people will manually tweak spacing with \, etc, so you can't just change it whenever you want.

Blog post author here. The kerning is probably a problem with their font config that can hopefully be fixed. I don't think -- and that's me personal estimation -- that people will write tons of `a\,=\,b` to work around the bad kerning, so that's a change I would still recommend making.

I thought kerning specifically referred to small adjustments in spacing between pairs of letters. This just seems to be a failure in honoring the spacing for the different TeX math mode symbol classes. The rel and op classes each have a certain amount of spacing they are supposed to have on either side (unless they aren't used as binary operators), and somehow this is broken in their implementation -- the spacing doesn't come from the font configuration.

For example, a\mathbin{foo}b is supposed to render as "a foo b", but on GitHub it comes out as "afoob".

When I looked at the MathJax configuration GitHub uses, nothing pops out as being odd. It would be funny if a minifier totally messed up the part of the MathJax source code specifically for this.

Post reply on HN