Re: [asciidoc-wg] AsciiDoc implementation for the Java/JVM ecosystem / project proposal
breaking down the implementation to different modules sounds like a best
practive: this would keep the parsing of AsciiDoc and creating an AST
separate from creating an output format.
The Asciidoctor implementation already pluggable output formats (called
backends), and this proved very valuable in different scenarios. I think
it is a best practice this implementation should adopt. It also creates
a block-level AST that can be inspected at run-time.
If you are using Asciidoctor today and given some Ruby knowledge, you
could try your luck with either a tree processor (the Asciidoctor
extensions lab contains varios tree processors already) or a backend
(you might want to strip down the html5 backend, see the source of
If you have problems with Asciidoctor souce highlighting, maby as this
question with an example in the Asciidoctor forum.
Regarding the project proposal: If you want to add yourself as an
interested party to try out early releases, or if you want to suggest
requirements for the scope, please let me know.
On 11.06.2020 14:48, Didier Vojtisek wrote:
(not sure this is the best thread)
what are the plan about implementation extensions in order to support
various output variants or complement?
for example, one of my daily usecase is to generate both the html and
the toc.xml files in order to include the generated html file in the
Eclipse help system.
As far as I known this toc.xml generation doesn't exist in
asciidoctor, so our current tool chain is more complex: first generate
the docbook from the asciidoc then use the docbook toolchain to
generate the complementary toc files.
similarly, there is also the point about supporting custom variants
for html such as webhelp (again a quite old output from docbook
toolchain but that has the good benefit to have a scalable outline/toc)
ps: short introduction about myself:
I started using docbook since ~2005 to write the documentation of our
research tools, I moved to asciidoc as input language but regularly
still need to fallback to docbook toolchain due to lacks in asciidoc
toolchain such as the one above or the poor support of highlighting
for custom languages in the [source] code block
Alexander Schwartz (alexander.schwartz@xxxxxxx)