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 defacto-standard packaging mechanisms like RubyGems 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 Example.
- Tree processor
-
Processes the Asciidoctor::Document (AST) once parsing is complete. See Tree Processor Extension Example.
- 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.