PowerPoint Output in an ant Task

For several years now I have been working on utilities to convert DITA to PowerPoint, as I have discussed elsewhere. The original implementation was as a VBA macro stored inside a PPT template. I won’t go on at length about all the limitations that VBA has; suffice it to say that it’s verbose and not very robust. My colleagues in the training group requested some enhancements and I couldn’t bear the thought of spending much time in VBA.

So I decided to rewrite it in PowerShell. Other posts in Ditanauts have detailed working with XML files in PowerShell, which I have found to work pretty well. In addition, PowerShell has much better capabilities for exception handling, and it can manipulate PPT objects.

The logic for the PS version is virtually identical to the logic for the VBA macro, with one notable exception: instead of processing source maps and topics as in the VBA version, the PS version processes the merged file that is created as the first stage in PDF output. Why did I choose this approach? So that I could leverage the DITA-OT filtering and reference resolution capabilities and not have to reinvent them in PS. In my current group we make heavy use of conrefs and filtering conditions, so there were numerous instances of missing or extraneous content in the slides. Building the merged files with the appropriate ditaval and then processing the merged file resolves these shortcomings.

With the processing in a standalone script rather than embedded in an PPT file, it can be called from an ant build file. Some typical parameters are set (dita.dir etc.), then some specific parameters, then the build target. The build target first generates the PDF then executes the PS script with the merged XML file from the PDF output as an argument.

<property name="transtype" value="pdf_course" />
<property name="clean.temp" value="no" />
<property name="preprocess.chunk.skip" value="true" />
<target name="guides2out">
  <copy file="${build.dir}/log.xsl" todir="${args.logdir}" />
  <property name="args.input" location="${docdir}/Courseware.ditamap" />
  <basename property="dita.input.filename" file="${args.input}" />
  <dirname property="dita.input.dirname" file="${args.input}" />
  <basename property="dita.map.filename.root" file="${dita.input.filename}"
    suffix=".ditamap" />
  <property name="merged"
    value="${dita.temp.dir}/${dita.map.filename.root}_MERGED.xml" />
  <echo>Merged file: ${merged}</echo>
  <ant />
  <exec executable="powershell">
    <arg value="Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Force -Scope Process;"/>
    <arg value="${build.dir}\dita2ppt.ps1" />
    <arg value="${merged}"/>
    <arg value="${build.dir}\SlideTemplate.pptx"/>
  </exec>
</target>

One drawback is that an extra PDF is created, but that’s relatively minor. A more elegant solution would be to package everything into an OT plugin.

The real drawbacks are around PPT itself. The most nagging problem is the question of slide boundaries. In the nearly four years I have been working on PPT I haven’t been able to programmatically figure out when a slide is full and break to a new one. In general, the tagged elements in a topic should only be as much as can fit on a slide, but in some cases (notably tasks) that’s not always possible.

The other nagging and more esoteric problem is around element nesting. For example, if a table is tagged for inclusion on slides, and table cells include block elements (like ul/li), the nested element gets collapsed. XSLT handles this sort of recursion marvelously; it’s not something I want to try to tackle in PS. Both of these cases are infrequent enough that the time savings, consistency, and reliability are much greater than creating slides by hand, but the fact that they occur means that even the new version isn’t a fully automated solution.

The genesis of the PPT macro was in the fact that slides in PowerPoint—not PDF, not dynamic HTML, not OpenOffice—was set as a requirement. (The reason for this was so trainers could augment and reorganize slides if they desired, which in my view is something that should be prevented, not supported. But I lost that argument.) My current training colleagues are not insisting on PPT slides and have indicated that dynamic HTML would be acceptable.

So my next step will be to replace PPT slides with dynamic HTML slides. I’m looking at HTML Slidy from W3C and Google I/O. The rewrite of the PPT utility will hold us until I can get that implemented.

2 thoughts on “PowerPoint Output in an ant Task

  1. Great write-up, Ben! I encourage you to take that next step with HTML-based presentation since the world is gearing up to interoperate around HTML5 anyway. Besides W3C’s Slidy stylesheet, there is also Eric Meyer’s S5 system (http://meyerweb.com/eric/tools/s5/) and Bartek Szopka’s impress.js system (https://github.com/bartaz/impress.js/).

    I have taken a liking to impress.js and adapted a DITA-driven viewer at the Contelligence Group’s web site. Here is a link to a ditamap of the slideshow:
    http://contelligencegroup.com/page/map/Adaptive-DITA
    Use this parameter to render the topicrefs as an aggregated view:
    http://contelligencegroup.com/page/map/Adaptive-DITA?xType=all
    (then use this to return to the standard ToC-like view of the map:
    http://contelligencegroup.com/page/map/Adaptive-DITA?xType=html)
    Then, use this to bring up the slides within those topics as content for a Prezi-like slide show (note the escape back to standard view in the lower left):
    http://contelligencegroup.com/page/map/Adaptive-DITA?themeName=Impress&tempTheme=Skeleton

    All of this should be possible with DITA OT, other than the dynamic switching in expeDITA; I’d be glad to share my code and experiences with you for building into the appropriate plugins. 🙂

Leave a Reply to Don Day Cancel reply

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


*