| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Not worth the effort considering it is not used at all.
|
|
|
|
|
|
The trigger but not the actual reason for this replacement of `kramdown` with `pandoc` was a strange generation issue with `kramdown`'s latest release.
All recent articles failed to generate anything more than an empty page. A quick check of the resulting HTML for those articles offered nothing out of the ordinary. After taking a close look at the articles in question I narrowed the set of failing articles down to those containing footnotes - tangentially I only started using footnotes a couple of articles ago i.e. this explained this part of the issue.
Some debugging of `InputXSLT` offered the following problem: `Xerces-C` generated an error message and stopped processing XML inputs containing `nbsp` non-blocking space characters in the implementation of the `external-command` function. This change in `kramdown`'s output can be traced back to enhancement issue [399](https://github.com/gettalong/kramdown/pull/399). Obviously this is not a problem in `kramdown` but an issue in the way this static site generator is wrapping HTML inputs.
This problem should be solvable by adding appropriate namespace and doctype declarations to the markdown-generated HTML output. Instead I opted to perform the change to `pandoc` I had already planned for quite some time.
The choice fell on `pandoc` as it offers some additional markdown features as well as allowing for conversion to a rich set of document formats. i.e. features like printing articles as PDF using LaTeX are trivial to implement if `pandoc` is the markdown processor of choice. Furthermore page compilation is noticeably faster using `pandoc`.
One might note that this switch only solved the original issue by coincidence: Should `pandoc` start to generate non-blocking space characters the same problem will occur. But I have hopes that such a change would be configurable via `pandoc`'s plethora of configuration options. As this static site generator assumes everything to be XHTML I see no reason why I should not continue to treat HTML inputs as XML.
|
|
_KaTeX_ offers explicit support for server-side rendering instead of the hacky solution using _Mathjax_. Furtermore it ist noticeably faster and produces better output in my test cases.
|
|
* enables automatic detection of the feed in e.g. Opera
|
|
|
|
|
|
|
|
|
|
|
|
* stream view is still available from the archive to preserve backwards compatability
* reduce layout / styling differences between kummerlaender.eu and this blog
|
|
|
|
|
|
|
|
|
|
Previously multiple footnotes on article stream pages caused conflicts between articles and as such only worked correctly for the first article on each stream page.
|
|
|
|
Add support for header elements with inline math expressions
|
|
|
|
|
|
See paragraph 5 in 67162f80a77a41bc95d7de05a87f7ee9a21a121c
|
|
|
|
Many websites employ the [MathJax](https://www.mathjax.org/) library for dynamically rendering LaTeX math expressions on the client side. I expect to require support for doing just that in the future. But as with syntax highlighting I am of the opinion that this kind of stuff should be performed once during site compilation instead of wasting ressources by forcing each client to do this job for every single page request.
Luckily there is a [MathJax-node](https://github.com/mathjax/MathJax-node) module that allows using the _MathJax_ library on the server side.
This commit adds support for rendering math expressions written in Markdown respectively LaTeX as follows: `$$1 + 1 \neq 0$$` on the server side.
This required the introduction of a new `math_highlighter` helper template in `formatter.xsl` based on the `tex2html` utility provided by _MathJax-node_. This formatter is matched against the (Markdown parser generated) `script` node in `formatter.xsl`'s _embellish_ mode. The HTML rendering of the expression is then embedded in a `p class="math"` node. This explicit labeling allows `master.xsl` to include the `math.css` rules only for pages that actually contain math expressions.
Note that the XHTML rendering utility stylesheet `xhtml.xsl` currently adds a XML comment to each `span` node. This is a workaround to prevent _Xalan_ from collapsing "empty" `span` tag pairs into single nodes which otherwise leads to rendering errors as it is not valid HTML and is interpreted as a wrong tree structure by the browser.
Note that the CSS rules declared in `math.css` are explicitly not part of the MIT licensed part of this repository but where generated by _MathJax_.
As there is currently no _productive_ content making use of math expressions a demo page is available under `page/math_test/`.
|
|
|
|
|
|
|
|
|
|
I am of the opinion that a website has no business messing around with the client's default fonts beyond defining the style and size relative to the default font size.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
…otherwise various browsers correctly complain about unencrypted ressources if the website is accessed via `https`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
