diff options
authorAdrian Kummerlaender2017-01-17 20:38:18 +0100
committerAdrian Kummerlaender2017-01-17 20:38:18 +0100
commit23f6297c212525d71692eb7ee8e6e096ad4711a3 (patch)
parent0fc13c9422d340faf757eec2bf76219df4b309fd (diff)
Use `pandoc` as markdown processor
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.
1 files changed, 15 insertions, 6 deletions
diff --git a/utility/formatter.xsl b/utility/formatter.xsl
index e30a549..f590d89 100644
--- a/utility/formatter.xsl
+++ b/utility/formatter.xsl
@@ -1,6 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
+ xmlns="http://www.w3.org/1999/xhtml"
@@ -76,8 +77,8 @@
<xsl:with-param name="source" select="code/text()"/>
<xsl:with-param name="language">
- <xsl:when test="code/@class">
- <xsl:value-of select="substring(code/@class, 10, string-length(code/@class))"/>
+ <xsl:when test="@class">
+ <xsl:value-of select="@class"/>
@@ -87,9 +88,17 @@
-<xsl:template match="script" mode="embellish">
+<xsl:template match="div[@class = 'figure']" mode="embellish">
+ <p>
+ <xsl:apply-templates select="img" mode="embellish"/>
+ </p>
+<xsl:template match="div[@class = 'footnotes']/hr" mode="embellish"/>
+<xsl:template match="span[contains(@class, 'math')]" mode="embellish">
- <xsl:when test="contains(@type, 'mode=display')">
+ <xsl:when test="contains(@class, 'display')">
<p class="math">
<xsl:call-template name="math_highlighter">
<xsl:with-param name="source" select="text()"/>
@@ -102,7 +111,7 @@
<span class="math">
<xsl:call-template name="math_highlighter">
- <xsl:with-param name="source" select="text()"/>
+ <xsl:with-param name="source" select="text()"/>
@@ -114,7 +123,7 @@
<xsl:variable name="content">
<xsl:call-template name="plain_formatter">
- <xsl:with-param name="format">kramdown</xsl:with-param>
+ <xsl:with-param name="format">pandoc -f markdown -t html --katex --no-highlight</xsl:with-param>
<xsl:with-param name="source" select="$source"/>