The xtpxlib-xdoc component uses DocBook 5.1 as its source and target vocabulary. However, for generating output (see the docbook-to-pdf and docbook-to-xhtml pipelines) it does not implement the full standard (which is huge!) but only those elements/attributes that were deemed necessary. This document will explain what is in and what's not.

6.1 Supported root elements

Both the <book> and the <article> root element are supported.

For docbook-to-pdf conversion: A <book> root results in a book-like output (with a front page, ToC, etc.). The <article> root results in something more memo style.

6.2 Document information

Document information: The only document information elements recognized are (any others are ignored):

<info>
  
  <title> ... main title ... </title>
  <subtitle> ... subtitle ...</subtitle>
  <pubdate> ... publication date ... </pubdate>
  <author>
    <personname> ... author name ...</personname>
  </author>
  
  <orgname> ... organization ... </orgname>
  
  <mediaobject role="top-logo">
    <!-- Use either role="top-logo" or no role attribute. -->
    <imageobject>
      <imagedata fileref="..." width="...(opt)" height="...(opt)"/>
    </imageobject>
  </mediaobject>
  
  <mediaobject role="center-page">
    <imageobject>
      <imagedata fileref="..." width="...(opt)" height="...(opt)"/>
    </imageobject>
  </mediaobject>
  
</info>

All elements are optional.

6.3 Chapter/Section structure

6.4 Block constructions

the following block level constructions are recognized and handled:

6.5 Inline elements

the following inline elements are recognized and handled:

6.6 Other constructs

6.7 Fixed-width column mechanism

FOP (in the current version, 3Q19) cannot compute the column-widths automatically. It divides the space and you can set a fixed column-width (with colspec/@colwidth). For the case that a column contains code stuff (text in a fixed-width font) and you want the column-width to be dependent on the text in such a column, there is a (unfortunately a bit complicated) mechanism for this.

The fixed-width column mechanism consists of two parts:

Dynamically compute the column width

This part is optional.

Add a role attribute to the <colspec> element with, as one of the roles, code-width-cm:min-max, where min and max are (positive) doubles. For instance <colspec role="code-width-cm:1.2-4">. min and max are the minimum and maximum column-widths, expressed in cm.

The PDF conversion will now look in all the contents of this particular column for entries <code role="code-width-limited">. Based on the length of these entries it computes an optimal column-width, but always between min and max.

Output code width-limited

If a table entry contains contents in a <code role="code-width-limited"> element, it tries to make it fit within the available column-width. If necessary the line is split to prevent overflowing of table cell contents.

This is (currently) not completely fool-proof: if the contents contains whitespace or hyphens, it is assumed to line-break correctly by itself. That, of course, does not guarantee correct results. So it may need a little experimenting before things look right.

A column that contains <code role="code-width-limited"> contents must have a column width set in cm (either directly with <colspec colwidth="…cm"> or by the dynamic mechanism described above).