Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]

DAPS AsciiDoc Quick Start Guide

Author: Frank Sundermeyer
Publication Date: 2021-05-11

AsciiDoc (http://asciidoc.org/) is a widely used markup language which, among other features, natively supports conversion to DocBook. Starting with the DAPS 3.0, DAPS supports AsciiDoc sources. AsciiDoc sources are converted to DocBook and then processed the same way as DocBook sources. Projects with AsciiDoc sources are handled the same way as regular DocBook projects. Therefore, the full range of output formats supported by DAPS is supported for AsciiDoc sources (HTML, single HTML, PDF, EPUB, Mobipocket, plain text). This quick start guide focuses on using DAPS with AsciiDoc sources and requires basic DAPS knowledge and AsciiDoc writing experience. Section 8, “For More Information” contains links to documentation on DAPS and AsciiDoc.

The complete DAPS documentation is available online at https://opensuse.github.io/daps/ (https://opensuse.github.io/daps/).

1 Motivation

Over the past years, a lot of software documentation projects have moved from DocBook to AsciiDoc. With products and solutions becoming increasingly complex, documentation needs to rely more and more on external contributors. The hurdle to contribute is significantly lower when using AsciiDoc as it is with DocBook. Such a move not only requires converting the DocBook sources to AsciiDoc, but also changing the project setup, the toolchain and writing new stylesheets. The AsciiDoc support in DAPS saves you from switching to a new toolchain and new stylesheets. Whether you convert an existing DAPS project from DocBook to AsciiDoc, or whether you have used DAPS before and are starting an AsciiDoc project from scratch, DAPS lets you:

  • use existing XSLT stylesheets (for converting DocBook into PDF, HTML, etc.)

  • use the same daps commands as with DocBook projects

  • use the same project setup as with DocBook projects

However, DAPS cannot handle the conversion to AsciiDoc as the new source format.

2 Requirements

To use AsciiDoc sources with DAPS, you need to install the following packages:

  • DAPS 3.0 or better

  • asciidoctor

To install DAPS follow the DAPS installation instructions (https://github.com/asciidoctor/docbookrx). For installing asciidoctor we recommend to use packages available for your Linux distribution.

3 Setting up a Project

An AsciiDoc project has got the same directory structure as a regular DocBook project managed with DAPS (see Directory Structure (https://opensuse.github.io/daps/doc/cha.daps.user.features.html#sec.daps.user.basics.dirstruct) for more information. However, there is one exception: For a DocBook project, images need to be saved in a directory structure where each image format has its own directory. To be able to also easily process AsciiDoc sources from a DAPS project with asciidoctor or to properly display the contents on, for example, GitHub, an AsciiDoc project can store all images in a single directory.

3.1 The Directory Structure

The following directory structure is recommended for AsciiDoc projects:

     |--DC-* 2
     |--adoc/ 3
     |   |--MAIN.adoc 4
     |   |--\*.adoc
     |   |--images/ 5
     |   |  |--\*.dia/
     |   |  |--\*.jpg
     |   |  |--\*.png/
     |   |  |--\*.svg/


The project’s root directory (working directory) for the respective documentation project.


One or more Doc Config files (DC files) defining your deliverables. Each DC file represents one book, article, or man page.


The directory containing all AsciiDoc source files. It must be named adoc/. AsciiDoc files in subdirectories are ignored.


The MAIN file of the documentation project. It may be the only file, but may also include other AsciiDoc files via the include directive.


The Directory containing image files. Place all images in this directory. Subdirectories are ignored. Either specify the path to this directory in the DC-file with ADOC_IMG_DIR (recommended) or on the command line with --adocimgdir.

3.2 The Doc Config File (DC File)

A configuration file in the project directory. Each book, article, or man page in a project can have its own documentation configuration file (DC file). It defines several parameters for your documentation deliverable (for example, the MAIN file, layout variants, or whether to render the sources as article or book). Although not mandatory, creating a DC file for each deliverable is recommended. You can store deliverable-specific configuration options in the DC-file that you otherwise need to enter on the command line each time you call DAPS.

DC files need to be placed in the project root. The file names need to start with DC-. The rest of the file name is used to name directories and files created by DAPS. For example, if a DC-file is named DC-adoc_test, file names and directories will start with adoc_test.

Of the multiple parameters that can be set in the DC file, the only one required is MAIN. It points to the MAIN AsciiDoc file that you want to process. Create at least one DC file per book or article.

Example 1: Example: A Typical DC File for an AsciiDoc Project
## Doc config file for the DAPS example document
## See /etc/daps/config for documentation of the settings below

# MAIN file (mandatory) 1

#----- optional parameters -----

# Image directory  2

# Type 3

# Turn on postprocessing  4

# Stylesheet directory  5

# XSLT Parameters for customizing the stylesheets 6
XSLTPARAM="--stringparam homepage=https://github.com/openSUSE/daps"
XSLTPARAM+="--param variablelist.as.blocks=1"


Name of the main AsciiDoc file from the adoc/ directory. You do not need to specify the full path, DAPS will automatically find it.


Path to the image directory containing images referenced in the AsciiDoc sources. If you specify a relative path (recommended for portability), it needs to be specified relative to the directory containing the DC file.


Document type (article, book, manpage).


Parameter for applying the (default) post-processing XSLT stylesheet. It cleans up some of the DocBook XML constructs created by asciidoctor.


For a custom layout, use the STYLEROOT parameter to specify the path to the directory containing the custom XSLT stylesheets. If not specified, DAPS will use the default DocBook stylesheets. For an introduction on how to create custom stylesheets, refer to Customizing the DocBook Stylesheets (https://opensuse.github.io/daps/doc/cha.daps.user.layout.html#sec.daps.user.layout.styleheets) (requires XSLT knowledge).


If the stylesheets allow customization via parameters, you can specify these parameters here.

The example above only shows a few options you can set. For a complete reference, refer to the DAPS configuration file at /etc/daps/config. An overview of the AsciiDoc-specific configuration options is also available at Section A.1, “Command Line Options and Configuration Settings for AsciiDoc”.

3.3 Image Linking and Processing

One of the core features of DAPS is automatic image conversion. Whether images need to be converted to grayscale for a printable PDF, whether .dia images need to be converted to SVG, or whether .svg images need to be converted to PNG—​DAPS automatically takes care. You only need to make sure that the image is available in a supported format in the AsciiDoc images directory. Refer to Image Handling (https://opensuse.github.io/daps/doc/cha.daps.user.img.html) for details.

When linking an image in the AsciiDoc sources, use the attribute :imagesdir: in the document header. Always use the file name only. The path for :imagesdir: is best specified relatively (relative to the adoc/ directory). Specifying :imagesdir: is optional, but recommended. It allows you to also process your AsciiDoc sources with tools other than DAPS.

Example 2: Example: Linking Images in AsciiDoc
= Linking images

:author: John Doe
:imagesdir: images/

This is an example of how to link images in AsciiDoc documents processed with DAPS.

image::test.png[Test Image]

For the example above, the images need to reside in adoc/images. Possible sources for the images in adoc/images are:

  • adoc/images/test.dia

  • adoc/images/test.jpg

  • adoc/images/test.png

  • adoc/images/test.svg

The AsciiDoc source example requests a PNG file. If it exists, it will be used as is. If it does not exist, DAPS will search for an image with the base name test (test.svg, test.dia) and automatically convert it to PNG.

Important: Unique Image Names

Because of the procedure described above, DAPS requires unique base names for images. If you would have two files with different content but the same base name, for example test.svg and test.dia, the outcome of an automatic conversion would be uncertain (could be either one of the two files). Therefore make sure to always use unique base names. To test for non-unique images, use the following daps command: daps -d <DCFILE> list-images-multisrc.

In AsciiDoc, image scaling is often achieved by setting pixel height/width. However, using plain pixel values for scaling is not supported well in DAPS and will usually cause issues in PDF builds. To scale images, instead use the scaledwidth attribute with a percentage:

Example 3: Example: Adding a scaled image
image::test.png[Test Image, scaledwidth=100%]

4 Creating Output with DAPS

After you have set up the directory structure, created AsciiDoc documents, and images (optionally), you can use DAPS to create PDFs, HTML, EPUB and other output formats. The command line syntax is the same as with DocBook projects:

Example 4: Example: Creating HTML output
daps -d DC-_MYADOC_  html
Example 5: Example: Creating Single Page HTML Output
daps -d DC-_MYADOC_  html --single
Example 6: Example: Creating a PDF Directly from an AsciiDoc Source File
daps -m adoc/_MYADOC_.adoc pdf

For more information, refer to daps --help. Help on the DAPS subcommands is available with the command daps <SUBCOMMAND> help.

4.1 Creating Partial Output

If you want to create output for parts of the documents (for example, to send a single chapter or section for review), you do not need to create the whole document and cut out the parts you need. DAPS supports creating partial documents on section titles for any of the supported output formats. All that is required is an anchor preceding the section title:

Example: Section title with an Anchor. 

== Brand New Chapter

This chapter is brand new

This anchor, new_chapter in the example above, can be passed to DAPS with the --rootid parameter. The following example shows how to build a PDF only containing the chapter "Brand New Chapter":

daps -d DC-_MYADOC_ pdf --rootid="new_chapter"

4.2 Spell Checking

DAPS also supports spell checking your sources. This is especially convenient, when your sources contain include files. A spellcheck with DAPS automatically checks all included files. DAPS supports the backends aspell and hunspell for spellchecking.

daps -d DC-_MYADOC_ spellcheck --lang=en_GB --spell-checker=hunspell

5 Common Errors and Pitfalls

Before generating output formats, DAPS internally converts AsciiDoc to DocBook XML. Because of that you may receive two different kind of errors when processing AsciiDoc sources:

AsciiDoc Errors

The conversion to DocBook XML is done by `asciidoctor. In case there are syntax or structural errors in the AsciiDoc sources, you will get an appropriate error or warning message. It usually contains the number of the line where the error occurred. These errors need to be fixed before any further processing can be done, DAPS will only proceed in case asciidoctor no longer produces errors or warnings.

DAPS Errors

After the internal conversion to DocBook XML is done, DAPS validates the resulting XML file to make sure it can properly be processed. Although this happens rarely, the conversion to DocBook XML might produce invalid XML. In this case, you will receive an error message claiming that "validation failed." The error message also contains the path to the file and the line number where the error occurred.

To fix the error, look at the text in the XML file at the given line and locate that text in the AsciiDoc sources. The error might be the result of some unsupported special asciidoctor macro or of an overly complex structure. Simplify the AsciiDoc code and try again.

5.1 Avoiding Mistakes

Section Titles (Headings)
  • DAPS only allows a single Level 0 section at the beginning of the document

  • Section titles need to be in correct order. It is not possible to skip a level. So == Level 2 followed by ==== Level 4 will not work.

  • DAPS currently does not support embedding videos

6 Linking Between Multiple Books

The asciidoctor built-in way to do inter-document cross references (via link:file.html#ID[TITLE]) does not work when generating the output via DocBook as DAPS does (and it only works for HTML output).

DAPS provides a way to allow links between multiple books (inter-document cross references) by converting the AsciiDoc sources into a DocBook set.

Requirements for the AsciiDoc sources
  • The AsciiDoc sources need to combine all books into a single "master book" (with the doctype book) by making each book a "part" of the master book. In AsciiDoc, a part is introduced by a level 0 headline (= HEADLINE) that follows the initial headline of the master book. See the Asciidoctor documentation (https://asciidoctor.org/docs/user-manual/#book-parts-and-chapters) for details.

  • The master book must only contain parts and no additional content outside these parts.

  • Each part needs to begin with a unique custom ID ([[UNIQUE_ID]])

  • You need to be extra careful not to mess up the headline hierarchy throughout the master book. If you are using prefix, appendix, glossary, etc. make sure you apply the special rules for parts regarding the headline levels (refer to the Asciidoctor documentation (https://asciidoctor.org/docs/user-manual/) for details)

  • Abstracts for chapters do not seem to work in parts (is this a bug?)

  • All IDs you use need to be unique. Duplicated IDs will cause errors.

  • Create a DC-file for the master book to be able to easily build it with DAPS (name it, for example, DC-multipart). MAIN needs to point to the top level AsciiDoc file that defines the master book.

Since tha AsciiDoc source now combines everything into a single book, you can link to all IDs anywhere in the book using <<ID>>.

Once the "master book" builds without errors and you can see a part for each book you want to build, proceed as follows to create stand-alone books in HTML, PDF, etc:

  1. Copy the DC-file for the master book (name the copy, for example DC-set)

  2. Add the line ADOC_SET="yes" to the copy of the DC file

  3. Create a copy of the new DC-file (DC-set) for the first book represented by a part in the master book. Add the ID of the respective part to the DC-file by adding a line ROOTID=<ID> (where you replave <ID> with the respective part ID)

  4. Repeat the previous step for each book represented by a part.

Using the respective DC-files you can now build the individual books. Using DC-set allows you to build the complete set.

  • the individual books cannot contain parts

  • the article document type is not supported with this setup

7 GitHub Integration

One of the advantages of using AsciiDoc as a source for documentation is its seamless integration with GitHub. GitHub not only renders AsciiDoc sources, but also allows to edit them directly in the Web interface. After having edited a document via the built-in editor, GitHub even automatically creates a pull request, depending on the repository setup. This improves the flow for external contributors.

To enable a smooth GitHub integration, a few adjustments in the AsciiDoc source code are required. Using the ifdef preprocessor macro, you can set directives specific to GitHub. The following adjustments are required:


In addition to this, including documents via the include directive needs to be worked around, since this is not supported by GitHub for security reasons. Create an anchor () at the top-level of the documents you want to include and use the following syntax:

// Links for GitHub
 <<FILE1.adoc#ANCHOR, TITLE1>>
 <<FILE2.adoc#ANCHOR, TITLE2>>
// includes for AsciiDoc processing
Admonition Images

Admonition boxes (warning, tip, etc.) usually come with an icon. To display these icons, you need to tell GitHub where to find them.

:tip-caption: :bulb:
:note-caption: :information_source:
:important-caption: :heavy_exclamation_mark:
:caution-caption: :fire:
:warning-caption: :warning:
Print this page