From 12aedfce92b3d728da12624c0154dec43a139e66 Mon Sep 17 00:00:00 2001 From: Danila Fedorin Date: Sun, 19 Jul 2020 14:09:24 -0700 Subject: [PATCH] Make small fixes to math rendering code. --- content/blog/backend_math_rendering.md | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/content/blog/backend_math_rendering.md b/content/blog/backend_math_rendering.md index e8cf5e5..6095dc5 100644 --- a/content/blog/backend_math_rendering.md +++ b/content/blog/backend_math_rendering.md @@ -42,9 +42,9 @@ like mine, to render math on the backend. I settled on the following architecture: -* As before I would generate my pages using Hugo. -* I would use the KaTeX NPM package to rendering math. -* To build the website no matter what computer I was on, I would use Nix. +* As before, I would generate my pages using Hugo. +* I would use the KaTeX NPM package to render math. +* To build the website no matter what system I was on, I would use Nix. It so happens that Nix isn't really required for using my approach in general. I will give my setup here, but feel free to skip ahead. @@ -119,9 +119,12 @@ which replaced mathematical expressions in a page with their SVG forms. This is still the case, in both MathJax and KaTeX. The ability to render math in one step is the main selling point of front-end LaTeX renderers: all you have to do is drop in a file from a CDN, and voila, you have your -math. There are no such easy answers for back-end rendering. +math. There are no such easy answers for back-end rendering. I decided +to write my own Ruby script to get the job done. From this script, I +would call the `katex` command-line program, which would perform +the heavy lifting of rendering the mathematics. -So what _do_ I do? Well, there are two types on my website: inline math and display math. +There are two types of math on my website: inline math and display math. On the command line ([here are the docs](https://katex.org/docs/cli.html)), the distinction is made using the `--display-mode` argument. So, the general algorithm is to replace the code inside the `$$...$$` with their display-rendered version, @@ -167,7 +170,7 @@ end There's a bit of a trick to the final layer of this script. We want to be really careful about where we replace LaTeX, and where we don't. In particular, we _don't_ want to go into the `code` tags. Otherwise, -it wouldn't be able to talk about LaTeX code! Thus, we can't just +it wouldn't be possible to talk about LaTeX code! Thus, we can't just search-and-replace over the entire HTML document; we need to be context aware. This is where `nokigiri` comes in. We parse the HTML, and iterate over all of the 'text' nodes, calling `perform_katex_sub` on all @@ -198,7 +201,7 @@ We write: * `//`, starting to search for nodes everywhere, not just the root of the document. * `*`, to match _any_ node. We want to replace math inside of `div`s, `span`s, `nav`s, all of the `h`s, and so on. -* `[not(self::code)]` cutting out all the `code` tags. +* `[not(self::code)]`, cutting out all the `code` tags. * `/`, now selecting the nodes that are immediate descendants of the nodes we've selected. * `text()`, giving us the text contents of all the nodes we've selected.