| Home | Libraries | People | FAQ | More

## Syntax Summary

A QuickBook document is composed of one or more blocks. An example of a block is the paragraph or a C++ code snippet. Some blocks have special mark-ups. Blocks, except code snippets which have their own grammar (C++ or Python), are composed of one or more phrases. A phrase can be a simple contiguous run of characters. Phrases can have special mark-ups. Marked up phrases can recursively contain other phrases, but cannot contain blocks. A terminal is a self contained block-level or phrase- level element that does not nest anything.

Blocks, in general, are delimited by two end-of-lines (the block terminator). Phrases in each block cannot contain a block terminator. This way, syntax errors such as un-matched closing brackets do not go haywire and corrupt anything past a single block.

## Comments

Can be placed anywhere.

    [/ comment (no output generated) ]

## Phrase Level Elements

### Font Styles

    ['italic], [*bold], [_underline], [^teletype]

will generate:

italic, bold, underline, `teletype`

Like all non-terminal phrase level elements, this can of course be nested:

    [*['bold-italic]]

will generate:

bold-italic

### Simple formatting

Simple markup for formatting text, common in many applications, is now supported:

    /italic/, *bold*, _underline_, =teletype=

will generate:

italic, bold, underline, `teletype`

Unlike QuickBook's standard formatting scheme, the rules for simpler alternatives are much stricter.

- Simple markups cannot nest. You can combine a simple markup with a nestable markup.
- A non-space character must follow the leading markup
- A non-space character must precede the trailing markup
- A space or a punctuation must follow the trailing markup
- If the matching markup cannot be found within a line, the formatting will not be applied. This is to ensure that un-matched formatting markups, which can be a common mistake, does not corrupt anything past a single line. We do not want the rest of the document to be rendered bold just because we forgot a trailing '*'.
- A line starting with the star will be interpreted as an unordered list. See Unordered lists.

#### More Formatting Samples

Markup | Result
--- | ---
`*Bold*` | Bold
`*Is bold*` | Is bold
`* Not bold* *Not bold * * Not bold *` | * Not bold* *Not bold * * Not bold *
`This*Isn't*Bold (no bold)` | This*Isn't*Bold (no bold)
`(*Bold Inside*) (parenthesis not bold)` | (Bold Inside) (parenthesis not bold)
`*(Bold Outside)* (parenthesis bold)` | (Bold Outside) (parenthesis bold)
`3*4*5 = 60 (no bold)` | 3*4*5 = 60 (no bold)
`3 * 4 * 5 = 60 (no bold)` | 3 * 4 * 5 = 60 (no bold)
`3 *4* 5 = 60 (4 is bold)` | 3 4 5 = 60 (4 is bold)
`*This is bold* this is not *but this is*` | This is bold this is not but this is
`*This is bold*.` | This is bold.
`*B*. (bold B)` | B. (bold B)
`['*Bold-Italic*]` | Bold-Italic

Thanks to David Barrett, author of Qwiki, for sharing these samples and teaching me these obscure formatting rules. I wasn't sure at all if Spirit, being more or less a formal EBNF parser, can handle the context sensitivity and ambiguity.

### Inline code

Inlining code in paragraphs is quite common when writing C++ documentation. We provide a very simple markup for this. For example, this:

    This text has inlined code `int main() { return 0; }` in it.

will generate:

This text has inlined code `int main() { return 0; }` in it. The code will be syntax highlighted.

Note that we simply enclose the code with the tick: `"`"`, not the single quote: `"'"`. Note too that ``some code`` is prefered over `[^some code]`.

### Source Mode

If a document contains more than one type of source code then the source mode may be changed dynamically as the document is processed. All QuickBook documents are initially in C++ mode by default, though an alternative initial value may be set in the Document Info section.

To change the source mode, use the `[source-mode]` markup, where `source-mode` is one of the supported modes. For example, this:

    Python's [python] `import` is rather like C++'s [c++] `#include`. A
    C++ comment `// looks like this` whereas a Python comment [python]
    `# looks like this`.

will generate:

Python's `import` is rather like C++'s `#include`. A C++ comment `// looks like this` whereas a Python comment `#looks like this`.

#### Supported Source Modes

Mode | Source Mode Markup
--- | ---
C++ | `[c++]`
Python | `[python]`

The source mode strings are lowercase.

### line-break

    [br]

Note that `\n` is now preferred over `[br]`.

### Anchors

    [#named_anchor]

A named anchor is a hook that can be referenced by a link elsewhere in the document. You can then reference an anchor with `[link named_anchor Some link text]`. More on anchors here, here and here.

### Links

    [@http://www.boost.org this is [*boost's] website....]

will generate:

this is boost's website....

URL links where the link text is the link itself is common. Example:

    see http://spirit.sourceforge.net/

so, when the text is absent in a link markup, the URL is assumed. Example:

    see [@http://spirit.sourceforge.net/]

will generate:

see http://spirit.sourceforge.net/

### Anchor links

You can link within a document using:

    [link section_id.normalized_header_text The link text]

See sections Section and Headings for more info.

### refentry links

In addition, you can link internally to an XML refentry like:

    [link xml.refentry The link text]

This gets converted into `<link linkend="xml.refentry">The link text</link>`.

Like URLs, the link text is optional. If this is not present, the link text will automatically be the refentry. Example:

    [link xml.refentry]

This gets converted into `<link linkend="xml.refentry">xml.refentry</link>`.

### function, class, member, enum or header links

If you want to link to a function, class, member, enum or header in the reference section, you can use:

    [funcref fully::qualified::function_name The link text]
    [classref fully::qualified::class_name The link text]
    [memberref fully::qualified::member_name The link text]
    [enumref fully::qualified::enum_name The link text]
    [headerref path/to/header.hpp The link text]

Again, the link text is optional. If this is not present, the link text will automatically be the function, class, member or enum. Example:

    [classref boost::bar::baz]

would have "boost::bar::baz" as the link text.

### Escape

The escape mark-up is used when we don't want to do any processing.

    '''
    escape (no processing/formatting)
    '''

Escaping allows us to pass XML markup to BoostBook or DocBook. For example:

    '''
    <emphasis role="bold">This is direct XML markup</emphasis>
    '''

This is direct XML markup

Be careful when using the escape. The text must conform to BoostBook/DocBook syntax.

### Single char escape

The backslash may be used to escape a single punctuation character. The punctuation immediately after the backslash is passed without any processing. This is useful when we need to escape QuickBook punctuations such as `[` and `]`. For example, how do you escape the triple quote? Simple: `\'\'\'`

`\n` has a special meaning. It is used to generate line breaks. Note that `\n` is now preferred over `[br]`.

### Images (terminal)

    [$image.jpg]

## Block Level Elements

### Document

Every document must begin with a Document Info section, which should look like this:

    [document-type The Document Title
        [version 1.0]
        [id the_document_name]
        [dirname the_document_dir]
        [copyright 2000 2002 2003 Joe Blow, Jane Doe]
        [purpose The document's reason for being]
        [category The document's category]
        [authors [Blow, Joe], [Doe, Jane]]
        [license The document's license]
        [last-revision $Date: 2005/07/12 07:46:58 $]
        [source-mode source-type]
    ]

Where document-type is one of:

- book
- library
- part
- article
- chapter

and `version`, `id`, `dirname`, `copyright`, `purpose`, `category`, `authors`, `license`, `last-revision` and `source-mode` are optional information.

Here `source-type` is a lowercase string setting the initial source mode. If the `source-mode` field is omitted, a default value of `c++` will be used.

### Section

Starting a new section is accomplished with:

    [section:id The Section Title]

where id is optional. id will be the filename of the generated section. If it is not present, "The Section Title" will be normalized and become the id. Valid characters are `a-Z`, `A-Z`, `0-9` and `_`. All non-valid characters are converted to underscore and all upper-case are converted to lower case. Thus: "The Section Title" will be normalized to "the_section_title".

End a section with:

    [endsect]

Sections can nest, and that results in a hierarchy in the table of contents.

### xinclude

You can include another XML file with:

    [xinclude file.xml]

This is useful when file.xml has been generated by Doxygen and contains your reference section.

### Paragraphs

Paragraphs start left-flushed and are terminated by two or more newlines. No markup is needed for paragraphs. QuickBook automatically detects paragraphs from the context.

### Ordered lists

    # One
    # Two
    # Three

will generate:

1. One
2. Two
3. Three

### List Hierarchies

List hierarchies are supported. Example:

    # One
    # Two
    # Three
        # Three.a
        # Three.b
        # Three.c
    # Four
        # Four.a
            # Four.a.i
            # Four.a.ii
    # Five

will generate:

1. One
2. Two
3. Three
   1. Three.a
   2. Three.b
   3. Three.c
4. Fourth
   1. Four.a
      1. Four.a.i
      2. Four.a.ii
5. Five

### Long List Lines

Long lines will be wrapped appropriately. Example:

    # A short item.
    # A very long item. A very long item. A very long item.
      A very long item. A very long item. A very long item.
      A very long item. A very long item. A very long item.
      A very long item. A very long item. A very long item.
      A very long item. A very long item. A very long item.
    # A short item.

1. A short item.
2. A very long item. A very long item. A very long item. A very long item. A very long item. A very long item. A very long item. A very long item. A very long item. A very long item. A very long item. A very long item. A very long item. A very long item. A very long item.
3. A short item.

### Unordered lists

    * First
    * Second
    * Third

will generate:

- First
- Second
- Third

### Mixed lists

Mixed lists (ordered and unordered) are supported. Example:

    # One
    # Two
    # Three
        * Three.a
        * Three.b
        * Three.c
    # Four

will generate:

1. One
2. Two
3. Three
   - Three.a
   - Three.b
   - Three.c
4. Four

And...

    # 1
        * 1.a
            # 1.a.1
            # 1.a.2
        * 1.b
    # 2
        * 2.a
        * 2.b
            # 2.b.1
            # 2.b.2
                * 2.b.2.a
                * 2.b.2.b

will generate:

1. 1
   - 1.a
     1. 1.a.1
     2. 1.a.2
   - 1.b
2. 2
   - 2.a
   - 2.b
     1. 2.b.1
     2. 2.b.2
        - 2.b.2.a
        - 2.b.2.b

### Code

Preformatted code starts with a space or a tab. The code will be syntax highlighted according to the current source mode:

    #include <iostream>

    int main()
    {
        // Sample code
        std::cout << "Hello, World\n";
        return 0;
    }

    import cgi

    def cookForHtml(text):
        '''"Cooks" the input text for HTML.'''

        return cgi.escape(text)

Macros that are already defined are expanded in source code. Example:

    [def __syntax_highlight__ [@quickbook/highlight.html syntax_highlight]]
    [def __quickbook__ [@index.html quickbook]]

        using __quickbook__::__syntax_highlight__;

Generates:

    using quickbook::syntax_highlight;

### Preformatted

Sometimes, you don't want some preformatted text to be parsed as C++. In such cases, use the `[pre ... ]` markup block.

    [pre

        Some *preformatted* text                    Some *preformatted* text

            Some *preformatted* text            Some *preformatted* text

                Some *preformatted* text    Some *preformatted* text

    ]

Spaces, tabs and newlines are rendered as-is. Unlike all quickbook block level markup, pre (and Code) are the only ones that allow multiple newlines. The markup above will generate:

    Some preformatted text                    Some preformatted text

        Some preformatted text            Some preformatted text

            Some preformatted text    Some preformatted text

Notice that unlike Code, phrase markup such as font style is still permitted inside `pre` blocks.

### Blockquote

    [:sometext...]

> Indents the paragraph. This applies to one paragraph only.

### Headings

    [h1 Heading 1]
    [h2 Heading 2]
    [h3 Heading 3]
    [h4 Heading 4]
    [h5 Heading 5]
    [h6 Heading 6]

# Heading 1

## Heading 2

### Heading 3

#### Heading 4

##### Heading 5

### Heading 6

Headings 1-3 [h1 h2 and h3] will automatically have anchors with normalized names with `name="section_id.normalized_header_text"` (i.e. valid characters are `a-z`, `A-Z`, `0-9` and `_`. All non-valid characters are converted to underscore and all upper-case are converted to lower-case. For example: Heading 1 in section Section 2 will be normalized to `section_2.heading_1`). You can use:

    [link section_id.normalized_header_text The link text]

to link to them. See Anchor links and Section for more info.

### Macros

    [def macro_identifier some text]

When a macro is defined, the identifier replaces the text anywhere in the file, in paragraphs, in markups, etc. macro_identifier is a string of non- white space characters except ']' while the replacement text can be any phrase (even marked up). Example:

    [def sf_logo [$http://sourceforge.net/sflogo.php?group_id=28447&type=1]]
    sf_logo

Now everywhere the sf_logo is placed, the picture will be inlined.

It's a good idea to use macro identifiers that are distinguishable. For instance, in this document, macro identifiers have two leading and trailing underscores (e.g. `__spirit__`). The reason is to avoid unwanted macro replacement.

Links (URLS) and images are good candidates for macros. 1) They tend to change a lot. It is a good idea to place all links and images in one place near the top to make it easy to make changes. 2) The syntax is not pretty. It's easier to read and write, e.g. `__spirit__` than `[@http://spirit.sourceforge.net Spirit]`.

Some more examples:

    [def :-)            [$theme/smiley.png]]
    [def __spirit__     [@http://spirit.sourceforge.net Spirit]]

(See Images and Links)

Invoking these macros:

    Hi __spirit__  :-)

will generate this:

Hi Spirit

### Predefined Macros

Quickbook has some predefined macros that you can already use.

#### Predefined Macros

Macro | Meaning | Example
--- | --- | ---
__DATE__ | Today's date | 2005-Jul-12
__TIME__ | The current time | 03:44:57 PM
__FILENAME__ | Quickbook source filename | quickbook.qbk

### Blurbs

    [blurb :-) [*An eye catching advertisement or note...]\n\n
        __spirit__ is an object-oriented recursive-descent parser generator framework
        implemented using template meta-programming techniques. Expression templates
        allow us to approximate the syntax of Extended Backus-Normal Form (EBNF)
        completely in C++.
    ]

will generate this:

An eye catching advertisement or note... Spirit is an object- oriented recursive-descent parser generator framework implemented using template meta-programming techniques. Expression templates allow us to approximate the syntax of Extended Backus- Normal Form (EBNF) completely in C++.

### Tables

    [table A Simple Table
        [[Heading 1] [Heading 2] [Heading 3]]
        [[R0-C0]     [R0-C1]     [R0-C2]]
        [[R1-C0]     [R1-C1]     [R1-C2]]
        [[R2-C0]     [R2-C1]     [R2-C2]]
    ]

will generate:

#### A Simple Table

Heading 1 | Heading 2 | Heading 3
--- | --- | ---
R0-C0 | R0-C1 | R0-C2
R2-C0 | R2-C1 | R2-C2
R3-C0 | R3-C1 | R3-C2

The first row of the table is automatically treated as the table header; that is, it is wrapped in `<thead>...</thead>` XML tags. Note that unlike the original QuickDoc, the columns are nested in [ cells... ]. The syntax is free-format and allows big cells to be formatted nicely. Example:

    [table Table with fat cells
        [[Heading 1] [Heading 2]]
        [
            [Row 0, Col 0: a small cell]
            [
                Row 0, Col 1:
                A very big cell...A very big cell...A very big cell...
                A very big cell...A very big cell...A very big cell...
                A very big cell...A very big cell...A very big cell...
            ]
        ]
        [
            [Row 1, Col 0: a small cell]
            [Row 1, Col 1: a small cell]
        ]
    ]

and thus:

#### Table with fat cells

Heading 1 | Heading 2
--- | ---
Row 0, Col 0: a small cell | Row 0, Col 1: A very big cell...A very big cell...A very big cell... A very big cell...A very big cell...A very big cell... A very big cell...A very big cell...A very big cell...
Row 1, Col 0: a small cell | Row 1, Col 1: a small cell

### Variable Lists

    [variablelist A Variable List
        [[term 1] [The definition of term 1]]
        [[term 2] [The definition of term 2]]
        [[term 3] [The definition of term 3]]
    ]

will generate:

A Variable List

term 1
  The definition of term 1
term 2
  The definition of term 2
term 3
  The definition of term 3

The rules for variable lists are the same as for tables, except that only 2 "columns" are allowed. The first column contains the terms, and the second column contains the definitions. Those familiar with HTML will recognize this as a "definition list".

| Copyright © 2002, 2004 Joel de Guzman, Eric Niebler