For example, my blog is supporting Markdown and ReST natively (Pelican-based). It is quite an absurd situation at this moment. At the same time it promises further development but nothing usable has come out of it so far.Īs a Python programmer, I would simply like to see a pure Python3 toolchain. The discussion was quickly dragged into the legal realm by 1 in particular, which very obviously dampened number 3's initial enthusiasm.Īdditionally, 2 describes itself somewhat prominently as a "legacy processor" for Python (technically correct in the current version, but legacy's meaning here is the relationship to the new Asciidoctor-specific constructs). In fact, also this claim is wrong, because there are three :Dġ and 2 seem to hate 3 (see issue trackers / web sites of all three) and meanwhile probably also vice versa. There's a few others that have largely stalled, like the packt build system for docx, but they're interesting. ah wait, they fixed that.Īfter these you have DBLATEX, which uses DocBook->LaTeX as its typesetting, and you have the Haskell thing, and the wiki-2-PDF converter that's default in Visual Studio Code Asciidoctor extension. Chews through some huge amounts of memory. This has the best promise, in my opinion, but it's still pretty raw, again, in my opinion. But again, XSL.Īsciidoctor-web-pdf:: this is the semi-experimental web based PDF tool, based on Paged.js, that uses the CMM Paged Media Module Level 3 (CMM PMM 元). It's also very capable of chewing through thousand page books if it's in its own environment. Yeah, I know, it's XSL, but since DocBook has such a long tail there's a huge amount of customization that's possible, along with some docbook-only features like better indices, list of figures, etc. Complex customization means extensions, and that has its own overhead.įOPUB aka docbook-xsl:: this is built in to the AsciidocFX dedicated editor, and uses the DocBook-XSL pipeline. Your PDF options in Asciidoc boil out to this:Īsciidoctor-pdf:: this is the Ruby prawn-based thing, it's the current official path, but SVG and images can choke it. So in that realm Asciidoc is practically useful to know. Which is in stark contrast to Asciidoc.Įdit: A small aside, I also learned that a few publishers that focus on tech writing specifically use Asciidoc for their "publishing" workflows. What I learned quickly when trying to come at Markdown from a technical perspective is that there are dozens or more Markdown flavors and the idea of "Markdown" as a "general thing" isn't accurate, there's not even really a "core" shared between the variants/flavors. And at the same time I wanted to have a common way to put together a book to be published. I learned all of this because I wanted to make a fast markdown parser in WASM directly. It's very flexible, very customizable, and does not aim for interop between implementations, for tooling, and so on.Īsciidoc tries to focus on being a Standard with a capital "S" so that the entire ecosystem around it can interop properly without implementation specific quirks/incompatibilities.īoth are good tools but with completely different philosophies. Markdown itself comes (not even implicitly, but explicitly!) with the philosophy that there is no "true" standard. The "promise" (I'd say) of Asciidoc in general versus Markdown is that it aims to truly be a standard. If you suggest us any shortcut request, we can implement it.This is both the power and "problem" with Markdown. AFX supports this ace shortcuts and custom shortcuts listed below.
0 Comments
Leave a Reply. |