[/
Copyright 2002,2004,2006 Joel de Guzman, Eric Niebler
Copyright 2010-2011 Daniel James
Distributed under the Boost Software License, Version 1.0.
(See accompanying file LICENSE_1_0.txt or copy at
http://www.boost.org/LICENSE_1_0.txt)
]
[chapter Language Versions
[quickbook 1.6]
[compatibility-mode 1.5]
[id quickbook.versions]
[source-mode teletype]
]
[section:stable Stable Versions]
Since quickbook 1.3 the `quickbook` attribute in the document block selects
which version of the language to use. Not all changes to quickbook are
implemented using a version switch, it's mainly just the changes that change
the way a document is interpreted or would break existing documentation.
[heading Quickbook 1.3 and later]
* Introduced quickbook language versioning.
* In the documentation info, allow phrase markup in license and purpose
attributes.
* Fully qualified section and headers. Subsection names are concatenated to the
ID to avoid clashing. Example: `doc_name.sect_name.sub_sect_name.sub_sub_sect_name`.
[heading Quickbook 1.5 and later]
* Ignore template argument separators inside square brackets.
* Don't separate the final template argument if the `..` separator was
used. i.e. never mix `..` and whitespace separators.
* Statically scope templates and their arguments rather than dynamically
scope them.
* Give table ids, and let you set them.
* Allow spaces between the `:` character and ids in elements which can
have ids.
[endsect]
[section:1_6 Quickbook 1.6]
Everything described in here may change depending on the feedback received.
[section:docinfo Includes with docinfo]
In quickbook 1.5 if you include a file which starts with a docinfo block, it's
ignored and the file is expanded in place. In quickbook 1.6 it's treated as a
document nested in the current position. So if it has an 'article' docinfo block,
boostbook 'article' tags are used.
It also mostly generates the same markup as if the file was converted separately -
so for example, the same ids are generated, the document is processed using the
language version specified in the docinfo block. If no language is specified it
uses the default (1.1) not the version of the document that included it. This
might seem surprising, but is requried so that quickbook will convert it the same
way as if it was converted separately.
So for the most part, includes with a docinfo are like an `xinclude`, apart from
a couple of differences. Templates and macros defined in the parent document are
used in the included document, and the id generator rewrites ids that clash
between multiple documents.
If an included document doesn't have a docinfo block, it's just included as
before.
[endsect] [/docinfo]
[section:doc_info_macros Macros in docinfo block]
You can now expand macros in text fields in the docinfo block. In the top
docinfo block only the predefined macros are available, but in nested documents
macros defined in the parent document are also available.
There's a small bug here - this leaks into older versions for the `license`
and `purpose` fields, but since only the predefined macros are available, it's
unlikely to break any existing documents. So I'd rather not complicate the code
further by fixing that.
[endsect]
[section:scope Scoping templates and macros]
A long standing quickbook bug is that macros are scoped by file, but templates
aren't. So you can define templates in a separate file and include them, but not
macros. This has been fixed so that templates defined in one file won't 'leak'
into another.
But this means there's no way to define templates in a separate file - a useful
feature. To do this the `import` element has been adapted to also support
quickbook files. If a quickbook file is imported, the templates and macros
defined in it are added to the current scope, but nothing else contained in that
file is used. This could be used to create template and macro library files.
This matches the existing semantics of importing code snippets.
When importing templates, they're bound to the language version of the file
they were defined in. This means that if you import them into a file with
a different version it won't change the way they're interpreted. Although,
as we'll see [link compatibility later], the generated boostbook is slightly
different.
[endsect] [/scope]
[section:include Including C++ and python files]
As `import` now supports quickbook files, `include` also supports source files.
It includes any quickbook contained in comments outside of code snippets.
Code snippets in the file are available to be expanded within the file but
are scoped to the file. In exactly the same manner as when templates and macros
are scoped in an included quickbook file.
[endsect] [/include]
[section:ids Id Generation]
Id generation in quickbook 1.5 is a bit buggy, but that can't be fixed without a
version switch as it will break existing documents. For example in quickbook 1.5
when you include a quickbook file, it stops using the explicit id from the
documentation info and generates a new id from the document title to use instead.
The id generator in quickbook 1.6 has been improved in some other ways to. When
generating ids from section titles, table titles etc. it always uses the
quickbook source rather than the generated boostbook to generate the id. It then
cleans up the id slightly, trimming leading and trailing underscores and replacing
multiple underscores with a single underscore. Then if the newly generated part
of the id is longer than 32 characters it truncates it.
While the new id generator generally creates better ids, it's more likely to
generate duplicates so quickbook needs to handle duplicates better. When there
are multiple identical ids, quickbook chooses one to use based on a priority
list - anchors are preferred, then explicit document and section ids, then other
explicit ids, followed by the generated ids. Then any other explicit ids in the
document have numbers added to avoid duplicates - first the explicit ids in the
order they appear and then the generated ids. A generated id which accidentally
clashes with an explicit id should never change the explicit id.
Older language versions still generate the same ids they always have, with the
exception of duplicate ids which are handled using the new mechanism - this
is not a breaking change since duplicate ids can't be linked to.
[endsect] [/ids]
[#compatibility]
[section:compatibility Compatibility Mode]
As mentioned before, changing the id generator will break links in documents
written using an old language version. So to ease the transition a
'compatibility mode' is used, this just requires an extra attribute in the
docinfo, for example if you're converting a 1.5 document to 1.6:
[article Document
[quickbook 1.6]
[compatibility-mode 1.5]
]
This means the document will be parsed as 1.6, using all the new features, but
ids (and possibly other markup) will generated as they were for a 1.5 document.
Compatibility mode is also implicitly used when generating templates written
in a different language version to the current document. So the template is
parsed in the version it was written for, but generates boostbook that's
compatible with the current document.
[endsect] [/compatibility]
[section:version Version info outside of document info block]
Can now use `quickbook` and `compatibility-mode` tags at the beginning of the
file. Either before or without a document info block. This is useful for
files just containing templates, which don't really need a document info
block.
If you don't specify `compatibility-mode`, the behaviour depends on whether or
not you have a docinfo block. If you do it uses the file's quickbook version,
if you don't it inherits the parent's compatibility mode even if you specify
a quickbook version. This is the right thing to do - mixing compatibility modes
within documents is problematic. It might actually be a mistake to allow them
to specified outside docinfo blocks.
This change is also backdated to older versions. So when including from an
older version, the included file's version can be set (older versions
ignore document info in included files).
[endsect]
[section:heading_ids Explicit Heading Ids]
Headings can now be given explicit ids:
[heading:id A heading with an explicit id]
[endsect] [/heading_ids]
[section:escapes Punctuation changes]
In 1.6, quickbook is more consistent about how it parses punctuation.
Escapes are now supported in links, anchors, table titles, image
attributes etc. The flip side of this is that quickbook is now stricter
about unescaped brackets. They can still be used, but need to match up,
otherwise there's an error.
Since quickbook now matches up square brackets it will fix some
mis-parses. For example `[*[bold]]` used to parse as [*\[bold]\] - note
that the closing square bracket isn't bold, now it parses as
[*\[bold\]]. In this case it's just a subtle visual difference, but it
could cause odd problems, for example when nested in a table cell.
[endsect] [/escapes]
[section:table Table Titles]
Table titles are now parsed as phrases, so some markup is allowd:
[table [*bold title]]
Which is an empty table with a bold title. The title is no longer ended
by a newline, but by either a closing square bracket, or two opening
square brackets - which you get at the start of the table cells, so
this now works:
[table Simple[[heading 1][heading 2]][[cell 1][cell 2]]]
[endsect] [/table]
[section:xmlbase XML base]
A problem when using `xi:include` tags in escaped boostbook is that you
typically don't know which directory the boostbook file will be in, so
it's impossible to use relative links. This can be fixed by adding an
`xml:base` attribute to the document tag. To do this use the new
`xmlbase` attribute in your document's docinfo block. For example to
make escaped `xi:include`s be relative to the directory of the file:
[library Library documentation
[quickbook 1.6]
[xmlbase .]
]
Any paths in `xinclude` elements will be rewritten accordingly. Note that
most documents won't need this, and probably shouldn't use it. Only use it
if you're totally sure that you will need it.
[endsect] [/xmlbase]
[section:elements New Elements]
[section:block `block`]
`block` is a block element that just marks its contents as a block,
so that they aren't wrapped in paragraph tags. The main use is
for escaped docbook block tags, such as:
[template chapter[title]
[block''''''[title]'''''']
]
[template chapterend
[block'''''']
]
[chapter An example chapter]
Content
[chapterend]
Without the `block` element, the `chapter` and `chapterend` templates
would be wrapped in paragraph tags.
[note In this example, the template body has to start with a newline so that
the template will be interpreted in block mode.]
[endsect]
[section:lists `ordered_list` and `itemized_list`]
These are used as an alternative to the normal wiki-style markup for
lists. They make it easier to nest lists inside other elements, and
nest elements inside lists. The markup is similar to a single level
table:
[ordered_list [item1][item2]]
is equivalent to:
# item1
# item2
[endsect]
[section:role `role`]
`role` is a phrase element used to mark up the text in the eventual html
with an a class. For example:
[role red Text content]
Will generate the docbook:
Text content
Which will generate html along the lines of:
Text content
And then you can use css to style this however you wish.
[endsect]
[endsect]
[section:listparagraphs Pargraphs in lists]
I'm still refining this, but paragraphs and block elements can now be used
in lists:
[pre
* Para 1
Para 2
* Nested Para 1
Nested Para 2
Code block
Para 3
]
generates:
* Para 1
Para 2
* Nested Para 1
Nested Para 2
Code block
Para 3
The docbook markup that this generates is pretty bad, but seems to create okay
html.
[endsect]
[endsect] [/ Quickbok 1.6]
[section:1_7 Quickbook 1.7]
[section:source_mode Source mode for single entities]
1.7 introduces a new `!` element type for setting the source mode of a single
entity without changing the source mode otherwise. This can be used for
code blocks and other elements. For example:
```
[!c++]
void foo() {};
[!python]``\`\`\`\ ``def foo():``\`\`\`\ ``
```
It can also be used to set the source mode for elements:
```
[!teletype][table
[[code][meaning]]
[[`+`][addition]]
]
```
When used a section, it's only set for the section element, not the
whole section.
Currently it does support other syntactic entities such as paragraphs
and lists. I'm not sure if it would be a good idea.
[endsect]
[section:callouts Callouts in code block]
Currently callouts can only be used in code snippets. 1.7 add
support in normal code blocks. The same syntax is used as in
code snippets, the callout descriptions appear immediately
after the code block.
[endsect]
[section:escaped_docinfo_attributes Escaped docbook in docinfo blocks]
Quickbook docinfo attributes will probably never be as rich as docbook
attributes so to allow more flexible markup, not supported by quickbook
escaped docbook can be included in the docinfo block:
```
[article Some article
[quickbook 1.7]
'''
John
Doe
john.doe@example.com
'''
]
```
The escaped docbook is always placed at the end of the docinfo block,
so it shouldn't be assumed that it will interleave the markup. A mixture
of quickbook and docbook attributes for the same information will not work
well.
[endsect] [/escaped_docinfo_attributes]
[section:templates_in_link_values Templates in link values]
There's very premilinary support for calling templates in link values. A lot
more work needs to be done, including:
* Considering other places where templates could be called (e.g. images are
quite tricky, as templates could get confused with attributes, should
templates be callable from something like an element's id?).
* Trimming spaces from the body of the template (which can cause surprising
results).
* Checking that the contents of the template are appropriate for the context.
Possibly even using a different grammar.
[endsect] [/templates_in_link_values]
[endsect] [/ Quickbok 1.7]