| Re: [asciidoc-wg] AsciiDoc implementation for the Java/JVM ecosystem / project proposal |
Hi Didier, I think having a document model and an appropriate API would solve this issue. You would then just parse the AsciiDoc files and inspect the model for the various elements that you need to generate your toc.xml or webhelp. This is something I would also like to make use of for generating EPUBs. Best regards, Torkild > 11. jun. 2020 kl. 14:48 skrev 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 > > _______________________________________________ > asciidoc-wg mailing list > asciidoc-wg@xxxxxxxxxxx > To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/asciidoc-wg
Attachment:
signature.asc
Description: Message signed with OpenPGP