KeenType VS pandoc

> modern languages like Markdown

Markdown was created in 2004. From the creator:

> ... the single biggest source of inspiration for Markdown’s syntax is the format of plain text email.

Email goes back to 1965, though I suspect Markdown's influence stems from the more widely adopted email usage from the 1990s.

> Part of LaTeX's success was the absolutely beautiful documents it can make with nothing but a personal computer.

I'd say that was TeX's success, with LaTeX bolted on later to greatly improve TeX's extensibility. Keep in mind, there are a number of TeX-centric implementations beyond LaTeX. For example, my fork of NTS, called KeenType, is a pure Java version of TeX that can typeset beautifully and has at its core Knuth's original TeX files.

https://github.com/DaveJarvis/KeenType/tree/main/tex/src/mai...

My port of the New Typesetting System (NTS), called KeenType, whittles down the Java-based implementation to a few of Knuth's files. Namely, "plain.tex" and "hyphen.tex":

https://github.com/DaveJarvis/KeenType/tree/main/tex/src/mai...

Getting familiar with the fonts required understanding the difference between font metrics (TFM files) and the fonts themselves. To make matters a little less straightforward, Knuth created a special character mapping for indexes into the fonts. It was not easy to find a font that mapped those glyphs exactly. The closest font was BaKoMa:

https://github.com/DaveJarvis/KeenType/tree/main/tex/src/mai...

This required hard-coding a mapping between Knuth's code points and the actual code points in the target font:

https://github.com/DaveJarvis/KeenType/blob/989dbe26f68eda75...

A while ago I optimized KeenType, which although not JavaScript-based, generates SVG images, which can be embedded into web pages.

https://github.com/DaveJarvis/keentype

The following tutorial shows the real-time rendering speed of KeenType within my text editor, KeenWrite:

https://youtu.be/vgyYXwwF_lc?list=PLB-WIt1cZYLm1MMx2FBG9KWzP...

In Java, many number-to-string implementations use NumberFormat. This is abysmally slow if the problem domain doesn't require internationalization, which is the case for machine-readable file formats, such as SVG. When I performance tested JMathTeX for rendering TeX, the bottleneck for converting TeX into SVG elements was JFreeSVG's use of NumberFormat[0]. Replacing NumberFormat with RyuDouble doubled the throughput[1]. (Reusing a StringBuilder for to concatenate strings yielded another doubling.)

For KeenType[2], a fork of the New Typesetting System (and more complete TeX implementation than JMathTeX), I added an SVG generator that converts numbers to string using a StackOverflow answer[3], instead of using Ryu[4]. The performance was even better and the algorithm vastly simpler.

Knuth was right: measure, then optimize.

[0]: https://github.com/jfree/jfreesvg

[1]: https://github.com/jfree/jfreesvg/pull/30

[2]: https://github.com/DaveJarvis/KeenType

[3]: https://stackoverflow.com/a/10554128/59087

[4]: https://github.com/DaveJarvis/KeenType/blob/fef005579021f394...

KeenType, a modernized and optimized NTS fork, replaces KeenTeX.

My main authoring tool is then Emacs Markdown Mode (https://jblevins.org/projects/markdown-mode/). For data entry, it comes with some bells and whistles similar to org-mode, like C-c C-l for inserting links etc.

I seldom export my notes for external usage, but if it is the case, I use lowdown (https://kristaps.bsd.lv/lowdown/) which also comes with some nice output targets (among the more unusual are Groff and Terminal). Of cource pandoc (https://pandoc.org/) does a very good job here, too.

This is one of those things that the ever-amazing pandoc (https://pandoc.org/) does very well, on top of supporting virtually every other document format.

Folks feel the same way about Markdown versus LaTeX: why use something significantly more complicated where a looser, human-readable grammar works better?

For any other situations, I use https://pandoc.org/, or, generate a Word doc scriptomatically.

pandoc toolchain pour builder une version confortable/imprimable en phase de travail (ePub, pdf, docx, html)

Congrats on the launch, I guess, but there are so many free options that I can't think of a situation where paying $0.25 per document would be justified...? Just to name a few:

Back in the days, I used to use XSL-FO [0] and it was okay. It was not very precise but it rarely if ever broke, and was perfectly integrated with an XML/XSLT solution. Yeah, this was a long time ago.

Last month I used html-to-pdfmake [1] and it's also not very precise and more fragile, but very efficient and fast.

Yet another approach would be to pro grammatically generate .rtf files (for example) and use Pandoc [2] to produce PDFs (I have not tried this in production but don't see why it wouldn't work).

[0] https://en.wikipedia.org/wiki/XSL_Formatting_Objects

[1] https://www.npmjs.com/package/html-to-pdfmake

[2] https://pandoc.org/

Others have mentioned static site generators. I like Hakyll [1] because it can tightly integrate with Pandoc [2] and allows you to develop custom solutions if your needs ever grow.

[1]: https://jaspervdj.be/hakyll/

[2]: https://pandoc.org/

Have you compared it with a conversion by pandoc (https://pandoc.org/)?

I have used it to kickstart a blogging project that I wish to come back to soon. The Lua inter-op for custom readers, writers and filters is great but I wish there was more editor integration and even perhaps an official IDE/editor with built-in debugging features (probably something already do-able with Emacs but I haven't checked). The only blocker for my project is no support for "ChunkedDoc" for Lua filters [1] which forces me to write more code and a complicated Makefile.

[1]: https://github.com/jgm/pandoc/issues/9061