Approaches for rendering math statically
#84
Open
opened 4 years ago by jnboehm
·
4 comments
Loading…
Reference in New Issue
There is no content yet.
Delete Branch '%!s(<nil>)'
Deleting a branch is permanent. It CANNOT be undone. Continue?
I'd like to render math entries statically during the build process, such that reading an article with math equations doesn't depend on the user enabling Javascript and MathJax (or KaTeX).
KaTeX already has facilities for this workflow, but is written in JS. Unfortunately I am unable to get a proper interoperability between those two languages going (with the help of subprocess). This would be the most direct way to go about it, but starting an entire node runtime for every single snippet of math will quickly degrade the performance. Hence, I am trying to find alternatives to calling out to
node
.The, to me, most promising one seems to be to collect all math formulas and then call out to node/KaTeX once to get the corresponding HTML elements, thus building up a hash map. I think it should be possible with pollen, but I am unsure of how to go about this. Are there any examples that do the same or something similar? I think something like bibliography management could be close enough.
I'm also curious about this. I assume that you'd have to parse the HTML output from Node/KaTeX back to X-expressions as well, since (as far as I know) it's not possible to specify raw HTML inside an X-expr.
This seems like a logical approach. I’d go about it like this (all inside your
root
tag function):splitf-txexpr
.decode
, providing a function provided for#:txexpr-proc
.The function provided for step 3 will only get one txexpr at a time, so it’s going to have to keep track of the formulas somehow. The simplest way to do this is to cheat and mutate some outer-scoped variable witin that function. Here’s one way to do it:
Keeping everything inside the
root
function has the advantage of being “safe” for multiple renders, since everything at the module level is shared across multiple Pollen docs if you are rendering more than one at a time.That's a good way to approach it, I was thinking about creating a hashmap that would then return the transformed katex-xexpr. This way the call to
decode
would only be a lookup in this dict and you'd get an (insignificant) amount of caching.To fill in the last piece of the puzzle I have implemented what Joel outlines and the code below basically completes step 2 above. You need
node
installed and the filekatex.js
.The txexpr can have an optional boolean attribute
display
that controls whether the snippet is rendered in display mode or in inline mode (default).To circumvent the issues with pipes in
subprocess
(for some reason I was not able to get that to work), I have opted to just call out tosystem
and use regular files for the JS instructions and for writing out the result.Thanks again for outlining the procedure Joel!