Extensions
Extensions are central to the success of AsciiDoc because they open up the language to new use cases. Asciidoctor provides an extension API that offers a superset of extension points. As a result, extensions in Asciidoctor are easy to write, powerful, and simple to distribute.
Asciidoctor also allows extensions to be written using the full power of a programming language (whether it be Ruby, Java, Groovy or JavaScript). You don’t have to shave yaks to get the functionality you want, and you can distribute the extension using de facto standard packaging mechanisms like gems or JARs.
Available extension points
Asciidoctor provides the following extension points:
- Preprocessor
-
Processes the raw source lines before they are passed to the parser. See Preprocessor Extension.
- Tree processor
-
Processes the Asciidoctor::Document (AST) once parsing is complete. See Tree Processor Extension.
- Postprocessor
-
Processes the output after the document has been converted, but before it’s written to disk. See Postprocessor Extension Example.
- Docinfo Processor
-
Adds additional content to the header or footer regions of the generated document. See Docinfo Processor Extension Example.
- Block processor
-
Processes a block of content marked with a custom block style (i.e.,
[custom]). (similar to an AsciiDoc filter) See Block Processor Extension Example. - Compound block processor
-
Register a custom block named
collapsiblethat transforms a listing block into a compound block. See Compound Block Processor Example. - Block macro processor
-
Registers a custom block macro and processes it (e.g.,
gist::12345[]). See Block Macro Processor Extension Example. - Inline macro processor
-
Registers a custom inline macro and processes it (e.g.,
Save). See Inline Macro Processor Extension Example. - Include processor
-
Processes the
include::<filename>[]directive. See Include Processor Extension Example.
There are additional extension examples in the Asciidoctor extensions lab.