Function fp:replace-element#5($array as array(*), $elemno as xs:integer, $count as xs:integer, $new-elem as item()*, $newarray as array(*)) as array(*) ♻
Function fp:replace-element#5($array as array(*), $elemno as xs:integer, $count as xs:integer, $new-elem as item()*, $newarray as array(*)) as array(*) ♻
\ No newline at end of file
diff --git a/guide/2.2.2/ackno.html b/guide/2.2.2/ackno.html
new file mode 100644
index 0000000000..60b10aaf93
--- /dev/null
+++ b/guide/2.2.2/ackno.html
@@ -0,0 +1,15 @@
+Acknowledgements
Acknowledgements
+
+
+
I’d like to thank The Academy, the…no, wrong event.
+
+
DocBook has benefited immeasurably by the time and energy that
+innumerable people have poured into it. I thank them all.
+
+
This project has benefited from the generous support of
+Michael Kay and Saxonica for Saxon EE and
+Micheal Miller and Antenna House for Antenna House Formatter.
+
+
+
Bethan Tovey-Walsh designed the lovely xslTNG logo.
+
\ No newline at end of file
diff --git a/guide/2.2.2/ch-building.html b/guide/2.2.2/ch-building.html
new file mode 100644
index 0000000000..afc4deb1b3
--- /dev/null
+++ b/guide/2.2.2/ch-building.html
@@ -0,0 +1,153 @@
+Chapter 6. Building the stylesheetsDocBook xslTNG Reference
Chapter 6. Building the stylesheets
If you wish, you can also clone the distribution and build them
+yourself. The distribution is designed to be self contained. In a Unix
+or Mac environment, running:
+
./gradlew dist
+will build the stylesheets. Building will:
Compile the stylesheets and run the unit tests. The compiled stylesheets
+will be available in build/xslt.
+
Running all the tests requires building the reference guide and
+a few other things. You can build the stylesheets without running any
+of the tests with the makeXslt task.
Compile the extension functions. The compiled extension functions will be
+available in build/libs. The jar task
+will compile the extensions without running the tests.
+
“Compile” the Python script that helps run
+the stylesheets. (It’s not really compiled, but several stylesheet-version-specific
+strings are interpolated.)
+The copyBin task will setup the Python script
+without running the tests.
+
☝
Important
In principle, it should be possible to build the stylesheets on
+Windows. In practice, it isn’t entirely
+reliable. It has been much improved as of version 2.1.4, but still
+fails randomly on some Windows machines, but not others. It may be
+more expedient to build in the Linux subsystem on Windows 10 or in a
+Docker container.
+
6.1. Prerequisites
In order to build the stylesheets, you must configure your
+system with several prerequisites:
Gradle. The stylesheet
+builds use the
+Gradle wrapper to assure a consistent environment across systems, it’ll
+be downloaded automatically the first time you build.
+
A modern version of Java. (Java 1.8 or later, for example.)
+
Python 3 and
+the click module.
+The Pygmentize program is also
+required for syntax highlighting, though that’s not technically a build requirement.
+
If you discover other prerequisites that have been overlooked,
+or have questions or suggestions about how best to manage them, please
+let us know.
6.2. Repository structure
The most significant parts of the repository hierarchy are:
These are the sources for the stylesheets themselves. The
+transform subdirectory contains the preprocessing
+stylesheets that are run as separate transforms. The
+modules directory doesn’t have any special significance, it
+just makes the main entry points easier to find.
You cannot run the XSLT stylesheets directly from the source
+location. You must build them first with the
+makeXslt build target.
The local-10 directory holds copies of the
+localization files from the XSLT 1.0 stylesheets. They’re transformed
+into the locale versions by the build system. This whole
+area is one that needs work.
These are the testing resources. You cannot run the XSpec tests
+directly from src/test/xspec. The build system copies them into
+build/xspec along with a few XSpec tests generated
+automatically by the stylesheets in generators.
+
The library of DocBook documents that are used for testing is
+stored in the xml directory. The HTML files in
+expected correspond to the expected results. The expected
+results aren’t usefully viewed in a browser. Only the
+body element and its
+decendants are stored in the expected results. This avoids a lot of
+noise in the
+head.
These are the sources, resources, and ancillary files for the
+reference guide and the website.
|tools
+
The tools directory holds a number of stylesheets and other scripts used
+by the build process.
|lib
+
The lib directory holds third party jar files. This is also where
+you can put your Saxon PE or EE files if you have them.
|build
+|build/actual
+|build/xslt
+
The build system puts all of its temporary files under build. It’s
+always safe to delete the entire directory and start over, though it will require internet
+access and it may take a while.
Test files that you format are published to
+build/actual and the images, CSS, and JavaScript resources
+are copied under there so that everything will look right in the
+browser. For security reasons, some JavaScript features may not work
+if you are looking at the documents from the filesystem. You can work
+around this by pointing a local web server at the build directory.
The built stylesheets are in build/xslt. You can run
+them directly from there.
6.3. Build configuration
Several build properties are defined in gradle.properties.
+
verbose
If true, enables additional messages in the extension functions.
requireCompileSuccess
If true, the build will fail if there are any errors building the stylesheets.
requireTestSuccess
If true, the build will fail if any tests fail.
xspecVersion
The version of XSpec.
xsltExplorerVersion
The version of XSLT Explorer.
pdftool
Select a tool for formatting PDFs. Expected values are antennahouse
+or prince.
antennahouse
The path to the Antenna House Formatter.
prince
The path to the Prince formatter.
There are four additional properties that are used by the
+dbtransform target. This target allows you to process arbitrary
+documents with the stylesheets. It takes care of loading all of the extension functions.
dbsource
The URI of the source document.
dboutput
The path for outputting the principle result document.
dbstyle
The URI of the base stylesheet, defaults to the main DocBook xslTNG stylesheet.
dbparams
Stylesheet parameters.
You can change these variables in your local version of gradle.properties,
+or you can specify them on the command line. For example, to enable verbose
+processing, pass -Pverbose=true on the Gradle command line.
6.4. Build tasks
The build system is Gradle. Gradle’s
+processing model operates in several phases, this allows an initial
+configuration phase to construct build targets (called tasks)
+dynamically. The DocBook xslTNG Stylesheets
+build script uses this facility quite a bit.
In the discussion that follows, testdoc is the
+base name of a test document, that is, one of the example files from the
+src/test/resources/xml directory. For example, one of the test documents
+is src/test/resources/xml/article.001.xml. In the build
+targets that would be the “testdoc” article.001.
+In an analogous way, “testset” is the root name of an XSpec test file in
+src/test/xspec.
The most important tasks are:
makeXslt
This tasks “compiles” the stylesheets into build/xslt.
+
report
This task runs all of the tests and generates a unified report in
+build/report. This is the default task.
+
test
Runs the test suite against the stylesheets.
+
jar
Compiles the extension functions and creates the jar file in
+build/libs.
+
dist
Builds an archive in build/distributions suitable for distribution.
+
guide
Builds the reference guide.
+
website
Builds the website.
+
explorer
Generates the XSLT Explorer
+report for the stylesheets in
+build/explorer.
+
helloWorld
A smoke test target. It just prints a message, but doing so will exercise
+a bunch of the build machinery in Gradle.
+
6.5. Testing tasks
The way tests are managed was completely refactored in version 2.0.13. The new
+system is largely automatic.
Create a new test document in src/test/resources/xml. For this
+example, we’ll create para.003.xml, an example of a sidebar
+in a para.
+
Use the build target para.003.html to format the document.
+This build target (and several others) exist automatically because the source file has
+been created.
Inspect the results (in build/actual/para.003.html) and adjust
+the stylesheets until you are satisfied that the results are correct. Each time you make a
+stylesheet change, you can re-run the para.003.html target to
+rebuild the output.
When you are satisified, run param.003.expected to
+update the expected results.
Run the report target to make sure no other tests have broken
+as a result of your changes.
More generally, the following targets exist for any source document in
+src/test/resources/xml:
testdoc.html
Formats testdoc into HTML and stores the result
+in build/actual where it can be viewed in the browser with the appropriate
+CSS, JavaScript, images, etc.
+
testdoc.expected
Formats testdoc into HTML and stores the result
+in src/test/resources/expected. You should only run this
+task when you’ve made a change and determined that the new results are correct and should
+replace the previously expected results.
+
testdoc.pdf.html
Formats testdoc into HTML suitable
+for paged media and stores the result in build/actual.
+
testdoc.pdf
The .pdf target will generate the
+.pdf.html output and then attempt to transform it into PDF
+with either AntennaHouse or PrinceXML. Additional configuration may be
+necessary to get this to work.
+
testdoc.chunk
Formats testdoc into HTML with chunking turned
+on. The result is stored in index.html and other files
+in build/actual. No attempt is made to avoid having
+the output files from different documents overwrite each other. At the moment,
+none of the automated tests create chunked output.
+
testset.xspec
Runs the testset set of XSpec tests.
+The test sets that are available are the sets constructed from build environments and
+the sets created by hand (in src/test/xspec).
+
6.6. Running XSpec
In order to get consistent results across different runs and in different
+environments, the XSpec tests run a driver stylesheet, xspec-driver.xsl.
+
Note also that the XSpec shell script is modified by the stylesheets.
Chapter 5 . Implementation details
Appendix A . Changes in version 2.x
\ No newline at end of file
diff --git a/guide/2.2.2/ch-customizing.html b/guide/2.2.2/ch-customizing.html
new file mode 100644
index 0000000000..b2382b9087
--- /dev/null
+++ b/guide/2.2.2/ch-customizing.html
@@ -0,0 +1,787 @@
+Chapter 3. Customizing the stylesheetsDocBook xslTNG Reference
Chapter 3. Customizing the stylesheets
In many circumstances, the stylesheets can be used “out of the
+box” without any customization. But sometimes you may need to change
+the formatting of certain elements. One common reason is to change the
+formatting of title pages or navigational features. In other cases, it
+may be to support local extensions to DocBook or simply to change the
+markup to support a particular use case.
Three approaches are possible, with increasing degrees of
+effort: changing stylesheet parameters, creating your own
+customization layer, or making broader changes to the stylesheet’s
+implementation.
The subject of broader implementation changes is the subject of
+Chapter 5, Implementation details. In this chapter, we’ll look at the
+easier options.
3.1. Changing stylesheet parameters
The DocBook xslTNG Stylesheets define a
+lot of parameters. They are all described in I. Parameter reference.
+If the change you want to make has already been parameterized, you may
+be able to achieve your goal simply by setting a parameter at runtime.
For example, if you want to change the formatting of dates and times
+in date elements, you can simply change the
+date and time formatting
+parameters. Similarly, if you want to change the numeration style of
+ordered lists, you can simply change the ordered list item
+numeration parameter.
These changes can be accomplished by simply passing the new
+values to the processor, on the command line or in a configuration
+file, for example. You do not have to write any XSLT to make these
+changes.
Parameter values apply to the entire document processed by the
+stylesheets. In some cases, you may wish to change the presentation of
+just one or small number of elements. This can often be accomplished
+with a db processing instruction in
+the source document itself. These customizations can also be
+accomplished without writing any XSLT.
If you want to make a change that isn’t supported by a
+parameter, or an ad hoc exception that doesn’t have a supporting
+processing instruction, you will have to write a customization layer.
+(You are invited to submit an issue with your use case if you think it
+would be of general interest.)
+
You may also find it convenient to write a customization layer
+if you want to change several parameters and you find it inconvenient
+to pass them all to the processor on every invocation.
+
3.2. Creating a customization layer
A customization layer is simply an XSLT stylesheet that you
+write which extends the DocBook stylesheets. The simplest* customization
+layer is:
1 |<?xml version="1.0" encoding="utf-8"?>
+|<xsl:stylesheet
+|xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+|xmlns:db="http://docbook.org/ns/docbook"
+ 5 |xmlns:xs="http://www.w3.org/2001/XMLSchema"
+|xmlns="http://www.w3.org/1999/xhtml"
+|exclude-result-prefixes="db xs"
+|version="3.0">
+|
+10 |<!-- This href has to point to your local copy
+| of the stylesheets. -->
+|<xsl:importhref="docbook/xslt/docbook.xsl"/>
+|
+|</xsl:stylesheet>
+
This customization doesn’t do anything. But you can, for example, redefine
+parameters if you wish:
This will have the effect of running the DocBook stylesheets with those two
+parameters set as specified.
If you want to change the HTML output for an element, you can write a template
+for that element in your customization layer. Consider this DocBook document:
+
Suppose that you decided you wanted to have the
+productname element link automatically to the vendor
+webpage.
☝
Important
The DocBook xslTNG Stylesheets process
+all DocBook elements in the
+m:docbook mode. This is different from previous XSLT stylesheets for DocBook
+which simply used the default mode.
You must either specify a default mode in your customization layer
+or remember to specify the mode on match templates and template applications.
+If you forget the mode, you’ll get unexpected results!
One way to do that would be to redefine the template that processes the
+productname element:
I repeat, all of the DocBook elements are processed in the
+“m:docbook” mode. I expect that failure to declare this mode is going to be a common
+error.
Yes, this whole listing is rather cramped.
+I’m trying to make it all narrow
+enough to fit in the display without making horizontal scrolling necessary.
+
Calling xsl:next-match invokes the underlying
+processing. The effect of this template is to wrap an HTML
+“a” around the default processing for
+productname.
It’s worth pointing out that if the tag has an
+xlink:href attribute, that will generate an HTML
+a as well. A more robust stylesheet would check for that,
+but I’m trying to keep the example simple.
3.3. Managing CSS stylesheets
The HTML that the DocBook xslTNG stylesheets
+produce is intended to be clean, robust markup for styling with CSS.
+Exactly how you control which stylesheet links are produced has
+changed several times. The current scheme is this:
If $use-docbook-cssis true,
+links to the standard DocBook stylesheets are included. Those stylesheets
+are docbook.css (for all media),
+docbook-screen.css (for screen media), and
+docbook-page-setup.css and
+docbook-paged.css (for print media).
+
The DocBook element that is the context element when the HTML
+head is being
+generated is processed in the m:html-head-links mode.
+By default, that template does nothing, but you can change that in
+a customization layer.
If any CSS stylesheets are defined in
+$user-css-links, they are included.
+
The DocBook element that is the context element when the HTML
+head is being
+generated is processed in the m:html-head-last mode.
+By default, that template does nothing, but you can change that in
+a customization layer.
3.4. Customizing title pages
All of the titled elements (books, chapters, sections, etc.) have “title pages”. That is,
+they have a
+header element that contains the
+elements from the info that should be presented in the title header.
+In practice, info is a wrapper for general metadata about the element and
+often contains many elements that shouldn’t be presented.
There’s so much variation both in what goes in the
+info elements and in what users need to have in the title header, that
+there’s no practical way to control it simply with stylesheet parameters.
Instead the stylesheets offer two customization mechanisms: first, each header is formed
+from a header template. You can change the titlepage template in your
+customization layer.
For example, the default titlepage template for chapter headers is:
The tmp:apply-templates elements aren’t as sophisticated as
+XSLT templates, but they let you select parts of the document. If nothing is
+selected, the content is ignored. When the title page template is evaluated, the context
+item is the info element.
Inside the tmp:apply-templates, you can decide what HTML markup should
+appear. The
+tmp:content element will be replaced by the result of processing
+the element or elements you selected.
As a consequence of that template, a chapter title page contains the
+chapter title in an h2 and
+the subtitle in an h3. No
+other elements in the info are presented.
Suppose you are writing a book where each chapter has a different author.
+You can add the authors to the chapter title page by updating the template in
+your customization layer. The stylesheets contain a
+$v:templates variable for this purpose. Any templates that you
+put inside it will be used before the default templates.
With that customization, a chapter title page contains the
+chapter title in an h2
+and the subtitle and authors in
+h3 elements, in that order.
+If you change the order of the tmp:apply-template elements, the
+order of the elements in the header will change.
Another common requirement is to put a graphic on the title page of a
+book. Here’s how you might do that. (This example appears in the test suite
+as test book.014.xml.) Add the cover to your
+info element:
This template will output the cover image, then the title, then the editor.
+If you want to update multiple templates, put them all in the same
+$v:templates element as siblings.
Once you’ve output the elements in the header, you can use CSS to
+customize their appearance further.
You can get a long way just by updating the title page templates, but not
+always far enough. If you can’t achieve what you need by changing a template,
+you can take full control.
Each element generates its title page with the m:generate-titlepage
+mode. If you add a template in that mode to your customization layer, it has
+complete freedom to generate a custom title page.
With this XSLT template in your customization layer, the book title page
+will consist of the title in an
+h1
+and the phrase “Hello, world” in a paragraph.
+In this case, the context item for the XSLT template is the main element, not
+its info child. But it will always have an
+info child, even if your original document didn’t have a wrapper
+around the titlepage metadata.
3.5. Managing media
References to external media through imagedata,
+videodata, audiodata, and even
+textdata can be tricky to manage. On the one hand, it’s
+most convenient if the URIs in the source documents point to the
+actual media files. This allows extensions, like the image properties
+extension function, to access the
+files. At the same time, the references generated in the HTML have to
+point to the locations where they will be published. It is often, but
+not always, the case that the authoring structures and the publishing
+structures are the same.
The stylesheets are regularly tested against five possible
+arrangements: three where the media are stored in locations relative
+to the XML files and two where the media are stored in a separate
+hierarchy. These are unimaginative named “mo-1”, “mo-2”, “mo-3”, “mo-4”,
+and “mo-5”.
+You can find them in the
+src/test/resources/xml hierarchy in the repository.
mo-1
All of the XML files are in a single directory, the media are in the same
+hierarchy. Media references in the source use relative URIs to refer to the
+underlying media: preface.xml refers to the “this is a test”
+audio clip as media/this-is-a-test.mp3.
+
mo-2
The XML files are in different directories (this changes the
+base URI of the media elements). The media are in the same hierarchy.
+Media references in the source use relative URIs to refer to the
+underlying media: front/preface.xml refers to the “this is a test”
+audio clip as ../media/spinning-top.mp4.
+
mo-3
The XML files are in different directories, but the structure is
+deeper. This scenario represents the case where there might be multiple books, each
+with their own media, but also a shared media folder “above” the book hierarchies.
+The media are in the same hierarchy, but some are “above” the book.
+Media references in the source use relative URIs to refer to the
+underlying media: book/front/preface.xml refers to the “this is a test”
+audio clip as ../../media/spinning-top.mp4.
+
mo-4
The XML files are still in different directories, but the significant change
+here is that the media are in their own hierarchy.
+Media references in the source use URIs relative to the root of that
+hierarchy: book/front/preface.xml refers to the “this is a test”
+audio clip as spinning-top.mp4.
+
mo-5
The XML files are in different directories and the media are in their own
+hierarchy. What’s different here is that the media hierarchy is further
+subdivided by media type.
+Media references in the source use URIs relative to the root of media
+hierarchy without the media type:
+book/front/preface.xml still refers to the “this is a test”
+audio clip as spinning-top.mp4, but this time it is found in
+media/mp4/spinning-top.mp4 rather than directly in
+media.
+
For each arrangement, we look at five possible output structures:
A single HTML document with the media in the same relative locations
+as the sources.
+
A single HTML document with the media in a single media
+subdirectory.
+
“Chunked” HTML output with the media in the same relative locations
+as the sources.
+
“Chunked” HTML output with the media in custom locations. (This is especially
+tricky for the “mo-5” case because there are two kinds of customization involved.)
+
“Chunked” HTML output with the media in a single media
+subdirectory.
+
The list below gives a brief summary of the parameters used to achieve
+the desired results for each combination of input and output arrangements.
ⓘ
Note
Remember that in each case, the questions are: can the
+stylesheets find the media files to query them and are the correct
+HTML references produced? Actually copying the media files from where
+they are in the source system to where they need to be in the HTML is
+“not our problem.”
The output base URI is relative to the “root” of the HTML result.
+Setting the output paths to “false” removes intermediate hierarchy from the
+image references.
+
This combination is really the same as the previous except that
+it uses a
+custom stylesheet
+with a template in the m:mediaobject-output-adjust mode
+to add an extra level of hierarchy to the output URIs. This is just an
+example of arbitrary, custom processing.
+
The output base URI is relative to the “root” of the HTML result.
+Setting the output paths to “false” removes intermediate hierarchy from the
+image references.
+
The input base URI will be made absolute relative to the base URI
+of the input document, so it’s often convenient to specify it as a relative
+URI. It’s equally possible to specify it as an absolute URI.
+
This combination is really the same as the previous except that
+it uses a
+custom stylesheet
+with a template in the m:mediaobject-output-adjust mode
+to add an extra level of hierarchy to the output URIs. This is just an
+example of arbitrary, custom processing.
+
The “mo-5” scenarios are all the same as the “mo-4” scenarios
+with the addition of one more parameter:
|mediaobject-grouped-by-type = "true"
+
In each case, this adds the extra “media object type” level to the
+URI path.
+
If you download the source repository, you can see these combinations
+in action with the build targets
+“mo_number_test_scenario”,
+for example, run:
|./gradlew mo_3_test_2
+
to see the results of processing “mo-3” in scenario 2. The output
+will be in the build/actual directory. The build target
+all_mo_tests will run them all.
3.6. Controlling numeration
Numeration refers to the process(es) by which sets, books,
+divisions, components, sections, and formal objects are numbered.
+There are three separate aspects to numeration: what’s numbered, where
+does numbering begin, and does the number inherit from its ancestors.
Let’s suppose that parts are numbered “I” and “II”. (The number
+format is controlled by the localization, see Chapter 4, Localization.) If chapter
+numbering begins at the book level, those chapters will be
+numbered “1”, “2”, and “3”. If chapter numbering begins at the division level
+(the part), those chapters will be numbered “1”, “1”, and “2”.
+If division numbers are inherited, those numbers will be “I.1”, “II.1”, “II.2”.
+
In the 1.x versions of these stylesheets, all of the aspects of
+numeration were controlled by three now obsolete parameters:
+$component-numbers-inherit,
+$division-numbers-inherit, and
+$section-numbers-inherit. In the 2.x stylesheets, the
+various aspects can be controlled independently and the result is
+much more consistent, if a bit more complicated.
The default numeration parameters are designed to cover the most
+common use cases and are specified with strings so that they’re easy to control
+with parameters. Any numeration scheme can be implemented
+with a customization layer, but hopefully that will be necessary only rarely and
+in uncommon cases.
To simplify the problem, we divide the DocBook elements into six categories:
sets
The set is the only member of this category.
+
books
The book is the only member of this category.
+
divisions
The divisions elements are part and reference.
+
components
The component elements are
+acknowledgements,
+appendix,
+article,
+bibliography,
+chapter,
+colophon,
+dedication,
+glossary,
+index,
+partintro,
+preface,
+refentry, and
+setindex.
+
sections
The section elements are
+section,
+sect1,
+sect2,
+sect3,
+sect4,
+sect5,
+simplesect.
+The refentry section elements are not included because they are
+not typically numbered.
formal objects
The formal objects are
+figure,
+table,
+example,
+equation,
+formalgroup,
+procedure.
+
There’s a bit of complexity here. A formalgroup that contains figures
+counts as a figure, a formalgroup that contains tables
+counts as a table, etc. An equation or procedure
+only counts as a formal object if it has a title.
Six parameters control where numbering starts (or restarts):
+$sets-number-from,
+$books-number-from,
+$divisions-number-from,
+$components-number-from,
+$sections-number-from, and
+$formal-objects-number-from. In each case, the value
+of the parameter must be the name of one of the categories. Sets and books
+can only number from sets, divisions can number from sets or books,
+components can number from sets, books, or divisions, etc. It is also
+possible to specify the value root to indicate that elements in
+the relevant category are numbered sequentially through the whole document.
To assure consistency, “numbering from” resets when the specified
+category or one of its ancestors is encountered. In other words, if
+you’re formatting a set of books and numbering components from
+divisions, the numbering resets when a new division, book, or set begins.
For example, the default value for formal objects is to
+inherit from “component section”. That means that the
+first figure in chapter 2 will be labeled “2.1” and the first figure
+in the first section in chapter 2 will be labeled “2.1.1”, etc.
+This most closely reproduces the numbering from the 1.x stylesheets.
3.6.1. Numeration overrides
Although the numeration parameters give you complete control over
+numeration, they aren’t simple to use. A few common cases can be handled with
+simpler settings: $division-numbers,
+$component-numbers, and
+$section-numbers. Each of these parameters is “true” by
+default and numeration of divisions, components, and sections is handled as
+described above. If these parameters are set to “false”, divisions, components,
+and sections, respectively, will not be numbered.
Numbering can also be controlled on a per-element basis with the
+db processing instruction.
+
+If the numbered
+
+pseudo-attribute is “true”, the division, component, or section in which that
+processing instruction occurs, and all of its descendants, will be numbered.
+If it’s “false”, the element and its descendants will not be numbered.
In this way, it would be possible to have a single chapter or article with
+numbered sections even in a book where sections are not normally numbered.
3.7. Using glossaries
There are essentially two ways to manage glossaries: you can
+author them by hand, or you can compose them automatically from a
+collection of glossary entries.
In a glossary authored by hand, no special processing
+takes place. The entries appear as they are listed and every entry appears
+whether there is a corresponding glossary reference in the document or not.
+The author is free to use glossdiv elements
+to divide the glossary into sections and the document may have multiple
+glossary elements.
If you compose them from glossary collections, only the terms
+used in your document (in glossterm or firstterm
+elements) will appear in the glossary. The glossary collections can be
+managed internally or externally. If multiple definitions appear in
+the glossary collections, only the first definition is
+included.
The best way to explain automatic glossaries is to use an
+example. Let's assume that you have marked the two terms
+Apple and
+Pear as glossterms in your document.
+Your automatic glossary should ultimately contain exactly two entries,
+one for each of those terms.
Create a glossary in your document and add auto to the
+role attribute on the glossary element.
+(If you’re using automatic glossaries, there should only be one glossary
+element in your document.) This is the internal glossary.
Even if your internal glossary has three entries, one each for Apple,
+Jackfruit and Pear, you will end up with a
+glossary in the generated document that has only two entries. There will be no entry for
+Jackfruit, since there is no corresponding glossterm
+or firstterm in the main part of your text.
You can also use external glossaries for
+this task, which can be identified by the
+$glossary-collection parameter, or the
+db processing instructions with a
+glossary-collection pseudo-attribute in the root element.
If you use external glossaries, you can leave the internal,
+automatic glossary completely empty. As long as there are entries for
+Apple and Pear in one of
+your external glossaries, you will end up with those two entries in
+the generated glossary, even if the external glossaries contain many
+more terms.
+
You can use the internal, automatic glossary in conjunction with
+external glossaries. In this case, entries from the internal glossary
+take precedence over entries for the same term from external
+glossaries. Lets say you have entries for Apple
+and Pear among others in your external glossary,
+and also a glossentry for Apple in
+your internal glossary. In this case you will end up with a glossary
+which contains two entries, one for Apple, with
+the definition taken from the internal glossary, and one for
+Pear with a definition from the
+external glossary.
+
Entries will appear in the glossary in the same order as they appear in the
+internal and external glossaries unless they are sorted. Sorting is controlled
+by the $glossary-sort-entries parameter.
An automatic glossary may have glossary divisions. Those are
+controlled by the $glossary-automatic-divisions
+parameter.
3.7.1. Using Schematron to manage the glossary
Schematron rules can help manage the glossary. The
+f:glossentries() function (defined in
+standalone-functions.xsl in the xslTNG install
+directory) has been designed so that it can be integrated into
+Schematron independently of the xslTNG stylesheets. You can use it to
+check whether a corresponding glossentry exists for a
+glossterm or firstterm while you are still
+writing. Corresponding Schematron schemas are not yet part of the
+xslTNG framework. Example 3.1, however,
+shows how you could use schematron to check whether there is exactly one glossentry
+for the glossterm and firstterm elements in your document.
Use the f:glossentries() function
+ to get the number of matching glossentry elements for the given glossterm or firstterm
Example 3.1. A Schematron schema to check glossary terms
If you want to use Schematron rules with external glossaries,
+it’s most convenient to use the db processing instruction
+to identify the external glossaries. The
+f:glossentries() function will load them automatically (see Example 3.2).
+
Example 3.2. Pass the glossary-collection parameter to Schematron
3.8. Using bibliographies
Bibliographies are more complicated than glossaries.
+Bibliography entries can be “cooked” (bibliomixed) or “raw”
+(biblioentry) and there’s no obvious way to sort
+bibliography entries in the general case.
There are also two different cross-referencing mechanisms for
+bibliographic entries: by ID, using biblioref or xref,
+or with citation that matches on abbrev elements
+in the bibliography entry.
The first entry can be cited in two ways: <biblioref linkend="bib.xml"/>
+or <citation>XML</citation>. The second can only be cited with
+a <citation>MalerElAndaloussi96</citation>
+(it has no xml:id to link to).
Taking all of these variations into account, there are three
+ways to construct bibliographies:
When external bibliographies are used, they can be identified either with the
+$bibliography-collection parameter or with
+db processing instructions with a
+bibliography-collection pseudo-attribute in the root element.
3.8.1. Entirely by hand
In a bibliography constructed entirely by hand, no special processing
+takes place. The entries appear as they are listed and every entry appears
+whether it is cited or not. The author is free to use bibliodiv elements
+to divide the bibliography into sections and the document may have multiple
+bibliography elements.
3.8.2. Managed by hand
Bibliographic entries can be complex and may be shared across multiple
+documents. One approach to managing this complexity is to store the full entries in
+an external bibliography and use only placeholders in your actual document.
A placeholder is an empty entry with an xml:id, or an entry that contains only an
+abbrev (if it has both an xml:id and contains only an abbrev, the
+ID will be used to search for a matching entry in the external bibliography).
+It will be replaced by the full entry from the external bibliography
+when the document is formatted.
For example, if the full entries are available externally, the preceding
+bibliography example could be shortened to:
The entries appear in the order listed and every entry appears
+whether it is cited or not. The author is free to use bibliodiv elements
+to divide the bibliography into sections and the document may have multiple
+bibliography elements.
3.8.3. Automatic
An automatic bibliography is selected by using the token
+auto in the role attribute on a bibliography.
+Placeholders can still be used, but they are unnecessary when using
+citation for citations.
Any citation that appear in the text will be matched to entries
+in the external bibliographies. Those entries will be included
+automatically. Automatically added entries appear at the end of the
+bibliography (after any internal ones, if the internal bibliography
+has entries), in the order that they appear in the external
+bibliographies.
+If multiple external entries match, only the first is added.
Any bibliography entries in the internal bibliography that
+aren’t cited will be removed.
When using the automatic style, there should be only one
+bibliography in the document and it cannot contain
+divisions.
3.9. Creating something completely different
Your input documents go through several pre-processing steps
+before they are rendered into HTML. If you want to produce completely
+different outputs, the place to start is with root template in the
+m:docbook mode.
Consider, for example,
+the task of creating a JSON version of the Table of Contents. In principle, you could
+write your own stylesheet to do this, but leveraging the
+DocBook xslTNG Stylesheets means you can make use of functions like
+f:generate-id() to create links.
To produce completely different results, override the root template in the
+m:docbook mode:
1 |<xsl:templatematch="/"mode="m:docbook">
+|<xsl:document>
+|<!-- your processing here -->
+|</xsl:document>
+5 |</xsl:template>
+
This template must return a document node.
Note that you can mix-and-match your processing with default
+processing by processing DocBook elements in the
+m:docbook mode.
Here is a simple example of a stylesheet that produces a JSON version of the
+Table of Contents for a DocBook document:
1 |<?xml version="1.0" encoding="utf-8"?>
+|<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+| xmlns:db="http://docbook.org/ns/docbook"
+| xmlns:f="http://docbook.org/ns/docbook/functions"
+ 5 | xmlns:m="http://docbook.org/ns/docbook/modes"
+| xmlns:t="http://docbook.org/ns/docbook/templates"
+| xmlns:xs="http://www.w3.org/2001/XMLSchema"
+| xmlns="http://www.w3.org/1999/xhtml"
+| exclude-result-prefixes="db f m t xs"
+10 | version="3.0">
+|
+| <!-- This href has to point to your local copy
+| of the stylesheets. -->
+| <xsl:import href="docbook/xslt/docbook.xsl"/>
+15 |
+| <xsl:output method="text"/>
+|
+| <!-- Suppress xslTNG's default HTML output; note that this template
+| must return a document node. -->
+20 | <xsl:template match="/" mode="m:docbook">
+| <xsl:document>
+| <xsl:apply-templates select="." mode="TOC"/>
+| </xsl:document>
+| </xsl:template>
+25 |
+| <!-- The templates below generate a simple JSON ToC. -->
+|
+| <xsl:template match="/" mode="TOC">
+| {"toc": [
+30 | <xsl:apply-templates mode="TOC"/>
+| ]}
+| </xsl:template>
+|
+| <xsl:template match="db:part|db:article|db:section|db:chapter" mode="TOC"
+35 | expand-text="yes">
+| <xsl:if test="preceding-sibling::db:part
+| | preceding-sibling::db:article
+| | preceding-sibling::db:section
+| | preceding-sibling::db:chapter">, </xsl:if>
+40 | {{
+| "ref": "{f:generate-id(.)}",
+| "title": "{normalize-space(db:info/db:title)}",
+| "subtitle": "{normalize-space(db:info/db:subtitle)}",
+| "items": [
+45 | <xsl:apply-templates select="db:part|db:article|db:section|db:chapter" mode="TOC"/>
+| ]
+| }}
+| </xsl:template>
+|
+50 | <xsl:template match="*" mode="TOC">
+| <xsl:apply-templates select="*" mode="TOC"/>
+| </xsl:template>
+|</xsl:stylesheet>
+
ⓘ
Note
This example is meant as a starting point; it’s not robust as it only handles
+a few of the possible elements that might appear in a Table of Contents.
When processing documents this way, be aware that you are transforming the pre-processed,
+normalized versions of your input documents. For example, whether or not you put
+info wrappers around the titles of your sections, in the pre-processed input,
+titles always appear inside info wrappers.
+This normalization greatly simplifies processing in many places.
Chapter 2 . Using the stylesheets
Chapter 4 . Localization
\ No newline at end of file
diff --git a/guide/2.2.2/ch-implementation.html b/guide/2.2.2/ch-implementation.html
new file mode 100644
index 0000000000..67b27a3195
--- /dev/null
+++ b/guide/2.2.2/ch-implementation.html
@@ -0,0 +1,280 @@
+Chapter 5. Implementation detailsDocBook xslTNG Reference
Chapter 5. Implementation details
This section sketches out some features of the implementation.
+It would probably be better to build an annotated
+Definitive Guide or
+something, but this will have to do for now.
+
5.1. Customizing chunking
Chunking is controlled by the $chunk-include and
+$chunk-exclude parameters. These parameters are both
+strings that must contain an XPath expression.
For each node in the document, the $chunk-include
+parameter is evaluated. If it does not return an empty sequence, the element
+is considered a chunking candidate. In this case, the
+$chunk-exclude parameter is evaluated. If the exclude
+expression does return an empty sequence, then the element identified
+becomes a chunk. (If the exclude expression returns a non-empty value, the element
+will not become a chunk.)
5.2. Lengths and units
Lengths appear in the context of images (width and height) and
+tables (column widths). Several different units of length are
+possible: absolute lengths (e.g., 3in), relative lengths (e.g., 3*),
+and percentages (e.g., 25%). In some contexts, these can be combined:
+a column width of “3*+0.5in” should have a width equal to 3 times the
+relative width plus ½ inch.
In practice, some of the more complicated forms in TR
+9502:1995 have no direct mapping to the units available in
+HTML and CSS. The stylesheets attempt to specify a mapping that’s
+close. Broadly, they take the nominal width of the table
+($nominal-page-width), subtract out the fixed
+widths, divide up the remaining widths proportionally among the
+relative widths, and compute final widths. The final widths can be
+expressed either in absolute terms or as percentages.
In handling the width and height of images, the intrinsic width
+and height of the image in pixels are converted into lengths by
+dividing by $pixels-per-inch. Nominal widths are
+taken into consideration if necessary.
ⓘ
Note
Determining the intrinsic size of an image depends on an extension function.
+See Section 2.6, “Extension functions”. Many bitmap image formats are supported.
+The bounding box of EPS images is used, if it’s present. The intrinsic size of
+SVG images is not available.
The list of recognized units (in, cm, etc.) are taken from
+$v:unit-scale.
5.3. Verbatim styles
There are four verbatim styles: lines, table,
+plain, and raw.
lines
In the lines style, each line of the verbatim environment is
+marked up individually. In this style, lines can be numbered and
+callouts can be inserted.
+
table
In the table style, each line of the verbatim environment is
+marked up individually, very much like the lines style. In this style,
+lines can be numbered and callouts can be inserted. It differs from
+the lines style in that the whole thing is wrapped in a table.
The table has one row and two columns. The line numbers appear in the
+first column, the lines in the second. This format was added in order
+to improve the display in user agents that don’t support CSS.
+Ironically, in the course of adding this style, a number of changes
+were made to the way line numbers are formatted in the lines style
+making it largely, perhaps entirely, unnecessary.
+
plain
In the plain style, callouts can be inserted, but additional markup is not
+added (except for the callouts). Consequently, it isn’t possible to do line numbering
+or syntax highlighting. (It may be possible to provide these features with JavaScript
+libraries in the browser, however.)
+
raw
In the raw style, no changes are made to the verbatim content. It’s output as
+it appears. Inline markup that it contains, emphasis or other elements, will
+be processed, but you cannot add line numbers, callouts, or syntax highlighting.
+
Consult I. Parameter reference for a variety of parameters that control
+aspects of verbatim processing.
5.3.1. Line numbers
In the lines and table styles, line
+numbers may be added to the beginning of some (or all) lines. Prior to version
+1.10.0, the stylesheets inserted the numbers without any padding:
(The newlines and indentation in these examples are for clarity. In practice, these
+are inside a pre where every
+space counts and they’re all run together with line breaks only occurring
+between lines.)
In a graphical browser with CSS support, this looked fine. But
+without CSS, the line numbers and the text that followed them could
+flow together and the alignment of the numbers was unclear.
Starting in version 1.10.0, the stylesheets insert padding
+spaces before each number so that they will all be aligned. If the
+largest line number is three digits long, every number smaller than
+100 will be padded to a width of three characters. A single space is
+added after the number to separate it from the text that follows.
+An additional separator may also be inserted, as shown here.
These changes have no visible effect when CSS is used to style
+the verbatim environment. But without CSS, the numbers are aligned and
+separated from the text that follows. The
+$verbatim-number-separator is generally
+suppressed by CSS, but is visible in text browsers.
5.4. Processing mediaobjects
Starting in version 1.11.0, the way media objects are processed has been
+refactored. This is designed to support fallback at both the object
+level (imageobject, audioaobject, videoobject,
+textobject, and imageobjectco) and at the data
+level (imagedata, audiodata, videodata,
+and textdata within the objects).
Each data element and object element is processed in the
+m:mediaobject-info mode. This returns a map for each object
+that contains an array of maps, one for each data element:
Table 5.1. The object map
Key
Value
content-types
An array of the distinct content types in the data elements
datas
An array of data maps
extensions
An array of the distinct extensions in the data elements
DocBook
+uses “depth” instead of “height”, but we convert
+it to height for consistency with most other systems.
The uri and href properties are computed
+by processing the data elements in the m:mediaobject-uris mode.
Armed with information about the objects and the data associated with them,
+the stylesheets proceed to choose an object and then process it. Each object is
+considered in turn, if any of the data elements it contains were excluded, then it is
+rejected. The first object where all of the elements are acceptable is selected.
If this is being processed for online presentation, the default
+value of $mediaobject-exclude-extensions will exclude the
+EPS file. Because one of it’s data elements was excluded, the processor will choose
+the object containing only the SVG and PNG images for online presentation.
Once an object is selected, an appropriate wrapper is created and all
+of the alternatives are placed within it. So the example above will result in
+picture element containing
+a
+source for the SVG image and an
+img for the fallback PNG.
+
ⓘ
Note
Consistent with HTML, only the size, scaling, and alignment attributes of
+the last alternative data element are considered! These apply
+irrespective of which alternative is selected.
5.4.1. Mediaobject URIs
Media object URIs are tricky to handle. It’s most
+convenient if the URIs in the source documents point to the actual media files.
+This allows extensions, like the image properties
+extension function, to access the files.
+At the same time, the references generated in the HTML have to point to the
+locations where they will be published.
In previous versions, the stylesheets attempted (broadly) to use
+the relative difference between the input and output base URIs to work out
+the correct relative URIs for media. That imposed restrictions on the
+authoring environment that weren’t always easy to work with.
+Starting in version 2.0.6, the mechanisms for finding sources
+and producing references in the output has changed. Three parameters
+are used:
If the $mediaobject-input-base-uri is empty (the default),
+then URIs in the source document are assumed to be relative to the base URI on
+which they occur. This is the usual case if you mix XML and media into the same
+directory structure on the filesystem.
If the $mediaobject-input-base-uri is not empty, it is
+used to resolve all media URIs. If it’s initialized with a relative URI, that URI will
+be made absolute against the base URI if the input document.
If the $mediaobject-output-base-uri is empty (the default),
+then URIs in the output are treated as parallel to the URIs in the input. If the
+reference ../image.png works in the source document, it’s assumed
+that will also work in the output document.
If the $mediaobject-output-base-uri is not empty, it is
+the base URI used for media objects. If this is a relative URI, it is taken to be
+relative to the root of the output hierarchy.
Suppose the output base URI is https://images.example.com/, then
+a reference to image.png will appear as
+https://images.example.com/image.png in the output.
If the output base URI is media/, then
+a reference to image.png will appear as
+media/image.png in the output. If the document is chunked, the paths back
+to the output directory are relative. In otherwords, if the reference to
+image.png appears in a chunk that will be located at
+back/appendix.html, then the media URI will be
+../media/image.png.
+
This parameter controls whether the relative paths in the input URIs apply
+to the output URIs as well. If the parameter is true,
+the output base URI is media/, and the input URI is
+path/to/image.png, then the output reference will be to
+media/path/to/image.png. If it’s false, then the output reference
+will be to media/image.png.
+
The stylesheets are not responsible for actually copying the media files
+into the correct locations in the output. The stylesheets only generate the HTML
+files and the references. You must copy the images and other media with some
+other process.
5.5. Templates
It’s difficult to make title pages for documents easy to customize. There
+is a lot of variation between documents and the styles can
+have very precise design constraints. At the end of the day, if you need complete control,
+you can define a template that matches the element in the
+m:generate-titlepage mode and generate all of the markup you wish.
The default title page handling attempts to make some declarative customization
+possible by using templates. A typical header template looks like this:
Any HTML element in the template will be copied to the output. The semantics
+of a “template apply templates” element (tmp:apply-templates) is that
+it runs the ordinary xsl:apply-templates instruction on the elements that
+match its select expression. If they result is the empty sequence (e.g, if there is no
+subtitle), nothing is output. If there is a result, the content of the
+tmp:apply-templates element is processed. Anywhere that
+tmp:content appears, the result of applying templates will be output.
In this example, if the title is “H2O” and there is no subtitle,
+the resulting HTML title page will be:
|<header>
+|<h2>H<sub>2</sub>O</h2>
+|</header>
+
5.6. Annotations
The stylesheets fully support annotations, including a number
+of presentation styles enabled by JavaScript in the browser. They also
+support an extension of the documented semantics of
+annotation.
Annotations are applied to elements with links. Either the
+element must point to its annotations (with an annotations
+attribute) or the annotations must point to the elements they annotate
+(with an annotates attribute). These are documented as
+ID/IDREF links but they are not IDREFS attributes
+because annotations may be stored separately.
Starting in version 1.5.1, the DocBook xslTNG
+Stylesheets⌖1 support a non-standard extension: if you place
+the string xpath: in the annotates attribute of
+an annotation, then the rest of the attribute is assumed to contain
+an XPath expression that points to the element(s) to which the annotation
+applies. (If you want to put IDREF values before the xpath: token,
+that’s fine, but you can’t put them after; the expression continues to the end
+of the attribute value.)
Suppose, for example, that you wanted to annotate the stylesheet
+title in the previous paragraph. The standard mechanisms would require that
+you either put an xml:id attribute on the element or point to the
+annotation from the element. With the XPath extension, you can do this:
When the XPath expression is evaluated, the annotation
+element is the context item. Often, this means that you’ll want to start
+the expression with id() or /.
The namespace context for the expression is also the annotation
+element, that’s why I’ve added the DocBook namespace binding for the
+db prefix. In practice, if you’re doing this on
+several annotations, you can just put all the namespace bindings on a common
+ancestor. All of the bindings in scope on the
+annotation element are available in the expression.
Caveats:
There’s no way to have multiple XPath expressions. You can’t put
+“xpath:” in there twice. If you want an annotation to apply to
+multiple elements, you’ll have to construct a single expression that selects
+all the elements, or duplicate the annotation, or use ID/IDREF links.
If this turns out to be a serious limitation in practice, additional
+syntax could be added to support multiple expressions, but it doesn’t
+seem necessary.
You can only select elements. There’s no way to select the third word
+in a particular paragraph, for example, unless it already has some markup
+around it. There’s also no way to select a comment or a processing instruction.
+
The placement of the annotation marker (“⌖” by default) can also be
+controlled globally and on individual annotations. The
+$annotation-placement parameter provides global control.
+To specify the position for an individual annotation, put the token
+“before” or “after” in the role
+attribute on the annotation.
5.7. The pre- and post-processing pipeline
Processing a DocBook document is a multi-stage process. The
+original document is transformed several times before converting it to
+HTML. The standard transformations are:
Adjust the logical structure. Adds an XML base attribute to the root of the
+document and converts media object entityref attributes
+into fileref attributes.
+
Perform XInclude processing. Only occurs if the appropriate
+extension function is available and if the document contains XInclude
+element.
+
Convert DocBook 4.x to DocBook 5.x. Only occurs if the root element is not in
+a namespace.
+
Peform transclusion.
+
Perform profiling.
+
Normalize the content. This removes a lot of variation that’s allowed for authoring.
+For example, authors aren’t required to use an info element if a formal object
+has only a title. This process adds the info element if it’s missing.
+
Resolve annotations.
+
Process XLink link bases.
+
Validate. Only occurs if the appropriate
+extension function is available and the stylesheet specifies a
+$relax-ng-grammar.
+
Process Oxygen change markup. Only occurs if
+$oxy-markupis true and the document contains
+Oxygen change markup processing instructions.
+
A customization can introduce transformations to the original
+document using three parameters:
This transform runs before step 1 in the standard transformations.
+If this transformation is used, it must take special care to preserve the
+base URI of the original document by adding an xml:base
+attribute to the root element (if it doesn’t already have one).
Only the first transformation in the list has access to the original base URI.
+If it isn’t preserved, relative references to other documents will be resolved against
+the static base URI of the stylesheet and not the URI of the original document. That’s
+unlikely to be correct.
This transformation runs after the DocBook document has been transformed into HTML.
+The resulting HTML document is not valid HTML, but contains islands of valid HTML that will
+be separated out into chunks by subsequent processing.
+
(If you need
+to insert a transformation in the middle of the standard transformations,
+you’ll have to update the $v:standard-transforms
+variable in your customization.)
Each of the transformation variables holds a list of transforms that will
+be applied in the order specified. Each member of the list can be a map or a
+string. If a string is provided, it’s the equivalent of providing this map:
+
The location of the XSLT stylesheet that performs this transformation.
+This key is required.
extra-params
A map of QName/value pairs. These parameters will be made available to
+the transformation in addition to all of the standard parameters available to a
+standard DocBook stylesheet.
functions
A list of functions (expressed as EQNames). The transformation will only be
+run if every extension function listed is available.
test
An arbitrary XPath expression. The expression will be evaluated with the
+document as the context item. If it returns an effective boolean value of true,
+the transformation will be run.
Chapter 4 . Localization
Chapter 6 . Building the stylesheets
\ No newline at end of file
diff --git a/guide/2.2.2/ch-localization.html b/guide/2.2.2/ch-localization.html
new file mode 100644
index 0000000000..0b3d18ff33
--- /dev/null
+++ b/guide/2.2.2/ch-localization.html
@@ -0,0 +1,306 @@
+Chapter 4. LocalizationDocBook xslTNG Reference
Chapter 4. Localization
The DocBook xslTNG stylesheets support
+localization in more than 70 languages. At the time of this writing:
+Afrikaans, Albanian, Amharic, Arabic, Assamese, Asturian, Azerbaijani,
+Bangla, Basque, Bosnian, Bulgarian, Catalan, Chinese, Chinese
+(Taiwan), Chinese Simplified, Croatian, Czech, Danish, Dutch, English,
+Esperanto, Estonian, Finnish, French, Galician, Georgian, German,
+Greek, Gujarati, Hebrew, Hindi, Hungarian, Icelandic, Indian Bangla,
+Indonesian, Irish, Italian, Japanese, Kannada, Kirghiz, Korean, Latin,
+Latvian, Lithuanian, Low German, Malayalam, Marathi, Mongolian,
+Northern Sami, Norwegian Bokmål, Norwegian Nynorsk, Oriya, Polish,
+Portuguese, Portuguese (Brazil), Punjabi, Romanian, Russian, Serbian
+in Cyrillic script, Serbian in Latin script, Slovak, Slovenian,
+Spanish, Swedish, Tagalog, Tamil, Telugu, Thai, Turkish, Ukrainian,
+Urdu, Vietnamese, Welsh, and Xhosa.
4.1. Background
Near the end of the previous millennium, I was working
+on the
+DSSSL
+stylesheets for DocBook. They were popular enough that users of languages
+other than English wanted to use them.
I invented a mechanism for doing simple localization
+so that the word “Chapter” in “Chapter 5” would, for example,
+be spelled “Chapitre” if the
+book was in French, and “Розділ” if it was in Ukrainian.
+What started as a simple word substitution system grew a few
+macro facilities and became a little more sophisticated*.
Over time, with the aid of dozens of volunteers around the world
+who contributed files for their languages, the DocBook stylesheets
+developed localization capabilities that were for the most part good
+enough.
Fast forward a few years and those language-specific
+localization files, and some of those mechanisms, were ported to the
+XSLT 1.0 stylesheets for DocBook.
Fast forward another decade and those XSLT 1.0 localization
+files and some of the mechanisms were ported to the XSLT 2.0 stylesheets
+for DocBook.
Fast forward the better part of another
+decade and those XSLT 2.0 localization files and some of the
+mechanisms were ported to the DocBook xslTNG
+stylesheets.
Well. Sort of. Initially, I tried to replace the complex system
+of templates with a model that took the text that had to be generated
+and decomposed it into logical parts. It worked fine for English and
+many other languages, but didn’t account for the complexity of
+many others, such as Chinese.**
Starting in version 2.0.0, the xslTNG stylesheets have reverted
+back to a templating system. The localization files have been
+transformed a little bit to make some of the customization easier (I
+hope). They can’t stray too far from the original designs because I
+must reuse the localization data I have. I don’t want to devise a
+system that requires another army of volunteers to provide new
+localization data.
4.1.1. Consequences
One unfortunate consequence of this history is that there’s some
+cruft in the localization files. There are mappings and possibly
+templates that aren’t actually used. Or, at least, they’re not used in
+the standard DocBook stylesheet. They might be used in customization
+layers.
I made a few attempts to trim out cruft, but found all of the
+results unsatisfying. So, at least for the moment, I’ve left it in
+place. Like everything on earth, it’s mostly
+harmless.
+
4.2. Overview
In this context, localization mostly refers to “generated text”,
+words and symbols that appear in a published DocBook document that
+aren’t present in the original XML. Consider Figure 4.1, “Sample book source”.
The title “Table of Contents” is entirely generated; it appears
+nowhere in the XML. The chapter title appears in the text, but it’s
+labeled “1.” in the list of titles, “Chapter 1.” in the chapter itself,
+and “Chapter 1” (without the title) in the cross reference.
The question is, how is this accomplished? The answer, I’m
+afraid, is not simple.
It begins with a localization file.
4.3. Localization files
The localization files are in
+src/main/locale in the repository. The
+localization file is designed to be simple enough to edit by hand. The stylesheets
+use compiled versions created by processing the input locale with
+src/main/xslt/modules/xform-locale.xsl to produce
+the files in
+xslt/locale in the distribution.
A locale begins by defining the language it supports and
+providing an English language name for it. The language
+attribute identifies the language (in the same terms as
+xml:lang) to which this localization applies.
That’s followed by metadata about the file (authors, etc.), then
+mappings, groups, lists, and letters as shown in
+Figure 4.5, “Example locale file (excerpted)”. We’ll consider each
+section in detail below.
These mappings serve two purposes. For many languages, a lot of the
+work of defining a new localization is just updating these mappings.
+For a stylesheet customization layer, it provides a mechanism for remapping
+on an ad hoc basis.
In a localization template, any key entered in curly braces will
+be replaced by the mapping. In other words, for the example above,
+{abstract} will be replaced by the word “Abstract”.
+This mapping is done when the document is transformed, not when the
+localization file is compiled.
4.3.2. Group
Groups are the primary templating system. In a context where
+generated text is required, a group is selected and within that group,
+a template is selected. The template is selected by evaluating the
+expression in the match attribute with the current node
+as the context item. A template with the match express true()
+will always succeed; it is used as a fallback.
The title-numbered group determines how
+titles are formatted if they are numbered, (there’s also
+title-unnumbered when titles aren’t being
+numbered):
Within a template, two kinds of substitution are performed: names in
+curly braces are replaced by the corresponding mapping and %-letter values
+are substituted as follows:
Table 4.1. Template %-letter substitutions
%-letter
Substitution
%c
The content (for example, the text of the title)
%l
The label (for example, “Chapter 1” or “see also”)
%p
The page number (not yet implemented)
%o
The olink title (not yet implemented)
%.
The separator (often, “. ”)
%%
A literal % character
If the title group is being used to generate
+text for the chapter from our example
+document:
The chapter context is used to select
+the template ({chapter} %l%.%c).
The string {chapter} is replaced by the mapping for
+chapter, which is “Chapter” in English.
The label %l is “1” because this is the first
+chapter. (In fact, constructing the label uses templates from the
+localization file as well.)
The separator %. is “. ”. (Like the label, this is
+also constructed from a separate query to the localization file.)
And the content %c is “Chapter the first”. (There’s no markup
+in this title, but if there was, it would be retained. The content is a list of items,
+not a string.)
Literal text, such as the non-breakable space between “{chapter}”
+and “%l”, is retained verbatim.
+
4.3.3. List
List elements are used to format items that can be repeated (terms
+in a variable list, lists of authors, lists of “see also” terms, etc.).
+The list consists of a series of items. Within each item, one or more
+content replacements is specified with %c. The items
+must be arranged so that there’s a match for one, two, three, etc. items.
If an item contains a repeat, that repeat will be used for as many
+items as necessary to complete the list formatting. The default
+list format is:
Consider how a list of four authors in an authorgroup
+would be formatted. Call them A, B, C, D, for simplicity (and assume
+there’s no list for “authorgroup”, so the
+“_default” will be used).
The first two items match one and two items, respectively. They
+aren’t appropriate for a list of four items. The third item contains
+three items and a repeat, so that can be used for a list of four (or
+more) items.
The first %c is “A”. The second %c is
+in a repeat, followed by another %c. There are three
+elements left in the list at this point, so two will be used in the
+repeat and the last one will follow it.
The result will be A, B, C, and D where the
+word “and” was found by looking for the and key in
+the mappings.
4.3.4. Letters
The letters group is used to identify the lexical order and grouping
+of letters.
All of the symbols with the same “i” value will be grouped
+together.
This mechanism dates from the days before XSLT supported
+language-specific collations. It is used in generated indexes, but perhaps it should simply
+be phased out.
4.4. Customizing a localization
For many users, the localizations provided are entirely sufficient.
+But if you want to change them, you have a few options.
4.4.1. Replacing entire localization files
If you want to replace an entire localization file (if, for example,
+you want to apply the same changes to a set of stylesheets), you can
+approach that as follows:
Copy the localization source files.
Update the ones you wish to change.
Compile them all with
+src/main/xslt/modules/xform-locale.xsl saving
+the output in a new location.
In your stylesheet, change the
+$v:localization-base-uri to point to the directory
+where the new locales reside. Those locale files will be used.
+
4.4.2. Overriding mappings, groups, etc.
If you only want to override a small number of localization
+features, it may be simpler to do so directly in your stylesheet.
+The variable $v:custom-localizations will be merged
+with the default localizations before transformation begins.
+But you can only override existing groups with the procedure described here.
+You cannot use $v:custom-localizations to define new groups.
Suppose, for example, that you wanted:
The table of contents title to simply be “Contents”,
+
To omit the word “Appendix” from the appendix title, and
+
To change the form of the cross reference to
+appendixes to read “App. A” instead of “Appendix A”.
+
The following customization would accomplish that:
Note that it defines (a portion of) a locale source file for the
+language en. These changes only apply to that
+locale.
This fragment replaces the mapping for
+TableofContents and the templates for numbered
+titles and numbered cross references.
To update multiple languages, put additional locale
+elements in the variable as siblings.
Formatting our example document above now produces:
Figure 4.6. Sample book (Alternate)
4.4.3. Changing the group
Sometimes, rather than change a template, you want to change
+which group of templates is used. This is controlled by two variables:
+$v:user-title-groups and
+$v:user-xref-groups.
+
4.4.3.1. Changing the title group
The $v:user-title-groups element consists of a
+list of title elements, each with an xpath
+attribute, a group attribute, and an optional template
+attribute.
Suppose the stylesheet is trying to generate a title for an
+element. It considers each title element in turn. The
+xpath expression is evaluated with the element as the
+context item. If the effective boolean value of the expression is
+true(), then that title is selected and templates from
+the corresponding group are used.
If a template attribute is present, a template with
+that name is used. Otherwise the local name of the element is used as
+the template name.
By default, sections in a preface are not numbered. That’s
+because the default title groups include:
Because all of the user groups are consulted first, it isn’t
+necessary to include the predicate that limits this title to sections
+in a preface (although it wouldn’t change the result if you did).
The default for cross references to chapters and appendixes is
+“xref-number-and-title”, so you get things like “Chapter
+1. The Chapter Title”. In order to get a different presentation in the
+localization example used in this chapter, the following localization
+is used:
That’s why the cross reference to the first chapter is just
+“Chapter 1”.
+
4.5. Caveats
There’s currently little documentation to tell you which group
+or template to change. The names are supposed to be somewhat self
+explanatory (for speakers of English), but sometimes you just have to
+look in the stylesheet.
The formalgroup element is unique in DocBook in that
+its label depends on what it contains. A formalgroup of
+figure elements is itself a “Figure” where a
+formalgroup of example elements is an
+“Example”.
+If you need to change it, you may have to create your own
+template for the formalgroup element in the
+m:headline mode. The default version is in
+modules/titles.xsl.
Chapter 3 . Customizing the stylesheets
Chapter 5 . Implementation details
\ No newline at end of file
diff --git a/guide/2.2.2/ch-overview.html b/guide/2.2.2/ch-overview.html
new file mode 100644
index 0000000000..4228e1d85c
--- /dev/null
+++ b/guide/2.2.2/ch-overview.html
@@ -0,0 +1,53 @@
+Chapter 1. OverviewDocBook xslTNG Reference
Chapter 1. Overview
Before we get started, let’s look at what the stylesheets do and
+where you can get them!
1.1. What do the stylesheets do?
The DocBook xslTNG stylesheets transform
+DocBook V5.x into HTML. The intent is that they support all of DocBook
+V5.2, including the DocBook Publishers elements. (The
+test suite report
+gives a precise summary of the current state of coverage.) They will also
+process DocBook V4.x documents by first converting them (tranforming
+source elements that have changed, adding the namespace, etc.) into
+5.x documents.
Some parts of DocBook, especially the modeling parts, are very
+open-ended. One could, in principle, write a function synopsis for any
+programming language. The stylesheets are naturally going to support
+only a subset of languages out of the box. Every attempt has been made
+to make customizations easy where it’s anticipated that they may be
+necessary.
The stylesheets can also be used to produce paged media such as
+PDF files. This works by having a slightly different HTML
+transformation initially, and then by further transforming the HTML so
+that it can be formatted with an appropriate CSS formatter to produce
+paged output. This is similar, but not the same as producing XSL
+Formatting Objects and then transforming those.
Producing other output formats, EPUB files, for example, is
+planned for the future but no specific schedule is promised. There are no
+plans at the moment to produce XSL FO stylesheets.
The latest release is always available from the
+GitHub
+releases page. At the time of publication, the latest release was
+version 2.2.2-SNAPSHOT.
Distributed this way, you’ll get a ZIP file that contains the stylesheets
+plus a number of ancillary files and tools. These are mostly covered in
+the next chapter Chapter 2, Using the stylesheets.
You can unzip the file anywhere that’s convenient: in your home
+directory or in a system-wide location.
1.2.2. Getting the release from Maven
The latest release is always available
+from
+Maven*.
+
The group, artifact, and version ID for the latest release at
+the time of publication is:
org.docbook:docbook-xslTNG:2.2.2-SNAPSHOT
If you’re comfortable using Maven, I’m going to assume that’s all you
+need to know.
The Maven distribution differs from the zip file in a couple of ways:
It doesn’t bundle any of the dependencies. The
+ZIP file is more akin
+to
+an
+“uber” or “fat” jar; it includes (some of) the core dependencies so
+that it works out-of-the-box. Maven is designed to resolve dependencies,
+so that shouldn’t be necessary here.
The Maven jar doesn’t include the Python script or the extra resources
+(CSS and JavaScript files) because it doesn’t seem like it would be convenient
+to extract them from the Maven jar (which will probably be installed deep in
+some repository hierarchy well out of sight). Consequently, you may want to
+download the distribution periodically as well.
+
Preface
Chapter 2 . Using the stylesheets
\ No newline at end of file
diff --git a/guide/2.2.2/ch-preface.html b/guide/2.2.2/ch-preface.html
new file mode 100644
index 0000000000..d2ccb7181a
--- /dev/null
+++ b/guide/2.2.2/ch-preface.html
@@ -0,0 +1,73 @@
+PrefaceDocBook xslTNG Reference
Preface
These stylesheets are the third
+iteration of stylesheets for DocBook that I’ve written. I started working on the
+XSLT 1.0
+Stylesheets for DocBook in the 90’s, before XSLT 1.0 was
+even a W3C Recommendation. I started working on the
+XSLT 2.0
+Stylesheets for DocBook just around the time when XSLT 2.0 became
+a W3C Recommendation. I wrote most of
+DocBook xslTNG just a month or so before the third anniversary
+of the XSLT 3.0 Recommendation.
Why did it take so long?
To answer that question, we need to reflect for a moment on XSLT and
+ its place in the XML ecosystem. When XSLT arrived on the scene, we
+ were near the peak of XML enthusiasm. Not only was XML supported
+ everywhere, it was possible to imagine XSLT everywhere as well.
+ Certainly, the presence of XSLT in the browser felt significant at
+ the time.
+
The ubiquity of XML and the fact that XSLT was “just an XML
+ vocabulary” may have contributed to another significant phenomenon:
+ lots of users who did not self identify as programmers were learning
+ to use XSLT and doing significant things with it.
+
There were other tools available for transforming markup at the
+ time, and arguably some of them were better than XSLT, but they were
+ programming languages and you had to be a programmer to use them.
+ They were also mostly commercial applications not widely available
+ to casual users.
+
XSLT was free, it was everywhere, and it was used by everyone, not
+ “just” programmers. It was the clear winner than and remains the
+ clear winner today in terms of markup transformation.
+
You could do a lot of things with XSLT 1.0. You could do a lot more
+ things than you might at first even have thought possible. (In fact,
+ you could do all things, but the
+ Turing complete nature of XSLT isn’t relevant here.) Some very
+ common tasks, like grouping, were possible but difficult. Lots of
+ very useful things were either not possible or required extensions:
+ regular expressions, functions, date and time formatting, creating
+ special characters in the output, to name just a few.
+
XSLT 2.0 solved all of these problems (and more). Significantly, I
+ think, all of these new features appealed directly to almost all
+ users of XSLT 1.0. Everyone had encountered a grouping problem
+ (building an index, for example). Everyone had wanted regular
+ expression matching or date formatting. Lots of users wanted to
+ write more sophisticated predicates (and many were willing to learn
+ how to use functions to achieve that result).
+
XSLT 3.0 arguably introduces larger and
+ more dramatic features than XSLT 2.0 did. There are a bunch of new
+ features designed to enable streaming processing; there are
+ significant software engineering improvements: packaging, exception
+ handling, and assertions; there are common programming language
+ constructs like maps and arrays. There is also a selection of
+ features inherited from updates to XPath (new functions, a subset of
+ let syntax, and support for higher order
+ functions, for example).
+
What’s curious, I think, is that many of these features are probably
+ less immediately appealing to many (most?) current users. XSLT 2.0
+ doesn’t feel constraining in the same way that XSLT 1.0 did, and the
+ features in XSLT 3.0 don’t immediately and obviously solve problems
+ that most users have.
+
Streaming, for example, is incredibly powerful and it’s an important
+ and significant milestone in markup processing. It makes it possible
+ to solve whole classes of problems that were previously impossible
+ to solve or required enormously expensive hardware. But my laptop
+ will quite easily process a book full of complex markup that runs to
+ hundreds of pages. I don’t have any problems that require a
+ streaming processor.
+
Likewise, packaging is useful and important. The DocBook
+ xslTNG stylesheets should absolutely be a package. But
+ that’s not true of a lot of stylesheets. There might be software
+ engineering benefit in making a package even for stylesheets that
+ you don’t intend to distribute, but that’s more likely to appeal to
+ people who think of what they’re doing is programming.
+
Nevertheless, there are lots of good reasons to use XSLT 3.0 even if
+ you are “only” transforming documents and even if you don’t think of
+ writing transformations as programming.
+
Part I . Introduction
Chapter 1 . Overview
\ No newline at end of file
diff --git a/guide/2.2.2/ch-using.html b/guide/2.2.2/ch-using.html
new file mode 100644
index 0000000000..766d2366c6
--- /dev/null
+++ b/guide/2.2.2/ch-using.html
@@ -0,0 +1,664 @@
+Chapter 2. Using the stylesheetsDocBook xslTNG Reference
Chapter 2. Using the stylesheets
In principle, the stylesheets will run with any conformant XSLT
+3.0 processor. For many users, that means
+Saxon. Although earlier versions
+may work, Saxon 10.1 or later is recommended.
In principle, the instructions for using the stylesheets are
+straightforward: using your XSLT 3.0 processor of choice, transform your
+DocBook source documents with the docbook.xsl
+stylesheet in the xslt
+directory of the distribution.
In practice, for most users, running the stylesheets will
+require getting a Java environment configured appropriately. For many,
+one of the most significant challenges is getting all of the
+dependencies sorted out. Modern software development, for better or
+worse, often consists of one library relying on another which relies
+on another, etc.
The DocBook xslTNG stylesheets attempt to
+simplify this process, especially for the “out of the box” experience
+by providing two convenience methods for running the stylesheets: a
+jar file with a Main class, and a Python script
+that attempts, among other things, to make sure all of the
+dependencies are available.
If you’re an experience Java user, you may prefer to simply run
+the stylesheets
+directly with Java.
Irrespective of which method you choose, running the stylesheets
+is simply a matter of processing your input document
+myfile.xml with
+xslt/docbook.xsl. For example:
+
The exact path to docbook.xsl will vary, of course,
+but it’s in the xslt directory of the
+distribution.
ⓘ
Note
The resulting HTML document contains references to CSS stylesheets
+and possibly JavaScript libraries. The output won’t look as nice in your browser
+if those resources aren’t available. They’re in the resources directory of the distribution. A quick and easy way to see the
+results is simply to send the output to the samples
+directory from the distribution. The resources have already been copied into
+that directory. In the longer run, you’ll want to make sure that they get
+copied into the output directory for each of your projects.
Alternatively, you can copy them to a web location of your choosing and
+point to them there. You can even point to them in
+the
+DocBook CDN, but beware that those are not immutable. The “current”
+version will change with every release and versioned releases will not persist
+indefinitely.
Change the $resource-base-uri to adjust the paths
+used in the output document.
Many aspects of the transformation can be controlled simply by
+setting parameters (see I. Parameter reference). It’s also possible
+to change the transformation by writing your own customization layer
+(see Chapter 3, Customizing the stylesheets).
2.1. Using the Jar
The ZIP distribution includes a
+JAR file that you can run directly. That
+JAR file is
+$ROOT/libs/docbook-xslTNG-version.jar
+where “$ROOT” is whatever directory you chose
+to unzip the distribution into and version is the
+stylesheet version.
Assuming you unzipped the version 2.2.2-SNAPSHOT distribution into
+/home/ndw/xsltng, you can run
+the JAR like this:
Let’s try it out. Open a shell window and change to the samples directory,
+/home/ndw/xsltng/samples assuming you unzipped
+it as described above. Now run the java command:
This is a rendering of the sample document. It consists of the
+title “Sample Article” centered on the screen with a short paragraph
+of text below it. The text reads: This is a very simple DocBook
+document. It serves as a kind of "smoke test" to demonstrate that the
+stylesheets are working.
+
Figure 2.1. The sample document: article.xml
The JAR file, run this way, accepts the same
+command line options as Saxon, with a few caveats:
No -x, -y, or -r options
The executable in the JAR file automatically configures Saxon to
+use a catalog-based resolver and points the resolver at a catalog that
+includes the files in the distribution.
+
You can repeat the -catalog option. All of the catalogs
+you specify will be searched before the default catalog.
Default stylesheet
If you do not specify a stylesheet with the -xsl option,
+the xslt/docbook.xsl stylesheet will be used automatically.
+
2.2. Using the Python script
The ZIP distribution includes a
+Python script in the bin directory.
+This helper script is a convenience wrapper around Saxon. It sets up
+the Java classpath and automatically configures a catalog resolver and
+the DocBook extension functions.
☝
Important
The script requires the click and
+pygments packages,
+which you must install with pip before
+running the script. For example:
The significant feature of the Python script is that it will
+attempt to sort out the dependencies for you. It assumes that you’ve
+used Maven to install the package and its dependencies, so you’ll
+have to have installed
+Maven. How you do that varies by platform, but your package
+manager probably has it.
The following command will assure that you’ve downloaded all of
+the necessary dependencies. You only have to do this once.
The script will work through the dependencies that you have
+installed, and the things that they depend on, and construct a Java
+class path that includes them all.
The script stores its configuration in
+.docbook-xsltng.json in your home directory.
Options passed to the script are processed as follows: the
+initial options, all introduced by two hyphens, are interpreted by
+this script; all the remaining options are passed directly to
+Saxon.
The script options are:
--help
Prints a usage message.
+
--config:filename
Use filename as the configuration
+file. The default configuration file is
+.docbook-xsltng.json in your home directory.
+
--resources:dir
This option will copy the resources directory (the CSS and JavaScript files)
+from the distribution into the directory where your output files are going,
+dir. If
+dir is not specified, the script attempts to
+work out the directory from the -o option provided to Saxon.
+If no directory is specified and it can’t work out what the directory is, it does nothing.
+
--java:javaexec
Use javaexec as the Java executable.
+The default java executable is the first one on your PATH.
+
--home:dir
Use dir as the DocBook
+xslTNG home directory. This should be the location where
+you unzipped the distribution. (You probably shouldn’t change this.)
+
--verbose
Enables verbose mode; it prints more
+messages about what it finds.
+
--debug
Enables debug mode. Instead of running the
+transformation, it will print out the command that would have been run.
+
--
Immediately stop interpreting options. Everything that follows this option
+will be passed to Saxon, even if it begins with two hyphens.
+
2.3. Run with Java
Assuming you’ve organized your class path so that all of the
+dependencies are available (you may find that using a tool like Gradle
+or Maven simplifies this process), simply run the Saxon class.
For Saxon HE, the class is net.sf.saxon.Transform.
+For Saxon PE and EE, the class is com.saxonica.Transform.
2.4. Run with Docker
This is experimental.
The docker directory
+contains an experimental Dockerfile. Using docker allows you to
+isolate the environment necessary to run the DocBook xslTNG
+Stylesheets from your local environment. (If you’re using Linux, see
+Section 2.4.1, “Docker on Linux”.)
Using Docker is a three step process. Step 0, you have to have
+installed Docker!
Build the docker image. In the docker directory, run the docker build
+command:
|$ docker build -t docbook-xsltng .
+
The “-t” option provides a tag for the image;
+you can make this anything you want. There’s a VERSION
+build argument if you want to build a particular release. For example,
will build a Docker image for the 2.2.2-SNAPSHOT release of the
+stylesheets irrespective of the version in the Dockerfile.
Run the image, for example:
|$ docker run docbook-xsltng samples/article.xml
+
If you chose a different tag when you built the image, use that
+tag in place of docbook-xsltng in the run
+command. Everything after the container tag becomes options to the
+docbook Python script.
+
ⓘ
Note
The context the script runs in is inside
+the container. It can’t for example, see your local filesystem. The
+example above works because the distribution is unpacked inside the
+container. So the article.xml document isn’t the
+one on your local filesystem.
You can use the Docker facilities for mounting directories to
+change what documents the script can access. For example:
+
Assuming that the “samples” directory in the distribution is
+located at /path/to/samples, this will chunk the
+article.xml sample document that the script sees
+in /input
+(which is where you mounted samples) and it will write the
+output to /output (which is where you mounted
+/tmp).
When the script finishes, the chunked output will be in
+/tmp.
☞
Tip
If you choose to use Docker, you don’t have to rebuild the container
+everytime a new stylesheet release occurs. You can simply mount the new
+xslt directory into the container
+like any other directory.
2.4.1. Docker on Linux
When a Docker container running on Linux writes to the local
+filesystem, for example because you mounted it in a container, any
+files written by the container will be owned by “root”. This can be
+quite inconvenient.
If there’s an elegant solution to this problem, I haven’t found it.
+Some users have reported success using podman,
+a Docker-compatible, open source alternative that apparently doesn’t exhibit this behavior.
+
The following approach will work with Docker, but it’s a bit more complicated.
Create a volume, say docbook-output,
+with the docker volume command.
|docker volume create docbook-output
+
Instead of mounting a directory on the local filesystem in the container, mount
+the volume.
Run the transformation.
In order to copy the files off the volume, the volume has to be
+mounted on a running container. You can start one with docker run,
+for example:
You may want to remove the volume you created as well:
|docker volume rm docbook-output
+
and recreate it for the next transformation. If you don’t, be
+aware that the content of the volume will persist. If you resuse the
+volume for other transformations, the output from the various
+transformations will be mingled together on the volume.
And, perhaps obviously, if you remove the volume before you copy
+the files off of it, the files will be lost.
In short: using a Docker container on Linux is somewhat less convenient.
2.5. Run in Oxygen
“Oxygen” is a family
+of tools for XML authoring and development. The DocBook
+xslTNG Stylesheets are not currently shipped with Oxygen. To
+take advantage of the xslTNG stylesheets, you must setup the transformation scenarios
+yourself.
Download the nosaxon xslTNG release that you want to use in Oxygen
+ (docbook-xslTNG-nosaxon-version.zip) and unzip
+ it somewhere in your filesystem.
+ (Oxygen includes Saxon EE; the integration will be cleaner if the release you
+ use does not include a different version of Saxon.)
Define a transformation scenario with
+ path/xslt/docbook.xsl as the XSLT
+ file (where path is where you unzipped the release in the previous step.
In order to use the extension functions defined in
+ Section 2.6, you have to add the
+ docbook-xslTNG-version.jar library as an
+ Extension and set
+ org.docbook.xslt.extensions as the Initializer class
+ in the Advanced Saxon HE/PE/EE XQuery Transformation Options for
+ the transformation scenario.
Without this step the basic transformation will work, but extensions like
+ image metadate extraction with ext:image-metadata will
+ not be available.
Set the stylesheet parameters accordingly in the transformation scenario.
Run the transformation to generate HTML output. You will have to copy the
+ resources/css and resources/js directories to
+ the output location in order to get the styling and interactive features.
2.6. Extension functions
The stylesheets are distributed with several extension functions:
Returns much more comprehensive image properties and understands
+far more image types than ext:image-properties().
+Requires the metadata-extractor libraries.
+
Performs XInclude processing. This extension supports
+the basic XPointer schemes, RFC 5147 fragment identifiers,
+and search, a scheme that supports searching in text
+documents.
+
At the time of this writing, all of these extension functions require
+Saxon 10.1 or later.
+Make sure that the docbook-xsltng-version.jar
+file is on your class path and use the Saxon -init option to
+load them:
-init:org.docbook.xsltng.extensions.Register
2.6.1. Extension function debugging
When an extension function fails, or produces result other than
+what you expect, it can be difficult sometimes to work out what
+happened. You can enable debugging messages by setting the the system
+property org.docbook.xsltng.verbose.
Setting the property to the value “true” enables
+all of the debugging messages. For a more selective approach, set it
+to a comma separated list of keyword values.
The following keywords are recognized:
registration
Enables messages related to function registration.
+
image-properties
Enables messages related to image properties.
+
image-errors
Enables messages related to image properties, but only when the
+function was unable to find the properties or encountered some sort of error
+condition.
+
pygmentize-show-command
Enables a message that will show the pygmentize command as it was run.
+
pygmentize-show-results
Enables a message that will show the output of the pygmentize command,
+before it is processed by the function.
+
pygmentize-errors
Enables messages related to errors encountered attempting to highlight
+listings with pygmentize.
+
2.7. “Chunked” output
Transforming myfile.xml with
+docbook.xsl usually produces a single HTML
+document. For large documents, books like this one for example, it’s
+sometimes desirable to break the input document into a collection of
+web pages. You can achieve this with the
+DocBook xslTNG Stylesheets by setting
+two parameters:
+
This parameter should be set to the absolute path where you want
+to use as the base URI for the result documents, for example
+/home/ndw/output/guide/.
ⓘ
Note
The trailing slash is important, this is a URI. If you specify
+only /home/ndw/output/guide, the
+base URI will be taken to be /home/ndw/output/,
+and the documents won’t have the URIs you expect.
This output URI has nothing to do with where your documents are
+ultimately published and the documents themselves won’t contain any references
+to it. It simply establishes the root of output. If you’re running your
+XSLT processor from the command line, it’s likely that the documents will
+be written to that location. If you’re running an XProc pipeline, it simply
+controls the URIs that appear on the secondary result port.
+
Many aspects of chunking can be easily customized. A few of the most
+relevant parameters and templates are:
+
These templates control how the top-of-page and bottom-of-page
+navigation aids are constructed.
2.7.1. Keyboard navigation
If the $chunk-nav parameter is
+true, a reference to an additional JavaScript library will
+be included in the resulting pages. This library supports keyboard
+navigation between the pages. The navigation keys are described in the
+parameter reference page.
+
2.8. Presentation mode
Presentation mode implements paged navigation through a document.
+For presentation mode, a single document is used (rather than chunking) with
+some JavaScript code providing the user interface.
As the name implies, it’s designed for use in presentations:
It uses generally
+larger fonts by default and works best for many small pages
Each unit of a
+document (part, chapter, article, section, etc.) becomes a page.
Presentation mode replaces earlier “slides” and “speaker notes” implementations.
Beyond the paginated navigation, presentation mode has three key features:
Synchronization
When served with https
+(or from localhost with
+http), presentation mode can use
+local storage to synchronize display in different browser windows.
The key name is irrelevant, but is used to coordinate between windows.
+All documents with the same key name will be synchronized together.
+*
+
Synchronized displays are useful for reading speaker notes in one view
+while presenting the “normal” view to your audience.
Speaker notes
Speaker notes can be placed on any page.
+They are not displayed as part of the normal presentation.
+They can be revealed by selecting notes view (pressing S).
+
Use the speaker-notes role to add speaker notes.
+
Progressive reveal
Any elements marked with the role reveal will
+be hidden initially. Navigating forward or pressing Space will reveal them.
When applied to lists, the behavior applies to
+all of the items except the first.
If an item is marked both reveal and transitory,
+it will be revealed in turn and then concealed again when the next item is revealed.
+This allows one to create the illusion, for example, of bullet items being replaced.
In sort, you get:
Quick and easy presentations from DocBook documents.
+
No special markup required.
+
Easy navigation.
+
Clean look and feel.
+
Advanced features:
+
Synchronized display
+
Speaker notes
+
Progressive and transitory reveals
+
Pressing F1 in a presentation mode document will display
+a summary of the keyboard navigation shortcuts.
There’s a small customization layer in the distribution,
+presentation.xsl that enables presentation mode
+and changes some of the generated text so that the labels “Part”, “Chapter”, and so forth aren’t
+in the output.
2.9. Effectivity attributes and profiling
When documenting computer hardware and software systems, it’s
+very common to have different documentation sets that overlap
+signficantly. Documentation for two different models of network
+router, for example, might differ only in a few specific details. Or a
+user guide aimed at experts might have a lot in common with the new user
+guide.
2.9.1. Effectivity
There are many ways to address this problem, but one of the
+simplest is to identify the “effectivity” of different parts of a
+document. Effectivity in this context means identifying the parts
+of a document that are effective for different audiences.
When a document is formatted, the stylesheets can selectively
+include or omit elements based on their configured effectivity. This
+“profiled” version of the document is the one that’s explicitly
+targeted to the audience specified.
DocBook supports a wide variety of common attributes for this
+purpose:
Table 2.1. Common DocBook effectivity attributes
Attribute
Nominal effectivity axis
arch
The architecture, Intel or AMD
audience
The audience, operations or development
condition
Any condition (semantically neutral)
conformance
The conformance level
os
The operating system, Windows or Linux
outputformat
The output format, print or online
revision
The revision, 3.4 or 4.0.
security
The security, secret or top-secret
userlevel
The user level, novice or expert
vendor
The vendor, Acme or Yoyodyne
wordsize
The word size, 32 or 64 bit
ⓘ
Note
DocBook places no constraints on the values used for effectivity
+and the stylesheets don’t either. You’re free to use “cat” and “dog”
+as effectivity values in the wordsize attribute, if you
+wish. The further you deviate from the nominal meaning, the more
+important it is to document your system!
<para>This is an utterly contrived example of
+some common text. Options are introduced with the
+<phrase os="windows">/</phrase>
+<phrase os="mac;linux">-</phrase> character.</para>
Example 2.1. A contrived effectivity example
If this document is formatted with the $profile-os
+parameter set to “windows”, it will produce:
This is an utterly contrived example of
+some common text. Options are introduced with the
+/
+ character.
If “mac” or “linux” is specified, it will produce:
This is an utterly contrived example of
+some common text. Options are introduced with the
+
+- character.
☝
Important
If the document is formatted without any profiling, all
+of the versions will be included:
This is an utterly contrived example of
+some common text. Options are introduced with the
+/
+- character.
That is unlikely to work well.
2.9.2. Other common Attributes
In addition, the stylesheets support profiling on several common attributes
+that are not explicitly for effectivity: xml:lang, revisionflag,
+and role.
ⓘ
The role attribute is multi-valued
The stylesheets treat the role attribute as
+multi-valued, similar to the class attribute in HTML. It
+may contain a sequence of tokens, seperated by whitespace. This allows you, for example,
+to classify a section as informal which should be printed in
+landscape orientation with the role value
+“informal landscape”.
If it specifies a value for an effectivity attribute, the value
+is split into tokens at the
+$profile-separator.
If the corresponding profile parameter is not empty, then the
+element is discarded unless at least one of the tokens in the profile
+parameter list is also in the effectivity list.
In practice, elements that don’t specify effectivity are always included
+and profile parameters that are empty don’t exclude any elements.
2.9.4. Dynamic profiling
Dynamic profiling is a feature that allows you to profile the output
+of the stylesheets according to the runtime values of stylesheet parameters.
+You can, for example, produce different output depending on whether or not
+chunking is enabled or JavaScript is being used for annotations.
In the interest of performance, security, and legibility,
+dynamic profiles don’t support arbitrary expressions.
+You can use a variable name by itself, $flag, which tests
+if that variable is true, or you can use a
+simple comparison, $var=value which tests if (the string value of)
+$var has the value value.
+(If $var is a list, it’s an existential
+test.) You also can’t use boolean operators or any other fancy expressions.
+
If you really need to have a dynamic profile based on some
+arbitrary condition, you can do it by making a customization layer
+that stores that computation in a variable and then testing that
+variable in your dynamic profile.
Backwards incompatibility
This is slightly backwards
+incompatible in that profile values that begin with a dollar sign are
+now interpreted differently. This is only true if dynamic profiling is
+enabled.
An element with dynamic profiling will be published if none of
+it’s profile expressions evaluate to false. This is slightly different
+from the ordinary profiling semantic which publishes the element if
+any of it’s values match.
2.10. Customize individual cross references
Most kinds of generated text apply across an entire document: do you want chapters
+to be numbered? Should generated text be in English or French? What form should numbered
+and unnumbered sections have? The mechanisms for changing this generated text are
+described in Chapter 4, Localization. These mechanisms control the formatting
+of cross references.
But it’s sometimes desirable to be able to change the format of a
+cross reference on an individual basis (that is, on the basis of the
+context in which the reference occurs, not the
+nature of what is referenced). You might, for
+example, want to shorten a cross reference to just a label if it’s
+already been referenced several times.
Consider a cross reference to a section:
+see <xref linkend="syntax-highlighting"/>.
+In the localization style of this guide, that is rendered like this:
+see Section 2.11, “Syntax highlighting”.
The text that is generated by a cross reference can be customized
+for individual references with the xrefstyle attribute.
+For example,
+see <xref linkend="syntax-highlighting" xrefstyle="%l"/>,
+will produce a result like this:
+see 2.11.
You can use the %c, %l and
+%p values from Table 4.1, “Template %-letter substitutions” in
+xrefstyle. There is also an additional
+%label for the full Label, which is
+the component`s name and number. The use of these percent-values is
+explained in the following table, where all cross references target
+the next section called Syntax highlighting.
The full Label, ususally the targets number and name.
%p
Page number. Intended for print output (PDF). Displayed as "#" in HTML,
+ unless you differentiate between the output formats for print and online. See Section 2.10.1 for a possible
+ solution.
You can use different %-letters and combine with text
Legacy values for xrefstyle
In order to support migration from XSLT 1.0 Stylesheets, xslTNG supports the
+template: Syntax which is explained in
+“Customizing
+ with an xrefstyle attribute / Using template:” in
+ the book “DocBook XSL: The Complete
+ Guide”. This is summarized in the following
+ table.
The %p makes little sense in HTML output, since there are no page numbers.
+ If you use it anyway, it will be displayed as "#", which can be
+ confusing for readers. A possible solution for this problem is the use of the
+ outputformat attribute, that was intoduced in Section 2.9, “Effectivity attributes and profiling” and
+ Table 2.1.
This cross reference to Section 2.11
+ will include the target`s page number only when the
+ @profile.outputformat parameter is "print", but without
+ the annoying # in HTML.
1 |This cross reference to
+|<xref linkend="syntax-highlighting" xrefstyle="%label/>
+|<phrase outputformat="print">
+| on <xref linkend="syntax-highlighting" xrefstyle="page %p"/>
+5 |</phrase>
+|will reference the page number only when the
+|@profile.outputformat parameter is print, but
+|without the annoying # in HTML.
+
Example 2.2. Use outputformat to deal with page numbers in cross references
2.11. Syntax highlighting
Program listings and other verbatim environments can be “syntax highlighted”,
+that is, the significant tokens in the listing can be colored differently (keywords in red,
+quoted strings in blue, that sort of thing).
The default syntax highlighter is Pygments, an external
+Python program. This has the advantage that the highlighted listing is available to
+the stylesheets. The stylesheets can then render line numbers, call outs, and other
+features.
But running an external program for every verbatim environment requires
+having the external program and also, if there are many verbatim
+environments, may slow down the formatting process
An alternative is to use a JavaScript highlighter in the browser such as
+highlight.js or Prism. This approach
+has no impact on formatting and doesn’t require an external process. However, it means the
+xslTNG Stylesheets have no control over the process. Most of the
+verbatim options only apply when Pygments is used.
The persistent Table of Contents (ToC) provides a full ToC for
+an entire document accessible from each chunked
+page.
The ToC is accessed by clicking on the “book” icon in the upper right
+corner of the page as shown in Figure 2.2, “Opening the ToC”.
Figure 2.2. Opening the ToC
The icon and other aspects of the style can be changed by providing
+$persistent-toc-css.
Once open, the ToC is displayed. A long ToC will be scrolled to
+the location of the current page in the document as shown in
+Figure 2.3, “The Persistent ToC”.
Figure 2.3. The Persistent ToC
The persistent ToC popup is transient by default, meaning that
+it will disappear if you use it to navigate to a different page. If
+you open the popup by “shift-clicking” on it, the ToC will persist
+until you dismiss it. This can also be accomplished by selecting the
+check box in the ToC. The presense of the search bar is controlled by
+the $persistent-toc-search parameter.
2.12.1. Persistent ToC data
The data used by the persistent ToC can be stored in a separate
+file or stored in each chunk. This is controlled by the
+$persistent-toc-filename.
If chunking is enabled and the
+$persistent-toc-filename parameter is non-empty,
+it’s used as a filename and a single copy of the ToC will be saved in
+that file.
The benefit of this approach is that the HTML chunks are
+smaller. If the persistent ToC is written into every chunk, the size
+of each HTML chunk increases in proportion to the size of the ToC. For
+a large document with lots of small pages, this can be a significant
+percentage of the overall size.
There are two disadvantages:
This will not work if the documents are accessed with
+file: URIs: you must use http (and in some
+environments, perhaps https) to load the documents. The
+browser will (quite reasonably) not allow JavaScript to load documents
+from the filesystem.
Also, with this approach, opening the ToC requires another
+document to be loaded into the browser. For a large ToC, this can
+introduce visible latency, although browser caching tends to reduce
+that after the document has been loaded once.
+
If the
+$persistent-toc-filename parameter is the empty
+sequence, a copy of the ToC is stored in each chunk.
ⓘ
Note
When stored in each chunk, the Table of Contents is secreted away in a
+script element so that
+it will be ignored by screen readers and other user agents that don’t
+support JavaScript or CSS.
+
The benefit of this approach is that it requires no additional
+document to be loaded and will work even if the documents are loaded
+with file URIs.
The disadvantage of this approach is that it increases the size of
+each chunk. Whether that matters depends on the size of the ToC, the relative
+size of the chunks, bandwidth and other constraints.
If chunking is not being used, there will
+only be one HTML result and the ToC will always be stored in that chunk.
+
2.13. On-page table of contents
Documents come in many shapes and sizes. Consequently, there are
+a variety of navigation mechanisms available. For long documents, such as books,
+a Table of Contents (ToC) is traditional (as are indexes). For web presentation,
+long documents may be broken into chunks, for example at the chapter level.
+In this case, header and footer navigation between chunks is almost always
+available. For large documents a “persistent
+ToC” can enable quick navigation from any chunk.
You can also enable an on-page ToC. The on-page ToC provides a
+navigation mechanism for sections within a page. By default, it
+appears on the right of the page if the window is wide enough to
+comfortably display it next to the main body.
The current implementation requires JavaScript. In fact it is not
+constructed from the DocBook markup, but instead from the HTML markup when
+the page is rendered. To be precise, the ToC is constructed from HTML
+section elements that
+begin with a header that
+contains an
+h1…h6
+element. It is therefore either a bug or a feature, depending on your perspective,
+that a customization layer that changes how sections are marked up will change
+what appears in the ToC. If you simply wish to suppress a particular section
+from appearing in the ToC, add nopagetoc to its
+class attribute.
Several parameters control presentation and formatting of the on-page ToC.
A list of the names of the elements (technically, the classes of
+the sections) that should get an on-page ToC. It’s empty by default (meaning no
+such ToC is rendered). For the standard presentation of this guide,
+the list is set to preface chapter appendix refentry.
+(The sneaky among you may wonder if you could simply set it to “component”
+because that class is used for all those elements; “Yes. Yes, you could.”)
+
Determines whether or not the ToC is “dynamic”. Inspired by
+Kevin Drum’s
+table of contents progress
+animation, the ToC keeps track of the reader’s location in the main
+view and highlights the corresponding sections in the ToC (albeit without the
+clever SVG animation of the original).
Set this parameter to false if you find the animation distracting.
+(If the animation is enabled, a control is provided to let the reader turn it off,
+in case they find it distracting.)
This is the JavaScript that implements the on-page ToC. Changing this
+parameter allows you to replace it with JavaScript of your own invention.
+
CSS
There is no pagetoc-css parameter; the CSS is integrated
+into the standard CSS. You can find it in the pagetoc.scss file
+in the repository if you want to change the presentation. (Don’t change that file,
+simply add overriding rules later in the cascade.)
+
There is also a JavaScript API that you can use to control some features
+of the presentation. This is done by adding a DocBook property to
+the browser’s window object. The value of the DocBook property
+should be a map. To control the on-page ToC, add a pagetoc property
+to the DocBook map. The value of this property must also be a map.
The properties of the pagetoc map can be used to change
+the display:
decorated
This is the markup used for the user-control on the on-page ToC when
+the ToC is decorated. The default value is “☀”.
+
plain
This is the markup used for the user-control on the on-page ToC when
+the ToC is plain (not decorated). The default value is “○”.
+
hidden
This is the markup used for the user-control on the on-page ToC when
+the ToC is hidden. The default value is “◄”.
+
nothing_to_reveal
This property controls how the on-page ToC is rendered if there are
+no additional sections to be revealed. It can have the value
+“hide”, to hide the ToC, “plain” to
+make its presentation plain in this case, or “decorated” to
+use the decorated style. The ToC will not appear if there are no sections.
+
To use the JavaScript API, make sure your assignments to the
+DocBook object are performed before the
+on-page ToC JavaScript is executed.
2.14. Paged-media (print output)
Formatters, the tools that turn markup of any sort into
+aesthetically pleasing (or even passably acceptable) printed pages are
+fiendishly difficult to write.
In the XML space, there have been a number of standards and
+vendor-specific solutions to this problem. The current standards are
+XSL FO and CSS.
+
At present, the DocBook xslTNG Stylesheets
+are focused on CSS for print output. There’s a customization layer
+that produces “paged-media-ready” HTML that can be processed with
+a CSS formatter such as Antenna House
+or Prince.
To get print output, format your documents with the
+print.xsl stylesheet instead of the
+docbook.xsl stylesheet. The additional cleanup provided
+by print.xsl assures that footnotes, annotations, and
+other elements will appear in the right place, and with reasonable
+presentation, in the printed version.
The resulting HTML document can be formatted directly with a
+CSS paged-media formatter.
2.14.1. Landscape orientation
The default orientation for pages in print output is portrait. The
+stylesheets support a simple mechanism for selecting landscape pages. This works
+in many common cases, but you may need additional CSS if you have complex requirements.
ⓘ
Note
This feature enables whole pages with a landscape orientation.
+It doesn’t support rotating a single block element (paragraph, table, figure, etc.) to
+lanscape orientation within an otherwise portrait page. If you rotate
+a single block element, it will introduce a page break before and after the element.
+
Rotations within an otherwise portrait page might be possible with custom
+CSS, depending on your formatting engine.
The stylesheets slightly abuse the role attribute
+(which is multi-valued) for this
+purpose. Placing the token landscape in the role attribute
+will select lanscape orientation for the element on which the role
+attribute appears. (Placing the token portrait in the role
+attribute will select portrait orientation in an otherwise landscape document.)
This may apply to the whole book or
+article, or to individual chapter, section or
+appendix elements.
You can also print individual tables or figures in landscape, if they are
+too wide for portrait pages. For wide tables, you should use the
+orient attribute with the value land, because it is
+provided precisely for this purpose. However, in the interests of a uniform
+solution, the role attribute with the value landscape
+can also be used for tables.
For legacy reasons, the landscapeFigure processing instruction from the XSLT 1.0 stylesheets is also supported for figure and
+informalfigure elements, as described
+in Chapter 18 of Bob Staytons Complete Guide.
+
2.14.1.1. AntennaHouse extensions
The rotation mechanism supported by standard CSS rotates the entire page,
+including any running headers and footers. For documents that are read online,
+this has some real advantages as the PDF viewer is likely to show the landscape
+pages “the right way up”.
But for documents that are going to be printed, or where a more
+traditional presentation is desirable, the goal is usually to rotate the
+content of the page, but not the page itself.
This can be accomplished with the AntennaHouse formatter using the
+$vendor-css extension. In an otherwise portrait document,
+including the vendor-ahf-portrait.css file using
+$vendor-css will present landscape rotations in the
+portrait page. If the document is being printed on landscape pages,
+including the vendor-ahf-landscape.css file using
+$vendor-css will present portrait
+rotations in the landscape page.
2.15. EPUB output
The DocBook xslTNG Stylesheets will
+produce output designed for EPUB(3) if you use the
+epub.xsl stylesheet instead of
+docbook.xsl. This is new in version 1.11.0 and
+may be incomplete. The output conforms to
+EPUBCheck
+version 3.2.
Producing an EPUB file is a slightly complicated process. You
+must produce (X)HTML that conforms to strict requirements, you must
+produce a media type document containing a specific text string, you
+must produce a manifest that identifies all of the content including
+all the images, stylesheets, fonts, etc, and you must finally create a
+ZIP archive (with some special consideration as well).
The stylesheets can only do part of this process. In some future
+release where we use, for example, an XProc 3.0 pipeline, it may be
+practical to do more.
When you run the EPUB stylesheet, the principle result document is the
+media type document. This has two useful side effects: first, it establishes the
+output base URI from which all the relative documents can be created, and second, if
+you fail to process some element in the input, you’re likely to get extra text characters
+in the principle result document. That will cause tools to reject the EPUB and draw your
+attention to the error.
The stylesheets also produce the META-INF files and the OPS
+directory containing the document parts and the manifest.
There are two parameters specific to EPUB:
pub-id
This is the unique identifier for your EPUB. If you don’t specify one, a random
+one will be generated for you.
+
manifest-extra
This is a URI. If it’s specified, then it must be an XML document and that will
+be added to the EPUB manifest. This is how you can add links to media and other resources
+that the stylesheets don’t know about.
+
2.15.1. Adding metadata
You can add elements to the info element of the root element of your
+document to add metadata to your EPUB files. Elements in the Dublin Core namespace
+will be copied through. You can also add the elements
+meta and link in the special namespace
+http://docbook.org/ns/docbook/epub.
2.15.2. EPUB in action
The Getting
+Started project has been updated to show how to create EPUB
+from a book. The project has support for dealing with external media,
+fonts, and constructing the final ZIP file.
2.16. Ad hoc CSS styling
Generally speaking, it’s considered good practice to separate
+content from presentation. On the web, this is most often accomplished
+with clean, structural HTML as the content and CSS styling providing
+the presentation. Indeed, that’s how the output from the
+DocBook xslTNG Stylesheets is
+structured.
And yet, sometimes you need to tweak individual elements in
+small ways. For example, you may want to change the style of a single
+programlisting to avoid a page break inside it. Or perhaps
+you need to make some adjustment to a single image.
In principle, this can be done in a completely “hands off”
+manner: add an ID to the element and add an ID selector to the
+external CSS file. In practice, that’s a bit tedious and there’s
+nothing in the source to suggest that the styling is required or even
+exists.
HTML allows for inline styles with the style attribute and starting in version 2.1.5,
+the xslTNG stylesheets provide a way to access this feature.
DocBook allows namespace qualified attributes on any element.
+Adding attributes in the https://xsltng.docbook.org/ns/css
+namespace to an element will add those properties to the HTML style attribute. For example:
The generated HTML wraps up the CSS properties in a style
+attribute:
|<p style="padding:0.5em;border:1px solid blue;border-radius:0.5em;"
+|>This is a pargraph with a border.</p>
+
To facilitate different properties based on the output medium, the stylesheets
+will also look for attributes in the
+“https://xsltng.docbook.org/ns/css#$output-media”
+namespace. For example, this paragraph:
Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License,
+Version 1.1 or any later version published by the Free Software
+Foundation.
+A copy of the license is included in Appendix B, GNU Free Documentation License.
Many of the designations used by manufacturers and sellers to
+distinguish their products are claimed as trademarks. Where those
+designations appear in this book and the authors were aware
+of a trademark claim, the designations have been printed in caps or
+initial caps.
While every precaution has been taken in the preparation of this
+book, the publisher and author assume no responsibility for errors or
+omissions, or for damages resulting from the use of the information
+contained herein.
This extension function returns the current working directory from which
+the processor was executed.
+
III . Function reference
ext:image-metadata
\ No newline at end of file
diff --git a/guide/2.2.2/ext_image-metadata.html b/guide/2.2.2/ext_image-metadata.html
new file mode 100644
index 0000000000..5bec050901
--- /dev/null
+++ b/guide/2.2.2/ext_image-metadata.html
@@ -0,0 +1,44 @@
+ext:image-metadataDocBook xslTNG Reference
ext:image-metadata
ext:image-metadata — Return intrinsic properties of an image.
This extension function returns a map of metadata properties
+about the image, including its intrinsic size:
+its width and height in pixels. If the size can be determined, the map
+returned will have a “width” key whose value is the
+width of the image and a “height” key whose value
+is the height of the image. Both sizes will be integer values.
+
+
This function uses the metadata-extractor
+library. The map may contain other properties as well.
+
+
If the media was successfully parsed with metadata-extractor,
+all of the properties identified by the extractor will be returned. Each property
+name will be converted to lowercase and spaces will be replaced with hyphens.
+(In other words, a property with the tag name “Palette Colour Count” will appear
+in the map with a key of “palette-colour-count”.)
Property values that appear to be data/time values* will be converted to
+strings that are valid ISO 8601 date/time values. Any control characters that can’t appear
+in XML but that appear in a value will be replaced with Unicode references,
+\uxxxx. For example, a null byte will be
+replaced with \u0000.
If the media isn’t successfully parsed with metadata-extractor,
+
If it appears to be a PDF document, the function will search for the
+“MediaBox” or “CropBox” in the first 100 lines
+of the PDF. If either is found, its dimensions are used to calculate the width and height.
+If both are present, CropBox is preferred.
+
If it appears to be an SVG document, the function will search
+for width and height attributes on the root
+element. All of the attributes of the root element will be returned as
+properties, using Clark
+names.
+
+
+
If the width and height properties
+exist, they will always be integers. This means that if an image has a property
+with the name width or height and its value
+isn’t an integer, it will not be returned.
+
+
If the $debug parameter includes the token
+image-properties, the stylesheets will print every property
+returned in an xsl:message.
+
ext:cwd
ext:image-properties
\ No newline at end of file
diff --git a/guide/2.2.2/ext_image-properties.html b/guide/2.2.2/ext_image-properties.html
new file mode 100644
index 0000000000..1455a46ff9
--- /dev/null
+++ b/guide/2.2.2/ext_image-properties.html
@@ -0,0 +1,11 @@
+ext:image-propertiesDocBook xslTNG Reference
ext:image-properties
ext:image-properties — Return intrinsic properties of an image.
This extension function returns the intrinsic size of
+an image: its width and height in pixels. If the size can be determined, the map returned
+will have a “width” key whose value is the width of the image and
+a “height” key whose value is the height of the image. Both sizes
+will be integral numbers of pixels.
\ No newline at end of file
diff --git a/guide/2.2.2/ext_pygmentize-available.html b/guide/2.2.2/ext_pygmentize-available.html
new file mode 100644
index 0000000000..277ee73b4e
--- /dev/null
+++ b/guide/2.2.2/ext_pygmentize-available.html
@@ -0,0 +1,16 @@
+ext:pygmentize-availableDocBook xslTNG Reference
ext:pygmentize-available
ext:pygmentize-available — Returns true if pygmentize is available.
In order to run Pygments on listings, the
+ext:pygmentize() extension function must be
+available and the pygmentize
+(pygmentize.exe on Windows) command must be
+available on the host system.
+
+
If it’s inconvenient to put pygmentize on the system path,
+you can specify an explicit location with the Java system property
+org.docbook.xsltng.extensions.pygmentize. The value of the property
+should be the fully qualified path name of the executable.
+
+
This function returns true if it successfully finds the
+pygmentize command on the system path.
+
ext:pygmentize
ext:validate-with-relax-ng
\ No newline at end of file
diff --git a/guide/2.2.2/ext_pygmentize.html b/guide/2.2.2/ext_pygmentize.html
new file mode 100644
index 0000000000..088bc2cf07
--- /dev/null
+++ b/guide/2.2.2/ext_pygmentize.html
@@ -0,0 +1,18 @@
+ext:pygmentizeDocBook xslTNG Reference
ext:pygmentize
ext:pygmentize — Syntax highlight a listing with pygmentize.
Function:
{http://docbook.org/extensions/xslt}pygmentize#1
{http://docbook.org/extensions/xslt}pygmentize#2
{http://docbook.org/extensions/xslt}pygmentize#3
Synopsis
ext:pygmentize(
$listing as xs:string) as xs:string
ext:pygmentize(
$listing as xs:string,
$options as item()) as xs:string
ext:pygmentize(
$listing as xs:string,
$options as item(),
$pygments-options as map(xs:string,xs:string)) as xs:string
Description
+
+
This extension function runs the pygmentize command to
+add syntax highlighting to a listing.
+
The second argument can either be map, in which case the key-value pairs of the map
+constitute the options, or it can be a single string. If it’s a single string, it’s
+interpreted as if it was a map with the key “language” and the string
+as the value.
+
The third argument must be a map. Each key-value pair will be passed to
+pygmentize as “-Pkey=value”.
+
+
The function returns the string output from pygmentize. It must
+be parsed with parse-xml if you wish to process it as XML.
+
Be aware that pygmentize strips leading blank
+lines off of the source listing. If you’re selecting portions of a
+listing with XInclude, make sure not to select leading blank lines in
+the listing if you are trying to accurately count the lines.
+
ext:image-properties
ext:pygmentize-available
\ No newline at end of file
diff --git a/guide/2.2.2/ext_validate-with-relax-ng.html b/guide/2.2.2/ext_validate-with-relax-ng.html
new file mode 100644
index 0000000000..741383cedc
--- /dev/null
+++ b/guide/2.2.2/ext_validate-with-relax-ng.html
@@ -0,0 +1,25 @@
+ext:validate-with-relax-ngDocBook xslTNG Reference
ext:validate-with-relax-ng
ext:validate-with-relax-ng — Returns the current working directory.
$options as map(xs:string, xs:string)) as map(xs:string, item())
Description
+
+
This extension function validates the node provided
+against the schema. The schema can be either a
+string (the URI of the RELAX NG grammar file) or a node (a RELAX NG grammar
+document). There is no support for the RELAX NG Compact Syntax at this time.
+
+
The available options are assert-valid which defaults to
+true()
+and dtd-compatibility which isn’t actually supported yet.
+
If assert-valid is true() and the document is
+not valid according to the grammar provided, an exception is raised.
+
If assert-valid is false(), or the document
+is valid, the map returned will contain the following keys:
+
+
valid
A boolean indicating whether or not the document was valid.
+
document
The validated document. Today, this always returns the same node, but
+it may eventually return an augmented document.
+
errors
An array of maps containing the type
+(warning, error, or fatal-error),
+message,
+line, and column where an error occurred.
+If the document is valid, the errors key will not be present.
+
+
ext:pygmentize-available
ext:xinclude
\ No newline at end of file
diff --git a/guide/2.2.2/ext_xinclude.html b/guide/2.2.2/ext_xinclude.html
new file mode 100644
index 0000000000..10fd7ffc0c
--- /dev/null
+++ b/guide/2.2.2/ext_xinclude.html
@@ -0,0 +1,6 @@
+ext:xincludeDocBook xslTNG Reference
ext:xinclude
ext:xinclude — Performs XInclude processing.
Function:
{http://docbook.org/extensions/xslt}xinclude#1
{http://docbook.org/extensions/xslt}xinclude#2
Synopsis
ext:xinclude(
$node as node()) as node()*
ext:xinclude(
$node as node(),
$options as map(xs:QName, item()*)) as node()*
Description
+
+
Performs XInclude processing on node and all of its
+descendants. The options “fixup-xml-base” and
+“fixup-xml-lang” are true() by default.
+
ext:validate-with-relax-ng
f:absolute-length
\ No newline at end of file
diff --git a/guide/2.2.2/f_absolute-length.html b/guide/2.2.2/f_absolute-length.html
new file mode 100644
index 0000000000..16281604b0
--- /dev/null
+++ b/guide/2.2.2/f_absolute-length.html
@@ -0,0 +1,11 @@
+f:absolute-lengthDocBook xslTNG Reference
f:absolute-length
f:absolute-length — Returns the absolute length of a unit of measurement.
\ No newline at end of file
diff --git a/guide/2.2.2/f_attributes.html b/guide/2.2.2/f_attributes.html
new file mode 100644
index 0000000000..ad87d1da1c
--- /dev/null
+++ b/guide/2.2.2/f_attributes.html
@@ -0,0 +1,11 @@
+f:attributesDocBook xslTNG Reference
f:attributes
f:attributes — Returns the attribute that apply to an output element.
Most output elements have attributes: any xml:id
+attributes in the source are reflected in the output as
+id attributes, most elements get a class
+attribute, etc. The f:attributes() function is called to determine
+what those attributes should be.
+
In practice, the way this usually works is the element is processed in the
+m:attributes mode and that template calls f:attributes()
+to generate the actual attribute nodes.
+
f:absolute-length
f:available-bibliographies
\ No newline at end of file
diff --git a/guide/2.2.2/f_available-bibliographies.html b/guide/2.2.2/f_available-bibliographies.html
new file mode 100644
index 0000000000..ede4bef660
--- /dev/null
+++ b/guide/2.2.2/f_available-bibliographies.html
@@ -0,0 +1,17 @@
+f:available-bibliographiesDocBook xslTNG Reference
f:available-bibliographies
f:available-bibliographies — Returns a list of all available bibliographies.
The bibliographies available are all of the bibliographys in the current
+document plus any that are referenced with
+db processing instructions using the
+bibliography-collection pseudo-attribute in the root element.
+
+
In the two-argument form, a list of additional
+URIs may be passed. In common usage, the $bibliography-collection parameter
+is passed this way. (It’s not referenced directly because these functions are available
+for use outside of the stylesheets, for example in Schematron rules, in
+standalone-functions.xsl.)
+
+
The $term argument is only used to establish the context document for
+finding bibliographies in the current document.
+
f:attributes
f:available-glossaries
\ No newline at end of file
diff --git a/guide/2.2.2/f_available-glossaries.html b/guide/2.2.2/f_available-glossaries.html
new file mode 100644
index 0000000000..989914a203
--- /dev/null
+++ b/guide/2.2.2/f_available-glossaries.html
@@ -0,0 +1,17 @@
+f:available-glossariesDocBook xslTNG Reference
f:available-glossaries
f:available-glossaries — Returns a list of all available glossaries.
The glossaries available are all of the glossarys in the current
+document plus any that are referenced with
+db processing instructions using the
+glossary-collection pseudo-attribute in the root element.
+
+
In the two-argument form, a list of additional
+URIs may be passed. In common usage, the $glossary-collection parameter
+is passed this way. (It’s not referenced directly because these functions are available
+for use outside of the stylesheets, for example in Schematron rules, in
+standalone-functions.xsl.)
+
+
The $term argument is only used to establish the context document for
+finding glossaries in the current document.
+
f:available-bibliographies
f:biblioentries
\ No newline at end of file
diff --git a/guide/2.2.2/f_biblioentries.html b/guide/2.2.2/f_biblioentries.html
new file mode 100644
index 0000000000..ef44a24b41
--- /dev/null
+++ b/guide/2.2.2/f_biblioentries.html
@@ -0,0 +1,23 @@
+f:biblioentriesDocBook xslTNG Reference
f:biblioentries
f:biblioentries — Returns a list of all bibliographic entries for a citation.
Returns all the biblioentry or bibliomixed
+elements that have an abbrev that matches a
+citation. The internal bibliography of the input document
+is always taken into account.
+
In the form with only one argument, external bibliographies are also taken into account if
+they are designated in the input document with a <?db
+biblioary-collection='URIs'?> processing instruction.
+In the form with two arguments, you can specify a list of URIs of the external
+bibliographies.
+
+
When more than one entry is found, the result sequence will
+start with entries from the internal bibliography, if any.
+
+
The function is designed so that it can be used independently from
+the xslTNG stylesheets. You can, for example, integrate it in a
+Schematron rule that checks whether every citation has
+exactly one corresponding bibliographic entry while authoring your
+document.
+
+
f:available-glossaries
f:cals-colsep
\ No newline at end of file
diff --git a/guide/2.2.2/f_cals-colsep.html b/guide/2.2.2/f_cals-colsep.html
new file mode 100644
index 0000000000..ebf14e4bd2
--- /dev/null
+++ b/guide/2.2.2/f_cals-colsep.html
@@ -0,0 +1,7 @@
+f:cals-colsepDocBook xslTNG Reference
f:cals-colsep
f:cals-colsep — Returns the “colsep” value associated with a CALS table cell.
The column separator, or “colsep”, associated with a CALS table cell
+depends on a variety of factors: colspec, and spanspec
+elements as well as the attributes on the cell itself and its ancestors.
+
This function returns the value that applies to the specified cell.
+
f:biblioentries
f:cals-rowsep
\ No newline at end of file
diff --git a/guide/2.2.2/f_cals-rowsep.html b/guide/2.2.2/f_cals-rowsep.html
new file mode 100644
index 0000000000..4c1774964c
--- /dev/null
+++ b/guide/2.2.2/f_cals-rowsep.html
@@ -0,0 +1,7 @@
+f:cals-rowsepDocBook xslTNG Reference
f:cals-rowsep
f:cals-rowsep — Returns the “rowsep” value associated with a CALS table cell.
The row separator, or “rowsep”, associated with a CALS table cell
+depends on a variety of factors: colspec, and spanspec
+elements as well as the attributes on the cell itself and its ancestors.
+
This function returns the value that applies to the specified cell.
+
f:cals-colsep
f:check-gentext
\ No newline at end of file
diff --git a/guide/2.2.2/f_check-gentext.html b/guide/2.2.2/f_check-gentext.html
new file mode 100644
index 0000000000..c618860b27
--- /dev/null
+++ b/guide/2.2.2/f_check-gentext.html
@@ -0,0 +1,4 @@
+f:check-gentextDocBook xslTNG Reference
\ No newline at end of file
diff --git a/guide/2.2.2/f_chunk-filename.html b/guide/2.2.2/f_chunk-filename.html
new file mode 100644
index 0000000000..d57e620cd9
--- /dev/null
+++ b/guide/2.2.2/f_chunk-filename.html
@@ -0,0 +1,10 @@
+f:chunk-filenameDocBook xslTNG Reference
f:chunk-filename
f:chunk-filename — Returns the filename to use for a particular chunk.
When chunking, see Section 2.7, ““Chunked” output”, this function is
+called to determine the filename for a chunk. The default implementation considers
+relevant db processing instructions
+(filename,
+href, and
+basename pseudo-attributes) as well as the generated ID of the element.
+
+
f:chunk
f:chunk-title
\ No newline at end of file
diff --git a/guide/2.2.2/f_chunk-title.html b/guide/2.2.2/f_chunk-title.html
new file mode 100644
index 0000000000..6c74229568
--- /dev/null
+++ b/guide/2.2.2/f_chunk-title.html
@@ -0,0 +1,8 @@
+f:chunk-titleDocBook xslTNG Reference
When the title of a neighboring chunk is required (for header or
+footer navigation, for example), this function can be used to obtain
+the title of that chunk.
+
This function must return the HTML-formatted title, not the DocBook title.
+
+
f:chunk-filename
f:citations
\ No newline at end of file
diff --git a/guide/2.2.2/f_chunk.html b/guide/2.2.2/f_chunk.html
new file mode 100644
index 0000000000..90d4a53d1d
--- /dev/null
+++ b/guide/2.2.2/f_chunk.html
@@ -0,0 +1,6 @@
+f:chunkDocBook xslTNG Reference
f:chunk
f:chunk — Returns chunking attributes.
Function:
{http://docbook.org/ns/docbook/functions}chunk#1
Defined in:
modules/chunk.xsl
Used in:
modules/attributes.xsl
Synopsis
f:chunk(
$node as element()) as attribute()*
Description
+
+
This function returns the
+db-chunk and perhaps other chunking-related attributes
+for the given node.
+
f:check-gentext
f:chunk-filename
\ No newline at end of file
diff --git a/guide/2.2.2/f_citations.html b/guide/2.2.2/f_citations.html
new file mode 100644
index 0000000000..d6d5b094dc
--- /dev/null
+++ b/guide/2.2.2/f_citations.html
@@ -0,0 +1,7 @@
+f:citationsDocBook xslTNG Reference
Returns all of the citation elements in the document that match
+$term. The document is identified by $root, if specified,
+otherwise the document is the one that $term appears in.
+
+
f:chunk-title
f:conditional-orientation-class
\ No newline at end of file
diff --git a/guide/2.2.2/f_conditional-orientation-class.html b/guide/2.2.2/f_conditional-orientation-class.html
new file mode 100644
index 0000000000..61781092b4
--- /dev/null
+++ b/guide/2.2.2/f_conditional-orientation-class.html
@@ -0,0 +1,9 @@
+f:conditional-orientation-classDocBook xslTNG Reference
f:conditional-orientation-class
f:conditional-orientation-class — Returns an element’s orientation if it differs from its parent.
Determines if the element specified should be printed in portrait or landscape
+orientation. If that value is the same as the parent element’s value, an empty sequence
+is returned instead.
+
+
This avoids “double rotation” of, for example, a landscape table within a landscape chapter.
+
+
f:citations
f:css-length
\ No newline at end of file
diff --git a/guide/2.2.2/f_css-length.html b/guide/2.2.2/f_css-length.html
new file mode 100644
index 0000000000..73f08a600c
--- /dev/null
+++ b/guide/2.2.2/f_css-length.html
@@ -0,0 +1,5 @@
+f:css-lengthDocBook xslTNG Reference
f:css-length
f:css-length — Returns a length in the format of a CSS property.
Returns the CSS property specified with the corresponding length, if the length
+exists. Returns the empty sequence otherwise.
+
f:conditional-orientation-class
f:css-property
\ No newline at end of file
diff --git a/guide/2.2.2/f_css-property.html b/guide/2.2.2/f_css-property.html
new file mode 100644
index 0000000000..a6e32bcae3
--- /dev/null
+++ b/guide/2.2.2/f_css-property.html
@@ -0,0 +1,6 @@
+f:css-propertyDocBook xslTNG Reference
f:css-property
f:css-property — Returns a CSS property for a given value.
If the specified value exists, a string formatted as a CSS
+property is returned. If the value doesn’t exist, an empty sequence is
+returned.
+
f:css-length
f:date-format
\ No newline at end of file
diff --git a/guide/2.2.2/f_date-format.html b/guide/2.2.2/f_date-format.html
new file mode 100644
index 0000000000..2af7052718
--- /dev/null
+++ b/guide/2.2.2/f_date-format.html
@@ -0,0 +1,36 @@
+f:date-formatDocBook xslTNG Reference
f:date-format
f:date-format — Returns the format string for a date.
Dates may be stored in a variety of formats and the pubdate
+element even allows inline markup. The f:date-format() function
+determines how a date will be formatted:
+
If the date contains embedded markup, the special value
+“apply-templates” is returned to indicate that string formatting
+isn’t appropriate.
If the date does not conform to either of those date formats,
+“apply-templates” is returned.
+
+
If the date conforms to a date or dateTime, the author may override
+the format string by providing a
+db processing instruction with a
+date-format pseudo-attribute.
With default formats, these are formatted as shown:
+
+
The Unix epoch begins at
+00:00 01 Jan 1970.
+Grace Hopper was born on 09 Dec 1906.
+That was a Sunday.
+I was born on a Friday.
+
+
f:css-property
f:empty-length
\ No newline at end of file
diff --git a/guide/2.2.2/f_empty-length.html b/guide/2.2.2/f_empty-length.html
new file mode 100644
index 0000000000..2d766d87e1
--- /dev/null
+++ b/guide/2.2.2/f_empty-length.html
@@ -0,0 +1,21 @@
+f:empty-lengthDocBook xslTNG Reference
f:empty-length
f:empty-length — Returns a map that represents an empty length.
Lengths are compound objects. Lengths consist of
+a magnitude (a number) and a unit: 3 inches, for example, or 11.9
+barleycorns⌖2 in the case of absolute
+lengths. For relative lengths, the unit is something relative like percent.
+
These are represented as maps internally and f:empty-length()
+returns a length with no magnitude or units.
+
+
+
f:date-format
f:equal-lengths
\ No newline at end of file
diff --git a/guide/2.2.2/f_equal-lengths.html b/guide/2.2.2/f_equal-lengths.html
new file mode 100644
index 0000000000..756fd7352e
--- /dev/null
+++ b/guide/2.2.2/f_equal-lengths.html
@@ -0,0 +1,5 @@
+f:equal-lengthsDocBook xslTNG Reference
f:equal-lengths
f:equal-lengths — Returns true if two lengths are equal.
Lengths (see Section 5.2, “Lengths and units”) are stored in maps and so are not
+directly comparable. This function returns true if two lengths are equal.
+
f:empty-length
f:generate-id
\ No newline at end of file
diff --git a/guide/2.2.2/f_generate-id.html b/guide/2.2.2/f_generate-id.html
new file mode 100644
index 0000000000..af0ec28c36
--- /dev/null
+++ b/guide/2.2.2/f_generate-id.html
@@ -0,0 +1,15 @@
+f:generate-idDocBook xslTNG Reference
f:generate-id
f:generate-id — Generate a unique identifier for an element.
This function returns a unique ID for an element. The ID is
+generated from the names of the ancestors and preceding siblings of
+the element. This value will be consistent across different
+transformations as long as the ancestors and preceding siblings remain
+unchanged.
+
If use-xml-idis true
+and there’s an element with a xml:id attribute among
+the ancestors, the unique identifier is rooted at that element, rather
+than traversing all the way to the root of the document.
+
Disabling this feature by setting use-xml-id
+to false allows for the creation of globally unique IDs with
+f:unique-id().
+
f:equal-lengths
f:gentext
\ No newline at end of file
diff --git a/guide/2.2.2/f_gentext-letters-for-language.html b/guide/2.2.2/f_gentext-letters-for-language.html
new file mode 100644
index 0000000000..7b3a34fa5b
--- /dev/null
+++ b/guide/2.2.2/f_gentext-letters-for-language.html
@@ -0,0 +1,5 @@
+f:gentext-letters-for-languageDocBook xslTNG Reference
f:gentext-letters-for-language
f:gentext-letters-for-language — Returns the letters for a language.
Returns a language-specific list of letters. These are used, for example,
+to construct the divisions in an index.
+
f:gentext-letters
f:glossentries
\ No newline at end of file
diff --git a/guide/2.2.2/f_gentext-letters.html b/guide/2.2.2/f_gentext-letters.html
new file mode 100644
index 0000000000..0b9df04475
--- /dev/null
+++ b/guide/2.2.2/f_gentext-letters.html
@@ -0,0 +1,7 @@
+f:gentext-lettersDocBook xslTNG Reference
f:gentext-letters
f:gentext-letters — Returns the letters for the in-scope language.
\ No newline at end of file
diff --git a/guide/2.2.2/f_gentext.html b/guide/2.2.2/f_gentext.html
new file mode 100644
index 0000000000..462dfe1376
--- /dev/null
+++ b/guide/2.2.2/f_gentext.html
@@ -0,0 +1,5 @@
+f:gentextDocBook xslTNG Reference
\ No newline at end of file
diff --git a/guide/2.2.2/f_glossentries.html b/guide/2.2.2/f_glossentries.html
new file mode 100644
index 0000000000..859ff06cae
--- /dev/null
+++ b/guide/2.2.2/f_glossentries.html
@@ -0,0 +1,19 @@
+f:glossentriesDocBook xslTNG Reference
f:glossentries
f:glossentries — Returns a list of all glossentries for a term.
$collections as xs:string*) as element(db:glossentry)*
Description
+
+
Returns all glossentry elements that are targeted by $term,
+ which must either by a glossterm or a firstterm element. The
+ internal glossary of the input document is always taken into account.
+
In the form with only one argument, external glossaries are also taken into account if
+ they are designated in the input document with a <?db
+ glossary-collection='URIs'?> processing instruction.
+ In the form with two arguments, you can specify a list of URIs of the external
+ glossaries.
+
+
When there is more than one glossentry found, the result sequence will
+ start with entries from the internal glossary, if any.
+
The functions design allows its use independent from the xslTNG stylesheets. You can, for
+ example, integrate it in a Schematron rule that checks whether every glossterm
+ has exactly one corresponding glossentry while authoring your document. That’s
+ why the function can't use the $glossary-collection transformation
+ parameter.
+
f:gentext-letters-for-language
f:glossrefs
\ No newline at end of file
diff --git a/guide/2.2.2/f_glossrefs.html b/guide/2.2.2/f_glossrefs.html
new file mode 100644
index 0000000000..0d6365cb93
--- /dev/null
+++ b/guide/2.2.2/f_glossrefs.html
@@ -0,0 +1,7 @@
+f:glossrefsDocBook xslTNG Reference
f:glossrefs
f:glossrefs — Returns the glossary references for a term.
Returns all of the glossterm and firstterm elements in the document that match
+$term. The document is identified by $root, if specified,
+otherwise the document is the one that $term appears in.
+
+
f:glossentries
f:highlight-verbatim
\ No newline at end of file
diff --git a/guide/2.2.2/f_highlight-verbatim.html b/guide/2.2.2/f_highlight-verbatim.html
new file mode 100644
index 0000000000..3d3535a483
--- /dev/null
+++ b/guide/2.2.2/f_highlight-verbatim.html
@@ -0,0 +1,7 @@
+f:highlight-verbatimDocBook xslTNG Reference
Returns true if the specified verbatim environment should have
+syntax highlighting applied to it. This depends on the
+language specified on the environment and the
+$verbatim-syntax-highlight-languages parameter.
+
f:glossrefs
f:href
\ No newline at end of file
diff --git a/guide/2.2.2/f_href.html b/guide/2.2.2/f_href.html
new file mode 100644
index 0000000000..82a867007f
--- /dev/null
+++ b/guide/2.2.2/f_href.html
@@ -0,0 +1,6 @@
+f:hrefDocBook xslTNG Reference
This function generates a value for an HTML href attribute
+at the position of the context that will link to the node.
+
+
f:highlight-verbatim
f:id
\ No newline at end of file
diff --git a/guide/2.2.2/f_id.html b/guide/2.2.2/f_id.html
new file mode 100644
index 0000000000..0adb63e8e4
--- /dev/null
+++ b/guide/2.2.2/f_id.html
@@ -0,0 +1,12 @@
+f:idDocBook xslTNG Reference
This function returns the ID of the element. If the element has
+an xml:id attribute, the value of that attribute is returned.
+Otherwise, the function constructs a unique ID value for the element.
+
The simplest way to construct a unique ID is with the f:generate-id()
+function. However, those values are only unique within the context of a single transformation
+and tend to vary over time. This can break anchors used in published documents and leads
+to spurious differences between documents.
+
The stylesheets generate their own unique IDs with f:generate-id().
+
+
f:href
f:in-scope-language
\ No newline at end of file
diff --git a/guide/2.2.2/f_in-scope-language.html b/guide/2.2.2/f_in-scope-language.html
new file mode 100644
index 0000000000..7010ae6e94
--- /dev/null
+++ b/guide/2.2.2/f_in-scope-language.html
@@ -0,0 +1,6 @@
+f:in-scope-languageDocBook xslTNG Reference
f:in-scope-language
f:in-scope-language — Returns the in-scope-language associated with an element.
Returns the value of the nearest in-scope xml:lang attribute
+or $default-language if no such attribute exists.
+
+
f:id
f:intra-number-separator
\ No newline at end of file
diff --git a/guide/2.2.2/f_intra-number-separator.html b/guide/2.2.2/f_intra-number-separator.html
new file mode 100644
index 0000000000..4ea9da15e2
--- /dev/null
+++ b/guide/2.2.2/f_intra-number-separator.html
@@ -0,0 +1,5 @@
+f:intra-number-separatorDocBook xslTNG Reference
f:intra-number-separator
f:intra-number-separator — Return the intra-number separator.
\ No newline at end of file
diff --git a/guide/2.2.2/f_is-empty-length.html b/guide/2.2.2/f_is-empty-length.html
new file mode 100644
index 0000000000..e4bc988550
--- /dev/null
+++ b/guide/2.2.2/f_is-empty-length.html
@@ -0,0 +1,6 @@
+f:is-empty-lengthDocBook xslTNG Reference
\ No newline at end of file
diff --git a/guide/2.2.2/f_is-true.html b/guide/2.2.2/f_is-true.html
new file mode 100644
index 0000000000..01f385d686
--- /dev/null
+++ b/guide/2.2.2/f_is-true.html
@@ -0,0 +1,16 @@
+f:is-trueDocBook xslTNG Reference
f:is-true
f:is-true — Determines if a given value represents “true”
There are several conventions for indicating “true” or “false”.
+XSLT uses the words “yes” and “no” in many places. The XML Schema data
+type for xs:boolean uses “true” and “false” but also “1”
+and “0”.
+
The f:is-true() function returns
+true() for any of “true()”, “yes”, “true”,
+or a value that can be cast to an integer if that integer is not
+zero. It returns
+false()
+for any of “false()”, “no”, “false”, a value that can be
+cast to an integer that is zero, or the empty sequence.
+
It reports an error for any other value and returns “true()”.
+
+
f:is-empty-length
f:l10n-language
\ No newline at end of file
diff --git a/guide/2.2.2/f_l10n-language.html b/guide/2.2.2/f_l10n-language.html
new file mode 100644
index 0000000000..a1d3847fbc
--- /dev/null
+++ b/guide/2.2.2/f_l10n-language.html
@@ -0,0 +1,9 @@
+f:l10n-languageDocBook xslTNG Reference
f:l10n-language
f:l10n-language — Returns the best matching localization language.
This function returns the localization language that best
+matches the language of the $target node. If
+$gentext-language is specified, it is always returned.
+The $default-language
+will be returned if there is no localization available for the declared
+language of the $target.
+
f:is-true
f:l10n-token
\ No newline at end of file
diff --git a/guide/2.2.2/f_l10n-token.html b/guide/2.2.2/f_l10n-token.html
new file mode 100644
index 0000000000..3bf7a37550
--- /dev/null
+++ b/guide/2.2.2/f_l10n-token.html
@@ -0,0 +1,7 @@
+f:l10n-tokenDocBook xslTNG Reference
f:l10n-token
f:l10n-token — Returns the gentext token for a key.
This function returns the gentext token for a key. This is usually
+accomplished by looking in the localization,
+but if you need an override for a specific element, you can replace this
+function.
+
f:l10n-language
f:label-separator
\ No newline at end of file
diff --git a/guide/2.2.2/f_label-separator.html b/guide/2.2.2/f_label-separator.html
new file mode 100644
index 0000000000..083d91b8b1
--- /dev/null
+++ b/guide/2.2.2/f_label-separator.html
@@ -0,0 +1,4 @@
+f:label-separatorDocBook xslTNG Reference
The label separator separates a label from the number or title that follows it.
+
f:l10n-token
f:language
\ No newline at end of file
diff --git a/guide/2.2.2/f_language.html b/guide/2.2.2/f_language.html
new file mode 100644
index 0000000000..eb6fbf23d2
--- /dev/null
+++ b/guide/2.2.2/f_language.html
@@ -0,0 +1,5 @@
+f:languageDocBook xslTNG Reference
f:language
f:language — Returns the language associated with an element.
\ No newline at end of file
diff --git a/guide/2.2.2/f_languages.html b/guide/2.2.2/f_languages.html
new file mode 100644
index 0000000000..f88b40d5e4
--- /dev/null
+++ b/guide/2.2.2/f_languages.html
@@ -0,0 +1,5 @@
+f:languagesDocBook xslTNG Reference
f:languages
f:languages — Returns all of the localizations used by a document.
Returns all of the localizations that might be used in formatting this
+document.
+
f:language
f:length-string
\ No newline at end of file
diff --git a/guide/2.2.2/f_length-string.html b/guide/2.2.2/f_length-string.html
new file mode 100644
index 0000000000..ca433a37af
--- /dev/null
+++ b/guide/2.2.2/f_length-string.html
@@ -0,0 +1,8 @@
+f:length-stringDocBook xslTNG Reference
f:length-string
f:length-string — Returns the string representation of a length.
For a given length (see Section 5.2, “Lengths and units”), returns the relative
+or absolute length formatted as a string. Relative lengths are formatted
+as the length followed by a literal “*” (e.g., “3*”). Absolute lengths
+are formatted as the length followed by the unit (e.g., “2.54cm”).
+
+
f:languages
f:length-units
\ No newline at end of file
diff --git a/guide/2.2.2/f_length-units.html b/guide/2.2.2/f_length-units.html
new file mode 100644
index 0000000000..4b51761929
--- /dev/null
+++ b/guide/2.2.2/f_length-units.html
@@ -0,0 +1,5 @@
+f:length-unitsDocBook xslTNG Reference
f:length-units
f:length-units — Returns the units associated with a length.
For a given length (see Section 5.2, “Lengths and units”), returns the units
+associated with the length. Returns an empty sequence for relative lengths.
+
f:length-string
f:locales
\ No newline at end of file
diff --git a/guide/2.2.2/f_locales.html b/guide/2.2.2/f_locales.html
new file mode 100644
index 0000000000..bf923d9d67
--- /dev/null
+++ b/guide/2.2.2/f_locales.html
@@ -0,0 +1,4 @@
+f:localesDocBook xslTNG Reference
f:locales
f:locales — Returns the locales detected in the document.
\ No newline at end of file
diff --git a/guide/2.2.2/f_make-length.html b/guide/2.2.2/f_make-length.html
new file mode 100644
index 0000000000..4cfaf5edb0
--- /dev/null
+++ b/guide/2.2.2/f_make-length.html
@@ -0,0 +1,7 @@
+f:make-lengthDocBook xslTNG Reference
f:make-length
f:make-length — Construct a length from constituent parts.
These functions construct a length (see Section 5.2, “Lengths and units”) from
+either a relative magnitude, an absolute magnitude and a unit, or
+both.
+
+
f:locales
f:mediaobject-amend-uri
\ No newline at end of file
diff --git a/guide/2.2.2/f_mediaobject-amend-uri.html b/guide/2.2.2/f_mediaobject-amend-uri.html
new file mode 100644
index 0000000000..f11cca4da3
--- /dev/null
+++ b/guide/2.2.2/f_mediaobject-amend-uri.html
@@ -0,0 +1,21 @@
+f:mediaobject-amend-uriDocBook xslTNG Reference
f:mediaobject-amend-uri
f:mediaobject-amend-uri — Amend the URI for media objects.
After the media object URI has been calculated,
+f:mediaobject-amend-uri() is called. This is an opportunity
+to update the URI so that the media object will be found.
+
The default version of this function returns the URI unchanged unless
+$mediaobject-grouped-by-typeis true.
+If media objects are grouped by type, the media object type is added to the
+URI. The media object type is determined by calling
+f:mediaobject-type().
+
Suppose, for example, that the calculated URI is
+file:///path/to/image.jpg and the
+f:mediaobject-type() returns “jpeg”. In that
+case, the URI returned will be
+file:///path/to/jpeg/image.jpg.
+
☝
Important
Consider how this function interacts with
+the m:mediaobject-output-adjust mode. In particular, beware that
+the value processed in the
+m:mediaobject-output-adjust mode will already
+have been updated by f:mediaobject-amend-uri().
+
f:make-length
f:mediaobject-input-base-uri
\ No newline at end of file
diff --git a/guide/2.2.2/f_mediaobject-input-base-uri.html b/guide/2.2.2/f_mediaobject-input-base-uri.html
new file mode 100644
index 0000000000..4f313f224c
--- /dev/null
+++ b/guide/2.2.2/f_mediaobject-input-base-uri.html
@@ -0,0 +1,13 @@
+f:mediaobject-input-base-uriDocBook xslTNG Reference
f:mediaobject-input-base-uri
f:mediaobject-input-base-uri — Identify the input base URI for media.
This value is calculated from the
+$mediaobject-input-base-uri parameter. If the
+parameter is the empty string, then this value is the empty sequence. Otherwise,
+this value is the absolute URI that results from resolving the value of the
+$mediaobject-input-base-uri parameter against
+the base URI of the input document.
+
+
In previous versions of the stylesheet, this value was computed once
+as a global variable. It was changed to a function because of failures
+resolving the base URI of documents when using XSpec.
+
f:mediaobject-amend-uri
f:mediaobject-type
\ No newline at end of file
diff --git a/guide/2.2.2/f_mediaobject-type.html b/guide/2.2.2/f_mediaobject-type.html
new file mode 100644
index 0000000000..831d357775
--- /dev/null
+++ b/guide/2.2.2/f_mediaobject-type.html
@@ -0,0 +1,8 @@
+f:mediaobject-typeDocBook xslTNG Reference
f:mediaobject-type
f:mediaobject-type — Return the type of a media object.
If
+$mediaobject-grouped-by-typeis true,
+this function will be called to determine the type of each media object.
+The default version simply returns the media object extension, if there is one.
+(The type of image.png is png.)
+
f:mediaobject-input-base-uri
f:mediaobject-viewport
\ No newline at end of file
diff --git a/guide/2.2.2/f_mediaobject-viewport.html b/guide/2.2.2/f_mediaobject-viewport.html
new file mode 100644
index 0000000000..884cfb4228
--- /dev/null
+++ b/guide/2.2.2/f_mediaobject-viewport.html
@@ -0,0 +1,6 @@
+f:mediaobject-viewportDocBook xslTNG Reference
f:mediaobject-viewport
f:mediaobject-viewport — Construct the “viewport” for media objects.
If your DocBook markup for media objects includes any of the size or scaling
+adjustment attributes, this function is called to construct the HTML markup that
+implements those adjustments.
+
f:mediaobject-type
f:number-separator
\ No newline at end of file
diff --git a/guide/2.2.2/f_number-separator.html b/guide/2.2.2/f_number-separator.html
new file mode 100644
index 0000000000..017ac31f8b
--- /dev/null
+++ b/guide/2.2.2/f_number-separator.html
@@ -0,0 +1,5 @@
+f:number-separatorDocBook xslTNG Reference
f:number-separator
f:number-separator — Returns the number separator.
\ No newline at end of file
diff --git a/guide/2.2.2/f_object-align.html b/guide/2.2.2/f_object-align.html
new file mode 100644
index 0000000000..32d960f62f
--- /dev/null
+++ b/guide/2.2.2/f_object-align.html
@@ -0,0 +1,5 @@
+f:object-alignDocBook xslTNG Reference
f:object-align
f:object-align — Returns the alignment of a media object.
By default, this function simply returns the value of the object’s
+align attribute.
+
f:number-separator
f:object-contentheight
\ No newline at end of file
diff --git a/guide/2.2.2/f_object-contentheight.html b/guide/2.2.2/f_object-contentheight.html
new file mode 100644
index 0000000000..a415ce22c1
--- /dev/null
+++ b/guide/2.2.2/f_object-contentheight.html
@@ -0,0 +1,13 @@
+f:object-contentheightDocBook xslTNG Reference
f:object-contentheight
f:object-contentheight — Returns the content height of an object.
Returns the content height, for reasons of historical accident,
+in the contentdepth attribute. This function returns the
+height of an object as a length (see Section 5.2, “Lengths and units”), if it
+has one. If the height is specified as a percentage, and the intrinsic size
+of the object is known, the an absolute length equal to that percentage of the
+intrinsic size is returned.
+
+
If $image-ignore-scaling is true, or no
+contentdepth is specified for the object, the empty sequence is
+returned.
+
f:object-align
f:object-contentwidth
\ No newline at end of file
diff --git a/guide/2.2.2/f_object-contentwidth.html b/guide/2.2.2/f_object-contentwidth.html
new file mode 100644
index 0000000000..c8e540131d
--- /dev/null
+++ b/guide/2.2.2/f_object-contentwidth.html
@@ -0,0 +1,12 @@
+f:object-contentwidthDocBook xslTNG Reference
f:object-contentwidth
f:object-contentwidth — Returns the content width of an object.
Returns the content width. This function returns the
+width of an object as a length (see Section 5.2, “Lengths and units”), if it
+has one. If the width is specified as a percentage, and the intrinsic size
+of the object is known, the an absolute length equal to that percentage of the
+intrinsic size is returned.
+
+
If $image-ignore-scaling is true, or no
+contentwidth is specified for the object, the empty
+sequence is returned.
+
f:object-contentheight
f:object-height
\ No newline at end of file
diff --git a/guide/2.2.2/f_object-height.html b/guide/2.2.2/f_object-height.html
new file mode 100644
index 0000000000..0fb630febc
--- /dev/null
+++ b/guide/2.2.2/f_object-height.html
@@ -0,0 +1,8 @@
+f:object-heightDocBook xslTNG Reference
f:object-height
f:object-height — Returns the height (depth) of a mediaobject.
The height of a mediaobject is specified, for reasons of historical
+accident, in the depth attribute. This function returns the
+height of an object as a length (see Section 5.2, “Lengths and units”), if it has one.
+If $image-ignore-scaling is true, or no depth
+is specified for the object, the empty sequence is returned.
+
f:object-contentwidth
f:object-properties
\ No newline at end of file
diff --git a/guide/2.2.2/f_object-properties.html b/guide/2.2.2/f_object-properties.html
new file mode 100644
index 0000000000..fec004adfd
--- /dev/null
+++ b/guide/2.2.2/f_object-properties.html
@@ -0,0 +1,20 @@
+f:object-propertiesDocBook xslTNG Reference
f:object-properties
f:object-properties — Returns the properties of an object.
$uri as xs:string) as map(xs:string, xs:anyAtomicType)
f:object-properties(
$uri as xs:string,
$image-file as xs:boolean) as map(xs:string, xs:anyAtomicType)
Description
+
+
If the extension functions
+are available, the stylesheets will interrogate images for their
+properties. The goal is to return, at a minimum, the height and width
+of the image. This is used to compute viewport and scaling factors.
+If the image metadata extension is available, then considerably more information
+my be returned in the map.
+
+
+For example, the image metadata properties of the Amaryllis photograph
+in Figure 1, “An amaryllis” are:
aSome values
+ have been truncated to prevent the table from becoming unwieldy.
+ These values an be identified by a trailing ellipsis (…).
+
+
Several rich, red amaryllis blossoms on a black
+background.
Figure 1. An amaryllis
+
f:object-height
f:object-scale
\ No newline at end of file
diff --git a/guide/2.2.2/f_object-scale.html b/guide/2.2.2/f_object-scale.html
new file mode 100644
index 0000000000..3587505230
--- /dev/null
+++ b/guide/2.2.2/f_object-scale.html
@@ -0,0 +1,7 @@
+f:object-scaleDocBook xslTNG Reference
f:object-scale
f:object-scale — Returns the scaling factor for an object.
Returns the scaling factor for an object. Scaling only applies if
+$image-ignore-scaling is false and the object has a
+scale attribute.
+
+
f:object-properties
f:object-scalefit
\ No newline at end of file
diff --git a/guide/2.2.2/f_object-scalefit.html b/guide/2.2.2/f_object-scalefit.html
new file mode 100644
index 0000000000..4e52cbe0bc
--- /dev/null
+++ b/guide/2.2.2/f_object-scalefit.html
@@ -0,0 +1,6 @@
+f:object-scalefitDocBook xslTNG Reference
This function determines whether or not an object should be scaled
+to fit its container.
+
+
f:object-scale
f:object-valign
\ No newline at end of file
diff --git a/guide/2.2.2/f_object-valign.html b/guide/2.2.2/f_object-valign.html
new file mode 100644
index 0000000000..96661adae8
--- /dev/null
+++ b/guide/2.2.2/f_object-valign.html
@@ -0,0 +1,8 @@
+f:object-valignDocBook xslTNG Reference
f:object-valign
f:object-valign — Returns the vertical alignment of a media object.
By default, this function simply returns the value of the object’s
+valign attribute. If it doesn’t have a
+valign attribute, the value “middle” is returned, because
+that’s what previous versions of stylesheets for DocBook did.
+
+
f:object-scalefit
f:object-width
\ No newline at end of file
diff --git a/guide/2.2.2/f_object-width.html b/guide/2.2.2/f_object-width.html
new file mode 100644
index 0000000000..96d2fb3e2f
--- /dev/null
+++ b/guide/2.2.2/f_object-width.html
@@ -0,0 +1,7 @@
+f:object-widthDocBook xslTNG Reference
f:object-width
f:object-width — Returns the width of a mediaobject.
This function returns the
+width of an object as a length (see Section 5.2, “Lengths and units”), if it has one.
+If $image-ignore-scaling is true, or no width
+is specified for the object, the empty length is returned.
+
f:object-valign
f:orderedlist-item-number
\ No newline at end of file
diff --git a/guide/2.2.2/f_orderedlist-item-number.html b/guide/2.2.2/f_orderedlist-item-number.html
new file mode 100644
index 0000000000..fce93ce3a5
--- /dev/null
+++ b/guide/2.2.2/f_orderedlist-item-number.html
@@ -0,0 +1,7 @@
+f:orderedlist-item-numberDocBook xslTNG Reference
f:orderedlist-item-number
f:orderedlist-item-number — Returns the item number of an item in an ordered list.
Returns the item number of a list item. This is always an integer, even if it will
+be formatted as a letter, roman numeral, or other symbol. For nested lists, this function
+returns the fully qualified item number. For example, for the second item in the fourth item in the
+third item of a list, it will return (2, 4, 3).
+
f:object-width
f:orderedlist-item-numeration
\ No newline at end of file
diff --git a/guide/2.2.2/f_orderedlist-item-numeration.html b/guide/2.2.2/f_orderedlist-item-numeration.html
new file mode 100644
index 0000000000..f178b6f8c8
--- /dev/null
+++ b/guide/2.2.2/f_orderedlist-item-numeration.html
@@ -0,0 +1,5 @@
+f:orderedlist-item-numerationDocBook xslTNG Reference
f:orderedlist-item-numeration
f:orderedlist-item-numeration — Returns the item numeration format for an ordered list.
\ No newline at end of file
diff --git a/guide/2.2.2/f_orderedlist-startingnumber.html b/guide/2.2.2/f_orderedlist-startingnumber.html
new file mode 100644
index 0000000000..8090b697b4
--- /dev/null
+++ b/guide/2.2.2/f_orderedlist-startingnumber.html
@@ -0,0 +1,9 @@
+f:orderedlist-startingnumberDocBook xslTNG Reference
f:orderedlist-startingnumber
f:orderedlist-startingnumber — Returns the starting number of an ordered list.
In most orderedlist elements, the first item in the list
+is item number “1”. However, the startingnumber attribute can specify
+a different initial number and, in the case of continued lists, the starting number
+depends on the ending number of the preceding list.
+
The f:orderedlist-startingnumber() returns the number
+of the first list item in an ordered list.
+
f:orderedlist-item-numeration
f:orientation-class
\ No newline at end of file
diff --git a/guide/2.2.2/f_orientation-class.html b/guide/2.2.2/f_orientation-class.html
new file mode 100644
index 0000000000..92dd480d2c
--- /dev/null
+++ b/guide/2.2.2/f_orientation-class.html
@@ -0,0 +1,5 @@
+f:orientation-classDocBook xslTNG Reference
f:orientation-class
f:orientation-class — Returns the class value to use for an element’s orientation.
Determines if the element specified should be printed in portrait or landscape
+orientation. The default is assumed to be portrait.
+
f:orderedlist-startingnumber
f:parse-length
\ No newline at end of file
diff --git a/guide/2.2.2/f_parse-length.html b/guide/2.2.2/f_parse-length.html
new file mode 100644
index 0000000000..b3b1b4d6c0
--- /dev/null
+++ b/guide/2.2.2/f_parse-length.html
@@ -0,0 +1,9 @@
+f:parse-lengthDocBook xslTNG Reference
This function parses a string such as “4in” or “3.14cm” or “50%”
+into a length. It will fall back to a distance of the
+$default-length-magnitude and
+$default-length-unit if the string cannot be parsed
+as a length.
+
+
f:orientation-class
f:pi
\ No newline at end of file
diff --git a/guide/2.2.2/f_pi-attributes.html b/guide/2.2.2/f_pi-attributes.html
new file mode 100644
index 0000000000..cc3511c4af
--- /dev/null
+++ b/guide/2.2.2/f_pi-attributes.html
@@ -0,0 +1,10 @@
+f:pi-attributesDocBook xslTNG Reference
f:pi-attributes
f:pi-attributes — Returns processing-instruction pseudo-attributes as attributes.
Using pseudo-attributes in a
+db processing instruction is a convenient mechanism
+for providing additional options to the stylesheets. But processing them
+is tedious. This function gathers together the pseudo-attributes specified
+in a series of processing instructions and returns them as attributes on
+an element. If the same property occurs more than once in the sequence,
+the last value will be returned.
+
f:pi
f:post-label-punctuation
\ No newline at end of file
diff --git a/guide/2.2.2/f_pi.html b/guide/2.2.2/f_pi.html
new file mode 100644
index 0000000000..09a1ce57a3
--- /dev/null
+++ b/guide/2.2.2/f_pi.html
@@ -0,0 +1,14 @@
+f:piDocBook xslTNG Reference
Several DocBook elements have alternate presentations that can be
+specified with global parameters. Many of them can also be set on a per-element
+basis with a db processing instruction.
+The date format, for example, can be changed in this way as described
+in the f:date-format() function.
+
The f:pi() function takes a context and the name
+of a property. It returns the value specified for that property from all of the
+db processing instructions in the
+specified context. The three argument version allows you to specify a default
+value. It will be returned if there are no values specified for the property
+in that context.
+
f:parse-length
f:pi-attributes
\ No newline at end of file
diff --git a/guide/2.2.2/f_post-label-punctuation.html b/guide/2.2.2/f_post-label-punctuation.html
new file mode 100644
index 0000000000..89e853d881
--- /dev/null
+++ b/guide/2.2.2/f_post-label-punctuation.html
@@ -0,0 +1,4 @@
+f:post-label-punctuationDocBook xslTNG Reference
f:post-label-punctuation
f:post-label-punctuation — Punctuation that follows a label.
\ No newline at end of file
diff --git a/guide/2.2.2/f_refsection.html b/guide/2.2.2/f_refsection.html
new file mode 100644
index 0000000000..05657897bb
--- /dev/null
+++ b/guide/2.2.2/f_refsection.html
@@ -0,0 +1,6 @@
+f:refsectionDocBook xslTNG Reference
Returns true if the node is a section in a refentry, a
+refsection, refsect1, refsect2, or refsect3
+element.
+
f:post-label-punctuation
f:relative-length
\ No newline at end of file
diff --git a/guide/2.2.2/f_relative-length.html b/guide/2.2.2/f_relative-length.html
new file mode 100644
index 0000000000..1113fda0a7
--- /dev/null
+++ b/guide/2.2.2/f_relative-length.html
@@ -0,0 +1,7 @@
+f:relative-lengthDocBook xslTNG Reference
f:relative-length
f:relative-length — Returns the relative portion of a length, if it has one.
For a given length, returns the relative length if it has one.
+For lengths that have no relative component, returns 0.0.
+For a discussion of units, see Section 5.2, “Lengths and units”.
+
+
f:refsection
f:relative-path
\ No newline at end of file
diff --git a/guide/2.2.2/f_relative-path.html b/guide/2.2.2/f_relative-path.html
new file mode 100644
index 0000000000..a8c4a635e4
--- /dev/null
+++ b/guide/2.2.2/f_relative-path.html
@@ -0,0 +1,10 @@
+f:relative-pathDocBook xslTNG Reference
f:relative-path
f:relative-path — Give two file paths, what’s the relative path between them?
This function attempts to determine the relative path between two
+absolute paths. For example, given a base path of
+/a/base/uri/path/ and a path of
+/a/base/uri/with/other, the results is
+../with/other.
+
If the path is an absolute URI (that isn’t a file: URI),
+then the URI is returned unchanged.
+
f:relative-length
f:section
\ No newline at end of file
diff --git a/guide/2.2.2/f_section-depth.html b/guide/2.2.2/f_section-depth.html
new file mode 100644
index 0000000000..98c4ffc2b1
--- /dev/null
+++ b/guide/2.2.2/f_section-depth.html
@@ -0,0 +1,5 @@
+f:section-depthDocBook xslTNG Reference
f:section-depth
f:section-depth — Returns the section depth of a node.
Returns the section depth of a node, that is, how many section elements
+are among its ancestors.
+
f:section
f:spaces
\ No newline at end of file
diff --git a/guide/2.2.2/f_section.html b/guide/2.2.2/f_section.html
new file mode 100644
index 0000000000..fd14dfa08c
--- /dev/null
+++ b/guide/2.2.2/f_section.html
@@ -0,0 +1,6 @@
+f:sectionDocBook xslTNG Reference
Returns true if the node is a section, a
+section or sect1-5
+element.
+
f:relative-path
f:section-depth
\ No newline at end of file
diff --git a/guide/2.2.2/f_spaces.html b/guide/2.2.2/f_spaces.html
new file mode 100644
index 0000000000..92794b2cc3
--- /dev/null
+++ b/guide/2.2.2/f_spaces.html
@@ -0,0 +1,20 @@
+f:spacesDocBook xslTNG Reference
This function returns a string of $length spaces.
+If $length:
+
is empty, an empty sequence is returned.
is an integer, or castable to an integer, a string of that length is
+returned. If the length is negative, an empty sequence is returned.
is anything else, the length of the string value of $length
+is used as the length.
+
+
In other words:
+
f:spaces(()) is ‘()’,
f:spaces(0) is ‘’ (no spaces),
f:spaces(-1) is ‘()’,
f:spaces(2) is ‘ ’ (two spaces),
f:spaces("1") is ‘ ’ (one space), and
f:spaces("test") is ‘ ’ (four spaces).
+
+
This function accepts a sequence to support the empty sequence.
+If it’s passed a sequence of more than one item, it treats that as if
+the string values of the items had been concatenated together. This can
+have slightly surprising consequences as “('a', '3', '0')”
+will return a string of three spaces whereas
+“('0', '3', '0')” will return a string of thirty.
+
+
+
f:section-depth
f:step-number
\ No newline at end of file
diff --git a/guide/2.2.2/f_step-number.html b/guide/2.2.2/f_step-number.html
new file mode 100644
index 0000000000..1d5c03cfe0
--- /dev/null
+++ b/guide/2.2.2/f_step-number.html
@@ -0,0 +1,9 @@
+f:step-numberDocBook xslTNG Reference
f:step-number
f:step-number — Returns the step number of a step in an procedure.
Returns the step number of step in a procedure. This is always
+an integer, even if it will be formatted as a letter, roman numeral,
+or other symbol. For steps nested in side substeps, this
+function returns the fully qualified item number. For example, for the
+second substep in the fourth substep in the third step of a procedure, it will
+return (2, 4, 3).
+
f:spaces
f:step-numeration
\ No newline at end of file
diff --git a/guide/2.2.2/f_step-numeration.html b/guide/2.2.2/f_step-numeration.html
new file mode 100644
index 0000000000..f5b24fee9f
--- /dev/null
+++ b/guide/2.2.2/f_step-numeration.html
@@ -0,0 +1,5 @@
+f:step-numerationDocBook xslTNG Reference
f:step-numeration
f:step-numeration — Returns the step numeration format for a step.
\ No newline at end of file
diff --git a/guide/2.2.2/f_syntax-highlight.html b/guide/2.2.2/f_syntax-highlight.html
new file mode 100644
index 0000000000..241ba4babe
--- /dev/null
+++ b/guide/2.2.2/f_syntax-highlight.html
@@ -0,0 +1,10 @@
+f:syntax-highlightDocBook xslTNG Reference
$pyoptions as map(xs:string,xs:string)) as node()*
Description
+
+
Verbatim environments that specify a language can be syntax highlighted.
+Syntax highlighting adds additional spans so that, for example, CSS can be used to make
+keyword bold or quoted strings a different color.
+
Syntax highlighting requires an extension function. The list of languages that
+will be syntax highlighted is taken from
+$verbatim-syntax-highlight-languages.
+
+
f:step-numeration
f:target
\ No newline at end of file
diff --git a/guide/2.2.2/f_target.html b/guide/2.2.2/f_target.html
new file mode 100644
index 0000000000..62713e04e7
--- /dev/null
+++ b/guide/2.2.2/f_target.html
@@ -0,0 +1,6 @@
+f:targetDocBook xslTNG Reference
f:target
f:target — Returns the element identified by a particular id.
Function:
{http://docbook.org/ns/docbook/functions}target#2
Defined in:
modules/functions.xsl
Used in:
modules/programming.xsl, modules/links.xsl
Synopsis
f:target(
$id as xs:string,
$context as node()) as element()*
Description
+
+
The item with the specified ID that is in the same document as
+$context item is returned.
+
+
f:syntax-highlight
f:template
\ No newline at end of file
diff --git a/guide/2.2.2/f_template.html b/guide/2.2.2/f_template.html
new file mode 100644
index 0000000000..6d79f3891b
--- /dev/null
+++ b/guide/2.2.2/f_template.html
@@ -0,0 +1,5 @@
+f:templateDocBook xslTNG Reference
f:template
f:template — Returns the title page template for an element.
Returns the title page template that should be used for an element.
+If no template is found, returns the $default template.
+
f:target
f:tokenize-on-char
\ No newline at end of file
diff --git a/guide/2.2.2/f_tokenize-on-char.html b/guide/2.2.2/f_tokenize-on-char.html
new file mode 100644
index 0000000000..4dca0f7b78
--- /dev/null
+++ b/guide/2.2.2/f_tokenize-on-char.html
@@ -0,0 +1,6 @@
+f:tokenize-on-charDocBook xslTNG Reference
f:tokenize-on-char
f:tokenize-on-char — Tokenize a string at a specific character.
This function tokenizes a string at a specific character (not a regular
+expression). If the specified character is a regular expression meta-character, it
+is automatically escaped.
+
f:template
f:translate-attribute
\ No newline at end of file
diff --git a/guide/2.2.2/f_translate-attribute.html b/guide/2.2.2/f_translate-attribute.html
new file mode 100644
index 0000000000..0bf805642b
--- /dev/null
+++ b/guide/2.2.2/f_translate-attribute.html
@@ -0,0 +1,12 @@
+f:translate-attributeDocBook xslTNG Reference
f:translate-attribute
f:translate-attribute — Controls the translate attribute.
When computing what attributes to put on elements in the output, this function
+is called to check whether a translate attribute should be
+output:
+
If it returns true, a translate attribute with the
+value “yes” will be output.
If it returns false, a translate attribute with the
+value “no” will be output.
If it returns the empty sequence, no translate attribute
+will be output.
+
The default implementation of this function checks the (local) name of the
+element with the $translate-suppress-elements list.
+
f:tokenize-on-char
f:unique-id
\ No newline at end of file
diff --git a/guide/2.2.2/f_unique-id.html b/guide/2.2.2/f_unique-id.html
new file mode 100644
index 0000000000..494e926b00
--- /dev/null
+++ b/guide/2.2.2/f_unique-id.html
@@ -0,0 +1,7 @@
+f:unique-idDocBook xslTNG Reference
This function returns a globally unique ID for the element. This allows
+a transformation to disambiguate between different elements that happen to have
+the same xml:id, as can occur if transclusion is performed.
+
+
f:translate-attribute
f:uri-scheme
\ No newline at end of file
diff --git a/guide/2.2.2/f_uri-scheme.html b/guide/2.2.2/f_uri-scheme.html
new file mode 100644
index 0000000000..e3f2951c97
--- /dev/null
+++ b/guide/2.2.2/f_uri-scheme.html
@@ -0,0 +1,5 @@
+f:uri-schemeDocBook xslTNG Reference
f:uri-scheme
f:uri-scheme — Returns the scheme portion of a URI.
If the URI begins with a scheme, this function returns the scheme.
+Otherwise, it returns an empty sequence.
+
f:unique-id
f:verbatim-highlight
\ No newline at end of file
diff --git a/guide/2.2.2/f_verbatim-highlight.html b/guide/2.2.2/f_verbatim-highlight.html
new file mode 100644
index 0000000000..0a1aa2ce2e
--- /dev/null
+++ b/guide/2.2.2/f_verbatim-highlight.html
@@ -0,0 +1,13 @@
+f:verbatim-highlightDocBook xslTNG Reference
f:verbatim-highlight
f:verbatim-highlight — Returns the highlight properties for a verbatim environment.
Verbatim elements can be styled in a variety of ways, see
+Section 5.3, “Verbatim styles”. This function returns the highlight settings
+for a particular verbatim environment.
+
If the style for this environment is explicitly “plain”, then no
+highlight settings are returned (this avoids a bunch of warning messages).
+Otherwise, if a
+db processing instruction with a
+verbatim-highlight pseudo-attribute is present,
+it is returned. If there’s no PI, then the default
+settings for this kind of environment are returned.
+
f:uri-scheme
f:verbatim-numbered
\ No newline at end of file
diff --git a/guide/2.2.2/f_verbatim-numbered.html b/guide/2.2.2/f_verbatim-numbered.html
new file mode 100644
index 0000000000..7d1e94020a
--- /dev/null
+++ b/guide/2.2.2/f_verbatim-numbered.html
@@ -0,0 +1,25 @@
+f:verbatim-numberedDocBook xslTNG Reference
f:verbatim-numbered
f:verbatim-numbered — Returns true if the listing should be numbered.
a
+db processing instruction with a
+verbatim-numberedpseudo-attribute that
+is true is specified.
+
+
+
There are two overriding conditions that will force the value to
+be false: first, if the linenumbering attribute is specified and has the
+value unnumbered, the listing will not be numbered.
+Second if the listing has a
+db processing instruction with a
+verbatim-style pseudo attribute that specifies the “plain” style. Listings
+in the plain style cannot be numbered, attempting to do so will generate
+a warning message from the stylesheets.
+
+
f:verbatim-highlight
f:verbatim-style
\ No newline at end of file
diff --git a/guide/2.2.2/f_verbatim-style.html b/guide/2.2.2/f_verbatim-style.html
new file mode 100644
index 0000000000..06c37a436a
--- /dev/null
+++ b/guide/2.2.2/f_verbatim-style.html
@@ -0,0 +1,18 @@
+f:verbatim-styleDocBook xslTNG Reference
f:verbatim-style
f:verbatim-style — Returns the style of a verbatim listing.
The f:verbatim-style() function returns the style
+of presentation that should be used for the
+specified verbatim listing.
+
+
If a
+db processing instruction with a
+verbatim-stylepseudo-attribute is present,
+the value of that pseudo-attribute will be returned.
+Otherwise, it will be “lines” if the
+element’s name is listed in
+$verbatim-line-style,
+“plain” if the
+element’s name is listed in
+$verbatim-plain-style, or “raw”.
+
+
f:verbatim-numbered
f:verbatim-trim-leading
\ No newline at end of file
diff --git a/guide/2.2.2/f_verbatim-trim-leading.html b/guide/2.2.2/f_verbatim-trim-leading.html
new file mode 100644
index 0000000000..386eaa1cd5
--- /dev/null
+++ b/guide/2.2.2/f_verbatim-trim-leading.html
@@ -0,0 +1,10 @@
+f:verbatim-trim-leadingDocBook xslTNG Reference
f:verbatim-trim-leading
f:verbatim-trim-leading — Return true if leading blank lines should be trimmed.
This function examines a verbatim environment, the $context,
+and returns true if leading blank lines should be trimmed from it.
+A db processing instruction with a
+verbatim-trim-leading pseudo-attribute may be used to override the
+$verbatim-trim-leading-blank-lines parameter on a
+case-by-case basis.
+
+
f:verbatim-style
f:verbatim-trim-trailing
\ No newline at end of file
diff --git a/guide/2.2.2/f_verbatim-trim-trailing.html b/guide/2.2.2/f_verbatim-trim-trailing.html
new file mode 100644
index 0000000000..0005553c0f
--- /dev/null
+++ b/guide/2.2.2/f_verbatim-trim-trailing.html
@@ -0,0 +1,10 @@
+f:verbatim-trim-trailingDocBook xslTNG Reference
f:verbatim-trim-trailing
f:verbatim-trim-trailing — Return true if trailing blank lines should be trimmed.
This function examines a verbatim environment, the $context,
+and returns true if trailing blank lines should be trimmed from it.
+A db processing instruction with a
+verbatim-trim-trailing pseudo-attribute may be used to override the
+$verbatim-trim-trailing-blank-lines parameter on a
+case-by-case basis.
+
+
f:verbatim-trim-leading
f:xlink-style
\ No newline at end of file
diff --git a/guide/2.2.2/f_xlink-style.html b/guide/2.2.2/f_xlink-style.html
new file mode 100644
index 0000000000..8c6822182a
--- /dev/null
+++ b/guide/2.2.2/f_xlink-style.html
@@ -0,0 +1,6 @@
+f:xlink-styleDocBook xslTNG Reference
f:xlink-style
f:xlink-style — Returns the XLink style for this document.
The stylesheets support XLink extended links. See
+$xlink-style for more details.
+
+
f:verbatim-trim-trailing
f:xpointer-idref
\ No newline at end of file
diff --git a/guide/2.2.2/f_xpointer-idref.html b/guide/2.2.2/f_xpointer-idref.html
new file mode 100644
index 0000000000..b549b4ae54
--- /dev/null
+++ b/guide/2.2.2/f_xpointer-idref.html
@@ -0,0 +1,14 @@
+f:xpointer-idrefDocBook xslTNG Reference
f:xpointer-idref
f:xpointer-idref — Parses an XPointer for a same-document ID reference.
In DocBook, there are generally two ways to refer to other
+elements in the current document by ID: using the linkend
+(or linkends) attribute or using the xlink:href
+attribute.
+
The f:xpointer-idref() function returns the
+ID portion of an XPointer that is a reference to another ID in the
+current document.
+
In other words:
+
+
f:xpointer-idref('#foo') is foo,
f:xpointer-idref('id(foo)') is foo,
and f:xpointer-idref('http://example.org/#foo')
+is the empty sequence.
+
f:xlink-style
IV . Template reference
\ No newline at end of file
diff --git a/guide/2.2.2/functions.html b/guide/2.2.2/functions.html
new file mode 100644
index 0000000000..d2b24824ce
--- /dev/null
+++ b/guide/2.2.2/functions.html
@@ -0,0 +1 @@
+III. Function referenceDocBook xslTNG Reference
f:xlink-style — Returns the XLink style for this document
f:xpointer-idref — Parses an XPointer for a same-document ID reference
$v:xref-properties
ext:cwd
\ No newline at end of file
diff --git a/guide/2.2.2/gfdl.html b/guide/2.2.2/gfdl.html
new file mode 100644
index 0000000000..a8eb5276ad
--- /dev/null
+++ b/guide/2.2.2/gfdl.html
@@ -0,0 +1,244 @@
+Appendix B. GNU Free Documentation LicenseDocBook xslTNG Reference
Appendix B. GNU Free Documentation License
+ Version 1.1, March 2000
+
+ Copyright (C) 2000 Free Software Foundation, Inc.
+ 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
0. PREAMBLE
The purpose of this License is to make a manual, textbook, or other
+written document "free" in the sense of freedom: to assure everyone
+the effective freedom to copy and redistribute it, with or without
+modifying it, either commercially or noncommercially. Secondarily,
+this License preserves for the author and publisher a way to get
+credit for their work, while not being considered responsible for
+modifications made by others.
This License is a kind of "copyleft", which means that derivative
+works of the document must themselves be free in the same sense. It
+complements the GNU General Public License, which is a copyleft
+license designed for free software.
We have designed this License in order to use it for manuals for free
+software, because free software needs free documentation: a free
+program should come with manuals providing the same freedoms that the
+software does. But this License is not limited to software manuals;
+it can be used for any textual work, regardless of subject matter or
+whether it is published as a printed book. We recommend this License
+principally for works whose purpose is instruction or reference.
1. APPLICABILITY AND DEFINITIONS
This License applies to any manual or other work that contains a
+notice placed by the copyright holder saying it can be distributed
+under the terms of this License. The "Document", below, refers to any
+such manual or work. Any member of the public is a licensee, and is
+addressed as "you".
A "Modified Version" of the Document means any work containing the
+Document or a portion of it, either copied verbatim, or with
+modifications and/or translated into another language.
A "Secondary Section" is a named appendix or a front-matter section of
+the Document that deals exclusively with the relationship of the
+publishers or authors of the Document to the Document's overall subject
+(or to related matters) and contains nothing that could fall directly
+within that overall subject. (For example, if the Document is in part a
+textbook of mathematics, a Secondary Section may not explain any
+mathematics.) The relationship could be a matter of historical
+connection with the subject or with related matters, or of legal,
+commercial, philosophical, ethical or political position regarding
+them.
The "Invariant Sections" are certain Secondary Sections whose titles
+are designated, as being those of Invariant Sections, in the notice
+that says that the Document is released under this License.
The "Cover Texts" are certain short passages of text that are listed,
+as Front-Cover Texts or Back-Cover Texts, in the notice that says that
+the Document is released under this License.
A "Transparent" copy of the Document means a machine-readable copy,
+represented in a format whose specification is available to the
+general public, whose contents can be viewed and edited directly and
+straightforwardly with generic text editors or (for images composed of
+pixels) generic paint programs or (for drawings) some widely available
+drawing editor, and that is suitable for input to text formatters or
+for automatic translation to a variety of formats suitable for input
+to text formatters. A copy made in an otherwise Transparent file
+format whose markup has been designed to thwart or discourage
+subsequent modification by readers is not Transparent. A copy that is
+not "Transparent" is called "Opaque".
Examples of suitable formats for Transparent copies include plain
+ASCII without markup, Texinfo input format, LaTeX input format, SGML
+or XML using a publicly available DTD, and standard-conforming simple
+HTML designed for human modification. Opaque formats include
+PostScript, PDF, proprietary formats that can be read and edited only
+by proprietary word processors, SGML or XML for which the DTD and/or
+processing tools are not generally available, and the
+machine-generated HTML produced by some word processors for output
+purposes only.
The "Title Page" means, for a printed book, the title page itself,
+plus such following pages as are needed to hold, legibly, the material
+this License requires to appear in the title page. For works in
+formats which do not have any title page as such, "Title Page" means
+the text near the most prominent appearance of the work's title,
+preceding the beginning of the body of the text.
2. VERBATIM COPYING
You may copy and distribute the Document in any medium, either
+commercially or noncommercially, provided that this License, the
+copyright notices, and the license notice saying this License applies
+to the Document are reproduced in all copies, and that you add no other
+conditions whatsoever to those of this License. You may not use
+technical measures to obstruct or control the reading or further
+copying of the copies you make or distribute. However, you may accept
+compensation in exchange for copies. If you distribute a large enough
+number of copies you must also follow the conditions in section 3.
You may also lend copies, under the same conditions stated above, and
+you may publicly display copies.
3. COPYING IN QUANTITY
If you publish printed copies of the Document numbering more than 100,
+and the Document's license notice requires Cover Texts, you must enclose
+the copies in covers that carry, clearly and legibly, all these Cover
+Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on
+the back cover. Both covers must also clearly and legibly identify
+you as the publisher of these copies. The front cover must present
+the full title with all words of the title equally prominent and
+visible. You may add other material on the covers in addition.
+Copying with changes limited to the covers, as long as they preserve
+the title of the Document and satisfy these conditions, can be treated
+as verbatim copying in other respects.
If the required texts for either cover are too voluminous to fit
+legibly, you should put the first ones listed (as many as fit
+reasonably) on the actual cover, and continue the rest onto adjacent
+pages.
If you publish or distribute Opaque copies of the Document numbering
+more than 100, you must either include a machine-readable Transparent
+copy along with each Opaque copy, or state in or with each Opaque copy
+a publicly-accessible computer-network location containing a complete
+Transparent copy of the Document, free of added material, which the
+general network-using public has access to download anonymously at no
+charge using public-standard network protocols. If you use the latter
+option, you must take reasonably prudent steps, when you begin
+distribution of Opaque copies in quantity, to ensure that this
+Transparent copy will remain thus accessible at the stated location
+until at least one year after the last time you distribute an Opaque
+copy (directly or through your agents or retailers) of that edition to
+the public.
It is requested, but not required, that you contact the authors of the
+Document well before redistributing any large number of copies, to give
+them a chance to provide you with an updated version of the Document.
4. MODIFICATIONS
You may copy and distribute a Modified Version of the Document under
+the conditions of sections 2 and 3 above, provided that you release
+the Modified Version under precisely this License, with the Modified
+Version filling the role of the Document, thus licensing distribution
+and modification of the Modified Version to whoever possesses a copy
+of it. In addition, you must do these things in the Modified Version:
Use in the Title Page (and on the covers, if any) a title distinct
+from that of the Document, and from those of previous versions
+(which should, if there were any, be listed in the History section
+of the Document). You may use the same title as a previous version
+if the original publisher of that version gives permission.
+
List on the Title Page, as authors, one or more persons or entities
+responsible for authorship of the modifications in the Modified
+Version, together with at least five of the principal authors of the
+Document (all of its principal authors, if it has less than five).
+
State on the Title page the name of the publisher of the
+Modified Version, as the publisher.
+
Preserve all the copyright notices of the Document.
+
Add an appropriate copyright notice for your modifications
+adjacent to the other copyright notices.
+
Include, immediately after the copyright notices, a license notice
+giving the public permission to use the Modified Version under the
+terms of this License, in the form shown in the Addendum below.
+
Preserve in that license notice the full lists of Invariant Sections
+and required Cover Texts given in the Document's license notice.
+
Include an unaltered copy of this License.
+
Preserve the section entitled "History", and its title, and add to
+it an item stating at least the title, year, new authors, and
+publisher of the Modified Version as given on the Title Page. If
+there is no section entitled "History" in the Document, create one
+stating the title, year, authors, and publisher of the Document as
+given on its Title Page, then add an item describing the Modified
+Version as stated in the previous sentence.
+
Preserve the network location, if any, given in the Document for
+public access to a Transparent copy of the Document, and likewise
+the network locations given in the Document for previous versions
+it was based on. These may be placed in the "History" section.
+You may omit a network location for a work that was published at
+least four years before the Document itself, or if the original
+publisher of the version it refers to gives permission.
+
In any section entitled "Acknowledgements" or "Dedications",
+preserve the section's title, and preserve in the section all the
+substance and tone of each of the contributor acknowledgements
+and/or dedications given therein.
+
Preserve all the Invariant Sections of the Document,
+unaltered in their text and in their titles. Section numbers
+or the equivalent are not considered part of the section titles.
+
Delete any section entitled "Endorsements". Such a section
+may not be included in the Modified Version.
+
Do not retitle any existing section as "Endorsements"
+or to conflict in title with any Invariant Section.
+
If the Modified Version includes new front-matter sections or
+appendices that qualify as Secondary Sections and contain no material
+copied from the Document, you may at your option designate some or all
+of these sections as invariant. To do this, add their titles to the
+list of Invariant Sections in the Modified Version's license notice.
+These titles must be distinct from any other section titles.
You may add a section entitled "Endorsements", provided it contains
+nothing but endorsements of your Modified Version by various
+parties—for example, statements of peer review or that the text has
+been approved by an organization as the authoritative definition of a
+standard.
You may add a passage of up to five words as a Front-Cover Text, and a
+passage of up to 25 words as a Back-Cover Text, to the end of the list
+of Cover Texts in the Modified Version. Only one passage of
+Front-Cover Text and one of Back-Cover Text may be added by (or
+through arrangements made by) any one entity. If the Document already
+includes a cover text for the same cover, previously added by you or
+by arrangement made by the same entity you are acting on behalf of,
+you may not add another; but you may replace the old one, on explicit
+permission from the previous publisher that added the old one.
The author(s) and publisher(s) of the Document do not by this License
+give permission to use their names for publicity for or to assert or
+imply endorsement of any Modified Version.
5. COMBINING DOCUMENTS
You may combine the Document with other documents released under this
+License, under the terms defined in section 4 above for modified
+versions, provided that you include in the combination all of the
+Invariant Sections of all of the original documents, unmodified, and
+list them all as Invariant Sections of your combined work in its
+license notice.
The combined work need only contain one copy of this License, and
+multiple identical Invariant Sections may be replaced with a single
+copy. If there are multiple Invariant Sections with the same name but
+different contents, make the title of each such section unique by
+adding at the end of it, in parentheses, the name of the original
+author or publisher of that section if known, or else a unique number.
+Make the same adjustment to the section titles in the list of
+Invariant Sections in the license notice of the combined work.
In the combination, you must combine any sections entitled "History"
+in the various original documents, forming one section entitled
+"History"; likewise combine any sections entitled "Acknowledgements",
+and any sections entitled "Dedications". You must delete all sections
+entitled "Endorsements."
6. COLLECTIONS OF DOCUMENTS
You may make a collection consisting of the Document and other documents
+released under this License, and replace the individual copies of this
+License in the various documents with a single copy that is included in
+the collection, provided that you follow the rules of this License for
+verbatim copying of each of the documents in all other respects.
You may extract a single document from such a collection, and distribute
+it individually under this License, provided you insert a copy of this
+License into the extracted document, and follow this License in all
+other respects regarding verbatim copying of that document.
7. AGGREGATION WITH INDEPENDENT WORKS
A compilation of the Document or its derivatives with other separate
+and independent documents or works, in or on a volume of a storage or
+distribution medium, does not as a whole count as a Modified Version
+of the Document, provided no compilation copyright is claimed for the
+compilation. Such a compilation is called an "aggregate", and this
+License does not apply to the other self-contained works thus compiled
+with the Document, on account of their being thus compiled, if they
+are not themselves derivative works of the Document.
If the Cover Text requirement of section 3 is applicable to these
+copies of the Document, then if the Document is less than one quarter
+of the entire aggregate, the Document's Cover Texts may be placed on
+covers that surround only the Document within the aggregate.
+Otherwise they must appear on covers around the whole aggregate.
8. TRANSLATION
Translation is considered a kind of modification, so you may
+distribute translations of the Document under the terms of section 4.
+Replacing Invariant Sections with translations requires special
+permission from their copyright holders, but you may include
+translations of some or all Invariant Sections in addition to the
+original versions of these Invariant Sections. You may include a
+translation of this License provided that you also include the
+original English version of this License. In case of a disagreement
+between the translation and the original English version of this
+License, the original English version will prevail.
9. TERMINATION
You may not copy, modify, sublicense, or distribute the Document except
+as expressly provided for under this License. Any other attempt to
+copy, modify, sublicense or distribute the Document is void, and will
+automatically terminate your rights under this License. However,
+parties who have received copies, or rights, from you under this
+License will not have their licenses terminated so long as such
+parties remain in full compliance.
10. FUTURE REVISIONS OF THIS LICENSE
The Free Software Foundation may publish new, revised versions
+of the GNU Free Documentation License from time to time. Such new
+versions will be similar in spirit to the present version, but may
+differ in detail to address new problems or concerns. See
+http://www.gnu.org/copyleft/.
Each version of the License is given a distinguishing version number.
+If the Document specifies that a particular numbered version of this
+License "or any later version" applies to it, you have the option of
+following the terms and conditions either of that specified version or
+of any later version that has been published (not as a draft) by the
+Free Software Foundation. If the Document does not specify a version
+number of this License, you may choose any version ever published (not
+as a draft) by the Free Software Foundation.
ADDENDUM: How to use this License for your documents
To use this License in a document you have written, include a copy of
+the License in the document and put the following copyright and
+license notices just after the title page:
Copyright (c) YEAR YOUR NAME.
+Permission is granted to copy, distribute and/or modify this document
+under the terms of the GNU Free Documentation License, Version 1.1
+or any later version published by the Free Software Foundation;
+with the Invariant Sections being LIST THEIR TITLES, with the
+Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.
+A copy of the license is included in the section entitled "GNU
+Free Documentation License".
If you have no Invariant Sections, write "with no Invariant Sections"
+instead of saying which ones are invariant. If you have no
+Front-Cover Texts, write "no Front-Cover Texts" instead of
+"Front-Cover Texts being LIST"; likewise for Back-Cover Texts.
If your document contains nontrivial examples of program code, we
+recommend releasing these examples in parallel under your choice of
+free software license, such as the GNU General Public License,
+to permit their use in free software.
system-property
\ No newline at end of file
diff --git a/guide/2.2.2/gindex.html b/guide/2.2.2/gindex.html
new file mode 100644
index 0000000000..6318888c21
--- /dev/null
+++ b/guide/2.2.2/gindex.html
@@ -0,0 +1 @@
+IndexDocBook xslTNG Reference
\ No newline at end of file
diff --git a/guide/2.2.2/glossary.html b/guide/2.2.2/glossary.html
new file mode 100644
index 0000000000..7f15164e5a
--- /dev/null
+++ b/guide/2.2.2/glossary.html
@@ -0,0 +1,27 @@
+GlossaryDocBook xslTNG Reference
Glossary
Clark name
A Clark name is a way of unambiguously representing a qualified
+name (see XML) as a string. It consists of the
+namespace name in curly braces followed immediately by the local name.
+For example, the Clark name for the DocBook para element
+is: “{http://docbook.org/ns/docbook}para”.
hamburger menu
The “hamburger menu” or
+“hamburger
+button” is the name for the “☰” icon often used to indicate a menu of choices.
+
intrinsic size
The intrinsic size of an object is it’s actual size, measured in absolute
+units, usually pixels. The stylesheets rely on extension functions to obtain
+the intrinsic size of objects; if the extension functions aren’t available or the
+image format is not recognized, no intrinsic size will be known.
is true
XPath defines a boolean type, xs:boolean, that is either
+true or false. But for the purpose of passing parameters to the stylesheet
+at runtime, whether it’s from the command line, from a configuration file, or
+through some other means, it’s often more convenient to pass string values.
+This saves the user from having to use whatever extra syntactic mechanisms
+would be required to identify the type of the variable.
To this end, many “boolean” parameters are actually strings. A string
+value is true if it consists of one of the strings “true”,
+“yes”, or “1”.
object
In this guide, the term “object” is used to refer generally to
+any image, video, or audio media element. They have a width and a height but no
+useful internal structure from the perspective of the stylesheets.
+
pseudo-attribute
Processing instructions (see XML) have no
+internal structure. The stylesheets interrogate the
+db processing instruction to determine formatting properties
+for a number of different elements.
In order to make it easy to consistently specify different properties,
+the value of the processing instruction is parsed as if it contained
+attributes. These pseudo-attributes must consist of
+a name, followed by “=”, followed by a quoted string.
Appendix A . Changes in version 2.x
References
\ No newline at end of file
diff --git a/guide/2.2.2/index.html b/guide/2.2.2/index.html
new file mode 100644
index 0000000000..7c144f9d09
--- /dev/null
+++ b/guide/2.2.2/index.html
@@ -0,0 +1,6 @@
+DocBook xslTNG Reference
Examples are adapted from ISO 690 and ISO 690-2 standards.
Elements marked with * are optional, + marks mandatory elements
-for online documents and optional for others.
1. Monographs
Non-serial bibliographic item, i.e. an item either complete in
+
Unit Test: iso690.001.xml
Examples are adapted from ISO 690 and ISO 690-2 standards.
Elements marked with * are optional, + marks mandatory elements
+for online documents and optional for others.
1. Monographs
Non-serial bibliographic item, i.e. an item either complete in
one part or complete (or intended to be completed) in a finite number
of separate parts.
Element
Example
Primary responsibility
LOMINADZE, DG.
Title
Cyclotron waves in plasma
*
Subordinate responsibility
Translated by AN. Dellis; edited by SM. Hamberger
Edition
1st ed.
*
Place of publication
Oxford
*
Publisher
Pergamon Press
Year of publication
1981
*
Extent
206 p.
*
Series
International series in natural philosophy
*
Notes
Translation of: Ciklotronnye volny v plasme
Standard number
ISBN 0-08-021680-3
Markup:
1 |<biblioentryrole="monograph">
diff --git a/report/expected/iso690.002.html b/report/expected/iso690.002.html
index 63fce7c9a4..a540069ae9 100644
--- a/report/expected/iso690.002.html
+++ b/report/expected/iso690.002.html
@@ -1,7 +1,7 @@
Unit Test: iso690.002.xml
Unit Test: iso690.002.xml
Examples are adapted from ISO 690 and ISO 690-2 standards.
Elements marked with * are optional, + marks mandatory elements
-for online documents and optional for others.
1. Serials
Publication, in any medium, issued in successive parts, usually
+
Unit Test: iso690.002.xml
Examples are adapted from ISO 690 and ISO 690-2 standards.
Elements marked with * are optional, + marks mandatory elements
+for online documents and optional for others.
1. Serials
Publication, in any medium, issued in successive parts, usually
having numeric or chronological designations, and intended to be
continued indefinitely.
Element
Example
Title
Communications equipment manufacturers
Responsibility
Manufacturing and Primary Industries Division, Statistics Canada
Edition
Preliminary edition
Issue designation (date and/or n°)
1970-
*
Place of publication
Ottawa
*
Publisher
Statistics Canada
Year of publication
1971-
*
Series
Annual census of manufacturers
*
Notes
Text in English and French
Standard number
ISSN 0700-0758
Markup:
1 |<biblioentryrole="serial">
diff --git a/report/expected/iso690.003.html b/report/expected/iso690.003.html
index 3d1686605c..d44100f5a4 100644
--- a/report/expected/iso690.003.html
+++ b/report/expected/iso690.003.html
@@ -1,7 +1,7 @@
Unit Test: iso690.003.xml
Unit Test: iso690.003.xml
Examples are adapted from ISO 690 and ISO 690-2 standards.
Elements marked with * are optional, + marks mandatory elements
-for online documents and optional for others.
1. Parts of monographs
Element
Example
Primary responsibility
PARKER, TJ. and HASWELL, WD.
Title of host document
A text-book of zoology
+
Unit Test: iso690.003.xml
Examples are adapted from ISO 690 and ISO 690-2 standards.
Elements marked with * are optional, + marks mandatory elements
+for online documents and optional for others.
1. Parts of monographs
Element
Example
Primary responsibility
PARKER, TJ. and HASWELL, WD.
Title of host document
A text-book of zoology
Edition
5th ed.
Numeration of the part
vol. 1
*
Subordinate responsibility
revised by WD. Lang
*
Place of publication
London
*
Publisher
Macmillan
Year of publication
1930
Location within host
Section 12, Phylum Mollusca, p. 663-782
Markup:
1 |<biblioentryrole="part">|<authorgroup>|<author>
diff --git a/report/expected/iso690.004.html b/report/expected/iso690.004.html
index 14f43fb0ed..b3434537ff 100644
--- a/report/expected/iso690.004.html
+++ b/report/expected/iso690.004.html
@@ -1,7 +1,7 @@
Unit Test: iso690.004.xml
Unit Test: iso690.004.xml
Examples are adapted from ISO 690 and ISO 690-2 standards.
Elements marked with * are optional, + marks mandatory elements
-for online documents and optional for others.
1. Contributions to monographs
Contribution is independent unit forming part of a document.
Element
Example
for contribution:
Primary responsibility
WRIGLEY, EA.
Title
Parish registers and the historian
for host:
Primary responsibility
STEEL, DJ.
Title
National index of parish registers
+
Unit Test: iso690.004.xml
Examples are adapted from ISO 690 and ISO 690-2 standards.
Elements marked with * are optional, + marks mandatory elements
+for online documents and optional for others.
1. Contributions to monographs
Contribution is independent unit forming part of a document.
Element
Example
for contribution:
Primary responsibility
WRIGLEY, EA.
Title
Parish registers and the historian
for host:
Primary responsibility
STEEL, DJ.
Title
National index of parish registers
Edition
— (not in this example)
*
Place of publication
London
*
Publisher
Society of Genealogists
Year of publication
1968
Location within host
vol. 1, p. 155-167
Markup:
1 |<biblioentryrole="contribution">|<bibliosetrelation="part">|<author>
diff --git a/report/expected/iso690.005.html b/report/expected/iso690.005.html
index f6266ae9ab..4dd7445788 100644
--- a/report/expected/iso690.005.html
+++ b/report/expected/iso690.005.html
@@ -1,7 +1,7 @@
Unit Test: iso690.005.xml
Unit Test: iso690.005.xml
Examples are adapted from ISO 690 and ISO 690-2 standards.
Elements marked with * are optional, + marks mandatory elements
-for online documents and optional for others.
1. Articles, etc., in serials
Element
Example
Primary responsibility
WEAVER, William
Title
The collectors: command performances
*
Subordinate responsibility
Photography by Robert Emmett Bright
Title of host document
Architectural Digest
+
Unit Test: iso690.005.xml
Examples are adapted from ISO 690 and ISO 690-2 standards.
Elements marked with * are optional, + marks mandatory elements
+for online documents and optional for others.
1. Articles, etc., in serials
Element
Example
Primary responsibility
WEAVER, William
Title
The collectors: command performances
*
Subordinate responsibility
Photography by Robert Emmett Bright
Title of host document
Architectural Digest
Edition
— (not in this example)
Location within host:
Year, Issue designation, Pagination of the part
December 1985, vol. 42, no. 12, p. 126-133
Markup:
1 |<biblioentryrole="article">|<bibliosetrelation="article">|<author>
diff --git a/report/expected/iso690.006.html b/report/expected/iso690.006.html
index 5cb67f3e6d..caf1e0a85f 100644
--- a/report/expected/iso690.006.html
+++ b/report/expected/iso690.006.html
@@ -1,7 +1,7 @@
Unit Test: iso690.006.xml
Unit Test: iso690.006.xml
Examples are adapted from ISO 690 and ISO 690-2 standards.
Elements marked with * are optional, + marks mandatory elements
-for online documents and optional for others.
1. Patent documents
Element
Example
*
Primary responsibility (applicant)
Carl Zeiss Jena, VEB
*
Title of the invention
Anordnung zur lichtelektrischen Erfassung der Mitte eines Lichtfeldes
+
Unit Test: iso690.006.xml
Examples are adapted from ISO 690 and ISO 690-2 standards.
Elements marked with * are optional, + marks mandatory elements
+for online documents and optional for others.
1. Patent documents
Element
Example
*
Primary responsibility (applicant)
Carl Zeiss Jena, VEB
*
Title of the invention
Anordnung zur lichtelektrischen Erfassung der Mitte eines Lichtfeldes
*
Subordinate responsibility
Erfinder: W. FEIST, C. WAHNERT, E. FEISTAUER
*
Notes
Int. Cl.3: G02 B 27/14
Identification:
Country or issuing office
Schweiz
Kind of patent document
Patentschrift
Number
608 626
Date of publication of cited document
1979-01-15
Markup:
1 |<biblioentryrole="patent">|<author>|<orgname>CarlZeissJena,VEB</orgname>
diff --git a/report/expected/iso690.007.html b/report/expected/iso690.007.html
index 7ba2903216..401f90bf1f 100644
--- a/report/expected/iso690.007.html
+++ b/report/expected/iso690.007.html
@@ -1,7 +1,7 @@
Unit Test: iso690.007.xml
Unit Test: iso690.007.xml
Examples are adapted from ISO 690 and ISO 690-2 standards.
Elements marked with * are optional, + marks mandatory elements
-for online documents and optional for others.
1. Monographs, databases and computer programs
Element
Example
Primary responsibility
CARROLL, Lewis
Title
Alice's Adventures in Wonderland
+
Unit Test: iso690.007.xml
Examples are adapted from ISO 690 and ISO 690-2 standards.
Elements marked with * are optional, + marks mandatory elements
+for online documents and optional for others.
1. Monographs, databases and computer programs
Element
Example
Primary responsibility
CARROLL, Lewis
Title
Alice's Adventures in Wonderland
Type of medium
[online]
*
Subordinate responsibility
— (not in this example)
Edition
Textinfo ed. 2.1
Place of publication
[Dortmund, Germany]
Publisher
Windspiel
Date of publication
November 1994
Date of update/revision
— (not in this example)
+
Date of citation
[cited 10 February 1995]
*
Series
— (not in this example)
*
Notes
— (not in this example)
+
Availability and access
Available from World Wide Web: <http://germany.eu.net/books/carroll/alice/html>
Also available in PostScript and ASCII versions from Internet: <ftp://ftp.Germany.EU.net/pub/books/carroll/>
Standard number
— (not in this example)
Markup:
1 |<biblioentryrole="monograph">|<author>
diff --git a/report/expected/iso690.008.html b/report/expected/iso690.008.html
index 98d9d8ccc4..4ee1a38ec5 100644
--- a/report/expected/iso690.008.html
+++ b/report/expected/iso690.008.html
@@ -1,7 +1,7 @@
Unit Test: iso690.008.xml
Unit Test: iso690.008.xml
Examples are adapted from ISO 690 and ISO 690-2 standards.
Elements marked with * are optional, + marks mandatory elements
-for online documents and optional for others.
1. Parts of monographs, databases and computer programs
Element
Example
Primary responsibility of host document
CARROLL, Lewis
Title of host document
Alice's Adventures in Wonderland
+
Unit Test: iso690.008.xml
Examples are adapted from ISO 690 and ISO 690-2 standards.
Elements marked with * are optional, + marks mandatory elements
+for online documents and optional for others.
1. Parts of monographs, databases and computer programs
Element
Example
Primary responsibility of host document
CARROLL, Lewis
Title of host document
Alice's Adventures in Wonderland
Type of medium
[online]
*
Subordinate responsibility of host document
— (not in this example)
Edition
Textinfo ed. 2.2
Place of publication
[Dortmund, Germany]
Publisher
Windspiel
Date of publication
November 1994
Date of update/revision
— (not in this example)
+
Date of citation
[cited 30 March 1995]
Chapter or equivalent designation (of part)
Chapter VII
Title (of part)
Mad Tea-Party
*
Numeration within host document
— (not in this example)
Location within host document
— (not in this example)
*
Notes
— (not in this example)
+
Availability and access
Available from World Wide Web: <http://germany.eu.net/books/carroll/alice_10.html#SEC13>
Standard number
— (not in this example)
Markup:
1 |<biblioentryrole="part">|<author>|<personname>
diff --git a/report/expected/iso690.009.html b/report/expected/iso690.009.html
index cba95d7409..c2d8787b13 100644
--- a/report/expected/iso690.009.html
+++ b/report/expected/iso690.009.html
@@ -1,7 +1,7 @@
Unit Test: iso690.008.xml
Unit Test: iso690.008.xml
Examples are adapted from ISO 690 and ISO 690-2 standards.
Elements marked with * are optional, + marks mandatory elements
-for online documents and optional for others.
1. Contributions to monographs, databases and computer programs
Element
Example
Primary responsibility (of contribution)
MCCONNELL, W. H.
Title (of contribution)
Constitutional History
Primary responsibility of host document
— (not in this example)
Title of host document
The Canadian Encyclopedia
+
Unit Test: iso690.008.xml
Examples are adapted from ISO 690 and ISO 690-2 standards.
Elements marked with * are optional, + marks mandatory elements
+for online documents and optional for others.
1. Contributions to monographs, databases and computer programs
Element
Example
Primary responsibility (of contribution)
MCCONNELL, W. H.
Title (of contribution)
Constitutional History
Primary responsibility of host document
— (not in this example)
Title of host document
The Canadian Encyclopedia
Type of medium
[CD-ROM]
*
Subordinate responsibility of host document
— (not in this example)
Edition
Macintosh version 1.1
Place of publication
Toronto
Publisher
McClelland & Stewart
Date of publication
c1993
Date of update/revision
— (not in this example)
+
Date of citation
— (not in this example)
*
Numeration within host document
— (not in this example)
Location within host document
— (not in this example)
*
Notes
— (not in this example)
+
Availability and access
— (not in this example)
Standard number
ISBN 0-7710-1932-7
Markup:
1 |<biblioentryrole="contribution">|<bibliosetrelation="part">|<author>
diff --git a/report/expected/iso690.010.html b/report/expected/iso690.010.html
index bdcd9e66cc..f4bc588e2e 100644
--- a/report/expected/iso690.010.html
+++ b/report/expected/iso690.010.html
@@ -1,7 +1,7 @@
Unit Test: iso690.009.xml
Unit Test: iso690.009.xml
Examples are adapted from ISO 690 and ISO 690-2 standards.
Elements marked with * are optional, + marks mandatory elements
-for online documents and optional for others.
1. Electronic serials
Element
Example
Title
Journal of Technology Education
+
Unit Test: iso690.009.xml
Examples are adapted from ISO 690 and ISO 690-2 standards.
Elements marked with * are optional, + marks mandatory elements
+for online documents and optional for others.
1. Electronic serials
Element
Example
Title
Journal of Technology Education
Type of medium
[online]
Edition
— (not in this example)
Place of publication
Blacksburg (Va.)
Publisher
Virginia Polytechnic Institute and State University
Date of publication
1989-
+
Date of citation
[cited 15 March 1995]
*
Series
— (not in this example)
*
Notes
Semi-annual
+
Availability and access
Available from Internet: <gopher://borg.lib.vt.edu:edu:70/1/jte>
Standard number
ISSN 1045-1064
Markup:
1 |<biblioentryrole="serial">|<title>JournalofTechnologyEducation</title>|<bibliomiscrole="medium">online</bibliomisc>
diff --git a/report/expected/iso690.011.html b/report/expected/iso690.011.html
index b18fa1c383..87cdb1f6f8 100644
--- a/report/expected/iso690.011.html
+++ b/report/expected/iso690.011.html
@@ -1,7 +1,7 @@
Unit Test: iso690.010.xml
Unit Test: iso690.010.xml
Examples are adapted from ISO 690 and ISO 690-2 standards.
Elements marked with * are optional, + marks mandatory elements
-for online documents and optional for others.
1. Articles and other contributions
Element
Example
Primary responsibility of contribution
PRICE-WILKIN, John
Title of contribution
Using the World-Wide Web to Deliver Complex Electronic Documents: Implications for Libraries
Title Serials
The Public-Access Computer Systems Review
+
Unit Test: iso690.010.xml
Examples are adapted from ISO 690 and ISO 690-2 standards.
Elements marked with * are optional, + marks mandatory elements
+for online documents and optional for others.
1. Articles and other contributions
Element
Example
Primary responsibility of contribution
PRICE-WILKIN, John
Title of contribution
Using the World-Wide Web to Deliver Complex Electronic Documents: Implications for Libraries
Title Serials
The Public-Access Computer Systems Review
Type of medium
[online]
Edition
— (not in this example)
Number designation
1994, vol. 5, no. 3
Date of update/revision
— (not in this example)
+
Date of citation
[cited 1994-07-28]
Location within host document
pp. 5-21
*
Notes
— (not in this example)
+
Availability and access
Available from Internet: <gopher://info.lib.uh.edu:70/00/articles/e-journals/uhlibrary/pacsreview/v5/n3/pricewil.5n3>
Standard number
ISSN 1048-6542
Markup:
1 |<biblioentryrole="article">|<bibliosetrelation="article">|<author>
diff --git a/report/expected/iso690.012.html b/report/expected/iso690.012.html
index ea64a095c2..31a2c03cb3 100644
--- a/report/expected/iso690.012.html
+++ b/report/expected/iso690.012.html
@@ -1,7 +1,7 @@
Unit Test: iso690.011.xml
Unit Test: iso690.011.xml
Examples are adapted from ISO 690 and ISO 690-2 standards.
Elements marked with * are optional, + marks mandatory elements
-for online documents and optional for others.
1. Electronic bulletin boards, discussion lists and electronic messages
Element
Example
Title
PACS-L (Public Access Computer Systems Forum)
+
Unit Test: iso690.011.xml
Examples are adapted from ISO 690 and ISO 690-2 standards.
Elements marked with * are optional, + marks mandatory elements
+for online documents and optional for others.
1. Electronic bulletin boards, discussion lists and electronic messages
Element
Example
Title
PACS-L (Public Access Computer Systems Forum)
Type of medium
[online]
Place of publication
Houston (Tex.)
Publisher
University of Houston Libraries
Date of publication
June 1989-
Date of citation
[cited 17 May 1995]
*
Notes
— (not in this example)
Availability and access
Available from Internet: <listserv@unhupvm1.uh.edu>
Markup:
1 |<biblioentryrole="messagesystem">|<title>PACS-L(PublicAccessComputerSystemsForum)</title>|<bibliomiscrole="medium">online</bibliomisc>
diff --git a/report/expected/iso690.013.html b/report/expected/iso690.013.html
index 561db31d14..82cfd1e997 100644
--- a/report/expected/iso690.013.html
+++ b/report/expected/iso690.013.html
@@ -1,7 +1,7 @@
Unit Test: iso690.012.xml
Unit Test: iso690.012.xml
Examples are adapted from ISO 690 and ISO 690-2 standards.
Elements marked with * are optional, + marks mandatory elements
-for online documents and optional for others.
1. Electronic messages
Element
Example
Primary responsibility of message
PARKER, Elliot
Title of message
Re: Citing Electronic Journals
Title of host message system
PACS-L (Public Access Computer Systems Forum)
+
Unit Test: iso690.012.xml
Examples are adapted from ISO 690 and ISO 690-2 standards.
Elements marked with * are optional, + marks mandatory elements
+for online documents and optional for others.
1. Electronic messages
Element
Example
Primary responsibility of message
PARKER, Elliot
Title of message
Re: Citing Electronic Journals
Title of host message system
PACS-L (Public Access Computer Systems Forum)
Type of medium
[online]
*
Subordinate responsibility/applicant(s)
— (not in this example)
Place of publication
Houston (Tex.)
Publisher
University of Houston Libraries
Date of publication
24 November 1989; 13:29:35 CST
Date of citation
[cited 1 January 1995; 16:15 EST]
*
Numeration within host message system
— (not in this example)
Location within host message system
— (not in this example)
Availability and access
Available from Internet: <telnet://brsuser@a.cni.org>
*
Notes
— (not in this example)
Markup:
1 |<biblioentryrole="message">|<bibliosetrelation="part">|<author>
diff --git a/report/expected/js/annotations.js b/report/expected/js/annotations.js
index befc643d6b..43a71ecccd 100644
--- a/report/expected/js/annotations.js
+++ b/report/expected/js/annotations.js
@@ -1,4 +1,4 @@
-/* DocBook xslTNG version 2.2.1-SNAPSHOT
+/* DocBook xslTNG version 2.2.2-SNAPSHOT
*
* This is annotations.js providing support for popup annotations.
*
diff --git a/report/expected/js/chunk-nav.js b/report/expected/js/chunk-nav.js
index 964de9ab93..61336104ba 100644
--- a/report/expected/js/chunk-nav.js
+++ b/report/expected/js/chunk-nav.js
@@ -1,4 +1,4 @@
-/* DocBook xslTNG version 2.2.1-SNAPSHOT
+/* DocBook xslTNG version 2.2.2-SNAPSHOT
*
* This is chunk-nav.js providing support for keyboard
* navigation between chunks.
diff --git a/report/expected/js/controls.js b/report/expected/js/controls.js
index 52a990078f..3594d9836e 100644
--- a/report/expected/js/controls.js
+++ b/report/expected/js/controls.js
@@ -1,4 +1,4 @@
-/* DocBook xslTNG version 2.2.1-SNAPSHOT
+/* DocBook xslTNG version 2.2.2-SNAPSHOT
*
* This is controls.js providing JavaScript controls.
*
diff --git a/report/expected/js/copy-verbatim.js b/report/expected/js/copy-verbatim.js
index 4ee3c33229..d35c560b9f 100644
--- a/report/expected/js/copy-verbatim.js
+++ b/report/expected/js/copy-verbatim.js
@@ -1,4 +1,4 @@
-/* DocBook xslTNG version 2.2.1-SNAPSHOT
+/* DocBook xslTNG version 2.2.2-SNAPSHOT
*
* This is copy-verbatim.js providing support for a dynamic
* copy-to-clipboard link on verbatim listings.
diff --git a/report/expected/js/fallback.js b/report/expected/js/fallback.js
index bfa640b6e1..7e2407485c 100644
--- a/report/expected/js/fallback.js
+++ b/report/expected/js/fallback.js
@@ -1,4 +1,4 @@
-/* DocBook xslTNG version 2.2.1-SNAPSHOT
+/* DocBook xslTNG version 2.2.2-SNAPSHOT
*
* This is fallback.js providing support for audio/video fallback.
*
diff --git a/report/expected/js/pagetoc.js b/report/expected/js/pagetoc.js
index 81af1eafee..9d81939057 100644
--- a/report/expected/js/pagetoc.js
+++ b/report/expected/js/pagetoc.js
@@ -1,4 +1,4 @@
-/* DocBook xslTNG version 2.2.1-SNAPSHOT
+/* DocBook xslTNG version 2.2.2-SNAPSHOT
*
* This is pagetoc.js providing support for on-page ToCs.
*
diff --git a/report/expected/js/persistent-toc.js b/report/expected/js/persistent-toc.js
index df007b49f6..3dadb10089 100644
--- a/report/expected/js/persistent-toc.js
+++ b/report/expected/js/persistent-toc.js
@@ -1,4 +1,4 @@
-/* DocBook xslTNG version 2.2.1-SNAPSHOT
+/* DocBook xslTNG version 2.2.2-SNAPSHOT
*
* This is persistent-toc.js providing support for the ToC popup
*
@@ -14,7 +14,7 @@
let borderLeftColor = "white";
let curpress = null;
let searchListener = false;
- let VERSION = "2.2.1-SNAPSHOT";
+ let VERSION = "2.2.2-SNAPSHOT";
let PTOCID = "ptoc-data-file";
const showToC = function(event) {
diff --git a/report/expected/js/presentation.js b/report/expected/js/presentation.js
index c9ee6c414f..1dbc2d8a8d 100644
--- a/report/expected/js/presentation.js
+++ b/report/expected/js/presentation.js
@@ -1,4 +1,4 @@
-/* DocBook xslTNG version 2.2.1-SNAPSHOT
+/* DocBook xslTNG version 2.2.2-SNAPSHOT
*
* See https://xsltng.docbook.org/
*
diff --git a/report/expected/js/xlink.js b/report/expected/js/xlink.js
index 7e34f6545d..73a6f70ccb 100644
--- a/report/expected/js/xlink.js
+++ b/report/expected/js/xlink.js
@@ -1,4 +1,4 @@
-/* DocBook xslTNG version 2.2.1-SNAPSHOT
+/* DocBook xslTNG version 2.2.2-SNAPSHOT
*
* This is xlink.js providing support for multi-targeted links
*
diff --git a/report/expected/l10n.001.html b/report/expected/l10n.001.html
index c10b45ab55..a791a87039 100644
--- a/report/expected/l10n.001.html
+++ b/report/expected/l10n.001.html
@@ -1 +1 @@
-Unit Test: l10n.001.xml
\ No newline at end of file
diff --git a/report/expected/l10n.002.html b/report/expected/l10n.002.html
index 57369fb57b..176d0c79d6 100644
--- a/report/expected/l10n.002.html
+++ b/report/expected/l10n.002.html
@@ -1 +1 @@
-Unit Test: l10n.002.xml
\ No newline at end of file
diff --git a/report/expected/l10n.003.html b/report/expected/l10n.003.html
index 275c84cde9..873033db06 100644
--- a/report/expected/l10n.003.html
+++ b/report/expected/l10n.003.html
@@ -1,4 +1,4 @@
-Unit test: l10n.003
This is a section.
Lorem ipsum dolor sit amet, consectetaur adipisicing elit, sed do
eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad
minim veniam, quis nostrud exercitation ullamco laboris nisi ut
diff --git a/report/expected/numeration-book.001.html b/report/expected/numeration-book.001.html
index 006ea2d6dc..8ce015276b 100644
--- a/report/expected/numeration-book.001.html
+++ b/report/expected/numeration-book.001.html
@@ -32,7 +32,7 @@
parts, components, and formal objects. In this book, division and
component numbers are in herited.
Book to test sequential numbering of
parts, components, and formal objects. In this book, division,
- component, and section numbers are inherited.
\ No newline at end of file
diff --git a/report/expected/oxy-changemarkup.001.html b/report/expected/oxy-changemarkup.001.html
index 6e11c3ee06..9d28b7e719 100644
--- a/report/expected/oxy-changemarkup.001.html
+++ b/report/expected/oxy-changemarkup.001.html
@@ -4,4 +4,4 @@
beginning of the next.
It has several
paras.
It hHas
several paras. Oxygen
- kept the markup balanced. nice.
<appendix><title>Appendix One</title><para>Some other paragraph.</para><section><title>Section One</title><para>Some other paragraph.</para><section><title>Section One.Two</title><para>Some other paragraph.</para></section><section><title>Section One.Three</title><para>Some other paragraph.</para></section></section></appendix>
\ No newline at end of file
+ kept the markup balanced. nice.
<appendix><title>Appendix One</title><para>Some other paragraph.</para><section><title>Section One</title><para>Some other paragraph.</para><section><title>Section One.Two</title><para>Some other paragraph.</para></section><section><title>Section One.Three</title><para>Some other paragraph.</para></section></section></appendix>
\ No newline at end of file
diff --git a/report/expected/oxy-changemarkup.002.html b/report/expected/oxy-changemarkup.002.html
index 1b1cbaf0b4..ecd2362df9 100644
--- a/report/expected/oxy-changemarkup.002.html
+++ b/report/expected/oxy-changemarkup.002.html
@@ -4,4 +4,4 @@
beginning of the next.
It has several
Has
several paras. Oxygen
- kept the markup balanced. nice.
\ No newline at end of file
diff --git a/report/expected/part.001.html b/report/expected/part.001.html
index bd894fb83d..173fa7a9e8 100644
--- a/report/expected/part.001.html
+++ b/report/expected/part.001.html
@@ -1,3 +1,3 @@
-Part I. Unit Test: part.001
\ No newline at end of file
diff --git a/report/expected/section.001.html b/report/expected/section.001.html
index ad51567d49..d8bd30276a 100644
--- a/report/expected/section.001.html
+++ b/report/expected/section.001.html
@@ -1 +1 @@
-Article wrapper
\ No newline at end of file
diff --git a/report/expected/section.004.html b/report/expected/section.004.html
index a96ae88f17..833b2ccef0 100644
--- a/report/expected/section.004.html
+++ b/report/expected/section.004.html
@@ -1 +1 @@
-Chapter 1. Article wrapper
Chapter 1. Article wrapper
Blah.
1. Section 1
blah.
1.1. Section 1.1
blah.
1.1.1. Section 1.1.1
blah.
1.1.1.1. Section 1.1.1.1
blah.
1.1.1.1.1. Section 1.1.1.1.1
blah.
1.1.1.1.2. Section 1.1.1.1.2
blah.
1.1.1.1.3. Section 1.1.1.1.3
blah.
1.1.1.2. Section 1.1.1.2
blah.
1.1.1.3. Section 1.1.1.3
blah.
1.1.2. Section 1.1.2
blah.
1.1.3. Section 1.1.3
blah.
1.2. Section 1.2
blah.
1.3. Section 1.3
blah.
2. Section 2
blah.
\ No newline at end of file
+Chapter 1. Article wrapper
Chapter 1. Article wrapper
Blah.
1. Section 1
blah.
1.1. Section 1.1
blah.
1.1.1. Section 1.1.1
blah.
1.1.1.1. Section 1.1.1.1
blah.
1.1.1.1.1. Section 1.1.1.1.1
blah.
1.1.1.1.2. Section 1.1.1.1.2
blah.
1.1.1.1.3. Section 1.1.1.1.3
blah.
1.1.1.2. Section 1.1.1.2
blah.
1.1.1.3. Section 1.1.1.3
blah.
1.1.2. Section 1.1.2
blah.
1.1.3. Section 1.1.3
blah.
1.2. Section 1.2
blah.
1.3. Section 1.3
blah.
2. Section 2
blah.
\ No newline at end of file
diff --git a/report/expected/section.005.html b/report/expected/section.005.html
index 5ec548f4ba..afa14453b6 100644
--- a/report/expected/section.005.html
+++ b/report/expected/section.005.html
@@ -1 +1 @@
-Unit Test: section.005
\ No newline at end of file
diff --git a/report/expected/simplesect.001.html b/report/expected/simplesect.001.html
index 878bac2b98..1680ba3418 100644
--- a/report/expected/simplesect.001.html
+++ b/report/expected/simplesect.001.html
@@ -1 +1 @@
-Chapter 1. Chapter wrapper
Chapter 1. Chapter wrapper
This test case is for simplesect.
1. A Section Title
Some content here.
First Simplesect
Some content
2. Another Section Title
Some content
2.1. A Subsection Title
Some content
Second Simplesect
Some content
\ No newline at end of file
+Chapter 1. Chapter wrapper
Chapter 1. Chapter wrapper
This test case is for simplesect.
1. A Section Title
Some content here.
First Simplesect
Some content
2. Another Section Title
Some content
2.1. A Subsection Title
Some content
Second Simplesect
Some content
\ No newline at end of file
diff --git a/report/expected/table-cals.024.html b/report/expected/table-cals.024.html
index ac8cc30d0d..f7208c384b 100644
--- a/report/expected/table-cals.024.html
+++ b/report/expected/table-cals.024.html
@@ -1 +1 @@
-
Table 1. This is a “landscape” table
foo
foo
bar
foo
\ No newline at end of file
+
Table 1. This is a “landscape” table
foo
foo
bar
foo
\ No newline at end of file
diff --git a/report/expected/titles.001.html b/report/expected/titles.001.html
index faba5e9e57..92af38053f 100644
--- a/report/expected/titles.001.html
+++ b/report/expected/titles.001.html
@@ -1,8 +1,8 @@
-Unit Test: titles.001.xml
\ No newline at end of file
diff --git a/report/expected/topic.003.html b/report/expected/topic.003.html
index d623f0b0db..e36e3cdd39 100644
--- a/report/expected/topic.003.html
+++ b/report/expected/topic.003.html
@@ -1,10 +1,10 @@
An book with several topics
In this document, no transclusion fixup is performed. Duplicate IDs exist,
links to those IDs are resolved by the user agent.
In a document where the same fragment is included (for example,
with XInclude) more than once, any ID values in that fragment will
be duplicated in the resulting document. Duplicate IDs should be avoided.
@@ -17,7 +17,7 @@
If it is simple transcluded more than once into a document, it will
introduce duplicate IDs in the document.
This caution has the xml:id value ‘caution’.
If it is simple transcluded more than once into a document, it will
diff --git a/report/expected/transclusion.002.html b/report/expected/transclusion.002.html
index c292d7bc36..56d6b971a5 100644
--- a/report/expected/transclusion.002.html
+++ b/report/expected/transclusion.002.html
@@ -1,4 +1,4 @@
-
In this document, all transcluded IDs are resolved with the ‘auto’ fixup.
In a document where the same fragment is included (for example,
with XInclude) more than once, any ID values in that fragment will
be duplicated in the resulting document. Duplicate IDs should be avoided.
The DocBook Transclusion
@@ -16,7 +16,7 @@
If it is simple transcluded more than once into a document, it will
introduce duplicate IDs in the document.
This caution has the xml:id value ‘caution’.
If it is simple transcluded more than once into a document, it will
diff --git a/report/expected/transclusion.003.html b/report/expected/transclusion.003.html
index a97ffd455f..a35ec92535 100644
--- a/report/expected/transclusion.003.html
+++ b/report/expected/transclusion.003.html
@@ -1,4 +1,4 @@
-
In this document, all transcluded IDs are resolved with the ‘suffix’ fixup
and the default linkscope which is ‘global’.
In a document where the same fragment is included (for example,
with XInclude) more than once, any ID values in that fragment will
be duplicated in the resulting document. Duplicate IDs should be avoided.
@@ -17,7 +17,7 @@
If it is simple transcluded more than once into a document, it will
introduce duplicate IDs in the document.
This caution has the xml:id value ‘caution’.
If it is simple transcluded more than once into a document, it will
diff --git a/report/expected/transclusion.004.html b/report/expected/transclusion.004.html
index a4ba2c0539..f1464666b7 100644
--- a/report/expected/transclusion.004.html
+++ b/report/expected/transclusion.004.html
@@ -1,4 +1,4 @@
-
In this document, all transcluded IDs are resolved with the ‘suffix’ fixup
and ‘local’ linkscope.
In a document where the same fragment is included (for example,
with XInclude) more than once, any ID values in that fragment will
be duplicated in the resulting document. Duplicate IDs should be avoided.
@@ -17,7 +17,7 @@
If it is simple transcluded more than once into a document, it will
introduce duplicate IDs in the document.
This caution has the xml:id value ‘caution’.
If it is simple transcluded more than once into a document, it will
diff --git a/report/expected/xref.002.html b/report/expected/xref.002.html
index 2fd36df481..6db27df380 100644
--- a/report/expected/xref.002.html
+++ b/report/expected/xref.002.html
@@ -1,3 +1,3 @@
-
\ No newline at end of file
diff --git a/report/fit-result.html b/report/fit-result.html
index 17ef59d2b3..e8f175b6fe 100644
--- a/report/fit-result.html
+++ b/report/fit-result.html
@@ -592,7 +592,7 @@