Consider this a lightweight alternative to Mathjax-Node. SsKaTeX uses KaTeX's
In contrast to Mathjax-Node, you do not need a NodeJS installation (whose dependency V8 is unavailable for my
What you need
On the kramdown side:
All these requirements need to be met only if SsKaTeX is actually used.
SsKaTeX quickstart configuration:
:math_engine: sskatex :math_engine_opts: katexjs: 'path-to-katex/katex.min.js'
In the HTML templates:
On the actual server:
All that KaTeX stuff is conveniently packaged in a tarball available at the KaTeX releases page.
There are some more configuration options; for the details I refer you to the documentation.
Things to consider
Looking forward to your feedback.
On branch de.1tein.ccorn.sskatex.execjs, I have prepared an ExecJS-based version. This might enable SsKaTeX use under JRuby which cannot install the Duktape gem. It might be interesting to test this with the CI's Node.js installation as well as with other engine bindings like
In case of interest, I could merge that branch here, or create another pull request, although that sounds like a bad idea to me.
The Caveat still applies: The engine flexibility of ExecJS increases the likelihood of malfunctioning configurations and corresponding ticket filings. I'd rather prefer something specific that is known to work.
Thank you for you pull request!
I'm currently rather busy so I had just a quick look - here are some of the more obvious things I noticed:
As for duktape vs execjs: I don't know either but if duktape is self-contained, with less dependencies, I would go for it.
I will have a more in-depth look when I have some time in the coming weeks.
New commits addressing the following:
I am used to contributing diffs, not entire branches, so I knew I would mess this up:
Not sure how to repair this without dents in the Github workflow. Rebasing seems out of the question because this branch is already public. I could transfer the changes summarily to a new branch, close this pull request and start a new one.
Installing Duktape needs not much more than a C99 compiler and a version of Ruby that can load native object files. Even my old PowerMac G5 can install Duktape (as opposed to V8, Node.js, and all that). However, your CI has demonstrated that JRuby cannot install Duktape.
With ExecJS that should not be an issue. It would even use Node.js, so your CI tests should pass without additional gems even for JRuby (not tested). ExecJS is described as being able to use other engines such as
There should be a way to preempt ExecJS's automatic JS engine selection on startup and make it user-configurable instead. This way, users could stick to a configuration known to work. Until that is the case with ExecJS, I'd favor Duktape.
No, that's not necessary. Just work on your branch but rebase, squash, etc. and then force push. After all: This is just a branch in your repo and although public there is no need to be conservative in this case. So please don't open a new pull request - thanks!
Radically squashed now. The CI failed, but that is
Due to repeated rebasing and squashing, there are some commits referenced here that are no longer part of a named branch. I have deleted them locally (their SHA1 ids no longer exist), but Github keeps them even with
Mission accomplished: No dents in the workflow (but noise instead).
I find that the engine selection (and the associated availability tests) by ExecJS can be overridden with an environment variable
ENV['EXECJS_RUNTIME'] ||= 'Disabled' require 'execjs' [...] ExecJS.runtime = ExecJS::Runtimes::Duktape
This seems to encourage an ExecJS-based approach.
I have now merged an
The results are encouraging.
For better control, I have introduced an additional option for
Note that there is no explicit dependency on
I have done a performance comparison of
What I expected was that
Edit: After inspection of the
Edit: After adding the same optimization to the