dita-ot/dita-ot

DITA Open Toolkit — the open-source publishing engine for content authored in the Darwin Information Typing Architecture.

DITA Open Toolkit

DITA Open Toolkit, or DITA-OT for short, is an open-source publishing engine for content authored in the Darwin Information Typing Architecture.

Visit the project website at dita-ot.org for documentation, information about releases, and download packages.

For information on additional DITA and DITA-OT resources, see SUPPORT. To report a bug or suggest a feature, create an issue. For more information on how you can help contribute to the project, see CONTRIBUTING.

• Prerequisites: Java 17
• Installing
• Building output
• Development
  • Running tests
  • Formatting code
  • Distribution builds
• License

Prerequisites: Java 17

To build and run DITA-OT, you’ll need Java Development Kit (JDK), version 17 or newer.

You can download the OpenJDK from AdoptOpenJDK.

Installing

1. Download the distribution package from dita-ot.org/download.
2. Extract the contents of the package to the directory where you want to install DITA-OT.

Installing via Homebrew

On macOS and Linux, you can also install DITA-OT using the Homebrew package manager:

brew install dita-ot

Homebrew will automatically download the latest version of the toolkit, install it in a subfolder of the local package Cellar and symlink the dita command to the bin subfolder of the Homebrew installation directory.

Note

Homebrew’s default installation location depends on the operating system architecture:

• /usr/local on macOS Intel
• /opt/homebrew on macOS ARM
• /home/linuxbrew/.linuxbrew on Linux

Building output

You can generate output using the dita command-line tool included with DITA Open Toolkit.

1. On the command line, change to the bin folder of the DITA-OT installation directory:

   cd path/to/dita-ot-dir/bin

2. Run the dita command to generate output:

   dita --input=input-file --format=format [options]

   where:

   • input-file is the DITA map or DITA file that you want to process
   • format is the output format (or “transformation type”)

See the documentation for arguments and options.

Development

Building the toolkit from source code and compiling the distribution package

1. Clone the DITA-OT Git repository, including submodules:

   git clone --recurse-submodules git://github.com/dita-ot/dita-ot.git

2. Change to the DITA-OT directory:

   cd dita-ot

3. In the root directory, run Gradle to compile the Java code and install plugins:

   ./gradlew

Running tests

./gradlew check

All tests are run by GitHub Actions test workflow on each push and for every pull request.

Formatting code

Requirements:

• Node.js

Prettier is used retain consistent Java formatting.

1. Run Prettier:

   npm run fmt

Distribution builds

1. In the root directory, set up the build environment:

   ./gradlew

2. Build the distribution packages:

   ./gradlew dist

   Distribution packages are built in the build/distributions directory.

   If Gradle throws an error like java.lang.OutOfMemoryError: Java heap space, you probably need to increase the maximum Java heap size. One way to do this is to set the GRADLE_OPTS environment variable to a value like -Xmx1024m.

   For more information on the -Xmx option, see the Java SE Documentation.

License

DITA Open Toolkit is licensed for use under the Apache License 2.0.

dita-ot's Issues

Stylesheet links in HTML emitted with local filesystem paths

Converted from SourceForge issue 1328689, submitted by cwong15

Subject: web site dita-ot.sf.net could not saved by firefox
in local disk
Date: Friday 14 October 2005 11:44 pm
From: "I.G.W" [email protected]
To: [email protected]

I don't know how to contact the webmaster at dita-ot.sf.
net, so I try
to reach by your email

There is a bug in firefox that prevent pages in
dita-ot.sourceforge.net being saved in local disk.
example, in
http://dita-ot.sourceforge.net/doc/DITA-relnotes.html.
Basically, the
cause of this bug is:

the windows path location. I have filled the bug to bugzilla
(bugs
number 312463):

https://bugzilla.mozilla.org/show_bug.cgi?id=312463

multiple document($FILTERFILE,/) doesn't work (XALAN)

Converted from SourceForge issue 1283644, submitted by imagiczhang

When using XALAN as the xsl processing engine and
we want to do flagging with ditaval file, there will
probably be a programmer error reported by XALAN
because it doesn't allow document($FILTERFILE,/) to
be called repeatedly and frequently. XALAN will throw
that exception if it founds the document tree of the
$FILTERFILE is already in its cache. It's an XALAN bug
but we can prevent invoking that bug by using a global
variable to contain the document tree of the filter file.

Intermediate dita files drops namespace prefix declaration

Converted from SourceForge issue 1209385, submitted by easirois

During the ANT process the namespace prefix declaration
is being dropped from the intermediate dita file which
would an invalid dita file.

wrong system id for html output used in validation

Converted from SourceForge issue 1323435, submitted by imagiczhang

When JavaHelp is produced with the toolkit, it uses the
HTML 4.0 public ID, but it uses the XHTML system ID.
This is because dita2html.xsl imports dita2xhtml.xsl;
the first one sets the public ID, but does not set a
system ID. So, the system ID for XHTML is used:

Use "em" instead of "pt" in css files

Converted from SourceForge issue 1323431, submitted by imagiczhang

Accessibility guidelines on CSS files say that "em"
must be used instead of "pt", because then spacing will
change with the user's font size. We need to
change "pt" values to "em" values in all css files we
provide.

generate different names for eclipse toc xml

Converted from SourceForge issue 1200393, submitted by leelix

The toc should have the same name as the map. If you
convert "sample.ditamap", you should get "sample.xml".
When you are able to format many at once, each should
get the name of the map.

RFE: No way to specify temp directory

Converted from SourceForge issue 1172346, submitted by lmandel

Our build process requires that temp files be created in
a specific location. To do this with the Dita Open Toolkit
requires that I place the toolkit in the temp location on
our build system as I can't specify the temp location. It
would be useful for the toolkit to support a random temp
directory, expecially one that is outside of the dita
toolkit directory.

DTD references not resolved

Converted from SourceForge issue 1311788, submitted by nodyad

Running "ant demo.faq.generalize" gives this error for
user Jennifer Linton:

demo.faq.generalize:

dita.topic.generalize:
[xslt] Processing C:\DITAOT\demo\faq\ditafaq.xml
to C:\DITAOT\out\demo\faq\ditafaq_GENERALIZED.xml
[xslt] Loading stylesheet C:\DITAOT\xsl\generalize.xsl
[xslt] : Fatal Error! Failure reading
file:///C:/DITAOT/demo/faq/ditafaq.xml Cause:
java.net.MalformedURLException: no protocol: topicDefn.ent
[xslt] Failed to process
C:\DITAOT\demo\faq\ditafaq.xml

This error was also reported in the dita-user list:
http://groups.yahoo.com/group/dita-users/message/1033

I am able to run the sample command correctly, but
there are 3 other users who have encountered this
particular error.

It appears that the topic.mod is not being resolved
correctly due to a tools configuration difference.
There are indications in Google that the Aelfred parser
also seems to generate a similar exception for DocBook
mod files, described in an XML catalog in the same way.

She gets the error with both JDK 1.5.0_04 and JDK
1.5.0_02. Please contact her directly for any other
diagnostics you need. Eric Sirois is also aware of this
problem and can reproduce it.

I rated this as high priority because it causes a fatal
error on a command that we use to verify
installation--users who have this problem have no
assurance of a valid system.

HTML Help subterm indexes not sorted

Converted from SourceForge issue 1323486, submitted by debbiep-sf

Single-level indexes work beautifully with HTML Help
(and presumably Java Help, which uses the same backend).

But within a given top-level term, the sub-terms are
not sorted. The sub-lists are in the order they were
encountered in the files referenced by the map file.

The problem is likely in
org/dita/dost/index/IndexTermCollection.java, where the
sort() method applies only to the overall collection,
not the sub-collections it finds. A possible solution
may be to do sorting inside the recursive method
outputIndexTerm in
org/dita/dost/writer/CHMIndexWriter.java (and the
JavaHelp equivalent).

The attached screenshot of the index pane from Windows
shows the issue. "license key files", "license queue",
"licenses" is in order. Under "license key files", the
order should be "adding", "deleting", "installing",
"location", "modifying".

RFE: Preexisting HTML files are not copied to output dir

Converted from SourceForge issue 1165070, submitted by lmandel

When there are pre-existing HTML documents as part of
the help documentation the HTML documents are not
copied to the output directory. In the case I'm working
on most of the files are dita but there are a few HTML
files. These files do not get copied into the temp
directory either.

HTMLHelp output does not reference CSS

Converted from SourceForge issue 1196409, submitted by nodyad

Subject: Getting htmlhelp output to reference CSS
[email protected]

I have the OASIS DITA-OT1.0.1 distribution running on
my machine, have created my own �samples� book that
outputs a chm nicely, but I can�t for the life of me
get the transforms to output html that references my
own .css. Anyone have a hint to get me unstuck?

DON DAY: I have replicated this issue, and am reporting
it for Jeremy.

Two possible issues:

• Is the toolkit properly passing a user's specific CSS
  to the build?
• Is the setup for the compile step proper, so as to
  allow the compiler to use the files that are there?

Not correctly use document() in dita2fo-links.xsl

Converted from SourceForge issue 1173164, submitted by imagiczhang

In dita2fo-links.xsl modified by Graham Hannington, the
document() is not correctly used and will find the xml
docuemnt in xsl file directory. The best practise here is
to use document() like this "document(@href,/)".

Add schema validation loading file for processing

Converted from SourceForge issue 1229058, submitted by easirois

For v1.1 of DITA-OT add schema validation when
pre-porcessing DITA documents.

In the following files:

writer/DitaWriter.java
reader/DitaValReader.java
reader/GenListModuleReader.java

the instance of XML reader should have the following
features set to true:

reader.setFeature("http://xml.org/sax/features/namespace-prefixes",
true);
reader.setFeature("http://xml.org/sax/features/validation",
true);
reader.setFeature("http://apache.org/xml/features/validation/schema",
true);

Kind regards,
Eric

Index generation doesn't cope with multilevel well

Converted from SourceForge issue 1273816, submitted by debbiep-sf

This is in the context of HTML help, but I imagine
other helps are the same.

If I have file1.xml containing
foobar
and I have file2.xml containing
foobaz
then I would expect to see an index like

foo

• bar
• baz

Instead what I get is
foo bar

• bar
  foo baz
• baz

Upon commenting out these lines (which I can't fathom
why you'd want anyway) in
reader/IndexTermReader.java::characters():

term.setTermName(new StringBuffer(term.getTermName())
.append(Constants.STRING_BLANK).append(temp)
.toString());

I get this, which is better:

foo

• bar
  foo
  -baz

but it still ought to collect those "foo"s. I figure
that this can be done in one of two places:

1. IndexTermReader::endElement()
2. IndexTermCollection::addTerm()

As a proof of concept, I had a go with sticking the
following code in as a third if-case in addTerm's for loop:

if (indexTerm.getTermName().equals(term.getTermName())) {
int j = 0;
int numSubTerms = term.getSubTerms().size(); //
always 1?
for (; j < numSubTerms; j++) {
indexTerm.addSubTerm((IndexTerm)
term.getSubTerms().get(j));
};
indexTerm.addTargets(term.getTargetList());
break;
};

and it works (sort of) for top-level index terms (i.e.,
foo), but I didn't make it work for cases where the top
two or more levels are shared because the
IndexTermCollection code isn't re-entrant and I didn't
want to mess up the rest of the code too much. Doing
this recursively would make all three (including mine)
of addTerm()'s cases collapse into one case anyway, so
it might be worth doing.

A related problem is that situations like this
foo
foobar
need to be dealt with, and I am not convinced that my
approach does so.

Broken XPath expression in mappull.xsl

Converted from SourceForge issue 1163523, submitted by jelovirt

Mappull.xsl contains

<xsl:apply-templates select="@*[not(self::navtitle)]"/>

The principal node type for self axis is element, thus
"self::navtitle" will return an empty node-set for
@navtitle and @navtitle is selected by the expression
along with the other attribute nodes. The expression
should be rewritten to

<xsl:apply-templates select="@*[not(name() =
'navtitle')]"/>

Fix catalog entries in catalag-ant.xml for OASIS DTDs

Converted from SourceForge issue 1314081, submitted by easirois

There are a couple of missing entries in the catalog
and some file names need to be updated to refelect the
new naming convention for some files defined in the
OASIS spec.

These missing entires result in errors during some
parts of the build process when using JDK 5.0.

I've inlcuded a file with the proprosed fix for this
defect.

Kind regards,
Eric

Index generation reqd

Converted from SourceForge issue 1161851, submitted by nobody

The .xsl needs to have ability to generate an index
from .dita files added

extra "../" link generated by topicgroup

Converted from SourceForge issue 1272687, submitted by nodyad

Reported by Jen Linton.

I can replicate an apparent bug that Jen is getting
with the included source files. The messages about an
invalid "../" link seem related to each occurence of
the topicgroup element which has no href.

My guess is that apparently the processing in DITA-OT
is falling through to topicref processing and thereby
expecting to find an href. Meanwhile, the relative
"../" path qualifier that would be generated for
content in a subdirectory still seems to be placed into
the rest of the map-driven processing, because this
error continues to appear later. I think this effect
is secondary, caused initially by processing topicgroup
improperly.

Use the following command to process the files in the
zip attached to this report. Unzip the set directly in
the dita-ot1.1 directory.

C:\DITA-OT1.1>java -jar lib/dost1.1.0.jar
/i:ditaworkshop/DITA_Workshop_reltable
.ditamap /outdir:out/test /transtype:xhtml
/ditaext:.dita > mylog.txt

Prompted ant--image does not link for single topic to PDF

Converted from SourceForge issue 1220644, submitted by nodyad

Reported by Dan Beigel and verified by Don Day as follows:

Use prompted ant to build a single file in the samples
directory that has an image:

C:\DITA-OT1.0.2>ant
Buildfile: build.xml

dita.init:

prompt.init:

prompt:
[echo] Please enter the filename for the DITA map
that you
[echo] want to build including the directory
path (if any).
[echo] The filename must have the .ditamap
extension.
[echo] Note that relative paths that climb
(..) are not supported yet.
[echo] To build the sample, press return
without entering anything.
[input] The DITA map filename:
samples/tasks/washingthecar.xml
[echo]
[echo] Please enter the name of the output
directory or press return
[echo] to accept the default.
[input] The output directory (out):

 [echo]
 [echo]     Please enter the type of output to

generate.
[echo] Options include: eclipse, htmlhelp,
javahelp, pdf, or web
[echo] Use lowercase letters.
[echo]
[input] The output type:
(eclipse,htmlhelp,javahelp,pdf,web,docbook)
pdf
[echo]
[echo] Ready to build
samples/tasks/washingthecar.xml
[echo] for pdf in out
[echo]
[input] Continue? (Y,y,N,n)
y

The job will run to completion, but this error will be
issued:

  [fop] [ERROR] Error while creating area : Error

while recovering Image Inf
ormations (file:/C:/image/carwash.jpg) :
C:\image\carwash.jpg (The system cannot
find the path specified)

The image will not be in the resulting PDF.

If you build the entire map using "ant samples.pdf",
the image will be resolved normally. The single-file
issue affects being able to use single topics as drafts

to verify content.

Don Day

CSS file location should be relative to the root dir

Converted from SourceForge issue 1173877, submitted by nobody

The Dita Open Toolkit allow you to specify the location
of a css file for the resultant HTML files. The css file
location must be specified relative to the generated
HTML files. As HTML files can appear at different
relative locations within the same project the css file
location shouldn't be relative to the resultant HTML files
but should rather be relative to a constant location such
as the root of the project.

For example, if my project is structured as

project/my.ditamap
project/component1/tasks/mytask1.dita
project/tasks/mytask2.dita

the css file location will be incorrect in one of the two
dita files.

Some folders were copied to DITA-OT's root directory

Converted from SourceForge issue 1304545, submitted by wuzhiq

When the dita files under input directory refer to some
files outside of input direcories, these directories
will be generated outside temp directory, which may
mistaken overide directories with same name.

All base directories are DITA-OT1.0

Converted from SourceForge issue 1173663, submitted by scotthutinger

I'm uncertain if having the src and different versions
all named DITA-OT1.0 is an oversight, or on purpose.
If possible, it would be nice to be able to tell the
version from the Root Directory name 'DITA-OT1.0.1b
DITA-OT1.0.1bsrc DITA-OT1.0 DITA-OT1.0src' or
something along those lines. It's possible for people
to download the source without knowing it. Outwardly,
it's impossible to tell what was downloaded by someone.

fo.img.ext target missing in "Ant tasks and script" topic

Converted from SourceForge issue 1329147, submitted by nodyad

The "fo.img.ext" target that is described on the Java
command line page as parameter foimgext is missing from
the target descriptions on the "Ant tasks and script"
topic.

unecessary space in document cause invalid parameter of Ant

Converted from SourceForge issue 1283600, submitted by imagiczhang

in document file DITA-installation.html there is a space
between "-" and "D" in sentence "set ANT_OPTS=%
ANT_OPTS% -
Djavax.xml.transform.TransformerFactory=com.icl.saxon
.TransformerFactoryImpl" which cause the incorrect
parameter passed to Ant.
There is no space between hyphen and "D".

Mapref function does not work for maps in another directory

Converted from SourceForge issue 1333481, submitted by robander

When a topicref points to a map in another directory,
not all of the paths in that new map are updated. In
the zip below, the first mapref goes to a topic in the
directory "subdir/". Inside that map, there are several
references.

The XSL passes the $remaining-path variable to topicref
elements in the other file. This works for the top
level topicrefs. However, topicrefs do not pass this
variable to their children. So, if my target map in
subdir/ has this:

only file1.dita will be updated with relative path
information.

It looks like the fix is to pass $relative-path to
children on line 382 of mappull.xsl.

XRefs do not work if target document has dita root element

Converted from SourceForge issue 1304870, submitted by prescod

Given an XRef like this:

XRef

and a target file like this:

<title>Title</title>

Para

The toolkit will generate the following FO.

...
<fo:basic-link internal-destination="">XRef
2/fo:basic-link
...

FOP will report the following problems:

C:\dita\DITA-OT1.1.1\ditatargets.xml:78:
org.apache.fop.apps.FOPException: file:
/C:/dita/DITA-OT1.1.1/out/DITA-articles.fo:88:40
internal-destination or external-destination must be
specified in basic-link

Patch: XLST match patterns test for element names

Converted from SourceForge issue 1163539, submitted by jelovirt

The following XSLT stylesheets have match patterns that
test for element names as opposed to the class attribute.

xsl/xslfo/domains2fo.xsl
xsl/xslfo/toc2fo.xsl
xsl/xslhtml/dita2htmlImpl.xsl
xsl/xslhtml/syntax-braces.xsl

Toolkit disallows repetition of topic ID within map

Converted from SourceForge issue 1304859, submitted by prescod

Given a simple map:

And two simple topics that are identical:

<title>Title</title>

Para

The following error will be reported:

C:\dita\DITA-OT1.1.1\ditatargets.xml:78:
org.apache.fop.apps.FOPException: file:
/C:/dita/DITA-OT1.1.1/pdf/DITA-articles.fo:94:33 The id
"dita-mapdomains" already exists in this document

The DITA specification does not say that IDs must be
unique across topics in a map. It says only that they
must be unique across document in a "document instance"
which is to say: a single XML document/file.

FileNotFoundException thrown from moving index

Converted from SourceForge issue 1204143, submitted by wuzhiq

move-index-entries:
[pipeline] Move index entries.
[pipeline] java.io.FileNotFoundException:
C:\eclipse-SDK-3.1M6-win32\workspace\DITA-OT-release1.1\temp\file.pdf
(系统找不到指定的文件。)
[pipeline] at java.io.FileInputStream.open(Native Method)
[pipeline] at java.io.FileInputStream.(Unknown
Source)
[pipeline] at java.io.FileInputStream.(Unknown
Source)
[pipeline] at
sun.net.www.protocol.file.FileURLConnection.connect(Unknown
Source)
[pipeline] at
sun.net.www.protocol.file.FileURLConnection.getInputStream(Unknown
Source)
[pipeline] at java.net.URL.openStream(Unknown Source)
[pipeline] at
org.apache.xerces.impl.XMLEntityManager.startEntity(Unknown
Source)
[pipeline] at
org.apache.xerces.impl.XMLEntityManager.startDocumentEntity(Unknown
Source)
[pipeline] at
org.apache.xerces.impl.XMLDocumentScannerImpl.setInputSource(Unknown
Source)
[pipeline] at
org.apache.xerces.parsers.DTDConfiguration.parse(Unknown
Source)
[pipeline] at
org.apache.xerces.parsers.DTDConfiguration.parse(Unknown
Source)
[pipeline] at
org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
[pipeline] at
org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown
Source)
[pipeline] at
org.dita.dost.writer.DitaIndexWriter.write(DitaIndexWriter.java:99)
[pipeline] at
org.dita.dost.module.MoveIndexModule.execute(MoveIndexModule.java:54)
[pipeline] at
org.dita.dost.pipeline.PipelineFacade.execute(PipelineFacade.java:30)
[pipeline] at
org.dita.dost.invoker.AntInvoker.execute(AntInvoker.java:103)
[pipeline] at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
[pipeline] at
org.apache.tools.ant.Task.perform(Task.java:364)
[pipeline] at
org.apache.tools.ant.Target.execute(Target.java:341)
[pipeline] at
org.apache.tools.ant.Target.performTasks(Target.java:369)
[pipeline] at
org.apache.tools.ant.Project.executeTarget(Project.java:1214)
[pipeline] at
org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:386)
[pipeline] at
org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:106)
[pipeline] at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
[pipeline] at
org.apache.tools.ant.Task.perform(Task.java:364)
[pipeline] at
org.apache.tools.ant.Target.execute(Target.java:341)
[pipeline] at
org.apache.tools.ant.Target.performTasks(Target.java:369)
[pipeline] at
org.apache.tools.ant.Project.executeTarget(Project.java:1214)
[pipeline] at
org.apache.tools.ant.Project.executeTargets(Project.java:1062)
[pipeline] at
org.eclipse.ant.internal.ui.antsupport.InternalAntRunner.run(InternalAntRunner.java:414)
[pipeline] at
org.eclipse.ant.internal.ui.antsupport.InternalAntRunner.main(InternalAntRunner.java:139)

RFE:Ant must be run from toolkit directory

Converted from SourceForge issue 1172349, submitted by lmandel

I am attempting to run an Eclipse help build as part of a
larger build process. I don't have control over the basedir
when the build process is run. The Dita Open Toolkit
requires that the ant build is run from the toolkit
directory. (ie. from DITA-OT1.0.) In order to allow this I
tried setting the base directory by using the ant task,

<ant dir="DITA-OT1.0_install_dir".../>

to set the basedir to the location of the toolkit. The temp
directory was still created in the base location of the
original ant call and the build did not complete
successfully. The basedir seems to be set correctly in
ant. This may be an XSL problem.

Can't point above the directory which contains the map file

Converted from SourceForge issue 1160964, submitted by lmandel

The current tools do not allow pointing to a location
above the directory which contains the map file. This
seems like an unnecessary restriction. My build should
be able to point to any location.

Don has indicated that this problem was discovered late
in the development cycle of 1.0.0 and is known. I have
opened a bug to track this problem.

Fatal error in published ditamap example

Converted from SourceForge issue 1306361, submitted by nodyad

I am getting the following error from a published
ditamap example. More details after this clip from the
logfile:

-----------------------8<-----------------------
dita2htmlhelp:

dita.map.htmlhelp:
[xslt] Transforming into
C:\DITA-OT1.1.1\out\ww\htmlhelp
[xslt] Processing
C:\DITA-OT1.1.1\temp\buying.ditamap to C:\DITA-OT1.1.1\ou
t\ww\htmlhelp\buying.hhc
[xslt] Loading stylesheet
C:\DITA-OT1.1.1\xsl\map2hhc.xsl
[xslt] file:/C:/DITA-OT1.1.1/temp/:1:1: Fatal
Error! Error reported by XML
parser Cause: org.xml.sax.SAXParseException: Content is
not allowed in prolog.
[xslt] : Warning! org.xml.sax.SAXParseException:
Content is not allowed in
prolog. Cause: org.xml.sax.SAXParseException: Content
is not allowed in prolog.

[xslt]

 [xslt] IDXS004W Warning: (File =

C:\DITA-OT1.1.1\ww\buyingtaskplus.ditamap,
Element = topicgroup:1)
[xslt] File does not exist.
-----------------------8<-----------------------

The sample ditamap and process for running it are
described here:
http://xml.coverpages.org/dita.html#priestleyWinUA2005.

Follow the instructions for downloading and installing
the zip file into dita-ot1.1.1. Run the installed ant
script as described at that link. The log file should
reproduce the above error.

I will open a separate bug report for another bug that
is represented by the same test above: common.css not
compiled with htmlhelp

File missing from the map causes abend

Converted from SourceForge issue 1325277, submitted by robander

I have a map with 3 topicrefs. One of the files is
missing from my system. When I try to format the map,
the process fails during the topicpull step, because it
tries to run topicpull on the missing file.

The process should give a good warning when a file is
missing. Currently it has this:
[pipeline] java.io.FileNotFoundException:
C:\DITA-OT1.1.1\test\fake.dita (The system cannot find
the file specified)

If the file is not present in the first step, it should
not be added to the dita.list temporary file. If it is
not in that file, it should not cause the process to
abend later, because the scripts will not try to
process it.

filtered-out indexterms leak into index through dita.list

Converted from SourceForge issue 1326439, submitted by debbiep-sf

The problem: Although entries in ditamap
files can be excluded through the ditaval/filtering
mechanism, any entries inside these topics
are still included in the index.

Probable reason: The dita.list file contains a list of
topics pulled from all maps. This is done before
filtering, so it may contain topics that are,
ultimately, filtered out through a ditaval file.

Index creation in DitamapIndexTermReader reads the list
of topic files from dita.list and then parses the
indexterms it finds. But since dita.list is made prior
to filtering, some indexterms are included that end up
pointing to topics that don't exist in the final output.

The Microsoft HTML Help compiler helpfully adds back
into the compiled help file any files that are
referenced in the index.hhk file but not mentioned in
the .hhp file, so these filtered-out topics end up back
in the help file anyway.

useless DRAFT param in FO transformation

Converted from SourceForge issue 1168974, submitted by imagiczhang

in xsl/xslfo/dita2fo-elems.xsl
There is a part of the code to process draft-comment
tag in dita source file

<xsl:template match="*[contains(@class,' topic/draft-comment ')]">
<fo:block background-color="#FF99FF" color="#CC3333">
<xsl:attribute name="border-style">solid</xsl:attribute>
<xsl:attribute name="border-color">black</xsl:attribute>
<xsl:attribute name="border-width">thin</xsl:attribute>
  <fo:block font-weight="bold">
Disposition: <xsl:value-of select="@disposition"/> / 
Status: <xsl:value-of select="@status"/>
  </fo:block> 
  <xsl:apply-templates/>
</fo:block>
</xsl:template>

the DRAFT parameter of xsl is not used here to specify
whether we should output the content of the draft-
comment.

The test case is the langref in /doc/langref directory in
which topicref-atts-no-toc.xml contains draft-comment
tag.

not including the css files when generating hhp file

Converted from SourceForge issue 1201215, submitted by imagiczhang

the css files don't take effect in the final html help
output now. That's because the css files are not
included in the [FILES] section in the hhp file. And
the html help workshop don't know, the css files should
be compiled in.

Multilevel HTML Help popup shows filenames

Converted from SourceForge issue 1297355, submitted by debbiep-sf

If I have two DITA topics, and each contains an
that has the same top-level text:

file1.dita:
generalspecific1
file2.dita:
generalspecific2

and I generate HTML Help from this, when I double-click
on the word "general" in the index pane of the Windows
help viewer, up pops a dialog box asking me if I want
specific1 or specific2. (This is normal for Windows
HTML Help.) But what it lists isn't the topic titles
from file1.dita and file2.dita, rather, the filenames
themselves.

This is because of the following in the generated .hhk
file:

The "Name" param needs to have a value that is the
topic's (search) title. This would be better:

Patch: Timestamp (TodaysDate) fix in dita2fo-shell.xsl

Converted from SourceForge issue 1183281, submitted by scotthutinger

Added the needed changes to get TodaysDate to output a
timestamp.

Add XML Schema processing to DITA-OT

Converted from SourceForge issue 1220569, submitted by easirois

Since the OASIS DITA specification defines a DTD and
XML Schema implementaiton of the DITA Architecture as
normative, DITA-OT should be able to process both DTD
and XML Schema validated instance documents. It
currently does not.

1- At leats two files will need to be updated.
PipelineReader.java and DITAWriter. Both of these file
must turn on DTD validation and XML Schema validation
features.

Both PipelineReader and DITAWriter should have the
following XML parser features turned on.

reader.setFeature("http://xml.org/sax/features/namespace-prefixes",
true);
reader.setFeature("http://xml.org/sax/features/validation",
true);
reader.setFeature("http://apache.org/xml/features/validation/schema",
true);

2- Also, since validation will be turned on we also
need to updated.
DTD - bookmap.mod

should be

XML Schema - bookmap_mod.xsd
<xs:group ref="topicref" maxOccurs="unbounded" /> should be

<xs:group ref="topicref" minOccurs="0"
maxOccurs="unbounded" />

3- The bookmap XML Schemas should conform to the naming
convention established in the OASIS DITA specification.

Dir produced outside of temp with ../ relative locations

Converted from SourceForge issue 1173869, submitted by nobody

I have dita files that contain xref links to files contained
in other Eclipse plugins. So I will have two plugins such
as
plugin1/toc.ditamap
plugin1/topics/file1.dita
plugin2/toc.ditamap
plugin2/topics/file2.dita

file1.dita contains an xref to file2.dita that looks like
../../plugin2/topics/file2.dita

This xref causes a plugin2 directory to be created
outside of the temp directory. This makes cleaning up
after the build difficult.

JavaHelp transform drops 2nd use of title

Converted from SourceForge issue 1208902, submitted by nodyad

The JavaHelp transform is given this requirement:
(a) control the navtitle from the DITAMAP and (b) call
a topic file more than once within a DITAMAP file. But
upon output, the Toc file produces no title for the
second instance.

Erik Hennum notes that this is a bug in his code. "The
intent was to use the Map as a BOM so you convert the
topic to XHTML only once. That should work
independently of the title retrieval. Apparently, the
code isn't getting the title from the file if it's not
generating the topic."

JavaHelp output does not work for Russian

Converted from SourceForge issue 1325290, submitted by robander

I expect this is also a problem for most languages that
do not use Latin-1.

Currently, the XSL files that produce JavaHelp files
all set the encoding to ISO-8859-1. When I use Russian
files, this causes the output to include lines like:

When I try to open this in the JavaHelp viewer, the
viewer cannot open.

I updated these files to use encoding="utf-8":
dita2html.xsl
map2javahelpmap.xsl
map2javahelpset.xsl
map2javahelptoc.xsl

This allowed the viewer to open correctly. However, the
index still uses ISO-8859-1 and appears corrupted.

generate null internal link destination in fo transformation

Converted from SourceForge issue 1173162, submitted by imagiczhang

When we use xref like following

DITA-OT will generate empty internal link destination.
And this will cause fop exception when it transform fo to
pdf.

common.css not compiled with htmlhelp

Converted from SourceForge issue 1306363, submitted by nodyad

See the previous bug report for "Fatal error in
published ditamap example." The same result directory
will have a compiled CHM file that was compiled without
the default common.css stylesheet. The stylesheet file
is not in the out directory, and the project file does
not list the css file as a dependency for compiling.
This bug is related to 1196409 HTMLHelp output does
not reference CSS, which is listed as closed. That bug
seems to have addressed user-supplied stylesheets.
Please use this bug report to check that the default
stylesheet is properly copied and compiled.

Unnecessary comment and href typo

Converted from SourceForge issue 1281900, submitted by leelix

From yahoo group message 927 by Alan Olson

http://groups.yahoo.com/group/dita-users/message/927?
threaded=1

Questions:

1. The ditafo-links.xsl file contains this comment on
   line 133:

Does this mean that intra-topic links are not yet
supported in OT 1.1?

Charlie: This should be removed

1. Line 136 contains a typo 'herf' instead of 'href'
   so I'm suspicious
   that this code is never called/used in any of the demo
   files.

Charlie: confirmed as a typo.

Update for Supported Parameters page

Converted from SourceForge issue 1297657, submitted by nodyad

For the output transforms listed on this page, the
troff output type is not listed:
http://dita-ot.sourceforge.net/doc/DITA-javacmd.html

Would you mind reviewing the other parms to make
certain that any changes to the options since May have
all been updated here? Thanks!

revision flag using unavailable pictures

Converted from SourceForge issue 1273751, submitted by imagiczhang

in xsl code which implement the transformation from
dita to html, we generate pictures to embrace the
content of specific revision which we want to mark up.
but the pictures in not available in the output.

prompted ant fails

Converted from SourceForge issue 1166355, submitted by nodyad

This error pertains only to the the dita-ot1.0.1 beta
patch version.

Running the "ant" command by itself causes the
following failure:

C:\DITA-OT1.0>ant
Buildfile: build.xml

dita.init:

prompt.init:

prompt:
[echo] Please enter the filename for the DITA map
that you
[echo] want to build including the directory
path (if any).
[echo] The filename must have the .ditamap
extension.
[echo] Note that relative paths that climb
(..) are not supported yet.
[echo] To build the sample, press return
without entering anything.
[input] The DITA map filename:
doc\dita-readme.ditamap

BUILD FAILED
C:\DITA-OT1.0\build.xml:550: The type doesn't
support the nested "conditi
on" element.

Total time: 11 seconds

format attribute should be set to 'dita' for dita topic

Converted from SourceForge issue 1181950, submitted by imagiczhang

In xsl files, DITAEXT is used for file extension name and
can reasonably be set to 'dita' or 'xml'. However, in the
format attribute, the only legal values when pointing to a
DITA topic are "dita" and "DITA". This is true even if the
extension of your DITA files is "xml". The DITA spec
defines "dita" or "DITA" as the correct values for
@Format.

RFE: Footer file must be in the same location as dita file

Converted from SourceForge issue 1165072, submitted by lmandel

The dita toolkit provides a property to register a footer to
be included in each transformed dita file. The toolkit
currently requires that the footer document be in the
same location as the dita file. With dita files in multiple
locations there must be multiple versions of the XHTML
document.

The toolkit should resolve the location of the footer
XHTML document relative to either the source directory
or the temp directory.