![]() |
Home | Libraries | People | FAQ | More |
Every document must begin with a Document Info section, which should look like this:
[document-type The Document Title
[quickbook 1.3]
[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]
[source-mode source-type]
]
Where document-type is one of:
quickbook 1.3 declares the version of quickbook the document is written for. In its absence, version 1.1 is assumed.
version, id, dirname, copyright, purpose, category, authors, license, last-revision and source-mode are optional information.
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.
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.
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 start left-flushed and are terminated by two or more newlines. No markup is needed for paragraphs. QuickBook automatically detects paragraphs from the context. Block markups [section, endsect, h1, h2, h3, h4, h5, h6, blurb, (block-quote) ':', pre, def, table and include ] may also terminate a paragraph.
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:
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.
Mixed lists (ordered and unordered) are supported. Example:
# One
# Two
# Three
* Three.a
* Three.b
* Three.c
# Four
will generate:
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:
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;
Inside code, code blocks and inline code, QuickBook does not allow any markup to avoid conflicts with the target syntax (e.g. c++). In case you need to switch back to QuickBook markup inside code, you can do so using a language specific escape-back delimiter. In C++ and Python, the delimiter is the double tick (back-quote): "``" and "``". Example:
void ``[@http://en.wikipedia.org/wiki/Foo#Foo.2C_Bar_and_Baz foo]``()
{
}
Will generate:
void foo() { }
When escaping from code to QuickBook, only phrase level markups are allowed. Block level markups like lists, tables etc. are not allowed.
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.
[note This is a note] [tip This is a tip] [important This is important] [caution This is a caution] [warning This is a warning]
generates DocBook admonitions:
![]() |
Note |
|---|---|
This is a note | |
![]() |
Tip |
|---|---|
This is a tip | |
![]() |
Important |
|---|---|
This is important | |
![]() |
Caution |
|---|---|
This is a caution | |
![]() |
Warning |
|---|---|
This is a warning | |
These are the only admonitions supported by DocBook. So, for example [information This is some information] is unlikely to produce the desired effect.
[h1 Heading 1] [h2 Heading 2] [h3 Heading 3] [h4 Heading 4] [h5 Heading 5] [h6 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.
In cases when you don't want to care about the heading level (1 to 6), you can use the Generic Heading:
[heading Heading]
The Generic Heading assumes the level, plus one, of the innermost section where it is placed. For example, if it is placed in the outermost section, then, it assumes h2.
Headings are often used as an alternative to sections. It is used particularly if you do not want to start a new section. In many cases, however, headings in a particular section is just flat. Example:
[section A] [h2 X] [h2 Y] [h2 Z] [endsect]
Here we use h2 assuming that section A is the outermost level. If it is placed in an inner level, you'll have to use h3, h4, etc. depending on where the section is. In general, it is the section level plus one. It is rather tedious, however, to scan the section level everytime. If you rewrite the example above as shown below, this will be automatic:
[section A] [heading X] [heading Y] [heading Z] [endsect]
They work well regardless where you place them. You can rearrange sections at will without any extra work to ensure correct heading levels. In fact, with section and heading, you have all you need. h1..h6 becomes redundant. h1..h6 might be deprecated in the future.
[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 ']'. A macro may not follow an alphabetic character or the underscore. 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.
![]() |
Tip |
|---|---|
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]]
Invoking these macros:
Hi __spirit__ :-)
will generate this:
Hi Spirit
Quickbook has some predefined macros that you can already use.
Templates provide a more versatile text substitution mechanism. Templates come in handy when you need to create parameterizable, multi-line, boilerplate text that you specify once and expand many times. Templates accept one or more arguments. These arguments act like place-holders for text replacement. Unlike simple macros, which are limited to phrase level markup, templates can contain block level markup (e.g. paragraphs, code blocks and tables).
Example template:
[template person[name age what] Hi, my name is [name]. I am [age] years old. I am a [what]. ]
Template identifiers can either consist of:
Template formal arguments are identifiers consisting of an initial alphabetic character or the underscore, followed by zero or more alphanumeric characters or the underscore. This is similar to your typical C/C++ identifier.
A template formal argument temporarily hides a template of the same name at the point where the template is expanded. Note that the body of the person template above refers to name age and what as [name] [age] and [what]. name age and what are actually templates that exist in the duration of the template call.
The template body can be just about any QuickBook block or phrase. There are actually two forms. Templates may be phrase or block level. Phrase templates are of the form:
[template sample[arg1 arg2...argN] replacement text... ]
Block templates are of the form:
[template sample[arg1 arg2...argN] replacement text... ]
The basic rule is as follows: if a newline immediately follows the argument list, then it is a block template, otherwise, it is a phrase template. Phrase templates are typically expanded as part of phrases. Like macros, block level elements are not allowed in phrase templates.
You expand a template this way:
[template_identifier arg1..arg2..arg3]
At template expansion, you supply the actual arguments. The template will be expanded with your supplied arguments. Example:
[person James Bond..39..Spy] [person Santa Clause..87..Big Red Fatso]
Which will expand to:
Hi, my name is James Bond. I am 39 years old. I am a Spy.
Hi, my name is Santa Clause. I am 87 years old. I am a Big Red Fatso.
![]() |
Caution |
|---|---|
A word of caution: Templates are recursive. A template can call another template or even itself, directly or indirectly. There are no control structures in QuickBook (yet) so this will always mean infinite recursion. QuickBook can detect this situation and report an error if recursion exceeds a certain limit. | |
Each actual argument can be a word, a text fragment or just about any QuickBook phrase. Arguments are separated by the double dot ".." and terminated by the close parenthesis.
Nullary templates look and act like simple macros. Example:
[template spirit[] [@http://spirit.sf.net Spirit]]
Expanding:
Please see [spirit]'s site.
We have:
Please see Spirit's site.
The difference with macros are
The empty brackets after the template identifier (spirit[]) indicates no arguments. If the template body does not look like a template argument list (the example above does), we can elide the empty brackets. Example:
[template aristotle_quote Aristotle: [*['Education is the best provision for the journey to old age.]]]
Expanding:
Here's a quote from [aristotle_quote].
We have:
Here's a quote from Aristotle: Education is the best provision for the journey to old age..
As mentioned, arguments are separated by the double dot "..". If there are less arguments passed than expected, QuickBook attempts to break the last argument into two or more arguments following this logic:
For example:
[template simple[a b c d] [a][b][c][d]] [simple w x y z]
will produce:
wxyz
"w x y z" is initially treated as a single argument because we didn't supply any ".." separators. However, since simple expects 4 arguments, "w x y z" is broken down iteratively (applying the logic above) until we have "w", "x", "y" and "z".
QuickBook only tries to get the arguments it needs. For example:
[simple w x y z trail]
will produce:
wxyz trail
The arguments being: "w", "x", "y" and "z trail".
It should be obvious now that for simple arguments with no spaces, we can get by without separating the arguments with ".." separators. It is possible to combine ".." separators with the argument passing simplification presented above. Example:
[simple what do you think ..m a n?]
will produce:
what do you think man?
With templates, one of our objectives is to allow us to rewrite QuickBook in QuickBook (as a qbk library). For that to happen, we need to accommodate single character punctuation templates which are fairly common in QuickBook. You might have noticed that single character punctuations are allowed as template identifiers. Example:
[template ![bar] <hey>[bar]</hey>]
Now, expanding this:
[!baz]
We will have:
<hey>baz</hey>
[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++.
![]() |
Note |
|---|---|
Prefer admonitions wherever appropriate. | |
[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:
The table title is optional. 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:
| 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 |
Here's how to have preformatted blocks of code in a table cell:
[table Table with code
[[Comment] [Code]]
[
[My first program]
[``
#include <iostream>
int main()
{
std::cout << "Hello, World!" << std::endl;
return 0;
}
``]
]
]
[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
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".
You can include one QuickBook file from another. The syntax is simply:
[include someother.qbk]
The included file will be processed as if it had been cut and pasted into the current document, with the following exceptions:
The [include] directive lets you specify a document id to use for the included file. When this id is not explicitly specified, the id defaults to the filename ("someother", in the example above). You can specify the id like this:
[include:someid someother.qbk]
All auto-generated anchors will use the document id as a unique prefix. So for instance, if there is a top section in someother.qbk named "Intro", the named anchor for that section will be "someid.intro", and you can link to it with [link someid.intro The Intro].
| Copyright © 2002, 2004 Joel de Guzman, Eric Niebler |