Except for providing logger support for converters I don't have much additional features on my list. For this I have no real inspiration yet how to go for it. If we leave this out I could do a release sooner than later.
@robertpanzer I would assume not to be fancy about it, but simply expose some form of Logger interface instance that converters can obtain by calling
getLogger() on the Converter interface. For a start the object returned can simply be a noop logger.
Converterwould be left out then. That could work. I'd like to avoid requiring methods like
setDelegate()to the interface. Too bad Java doesn't have traits
I am thinking off-the-cuff now as I did not look inside the implementation, but when the converter is registered via SPI, there is a Asciidoctor instance that is passed down. If you add a default method to the
setLogger(Logger), a converter can choose to implement that. The during registration of the converter, you can work out something to call
Converter.setLogger at that point.
What I like about the API is that it already has
LogRecord. Although that was designed for acting on logged events, it can also be applied in reverse. Alternatively what about making an instance of something available that can create
LogRecord and submit them. This instance can then be injected into a converter via
@Inject on a field or a c-tor.
News on the asciidoctor-gradle 3.x front, I have managed to create an additional plugin that integrates DeckTape to export slides to PDF/JPG/PNG. It can basically convert any HTML slide deck that DeckTape supports and that was created by an Asciidoctor task.
However, because we already have specific Reveal.js support in the GRadle plugins the integration is even more slick. It will detect the presence of the
asciidoctorRevealJs task and allow on-demand creation of