DITA-OT 2.5 includes a basic Java API, an experimental map-first
preprocessing option, better support for DITA composite documents, publishing with multiple DITAVAL files, and
more consistent styling for default PDF output.
Java Application Programming Interface
DITA-OT 2.5 includes a new
Java API to allow developers to embed DITA-OT more easily into other Java programs.
Tip: See the DITA-OT Java API documentation in the doc/api/ folder
of the DITA-OT distribution package for information on the packages, classes, interfaces and methods provided
by the Java API.
DITA-OT 2.5 introduces an experimental map-first preprocessing option as an
alternative to the default
preprocess operation. The new method provides the same functionality,
but takes a different approach.
Whereas the default preprocessing routine handles both maps and topics at the same
time, the map-first approach begins by processing maps as far as possible, and only then starts processing topics.
This simplifies the processing logic and creates cleaner module responsibilities, which makes it easier to process
only those topics that are actually referenced after filtering, for example, or to only process the map to
validate the map structure.
Note: The map-first preprocessing option is not enabled by default in DITA-OT 2.5, but
is offered as an experimental preview feature to allow users and vendors who extend preprocessing to provide
feedback on possible issues with the design. The new option will most likely become the default in DITA-OT
Experimental map-first preprocessing,
Improved PDF support for DITA composite documents
When publishing PDF output from a DITA composite document (a DITA document with a root
<dita> element), earlier versions of DITA-OT included only the first topic, and links
to topics within
<dita> elements were broken. The PDF output now includes the full
content of the referenced document, and links to any element within the document are correct.
Attributes from the
<dita> element are now preserved when merging topics. In
previous releases, attributes like
@xml:lang set on the
were lost during the PDF "topic merge" process.
Publishing with multiple DITAVAL filter files
args.filter parameter, which previously allowed you to specify a single DITAVAL file for
filtering or flagging, now accepts a list of URIs. The system separator character is used to separate the
values. DITAVAL files are evaluated in the order specified, so conditions specified in the first file take
precedence over matching conditions specified in later files, just as conditions at the start of a DITAVAL
document take precedence over matching conditions later in the same document.
This feature allows you to manage your conditions independently or combine conditions from multiple sources.
For example, you can now manage your filter conditions (that might change rarely) separately from revisions,
or easily combine flagging conditions from different products when those products are published together.
DITAVAL properties are now more flexible so that plug-ins can provide a common set of DITAVAL
conditions and override the args.filter parameter. Initialization code has been cleaned
up so that it does not set unnecessary properties.
Default PDF style improvements
Several legacy styles have been modified or removed in the default PDF plug-in
including the following:
- In task topics with only a single step, the step is now rendered as a simple block (rather than as a list
item without a label).
- Table containers now inherit the initial indentation (
start-indent) from the parent
- Borders and indentation have been removed from
- Links are no longer italicized.
- Titles for related link lists have been standardized to use the
set (which applies the
sans-serif font-family) and bold font weight.
- Several remaining occurrences of left/right borders, margins, padding, and text alignment now use the
corresponding start/end equivalents to better support right-to-left languages.