aboutsummaryrefslogtreecommitdiff
path: root/source/00_content/commits/blog.kummerlaender.eu/2017_01_17_20_38_23f6297c212525d71692eb7ee8e6e096ad4711a3.md
diff options
context:
space:
mode:
authorAdrian Kummerlaender2019-04-13 00:36:45 +0200
committerAdrian Kummerlaender2019-04-13 00:49:11 +0200
commit6e5e71882d9d9969e0ffe3013e656cac8fa4f115 (patch)
treeb25460980bf2a9a172c7c7872f0468e05261c2bc /source/00_content/commits/blog.kummerlaender.eu/2017_01_17_20_38_23f6297c212525d71692eb7ee8e6e096ad4711a3.md
parentcd9463e572f31b82a73cdab6db6b53f3a1237b3e (diff)
downloadOverview-6e5e71882d9d9969e0ffe3013e656cac8fa4f115.tar
Overview-6e5e71882d9d9969e0ffe3013e656cac8fa4f115.tar.gz
Overview-6e5e71882d9d9969e0ffe3013e656cac8fa4f115.tar.bz2
Overview-6e5e71882d9d9969e0ffe3013e656cac8fa4f115.tar.lz
Overview-6e5e71882d9d9969e0ffe3013e656cac8fa4f115.tar.xz
Overview-6e5e71882d9d9969e0ffe3013e656cac8fa4f115.tar.zst
Overview-6e5e71882d9d9969e0ffe3013e656cac8fa4f115.zip
Replace commit feed aggregation with manual import
This is the starting point for extending _Overview_ to support various types of recent updates (i.e. not just blog articles and commits over a certain message size). While direct fetching and rendering of markdown-formatted Git commit messages is an attractive concept, this new approach should be much more flexible. As a side benefit commit entries can now be edited and expanded compared to their fixed Git reference. e.g. retroactively expanding upon older commits or adding example media that doesn't strictly belong inside the actual commit message.
Diffstat (limited to 'source/00_content/commits/blog.kummerlaender.eu/2017_01_17_20_38_23f6297c212525d71692eb7ee8e6e096ad4711a3.md')
-rw-r--r--source/00_content/commits/blog.kummerlaender.eu/2017_01_17_20_38_23f6297c212525d71692eb7ee8e6e096ad4711a3.md13
1 files changed, 13 insertions, 0 deletions
diff --git a/source/00_content/commits/blog.kummerlaender.eu/2017_01_17_20_38_23f6297c212525d71692eb7ee8e6e096ad4711a3.md b/source/00_content/commits/blog.kummerlaender.eu/2017_01_17_20_38_23f6297c212525d71692eb7ee8e6e096ad4711a3.md
new file mode 100644
index 0000000..9145e13
--- /dev/null
+++ b/source/00_content/commits/blog.kummerlaender.eu/2017_01_17_20_38_23f6297c212525d71692eb7ee8e6e096ad4711a3.md
@@ -0,0 +1,13 @@
+# 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.