On Tue, 08 Mar 2016, Dan Allen <dan@xxxxxxxxxxxxx> wrote: > One of the key goals of the Asciidoctor project is to be able to directly > produce a wide variety of outputs from the same source (without DocBook). > We've added flexibility and best practices into the syntax and matured the > converter mechanism to bridge this (sometimes very wide) gap. I think our conclusion so far was that the native AsciiDoc (and Asciidoctor) outputs fell short of our needs, forcing us to use the DocBook pipeline. I, for one, was hoping we could eventually simplify the toolchain. For example, there was no support for chunked, or split to chapters, HTML, and the single page result was simply way too big. > Asciidoctor is the future of AsciiDoc. Even the AsciiDoc Python maintainers > acknowledge that (including the original creator). Thanks for the input. We've touched the topic of AsciiDoc vs. Asciidoctor before [1]. So we should be using Asciidoctor instead of AsciiDoc. That actually makes choosing asciidoc harder, because requiring another language environment complicates, not simplifies, the toolchain. I'd really like to lower the bar for building the documentation, for everyone, so much so that it becomes part of the normal checks for patch inclusion. BR, Jani. [1] http://mid.gmane.org/86pow31ddj.fsf@xxxxxxxxxxxxxxx -- Jani Nikula, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
