Improving readability of DOT build log

I ran across a post on the Yahoo DITA Users’ group today about improving the readability of the toolkit’s error log. It is surprisingly easy to do – in fact, I’m not sure why this isn’t the default behavior. At any rate, if you run the toolkit from the command line via ant, you can specify that the log be created in XML instead of plain text output to the command line window. Then, you can style is with XSL. I’ve created a stylesheet that makes the log much easier for a novice to read.

Begin, as Steve indicates in the post, by starting your command with:


That will create the log in the [DITAOT]\out folder, which is also the default location for your build output. Then you can append your specific build arguments, for example:

-Dargs.input=map.ditamp -Dtranstype=pdf2

So the entire command would be:

-logfile=buildlog.xml -Dargs.input=map.ditamp 

Doing all that gets you a build log written in XML. You can open it in a browser, but the results aren’t great until you apply a stylesheet called log.xsl. Steve says in the post that you can find that .xsl file if you have a full ant install – I didn’t, so I created a stylesheet and posted it to the DITA Users’ Group file page.

If you build, and create the log, simply copy the .xsl file I posted to the same folder as your error log.

I’d love to see vendors take this and make an easy to read log. I’ll make a few improvements to what I’ve posted as well.

8 thoughts on “Improving readability of DOT build log

    • Hi Bertrand,

      I made some significant updates today to the file I posted on DITA users. Still a long way to go, but I’ve got the basic structure in place. Now I just need to account for the 49 remaining error messages. 🙂

    • That’s cool, I didn’t even think to look for one from the ant project. That definitely improves the layout, but it doesn’t really make errors much easier to find. What I’d like to do is bring errors and warnings to the top of the page, and provide explanations and/or suggestions to resolve them.

      In other words, make the log a tool that authors could actually use to fix their builds.

Leave a Reply

Your email address will not be published. Required fields are marked *