Re: [asciidoc-wg] AsciiDoc implementation for the Java/JVM ecosystem / p

[Didier Vojtisek <didier.vojtisek@xxxxxxxx>]

Hi
(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,
> Alexander
>
> On 10.06.2020 19:02, Anthony Vanelverdinghe wrote:
> > Hi
> >
> > 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
> >
> > [1] https://github.com/asciidoctor/asciidoctor-pdf/
> >
> > Kind regards,
> > Anthony
> --
> Alexander Schwartz (alexander.schwartz@xxxxxxx)
> https://www.ahus1.de
>
> _______________________________________________
> asciidoc-wg mailing list
> asciidoc-wg@xxxxxxxxxxx
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/asciidoc-wg

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