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.
#2604
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.
Map-first preprocessing
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
3.0.
See
Experimental map-first preprocessing,
#2497
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.
#1077,
#1904,
#2679
Attributes from the <dita>
element are now preserved when merging topics. In
previous releases, attributes like @xml:lang
set on the <dita>
element
were lost during the PDF "topic merge" process.
#1298,
#2698
Publishing with multiple DITAVAL filter files
The 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 path separator character is used to delimit
individual file paths in the list of values (semicolon ‘;
’ on Windows, and colon
‘:
’ on macOS and Linux). 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.
#2637
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.
You can then pass the filenames to the dita command as follows:
dita --input=userguide.ditamap --format=pdf --filter=filters.ditaval:flags.ditaval
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.
#2681
Default PDF style improvements
Several legacy styles have been modified or removed in the default PDF plug-in org.dita.pdf2
,
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
elements.
- Borders and indentation have been removed from
<example>
elements.
- Links are no longer italicized.
- Titles for related link lists have been standardized to use the
common.title
attribute
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.