Fonts in PDFs

This seems like an odd choice for default behaviour...

To get any other font than the default (Helvetica) to appear in your PDFs, you have to copy the font-mappings.xml.orig file to font-mappings.xml in the folder dita-ot_homedir\demo\fo\Customization\fo. Until you do, the i18n-postprocess.xsl file in the demo\fo\xsl\fo folder adds a font-family="Helvetica" attribute to elements' FO code, overwriting any other fonts you may have specified for the element.

Adding a chapter to a DITABOOK

There are many ways to add a new chapter to a DITABOOK. Not all work...

When the chapter's content is in a single topic file, it is straightforward:
<chapter navtitle="Introduction" href="cIntroduction.xml"/>

A chapter may have an introductory paragraph or two before the first level one heading (typically "This chapter describes..."). In this case, just use the previous example and add topicref tags pointing to the chapter's sections. The topicrefs must be child elements of the chapter tag, for example:
<chapter href="TaskHelp/cIntroduction.xml">
<topicref navtitle="Updating a Module" href="FieldHelp/rModule_Update.xml"/>
</chapter>

If the chapter's content is more complex, you might prefer to put the chapter's content in a DITAMAP and reference this DITAMAP in the chapter tag:
<chapter href="chapter1.ditamap" format="ditamap"/>

There are some pitfalls too:

• If you do reference a DITAMAP, it must only contain a single top-level topicref tag. Otherwise, all the top-level topicref tags appear in the generated PDF at the chapter level but are not numbered as chapters.


• You must have an href attribute on the chapter tag, otherwise the topicref's titles appear at the chapter level and there's no chapter title. So neither of the following examples work:
  <chapter>
  <topicref ...>
  </chapter>
  <chapter navtitle="Introduction">
  <topicref ...>
  </chapter>

Visio and SVG still don't work together

Unfortunately, Microsoft don't seem interested in fixing the bug in Visio's SVG export filter that leaves arrowheads off lines. The bug survived the SP2 and SP3 updates for Visio, and apparently is even present in Visio 2007!
There are several workarounds:

• Don't use arrowheads in diagrams!
• Fix the SVG file before using it
• Use a different tool altogether.

To draw arrows in Visio, just draw one long and two short lines (or a line and a filled triangle), then group them together. Not pretty, but it works.

I found a small XSLT script that fixes the problem. Because SVG files are XML, you can run the script against the SVG, then save the resulting XML as a new SVG file. Here's the script:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE xsl:stylesheet>
<!-- Workaround for:
http://issues.apache.org/bugzilla/show_bug.cgi?id=38831 -->
<!-- Adds overflow="visible" to all <marker> elements. -->
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg" exclude-result-prefixes="svg">
<xsl:output method="xml" indent="no"/>
<xsl:template match="svg:marker">
<xsl:element name="marker" xmlns="http://www.w3.org/2000/svg">
<xsl:copy-of select="@*"/>
<xsl:attribute name="overflow">visible</xsl:attribute>
<xsl:copy-of select="node()"/>
</xsl:element>
</xsl:template>
<xsl:template match="@*¦node()">
<xsl:copy>
<xsl:apply-templates select="@*¦node()"/>
</xsl:copy>
</xsl:template>
</xsl:stylesheet>

I use oXygen to perform the transformation using the XSLT Debugger.

As far as alternative tools are concerned, I'm testing an Open Source tool called Inkscape. First impressions are that its interface is a bit quirky, but it seems perfectly adequate.

Migrating to a newer version of DITA-OT

Migrated to the latest "M24" milestone of the DITA-OT toolkit yesterday to hopefully benefit from some of the bug fixes.
The only things to do to migrate were:

• Copy my custom CSS files in the /css folder across.
• Copy the /common folder across (contains toolbar graphics for XHTML).
• Copy the /demo/fo/myCustomization folder across (customization layer for PDF generation).
• Edit the /demo/fo/build.xml file and edit the line <property name="customization.dir ... > to point to the customization folder.

oXygen stalls creating PDF file

This one has got me a couple of times recently, so it's probably more for my benefit than anyone else's.

When generating PDFs using oXygen, the PDFs are created correctly when using oXygen's internal DITA-OT. However, when I switch to using my own DITA-OT, the transform stalls when creating the .PDF from the .FO. As usual, oXygen's tech support came to the rescue...

Seems that "with Windows XP, Apache FOP blocks the console before the PDF is generated", whatever that means.

oXygen have introduced a patch into their internal DITA-OT to get around this. So you need to copy this patch across to your external DITA-OT version to benefit from the patch:

1. In the build.xml file, search for the "transform.fo2pdf.fop" target.
2. Comment out the target template and replace it with the following one:

<target name="transform.fo2pdf.fop" if="use.fop.pdf.formatter">
<java classname="org.apache.fop.cli.Main" fork="yes" classpath="${java.class.path}" dir="${dita.map.output.dir}" failonerror="true">
  <arg line="-fo "${inputfile}" -pdf "${outputFile}" -c "${fop.home}/conf/fop.xconf"/>
<java>
<target>

Migrating to oXygen 11

DITA-OT transformation scenarios created for version 10.3 do not work with oXygen 11. The 10.3 scenarios contain references to Saxon libraries that no longer exist in oXygen 11 because they have migrated to the enterprise edition of Saxon.
There are two easy workarounds:
1) Create new transformation scenarios and manually recreate the settings.
2) Edit the old transformation scenarios. Go to the Advanced tab and click the Libraries button.
In the Custom Libraries list, remove saxon9sa.jar and saxon9-dom.jar, then add ${oxygenHome}/lib/saxon9ee.jar

Figure sizes for DITA output to PDF

We will be having some people using FOP and others using XEP to generate PDF files. It's actually quite difficult to set the width and height attributes of figures so that graphics look good in both formats. Here are some recommendations:
- FOP and XEP only have a very limited number of supported formats in common: GIF, JPEG and PNG for bitmaps and SVG for vectorials.
- Only specify the width. The DITA-OT will then calculate the height automatically so as to preserve the original aspect ratio.
- Specify the width in "real" width units, for example "10mm" or "3in".
- For vectorial graphics, specify the same width value for all graphics to obtain a cleaner output. In the old FrameMaker template, the main text column was 135mm wide, so this is a good value to use.

So, for example:
<fig>
<img align="right" width="135mm" placement="break" href="architecture.svg"/>
</fig>