Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [asciidoc-wg] AsciiDoc implementation for the Java/JVM ecosystem / project proposal

(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)

Best regard
Didier Vojtisek

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

On 11/06/2020 13:07, Alexander Schwartz wrote:
Hello Anthony,

thanks for pointing me at PDF output. I am also a great fan of
asciidoctor-pdf as it allows my Java builds to create PDF without other
dependencies. I'll add this to the list, although HTML output will
probably be first.

Regarding the JDK 8 vs. 11 vs. 17: This willl be a library project that
wants to support a wide variety of existing applications. Therefore I
want to be conservative about the JDK release. I want people to choose
between AsciidoctorJ and the new library to gather feedback. This
wouldn't work IMHO if it would target only newer releases.

As of today GraalVM only support OpenJDK 11 at maximum, thefore I
wouldn't go futher than 11 as of today.

The new Java features would allow to write more expressive and efficient
code, but I don't see them as enabler of new features the library can
provide. Please correct me if I missed something.

Best regards,

On 10.06.2020 19:02, Anthony Vanelverdinghe wrote:

This is a great initiative! I have the following suggestions/questions:
* instead of specifying the runtime environments, specify the targeted
language release, possibly in a generic fashion, such as "the current
LTS release"
* given that this is a greenfield project, and an alternative
(AsciidoctorJ) exists for people that are stuck with Java SE 8, I
don't see why this project should restrain itself to Java SE 8
* it seems that a project like this could benefit from a lot of the
recent improvements in Java SE (text blocks, switch expressions,
records, sealed classes, ...), so consider targeting Java SE 17 (the
next LTS release, due next year, which will have most, if not all, of
these features standardized). This depends on how fast you're planning
to release a complete implementation, of course
* what are the plans w.r.t. conversion to PDF, like done by
asciidoctor-pdf [1]? If the goal is for this project to replace
AsciidoctorJ in the Java ecosystem, I believe it's essential to its
success to provide an implementation in pure Java for PDF conversion
as well


Kind regards,

Alexander Schwartz (alexander.schwartz@xxxxxxx)

asciidoc-wg mailing list
To unsubscribe from this list, visit

Didier Vojtisek
SED Rennes - DiverSE Team - LogicA Team
Inria, Univ Rennes, CNRS, IRISA
Campus de beaulieu
35042 Rennes
02 99 84 75 07

Back to the top