XMLmind Word To XML Manual

Explains how to install and use XMLmind Word To XML (w2x for short), how to customize the output of w2x and how to embed a w2x processor in a Java™ application.

Hussein Shafie
XMLmind Software
35 rue Louis Leblanc,
78120 Rambouillet,
France,
Phone: +33 (0)9 52 80 80 37,
Web: www.xmlmind.com/w2x/
Email: mailto:w2x-support@xmlmind.com (public mailing list)

Introduction

Microsoft® Word is an amazing popular writing tool. However, its main drawback is that, once your document is complete, you cannot do much with it: print it, convert it to PDF or send it as is by email.

XMLmind Word To XML aims no less than to suppress Microsoft® Word main drawback. This 100% Java™ software component allows to automate the publishing —in its widest sense— of contents created using Microsoft® Word 2007+.

More precisely, XMLmind Word To XML (w2x for short) allows to automatically convert DOCX files to:

• Clean, styled, valid XHTML+CSS, looking very much like the source DOCX files.

  Because the generated XHTML+CSS file is clean and valid, you can easily restyle it, extract metadata or an abstract from it before publishing it.

• Unstyled, valid, semantic XML (DITA, DocBook, XHTML, your custom schema, etc).

  In this case, most styles are converted to semantic tags. For example, numbered paragraphs are converted to proper ordered lists.

  Generating semantic XML out of DOCX files is useful for interchange reasons (e.g. implement open data) or because you want to port your existing documentation to a structured document format where form and content are completely separated (e.g. implement single source publishing).

Of course, deploying w2x does not require installing MS-Word on the machines hosting the software. Also note that w2x does not require the authors to change their habits while using MS-Word: no strict writing discipline, no specific styles, no specific document templates, no specific macros, etc.

This document explains:

• how to install and use w2x;
• how to customize the output of w2x;
• because w2x has been designed to be easily embedded in any Java, desktop or server-side, application, how to embed a w2x processor in a Java application.

Installing w2x

Requirements

XMLmind Word To XML (w2x for short) requires a Java™ runtime 1.8+. However, w2x is officially supported by XMLmind only on Windows 7, 8, 10 and 11, macOS (Intel® or ARM® processor) 13.x (Ventura) and 14.x (Sonoma) and Linux.

On Linux, make sure that the Java bin/ directory is referenced in the $PATH and, at the same time, check that the Java runtime in the $PATH has the right version:

$ java –version
openjdk version "22.0.2" 2024-07-16
OpenJDK Runtime Environment (build 22.0.2+9-70)
OpenJDK 64-Bit Server VM (build 22.0.2+9-70, mixed mode)

On Windows and on the Mac, this verification is in principle not needed as the java executable is automatically found in the $PATH when Java has been properly installed.

Install on Windows

1. Download the setup.exe distribution.
2. Double-click on the setup.exe file to launch the installer.
3. Follow the instructions of the installer.

Install on the Mac

1. Download the .dmg distribution.
2. Double-click the downloaded .dmg file to open it in the Finder.
3. Copy the WordToXML.app folder, an application bundle represented by icon , anywhere you want. For example, drag&drop this icon to the /Applications folder or to your desktop.
4. Start the w2x-app desktop application by double-clicking on the icon (or use the Launchpad).
5. The first time w2x-app is started, your Mac will generally ask you to confirm that you actually want to open an application downloaded from the Internet. Click Open to confirm.

   Don't worry, w2x-app has been digitally signed using a certificate issued by Apple itself. This confirmation is required for any digitally signed application not coming from the App Store.

6. Move the downloaded .dmg file to the Trash.

Manual install on any Java 1.8+ platform (Windows, Mac, Linux, etc)

Unzip the .zip distribution in any directory you want.

C:\> unzip w2x-1_12_0.zip

C:\> cd w2x-1_12_0

C:\w2x-1_12_0> dir 
... <DIR> bin
... <DIR> doc
... <DIR> legal
...

XMLmind Word To XML is intended to be used directly from the w2x-1_12_0/ directory. That is, you can run the w2x command by simply executing (in a Command Prompt on windows, a terminal on Linux):

C:\w2x-1_12_0> bin\w2x
Usage: w2x [-version] [-v|-vv] [Options] [-liststeps] in_docx_file out_file

-version
    Print version number and exit.
-v|-vv
    Verbose.
-liststeps
    List the conversion steps to be executed and exit.

Use '-?' to list options.

Contents of the installation directory

bin/w2x, w2x.bat

Scripts used to run XMLmind Word To XML (w2x for short). Use w2x on any Unix system. Use w2x.bat on Windows.

bin/w2x-app.exe, w2x-app.jstart

File w2x-app.exe is used to start w2x-app, a graphical application easier to use than the w2x command-line utility, on Windows. This .exe file is a home-made launcher parameterized by xxe.jstart, an UTF-8 encoded, plain text file.

bin/w2x-app, w2x-app-c.bat

Scripts used to run w2x-app, a graphical application easier to use than the w2x command-line utility. Use w2x-app on any Unix system. Use w2x-app-c.bat on Windows , but only when you need to start w2x-app with a console. On Windows, a console is needed to be able to see low-level error messages.

doc/index.html

Contains the documentation of w2x.

doc/manual/

Contains XMLmind Word To XML Manual. This document is available in source DOCX format, in PDF format and in all the output formats supported by w2x.

doc/manual/conv_manual.sh, conv_manual.bat

Scripts allowing to convert XMLmind Word To XML Manual to all the output formats supported by w2x. The files generated by these scripts are found in doc/manual/out/.

doc/xedscript/

Contains The XED scripting language.

doc/w2x_app_help/

Contains the online help of w2x-app, a graphical application which is easier to use than the w2x command-line utility.

doc/api/

Contains the reference manual of the Java™ API of w2x (generated using javadoc).

legal/, legal.txt

Contains legal information about w2x and about third-party components used in w2x.

lib/

All the (non-system) Java™ class libraries needed to run w2x:

xmlresolver.jar: an enhanced XML resolver with XML Catalog support.

saxon.jar: The Saxon 6.5.5 XSLT 1.0 engine.

w2x_all.jar: self-contained JAR containing everything needed to run w2x, that is, all the other JAR files and also all the scripts and the stylesheets found in subdirectories xed/ and xslt/.

w2x.jar: contains the w2x engine.

w2x_rt.jar: contains a runtime needed by the w2x engine. All these classes come from XMLmind XML Editor.

wmf2svg.jar: WMF to SVG Converting Tool & Library; needed to support the WMF picture format.

wmf_converter.jar: contains a picture format plug-in based on wmf2svg.jar.

whc.jar: contains the XMLmind Web Help Compiler engine.

snowball.jar: Snowball is used by XMLmind Web Help Compiler to implement stemming.

plugin/

An empty directory where user plugins are to be copied in order to be automatically registered with w2x.

sample_plugins/rss/

sample_plugins/wh5_zip/

The two sample plugins used as examples in this document. The rss/src/ subdirectory contains the Java™ source code of rss/date_util.jar (custom support code). The wh5_zip/src/ subdirectory contains the Java™ source code of wh5_zip/zip_step.jar (custom conversion step).

xed/

Contains the XED scripts used to convert styles to semantic XHTML tags.

xslt/

Contains the XSLT 1.0 stylesheets used to generate semantic XML.

Alternatives to using the w2x command-line utility

The w2x-app graphical application

Graphical application w2x-app should be easier to use than the w2x command-line utility. This application is found in w2x_install_dir/bin/. How to use it is explained in w2x-app - Online Help.

The “Word To XML” add-on for XMLmind XML Editor

Graphical application w2x-app is also available as an add-on for XMLmind XML Editor. This add-on adds an "Import DOCX" item to the File menu. The "Import DOCX" menu item displays a non-modal dialog box almost identical to w2x-app. XML output files created using the "Import DOCX" dialog box are automatically opened in XMLmind XML Editor.

As of version 9.1, the “Word To XML” add-on is included in all the software distributions of XMLmind XML Editor. Therefore following the instructions below is probably not needed. However please note that, when part of XMLmind XML Editor Personal Edition, this add-on runs in “evaluation mode”, that is, it generates output containing random words replaced by string "[XMLmind]").

Installing the “Word To XML” add-on

This add-on is compatible with latest version of XMLmind XML Editor. In order to install it, please proceed as follows:

1. Start XMLmind XML Editor.
2. Select Options→Install Add-ons. This displays the “Install Add-ons” dialog box.
3. In the Install tab, click the checkbox found before the table row containing “Word To XML”.

   

4. Click OK to download and install the “Word To XML” add-on.
5. Restart XMLmind XML Editor as instructed.

   Notice that the File menu has now an “Import DOCX” item.

   

The “Word To XML” servlet

The “Word To XML” servlet is a Java™ Servlet (server-side standard component) which has the same functions as the w2x-app desktop application.

Contents of the servlet software distribution

The “Word To XML” servlet comes in a software distribution of its own: w2x_servet-1_12_0.zip. This distribution contains a ready-to-deploy binary w2x.war, as well as the full Java™ source code of the servlet.

w2x.war

Ready-to-deploy Web application ARchive (WAR) containing the servlet.

src/

src/build.xml

The Java™ source code of the servlet. Run ant in src/ in order to use src/build.xml to rebuild w2x.war.

w2x/

Directory containing unpacked w2x.war. Needed to rebuild w2x.war.

lib/

Contains Java™ libraries needed to rebuild w2x.war.

Installing the servlet

File w2x.war may be easily installed in any servlet container implementing at least the Servlet 2.3 standard. Example of such servlet containers: Apache Tomcat, Jetty, Caucho Resin.

Though copying file w2x.war to the webapps/ folder of the servlet container and then restarting the servlet container is generally sufficient to deploy the “Word To XML” servlet, please refer to the documentation your servlet container to learn about the best deployment procedure.

Configuring the servlet

The “Word To XML” servlet is configured by specifying a number of init-param parameters. These parameters are found in WEB-INF/web.xml, where folder WEB-INF/ is contained in w2x.war.

All these init-param parameters are documented in web.xml. Example, parameter workDir:

<!-- workDir =============================================================
     Uploaded files and files generated during the conversion process 
     are stored in temporary subdirectories of this directory.
     If specified directory does not exist, it will be created.

     Value: this directory and its contents must be readable and writable
     by the operating system account used to run the Word To XML servlet.

     Default: dynamic; supplied by the Servlet Container.
====================================================================== -->

<init-param>
  <param-name>workDir</param-name><param-value></param-value>
</init-param>

Using the servlet to convert DOCX files

Let’s suppose your servlet container runs on host localhost and uses 8080 as its port. In order to use the “Word To XML” servlet, please point your Web browser to http://localhost:8080/w2x/. This will cause the browser to display a page containing a simple DOCX convert form.

In order to convert a DOCX file to another format:

1. Click “Choose File” to select the DOCX file to be converted.
2. Select the desired output format using the “Output format” combobox.
3. Click Convert to download a .zip (or .epub) archive containing the result of the conversion. Generating this .zip (or .epub) file may take several seconds to several minutes depending on the size of the DOCX input file.

Non interactive requests

It’s also possible to use the conversion services of the “Word To XML” servlet by sending URL /w2x/convert an HTTP POST request having a multipart/form-data encoding.

cURL^[2] example:

curl -s -S -o manual_docbook5.zip \
  -F "docx=@manual.docx;type=application/vnd.openxmlformats-officedocument.wordprocessingml.document" \
  -F "conv=docbook5" \
  http://localhost:8080/w2x/convert

Other example:

curl -s -S -o manual.epub \
 -F "docx=@manual.docx;type=application/vnd.openxmlformats-officedocument.wordprocessingml.document" \
 -F "conv=epub" \
 -F "params=-p epub.identifier urn:x-mlmind:w2x:manual -p epub.split-before-level 8" \
 http://localhost:8080/w2x/convert

The conversion request has three emulated form fields:

docx

Emulated <input type=”file”> field. Required. Contains the DOCX input file.

conv

Emulated <input type=”text”> field. Required. Contains the name of one of the conversionN.name init-param defined in WEB-INF/web.xml.

The stock WEB-INF/web.xml defines the following conversions to styled HTML:

xhtml_css (single page styled HTML), frameset (multi-page styled HTML, split on Heading 1), frameset2 (multi-page styled HTML, split on Heading 1, 2), frameset3 (multi-page styled HTML, split on Heading 1, 2, 3), webhelp (split on Heading 1), webhelp2 (split on Heading 1, 2), webhelp3 (split on Heading 1, 2, 3), epub (split on Heading 1), epub2 (split on Heading 1, 2), epub3 (split on Heading 1, 2, 3)

and also the following conversions to “semantic” XML:

docbook, docbook5, topic, map, bookmap, xhtml_strict, xhtml_loose, xhtml1_1, xhtml5.

params

Emulated <input type=”text”> field. Optional. Contains some w2x command-line options, generally -p parameters. These options are appended to the options of the conversion specified in the conv emulated form field.

The response to a successful conversion request is a .zip (or .epub) archive containing the result of the conversion.

Getting started with w2x

We’ll use this manual to explain the basic uses of the w2x command-line utility. This manual is found in DOCX format in w2x_install_dir/doc/manual/ and the w2x command-line utility is found in w2x_install_dir/bin/.

C:\w2x-1_12_0> cd doc\manual
C:\w2x-1_12_0\doc\manual> mkdir out

• Convert manual.docx to out\manual.xhtml, containing clean, styled, valid XHTML+CSS, looking very much like manual.docx:

  ..\..\bin\w2x manual.docx out\manual.xhtml
  

  If you want to generate XHTML which is treated by Web browsers as if it were HTML, simply use a .html file extension for the output file:

  ..\..\bin\w2x manual.docx out\manual.html
  

  Doing this automatically turn on options^[3] which remove the XML declaration (<?xml version=”1.0” encoding=”UTF-8”?>) normally found at the top of an XHTML file and insert a <meta content=”text/html; charset=UTF-8” http-equiv=”Content-Type”/> into the html/head element of the output document.

• Convert manual.docx to out\frameset\manual.xhtml, containing multi-page, clean, styled, valid XHTML+CSS, looking very much like manual.docx:

  ..\..\bin\w2x –o frameset manual.docx out\frameset\manual.xhtml
  

  The above command generates multiple “.xhtml” files in the out\frameset directory which is automatically created^[4] if needed to.

  Note that out\frameset\manual.xhtml contains a frameset. While an obsolete HTML feature, a frameset makes it easy browsing the generated XHTML+CSS pages. Moreover the table of contents used as the left frame, found in out\frameset\manual-TOC.xhtml, is a convenient way to programmatically list all the generated XHTML+CSS pages.

• Convert manual.docx to out\webhelp\manual.html, containing a Web Help looking very much like manual.docx:

  ..\..\bin\w2x –o webhelp manual.docx out\webhelp\manual.html
  

  The above command generates multiple “.html” files in the out\webhelp directory which is automatically created if needed to.

• Convert manual.docx to out\manual.epub, containing a EPUB 2 book looking very much like manual.docx:

  ..\..\bin\w2x –o epub manual.docx out\manual.epub
  

• Convert manual.docx to out\manual.xml, containing DocBook 4.5.

  ..\..\bin\w2x –o docbook manual.docx out\manual.xml
  

• Convert manual.docx to out\manual.xml, containing DocBook 5.0.

  ..\..\bin\w2x –o docbook5 manual.docx out\manual.xml
  

  By default, the generated DocBook files contain HTML tables. If you prefer DocBook to contain CALS tables, please use the following options:

  ..\..\bin\w2x –o docbook5¬
   -p convert.set-column-number yes -p transform.cals-tables yes¬
   manual.docx out\manual.xml
  

• Convert manual.docx to out\manual.xml, containing a DocBook V5.1 assembly.

  ..\..\bin\w2x –o assembly manual.docx out\manual.xml
  

• Convert manual.docx to out\manual.dita, containing a DITA topic.

  ..\..\bin\w2x –o topic manual.docx out\manual.dita
  

  Generating a task having “MyTask” as its ID is equally simple:

  ..\..\bin\w2x –o topic¬
   -p transform.topic-type task -p transform.root-topic-id MyTask¬
   manual.docx out\manual.dita
  

• Convert manual.docx to out\manual.ditamap, containing a DITA map.

  ..\..\bin\w2x –o map manual.docx out\manual.ditamap
  

• Convert manual.docx to out\manual.ditamap, containing a DITA bookmap possibly having chapter topicrefs and nested topicrefs acting as sections and subsections (but no sub-subsections).

  ..\..\bin\w2x –o bookmap -p transform2.section-depth 3¬
   manual.docx out\manual.ditamap
  

• Convert manual.docx to out\manual.xhtml, containing “semantic”, unstyled XHTML5.

  ..\..\bin\w2x –o xhtml5 manual.docx out\manual.xhtml
  

  Use the following options to generate other versions of semantic XHTML:

  Option	XHTML Version
  -o xhtml_strict	XHTML 1.0 Strict
  -o xhtml_loose	XHTML 1.0 Transitional
  -o xhtml_1	XHTML 1.1
  -o xhtml5	XHTML 5.0

How to generate useful multi-page HTML

In order to generate multi-page HTML, that is, frameset, Web Help, EPUB, we need to automatically split the source DOCX document into parts.

A new part is created each time a paragraph having an outline level less than or equal to specified split-before-level parameter is found in the source. An outline level is an integer between 0 (e.g. style “Heading 1”) and 8 (e.g. style “Heading 9”). The default value of parameter split-before-level is 0, which means: for each “Heading 1”, create a new page starting with this “Heading 1”.

Frameset example: for each “Heading 1” and “Heading 2”, create a new page (out/frameset/manual-1.xhtml, out/frameset/manual-2.xhtml, ..., out/frameset/manual-N.xhtml) starting with this “Heading 1” or “Heading 2”:

..\..\bin\w2x -p split.split-before-level 1¬
  –o frameset manual.docx out\frameset\manual.xhtml

EPUB example:

..\..\bin\w2x -p epub.split-before-level 1¬
  –o epub manual.docx out\manual.epub

Web Help containing “semantic” XHTML 5 example:

..\..\bin\w2x -p webhelp.split-before-level 1¬
  –o webhelp5 manual.docx out\webhelp\manual.html

Going further with w2x

When you execute the following command:

..\..\bin\w2x –o docbook5 manual.docx out\manual.xml

you execute in fact a sequence of 3 conversion steps:

1. Convert the DOCX file to a styled, valid, XHTML 1.0 Transitional document, looking very much like the input DOCX file.
2. Apply a number of XED scripts to this document to convert CSS styles into semantic tags. For example, numbered paragraphs are converted to proper ordered lists .

   The entry point of these “semantic” XED scripts is found in w2x_install_dir/xed/main.xed.

   The XED scripts edit in place the input XHTML document. Therefore, the result of this step is the same XHTML document, still valid, but this time, containing no CSS styles whatsoever.

3. Apply an XSLT 1.0 stylesheet to the unstyled, valid, XHTML 1.0 Transitional document in order to generate the desired semantic XML format.

   The XSLT stylesheets are all found in w2x_install_dir/xslt/. In the above case, we want to generate DocBook v5, therefore we use w2x_install_dir/xslt/docbook5.xslt.

This sequence of conversion steps can be made visible in every detail by specifying the –vv option (very verbose) :

..\..\bin\w2x –vv –o docbook5 manual.docx out\manual.xml

VERBOSE: Converting "manual.docx" to XHTML...
DEBUG: convert.xhtml-file=C:\w2x-1_12_0\doc\manual\out\manual.xhtml

VERBOSE: Editing XHTML document using "C:\w2x-1_12_0\xed\main.xed"...
DEBUG: edit.xed-url-or-file=file:/C:/w2x-1_12_0/xed/main.xed
DEBUG: Loading script "file:/C:/w2x-1_12_0/xed/main.xed"...
DEBUG: Loading script "file:/C:/w2x-1_12_0/xed/after-translate.xed"...
[...]
DEBUG: Loading script "file:/C:/w2x-1_12_0/xed/before-save.xed"...

VERBOSE: Transforming document using "C:\w2x-1_12_0\xslt\docbook5.xslt" then saving it to "C:\w2x-1_12_0\doc\manual\out\manual.xml"...
DEBUG: transform.out-file=C:\w2x-1_12_0\doc\manual\out\manual.xml transform.xslt-url-or-file=file:/C:/w2x-1_12_0/xslt/docbook5.xslt
[...]

In fact, option –o docbook5 is a shorthand for the following w2x command-line options:

• -c

  Execute a Convert step called “convert”.

• -p convert.xhtml-file C:\w2x-1_12_0\doc\manual\out\manual.xhtml

  Pass the above xhtml-file parameter to the conversion step called “convert”.

• -e

  Execute an Edit step called “edit”.

• -p edit.xed-url-or-file file:/C:/w2x-1_12_0/xed/main.xed

  Pass the above xed-url-or-file parameter to the conversion step called “edit”.

• -t

  Execute a Transform step called “transform”.

• -p transform.xslt-url-or-file file:/C:/w2x-1_12_0/xslt/docbook5.xslt
• -p transform.out-file C:\w2x-1_12_0\doc\manual\out\manual.xml

  Pass the above xslt-url-or-file and out-file parameters to the conversion step called “transform”.

The order of the –c, -e and –t options is significant because it means: first convert, then edit and finally transform. The order of the –p (and –pu) options is not important, as a parameter name must be prefixed by the name of the step to which it applies.

The Convert, Edit and Transform steps are the most important steps. There are other conversion steps though, which are all documented in chapter Conversion step reference. Moreover a Java™ programmer may implement its own custom conversion steps^[5] and instruct the w2x command-line to give them names (required to pass them parameters) and to execute them. See option –step.

A w2x processor executes a sequence of conversion steps whatever the output format. Simply the conversion steps, their order, number and parameters, depend on the desired output format. This is depicted in the figure below.

The first sequence of in the above figure reads as follows: in order to convert a DOCX file to styled XHTML, first convert the DOCX file to a XHTML+CSS document, then “polish up” this document (e.g. process consecutive paragraphs having identical borders) using XED script w2x_install_dir/xed/main-styled.xed, and finally save the possibly modified XHTML+CSS document to disk.

Stock XED scripts

XMLmind Word to XML comes with two stock “main” XED scripts:

w2x_install_dir/xed/main-styled.xed

Invokes XED scripts used to “polish up” the styled XHTML 1.0 Transitional document created by the Convert step (e.g. process consecutive paragraphs having identical borders).

w2x_install_dir/xed/main.xed

Invokes XED scripts used to prepare the generation of semantic XML of all kinds: XHTML, DocBook, DITA. These scripts leverage the CSS styles and classes found in the styled XHTML 1.0 Transitional document created by the Convert step. They translate these CSS styles and classes (e.g. numbered paragraph) into semantic tags (e.g. ol/li).

Both the above “main” XED scripts are organized as sequences of simpler, short, XED scripts. Using –p or –pu options, these short scripts may be replaced or removed and may be passed parameters. It’s also possible to insert custom scripts before or after any of these short scripts.

Excerpts from w2x_install_dir/xed/main-styled.xed:

script(defined("before.init-styles", ""));
script(defined("do.init-styles", "init-styles.xed"));
script(defined("after.init-styles", ""));

script(defined("before.title-styled", ""));
script(defined("do.title-styled", "title-styled.xed"));
script(defined("after.title-styled", ""));

script(defined("before.remove-pis", ""));
script(defined("do.remove-pis", "remove-pis.xed"));
script(defined("after.remove-pis", ""));

script(defined("before.expand-tabs", ""));
script(defined("do.expand-tabs", "expand-tabs.xed"));
script(defined("after.expand-tabs", ""));

script(defined("before.borders", ""));
script(defined("do.borders", "borders.xed"));
script(defined("after.borders", ""));

script(defined("before.number-footnotes", ""));
script(defined("do.number-footnotes", "number-footnotes.xed"));
script(defined("after.number-footnotes", ""));

script(defined("before.finish-styles", ""));
script(defined("do.finish-styles", "finish-styles.xed"));
script(defined("after.finish-styles", ""));

Examples:

• Remove script title-styled.xed:

  -p edit.do.title-styled “”
  

• Replace script borders.xed by custom script “C:\Users\john\w2x tests\MyBorders.xed”:

  -pu edit.do.borders “C:\Users\john\w2 tests\MyBorders.xed”
  

• Pass parameter finish-styles.css-uri to script finish-styles.xed:

  -p edit.finish-styles.css-uri css/manual.css
  

  By convention (this is not strictly required), the name of a parameter which applies to a given XED script is prefixed with the basename without any file extension of this script. Hence the full names of most parameters of Edit steps have the following syntax: step_name.script_name.parameter_name. Examples:

  -p edit.prune.preserve “p-ProgramListing”
  
  -p edit.inlines.convert “c-Code code”
  

• Execute script customize\patch_manual.xed before script finish-styles.xed:

  -pu edit.before.finish-styles customize\patch_manual.xed
  

• Execute script customize\patch_manual.xed after script borders.xed:

  -pu edit.after.borders customize\patch_manual.xed
  

Customizing the output of w2x

Customizing the XHTML+CSS files generated by w2x

Using a XED script to modify the styles embedded in the XHTML+CSS file

By default, w2x adds a number of CSS rules to the /html/head/style element of the generated XHTML+CSS file. Example: excerpts from w2x_install_dir/doc/manual/manual.html:

<style type="text/css">
body {
    counter-reset: n-1-0 0 n-1-1 0 n-1-2 0 n-17-0 0 n-20-0 0;
    font-family: Calibri;
    font-size: 11pt;
}
...
</style>

A XED script allows to modify, not only the nodes of an XHTML document, but also its “CSS styles”. These “CSS styles” may be either style properties contained in the style attribute of an element or class names found in the class attribute of an element or the CSS rules of the document.

Therefore, when the desired customization is limited, suffice to execute a XED script in order to modify the XHTML+CSS document created by the Convert step. Example:

w2x -pu edit.before.finish-styles customize\patch_manual.xed¬
 manual.docx out\manual.html

where w2x_install_dir/doc/manual/customize/patch_manual.xed contains:

set-rule(".p-ProgramListing", "white-space", "pre");

The above line adds CSS property “white-space: pre;” to the CSS rule having “.p-ProgramListing” as its selector. This CSS rule corresponds to custom paragraph^[6] style called “ProgramListing”.

Besides XED command set-rule, the following commands allow to edit the CSS styles contained in the XHTML+CSS document created by the Convert step: add-class, add-rule, remove-class, remove-rule, set-style.

Appending custom styles to the styles embedded in the XHTML+CSS file

XED script w2x_install_dir/xed/finish-styles.xed has a optional custom-styles-url-or-file parameter which makes it easy customizing the automatically generated CSS styles.

This parameter may be used to specify the location of a CSS file. The custom CSS styles found in specified file are simply appended to the automatically generated CSS styles. Example:

Example:

w2x -pu edit.finish-styles.custom-styles-url-or-file customize\custom.css¬
  manual.docx out\manual_restyled.html

where customize\custom.css contains:

body {
    font-family: sans-serif;
}

.p-Heading1,
.p-Heading2,
.p-Heading3,
.p-Heading4,
.p-Heading5,
.p-Heading6 {
    font-family: serif;
    color: #17365D;
    padding: 1pt;
    border-bottom: 1pt solid #4F81BD;
    margin-bottom: 10pt;
    margin-left: 0pt;
    text-indent: 0pt;
}

.p-Heading1 {
    border-bottom-width: 2pt;
}

...

.c-FootnoteReference,
.c-EndnoteReference {
    font-size: smaller;
}

Using an external CSS file rather than embedded CSS styles

XED script w2x_install_dir/xed/finish-styles.xed has a optional css-uri parameter which allows to specify the CSS file where all CSS rules, whether automatically generated or custom, are to be saved.

Same example as above but using an external CSS file rather than embedded CSS styles:

w2x -p edit.finish-styles.css-uri manual_restyled_css/manual.css¬
  -pu edit.finish-styles.custom-styles-url-or-file customize\custom.css¬
  manual.docx out\manual_restyled.html

All the CSS styles, whether automatically generated or the custom ones found in customize\custom.css, end up in manual_restyled_css\manual.css. Moreover, out\manual_restyled.html contains a link to manual_restyled_css\manual.css.

<link href="manual_restyled_css/manual.css"
      rel="stylesheet" type="text/css"/>

Combining all the above methods

It is of course possible to combine all the above methods. For example, the following w2x command is used to create w2x_install_dir/doc/manual/manual_restyled.html:

w2x -pu edit.before.finish-styles customize\patch_manual_restyled.xed¬
 -p edit.finish-styles.css-uri manual_restyled_css/custom.css¬
 -pu edit.finish-styles.custom-styles-url-or-file customize\custom.css¬
 manual.docx out\manual_restyled.html

where w2x_install_dir/doc/manual/customize/patch_manual_restyled.xed contains:

for-each /html/body/p[get-class("^p-Heading\d$")] {
    set-variable("class", get-class("^n-\d+-\d+$"));
    if $class != '' {
        set-variable("selector", concat(".", $class, ":after"));
        if find-rule($selector) >= 0 {
            remove-rule($selector);

            set-variable("selector", concat(".", $class, ":before"));
            set-rule($selector, "float");
            set-rule($selector, "width");
            set-rule($selector, "content",
                     concat(get-rule($selector, "content"), ' " "'));
            set-rule($selector, "display", "inline");
        }
    }
}

The above XED script:

1. Delete CSS rules like this one:

   .n-1-0:after {
       clear: both;
       content: "";
       display: block;
   }
   

2. Modify CSS rules like this one:

   .n-1-0:before {
       content: counter(n-1-0);
       counter-increment: n-1-0;
       float: left;
       width: 21.6pt;
   }
   

   which becomes:

   .n-1-0:before {
       content: counter(n-1-0) " ";
       counter-increment: n-1-0;
       display: inline;
   }
   

This script is useful because otherwise adding a bottom border to headings gives an ugly result. While the contents of the heading is “underlined”, the CSS float containing the numbering value of the heading is not.

Besides get-class, the following XPath extension functions may be used to access the CSS styles contained in the XHTML+CSS document created by the Convert step: find-rule, font-size, get-rule, get-style, lookup-length, lookup-style, style-count.

Customizing the semantic XML files generated by w2x

Converting custom character styles to semantic tags

Converting a custom character style to an XHTML element (possibly having specific attributes) is simple and does not require writing a XED script. Suffice for that to pass parameter inlines.convert to the Edit step.

Example 1: convert text spans having a “Code” character style to XHTML element code:

-p edit.inlines.convert "c-Code code"

The syntax for the value of parameter inlines.convert is:

value →  conversion [ S ‘!’ S  conversion ]*
conversion → style_spec S XHTML_element_name [ S attribute ]*
style_spec →  style_name | style_pattern
style_pattern  → ‘/’ pattern ’/’ | ‘^’ pattern ‘$’
attribute → attribute_name ‘=’ quoted_attribute_value
quoted_attribute_value →  “’” value “’” | ‘”’ value ‘”’

Example 2: in addition to what’s done in above example 1, convert text spans having a “Abbrev” character style to XHTML element abbr having a title=”???” attribute:

-p edit.inlines.convert "c-Code code ! c-Abbrev abbr title='???'"

What if the semantic XHTML created by the Edit step is then converted to DITA or DocBook by the means of a Transform step?

In the case of XHTML elements code and abbr, there is nothing else to do because the stock XSLT stylesheets already support these elements:

• w2x_install_dir/xslt/topic.xslt converts XHTML code to DITA codeph and XHTML abbr to DITA keyword,
• w2x_install_dir/xslt/docbook.xslt converts XHTML code to DocBook code and XHTML abbr to DocBook abbrev.

The general case which also requires using custom XSLT stylesheets is explained in section The general case.

Converting custom paragraph styles to semantic tags

Converting a custom paragraph style to an XHTML element (possibly having specific attributes) is simple and does not require writing a XED script. Suffice for that to pass parameter blocks.convert to the Edit step.

Example 1.a: convert paragraphs having a “ProgramListing” paragraph style to XHTML element pre:

-p edit.blocks.convert "p-ProgramListing pre"

If you use the above blocks.convert specification, it will work fine, except that you’ll end up with several consecutive pre elements (one pre per line of program listing). This is clearly not what you want. You want consecutive pre elements to be merged into a single pre element. Fortunately implementing this too is quite simple.

Example 1.b: convert paragraphs having a “ProgramListing” paragraph style to XHTML element span (having grouping attributes; more about this below):

-p edit.blocks.convert "p-ProgramListing span g:id='pre' g:container='pre'"

When any of the target XHTML elements have grouping attributes (g:id='pre'^[7], g:container='pre', in the above example), then w2x_install_dir/xed/blocks.xed automatically invokes the group() command at the end of the conversions. This has the effect of grouping consecutive <span g:id='pre' g:container='pre'> into a common pre parent element.

Given the fact that XED command group() automatically removes grouping attributes when done and that w2x_install_dir/xed/finish.xed discards all useless span elements, this leaves us with clean pre elements containing text^[8].

The syntax for the value of parameter blocks.convert is:

value →  conversion [ S ‘!’ S  conversion ]*
conversion → style_spec S XHTML_element_name [ S attribute ]*
style_spec →  style_name | style_pattern
style_pattern  → ‘/’ pattern ’/’ | ‘^’ pattern ‘$’
attribute → attribute_name ‘=’ quoted_attribute_value
quoted_attribute_value →  “’” value “’” | ‘”’ value ‘”’

Example 3: in addition to what’s done in above example 1.b, convert paragraphs having a “Term” paragraph style to XHTML element dt, convert paragraphs having a “Definition” paragraph style to XHTML element dl and group consecutive dt and dl elements into a common dl parent:

-p edit.blocks.convert "p-Term dt g:id='dl' g:container='dl' !¬
 p-Definition dd g:id='dl' g:container='dl' !¬
 p-ProgramListing span g:id='pre' g:container='pre'"

What if the semantic XHTML created by the Edit step is then converted to DITA or DocBook by the means of a Transform step?

In the case of XHTML elements pre, dt, dd and dl, there is nothing else to do because the stock XSLT stylesheets already support these elements.

The general case which also requires using custom XSLT stylesheets is explained in section The general case.

The general case

In the general case, customizing the semantic XML files generated by w2x requires writing both a XED script and an XSLT stylesheet.

For example, let’s suppose we want to group all the paragraphs having a “Note” paragraph style and to generate for such groups DocBook and DITA note elements.

The following blocks.convert parameter would allow to very easily create the desired groups:

-p edit.blocks.convert "p-Note p g:id='note_group_member'¬
 g:container='div class=\”role-note\” ’"

However this would leave us with two unsolved problems:

1. A paragraph having a “Note” paragraph style often starts with bold text “Note:”. We want to eliminate this redundant label.
2. The stock XSLT stylesheets will not convert XHTML element <div class=”role-note”> to a DocBook or DITA note element.

A custom XED script

The first problem is solved by the following w2x_install_dir/doc/manual/customize/notes.xed script:

namespace "http://www.w3.org/1999/xhtml";
namespace html = "http://www.w3.org/1999/xhtml";
namespace g = "urn:x-mlmind:namespace:group";

for-each /html/body//p[get-class("p-Note")] {
    delete-text("note:\s*", "i");
    if content-type() <= 1 and not(@id) {
        delete();
    } else {
        remove-class("p-Note");
        set-attribute("g:id", "note_group_member");
        set-attribute("g:container", "div class='role-note'");
    }
}

group();

The “Note:” label, if any, is deleted using XED command delete-text. If doing this creates a useless empty (content-type() <= 1) paragraph, then delete this paragraph using XED command delete.

The above script is executed after stock script w2x_install_dir/xed/blocks.xed by the means of the following w2x command-line option:

-pu edit.after.blocks customize\notes.xed

A custom XSLT stylesheet

The second problem is solved by the following w2x_install_dir/doc/manual/customize/custom_topic.xslt XSLT 1.0 stylesheet:

<xsl:stylesheet version="1.0"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:h="http://www.w3.org/1999/xhtml"
  exclude-result-prefixes="h">

<xsl:import href="w2x:xslt/topic.xslt"/>

<xsl:template match="h:div[@class = 'role-note']">
  <note>
    <xsl:call-template name="processCommonAttributes"/>
    <xsl:apply-templates/>
  </note>
</xsl:template>
...
</xsl:stylesheet>

This stylesheet, which imports stock w2x_install_dir/xslt/topic.xslt, is used for the topic, map and bookmap output formats (see –o option). Similar, very simple, stylesheets have been developed for the docbook and docbook5 output formats.

The above stylesheet replaces the stock one by the means of the following w2x command-line option:

-o topic -t customize\custom_topic.xslt

Do not forget to specify the –t option after the –o option, because it’s the –o option which implicitly invokes stock w2x_install_dir/xslt/topic.xslt (this has been explained in chapter Going further with w2x) and we want to use –t to override the use of the stock XSLT stylesheet.

Generating XML conforming to a custom schema

In order to use w2x to convert a DOCX input file to an XML output file conforming to your custom schema, all you have to do is write a custom XSLT 1.0 stylesheet converting the “semantic” XHTML 1.0 Transitional generated by the Edit step to your custom schema.

Let’s call your custom XSLT 1.0 stylesheet “C:\Users\John\foo\xsl\xhtml_to_foo.xsl”. Command-line tool w2x must then be passed the following options:

• -c

  Execute a Convert step called “convert”.

• -e XED_URL_or_file

  Execute an Edit step called “edit”.

  Example: -e w2x:xed/main.xed. Pass this stock XED script (converting the styled XHTML  1.0 Transitional created by the Convert step to “semantic” XHTML) to the conversion step called “edit”.

• -t XSLT_URL_or_file

  Execute a Transform step called “transform”.

  Example: -t "C:\Users\John\foo\xsl\xhtml_to_foo.xsl".

  Pass your custom XSLT 1.0 stylesheet to the conversion step called “transform”.

Stock XED script w2x:xed/main.xed creates a number of semantic XHTML elements having a class attribute starting with “role-“. Examples: <div class=”role-section1”>, <div class=”role-section2”>, <div class=”role-figure”>, <div class=”role-figcaption”>, <a class=”role-footnote-ref”>, <div class=”role-footnote”>, <a class=”role-xref”>, <span class=”role-index-term”>, etc. To learn how to process these elements, the simplest is to look how this is done in a stock XSLT stylesheet such as “w2x_install_dir/xslt/topic.xslt” or “w2x_install_dir/xslt/docbook.xslt”.

Packaging your customization as a w2x plugin

Command-line utility w2x and desktop application w2x-app support plugins.

Let’s suppose you have created a plugin called “rss” which may be used to convert DOCX to RSS. Once registered with w2x, this plugin may be invoked as it were a stock conversion, for example:

w2x -o rss my.docx my.xml

Other example, using a plugin called “wh5_zip” (see description below):

w2x -o wh5_zip -p zip.include-top-dir false my.docx my.zip

In w2x-app, you'll find the registered plugins in the "Convert to" combobox and in the "Output format" screen of the setup assistant.

Anatomy of a plugin

A plugin is simply a plain text file, using an UTF-8 character encoding, having a ".w2x_plugin" file suffix, containing a number of w2x command-line arguments and starting with comment lines containing information about the plugin (for example, its name). Example, w2x_install_dir/sample_plugins/rss/rss.w2x_plugin:

### plugin.name: rss
### plugin.outputDescription: RSS 2.0
### plugin.outputExtension: xml
### plugin.multiFileOutput: no

-c
-e w2x:xed/main.xed
-t rss.xslt

# Image files not useful here.
-step:com.xmlmind.w2x.processor.DeleteFilesStep:cleanUp
-p cleanUp.files "%{~pO}/%{~nO}_files"

The above rss plugin converts DOCX to RSS. This process is partly implemented by XSLT 1.0 stylesheet w2x_install_dir/sample_plugins/rss/rss.xslt which is part of this plugin. Stylesheet rss.xslt transforms its input, the semantic XHTML 1.0 Transitional file created by the Edit step (invoked using -e w2x:xed/main.xed), to RSS.

Aside XSLT 1.0 stylesheets, a plugin may also include XED scripts as well as ".jar" files containing support code and/or custom conversion steps implemented in Java™. Example, w2x_install_dir/sample_plugins/wh5_zip/wh5_zip.w2x_plugin:

### plugin.outputDescription: Web Help ZIP containing "semantic" (X)HTML 5.0
### plugin.outputExtension: zip

-o webhelp5
-p webhelp.split-before-level 8
-p webhelp.use-id-as-filename yes
-p webhelp.omit-toc-root yes
-p webhelp.wh-layout simple

# Generate all HTML files in a subdirectory of the output directory 
# having the same basename as the ".zip" output file.

-p convert.xhtml-file "%{~pO}/%{~nO}/%{~nO}.xhtml"

-p transform.out-file "%{~pO}/%{~nO}/%{~nO}_tmp.xhtml"

-p webhelp.out-file "%{~pO}/%{~nO}/%{~nO}.html"

-p cleanUp.files "%{~pO}/%{~nO}/%{~nO}_tmp.xhtml"

-step:ZipStep:zip 
-p zip.out-file "%{O}"

The above wh5_zip plugin specializes the stock conversion called webhelp5 (Web Help containing XHTML 5.0) by giving specific values to some of its parameters (e.g. -p webhelp.wh-layout simple) and also by archiving all the output files in a single “.zip” file.

This last step, -step:ZipStep:zip, is implemented by a custom conversion step found in w2x_install_dir/sample_plugins/wh5_zip/src/ZipStep.java. This Java™ code is compiled and archived in w2x_install_dir/sample_plugins/wh5_zip/zip_step.jar by the means of ant build file w2x_install_dir/sample_plugins/wh5_zip/src/build.xml.

Note that these ".jar" files, just like the ".w2x_plugin" files, are automatically discovered and loaded by w2x and w2x-app during their startup phase.

Registering a plugin with w2x

A plugin is registered with both w2x and w2x-app by copying all its files anywhere inside directory w2x_install_dir/plugin/.

However it's strongly recommended to group all the files comprising a plugin in a subdirectory of its own having the same name as the plug-in (e.g. w2x_install_dir/plugin/rss/).

Alternatively, this plugin may be installed anywhere you want provided that the directory containing the ".w2x_plugin" file is referenced in the W2X_PLUGIN_PATH environment variable. Example: set W2X_PLUGIN_PATH=C:\Users\John\w2x\rss;C:\temp\w2x_plugins.

The W2X_PLUGIN_PATH environment variable (or, equivalently, the W2X_PLUGIN_PATH Java™ system property; e.g. -DW2X_PLUGIN_PATH=C:\Users\John\w2x\rss;C:\temp\w2x_plugins) may contain absolute or relative directory paths separated by semi-colons (";"). A relative path is relative to the current working directory.

The W2X_PLUGIN_PATH environment variable may also contain "+", which is a shorthand for w2x_install_dir/plugin/. Windows example: set W2X_PLUGIN_PATH=..\sample_plugins;+. Linux/macOS example: export W2X_PLUGIN_PATH=+;/home/john/w2x_plugins.

The w2x command-line utility

Usage: w2x [-version] [-v|-vv] [Options] [-liststeps] in_docx_file out_file

Options are:

-o format

This option automatically adds all the steps needed to convert input DOCX file to an output file having specified format.

Possible formats: docbook, docbook5, assembly (DocBook V5.1 assembly), topic, map, bookmap, xhtml_css (single-page styled HTML, that is, single-page XHTML+CSS), xhtml_strict, xhtml_loose, xhtml1_1, xhtml5, frameset (multi-page styled HTML), frameset_strict (multi-page XHTML 1.0 Strict), frameset_loose (multi-page XHTML 1.0 Transitional), frameset1_1 (multi-page XHTML 1.1), frameset5 (multi-page XHTML 5.0), webhelp (Web Help containing styled HTML), webhelp_strict (Web Help containing XHTML 1.0 Strict), webhelp_loose (Web Help containing XHTML 1.0 Transitional), webhelp1_1 (Web Help containing XHTML 1.1), webhelp5 (Web Help containing XHTML 5.0), epub (EPUB 2 containing styled XHTML 1.1), epub1_1 (EPUB 2 containing semantic XHTML 1.1).

The default output format is: xhtml_css (single-page styled HTML, that is, single-page XHTML+CSS).

-p name value

Set parameter name to value.

Use parameter step_name.param_name to parametrize the step called step_name.

Because they are used to parameterize named steps, the order of –p and –pu options relatively to options specifying conversions steps (-c, -e, -t, -step, etc) is not significant. For example: “-p convert.charset UTF-8 -c” is equivalent to “-c -p convert.charset UTF-8”.

-pu name URL_or_file

Same as -p, except that parameter value URL_or_file is first converted to an URL.

URL_or_file is an absolute or relative URL (relative to current -f options file if any, to current working directory otherwise) or the filename of an existing file or directory.

-c

Add or replace “convert” step. This step converts input DOCX file to an in-memory XHTML +CSS document.

-l

Add or replace “load” step. This step, mainly used to test XED scripts, loads input XML file.

-e xed_URL_or_file

Add or replace “edit” step. This step edits in place input XHTML document using XED script xed_URL_or_file.

-e2 xed_URL_or_file

Add or replace “edit2” step. This step edits in place input XHTML document using XED script xed_URL_or_file.

-t xslt_URL_or_file

Add or replace “transform” step. This step transforms input XML document or file using XSLT stylesheet xslt_URL_or_file.

The output file is specified by parameter transform.out-file.

-t2 xslt_URL_or_file

Add or replace “transform2” step. This step transforms input XML document or file using XSLT stylesheet xslt_URL_or_file.

The output file is specified by parameter transform2.out-file.

-s

Add or replace “save” step. This step saves to disk input XHTML document.

The output file is specified by parameter save.out-file.

-step:java_class_name:step_name

Add or replace step called step_name by an instance of Java™ class java_class_name deriving from com.xmlmind.w2x.processor.ProcessStep.

-f options_URL_or_file

Load one or more of the above options from options_URL_or_file, a plain UTF-8 text file

-v

-vv

-vvv

Verbose. More Vs means more verbose.

-version

Print version number and exit.

-liststeps

List the conversion steps to be executed and exit. This option is useful to determine how to customize the conversion steps. Example:

$ w2x -o bookmap -liststeps
-step:com.xmlmind.w2x.processor.ConvertStep:convert
-p convert.create-mathml-object no
-p convert.set-column-number yes
-step:com.xmlmind.w2x.processor.EditStep:edit
-p edit.xed-url-or-file file:/opt/w2x/xed/main.xed
-step:com.xmlmind.w2x.processor.TransformStep:transform
-p transform.out-file %{~pnO}.dita
-p transform.single-topic no
-p transform.xslt-url-or-file file:/opt/w2x/xslt/topic.xslt
-step:com.xmlmind.w2x.processor.TransformStep:transform2
-p transform2.xslt-url-or-file file:/opt/w2x/xslt/bookmap.xslt
-p transform2.topic-type %{transform.topic-type}
-p transform2.output-path %{~po}
-step:com.xmlmind.w2x.processor.DeleteFilesStep:cleanUp
-p cleanUp.files %{~pnO}.dita

The -liststeps is also useful when developing a plugin. It may be used to learn how a stock conversion (e.g. bookmap) is implemented to get some inspiration when developing your own plugin.

Variables substituted in the parameter values passed to the –p and –pu options

The following variables are substituted in the parameter values passed to the –p and –pu options.

Variables %{I}, %{O}, %{i} and %{o} may all contain one or more of following modifiers. First modifier must be preceded by character “~”.

Note that combinations of modifiers other than “~nx”, “~pn”, “~pnx” do not make sense and that, for example, %{~pnxI} is equivalent to %{I}.

Examples: let’s suppose that command-line argument in_docx_file (see above) is “C:\My Docs\report.docx” and that argument out_file is “C:\My Docs\out\report.xml”.

• %{~nI} is replaced by “report”.
• %{~xI} is replaced by “.docx”.
• %{~pI} is replaced by “C:\My Docs”.
• %{~nxo} is replaced by “report.xml”.
• %{~pno} is replaced by “file:/C:/My%20Docs/out/report”.

Other variables substituted in the parameter values passed to the –p and –pu options:

• The value of another parameter passed to w2x by the means of the –p or –pu options. Example: when “w2x -o map -p transform.topic-type concept ...” is executed, %{transform.topic-type} is substituted with "concept".
• Any Java™ system property. Example: %{file.separator} is substituted with "\" on Windows and with "/" on the other platforms.

When a variable is not defined, its value is "", the empty string. Example: %{foo} is substituted with "".

Default conversion steps

If none of the options creating a step (-l, -c, -e, -e2, -t, -t2, -s, -step) have been specified, w2x automatically adds the equivalent of –o xhtml_css, which consists in the following conversion steps:

• -c
• -e
• -p edit.xed-url-or-file w2x:xed/main-styled.xed
• -s

The above options convert the input DOCX file to clean, styled, valid XHTML. The resulting output file is not indented.

Automatic conversion step parameters

If the first conversion step is a Convert step, the following parameters are automatically added by w2x (unless, of course, they have already been specified by the user):

• If out_file extension starts with “htm” or “shtm”,

  -p step_name.charset UTF-8

  The charset parameter allows to get Web browsers consider the generated document as being HTML, and not XHTML.

• -pu step_name.xhtml-file out_file_with_an_xhtml_extension

If the last conversion step is a Save step, Transform step, Split step, Web Help step or EPUB step the following parameters are automatically added by w2x (unless, of course, they have already been specified by the user):

• -pu step_name.out-file out_file

Conversion step reference

Convert step

Convert input DOCX file to a styled, valid, XHTML 1.0 Transitional document. The result of this step is this XHTML document.

Parameters:

<?column-number 1?>

Delete files step

Delete files or directories having specified path or matching specified glob pattern. The input of this step is ignored. The result of this step is thus equal to its input.

This step is used for example when generating a DITA map or bookmap. It is used to delete the intermediate topic file created by the first Transform step.

Parameters (for clarity, the “cleanUp.” parameter name prefix is omitted here):

Edit step

Edit in place input XHTML document using a XED script. The result of this step is the same XHTML document, but modified by the script.

Parameters:

Any other parameter is passed to the XED script as a XED global variable.

XMLmind Word to XML (w2x for short) comes with two stock “main” XED scripts:

w2x:xed/main-styled.xed

Invokes XED scripts used to “polish up” the styled XHTML 1.0 Transitional document created by the Convert step (e.g. process consecutive paragraphs having identical borders).

w2x:xed/main.xed

Invokes XED scripts used to prepare the generation of semantic XML of all kinds: XHTML, DocBook, DITA. These scripts leverage the CSS styles and classes found in the styled XHTML 1.0 Transitional document created by the Convert step. They translate these CSS styles and classes (e.g. numbered paragraph) into semantic tags (e.g. ol/li).

–p edit.blocks.convert "p-Code1 span g:id='pre' g:container='pre'"

–p edit.blocks.convert-to-pre "p-Code2 pre"

<div class="role-section2"
     id="Title_of_this_section">
  <h2>Title of this section</h2>
...

Simple conversion specifications

Above parameter blocks.convert (respectively inlines.convert) provides the user of w2x with a simple mean to convert p (respectively span) elements having certain paragraph (respectively character) styles to XHTML elements possibly having attributes.

The syntax of a simple conversion specification is:

spec → simple_spec  [ S ‘!’ S simple_spec ]*
simple_spec → style_spec S XHTML_element_qname [ S attribute_spec ]*
style_spec →  style_name | style_pattern
style_pattern  → ‘/’ pattern ’/’ | ‘^’ pattern ‘$’
attribute_spec →  attribute_qname ‘=’  quoted_attribute_value
quoted_attribute_value →  “’” value “’” | ‘”’ value ‘”’

Note that when specifying a XHTML_element_qname, you must restrict yourself to XHTML 1.0 Transitional elements. Specifying for example, XHTML 5.0 elements such as mark, aside, section, etc, will not give you the results you’ll expect.

Examples: stock styled span conversions used by w2x:xed/inlines.xed:

/Emphasis$/ em ! 
c-Strong strong ! 
c-BookTitle cite ! 
/((IntenseReference)|(SubtleReference)|(QuoteChar))$/ em !
/((itleChar)|(Heading\d+Char))$/ strong

Custom styled span conversions used to process this manual:

c-Code code

Stock styled paragraph conversions used by w2x:xed/blocks.xed:

/Quote$/ p g:id='blockquote' g:container='blockquote'

Custom styled paragraph conversions used to process this manual:

p-Term dt g:id="dl" g:container="dl" ! 
p-Definition dd g:id="dl" g:container="dl" ! 
p-ProgramListing span g:id="pre" g:container="pre"

Automatic grouping of the XHTML elements which are the results of the styled paragraph conversions

In the above examples, attributes having names prefixed with “g:” are in the “urn:x-mlmind:namespace:group” namespace. These attributes are called grouping attributes. Examples: g:id, g:container.

When parameter blocks.convert is used to create XHTML elements having grouping attributes, command group() is automatically invoked at the end of all the styled paragraph conversions. To make it simple, this command groups consecutive XHTML elements having the same g:id attribute into a common parent element. The parent element is specified by attribute g:container.

In the above examples,

• Consecutive p elements having grouping attributes g:id='blockquote' and g:container='blockquote' are grouped into a common blockquote parent element.
• Consecutive dt and dt elements having grouping attributes g:id="dl" and g:container="dl are grouped into a common dl parent element.
• Consecutive span elements having grouping attributes g:id="pre" and g:container="pre" are grouped into a common pre parent element.

EPUB step

Splits input XHTML document, whether styled or semantic, into several pages and packages these pages as an EPUB 2 book. The result of the this step is the file containing the EPUB book.

Same parameters as the Split step, plus the following EPUB specific parameters (for clarity, the “epub.” parameter name prefix is omitted here):

Load step

Loads an input XML file. The result of this step is loaded XML document.

This step is mainly useful to test XED scripts. Example:

w2x –l –e my_script.xed –s in.xhtml out.xhtml

Note that if loaded file starts with a <!DOCTYPE> pointing to a DTD, then a document loader created by this step will not attempt to load this DTD. The document loader will behave as if the <!DOCTYPE> was absent.

No parameters.

Save step

Saves input XHTML document to disk. The result of the this step is the save file.

Parameters (for clarity, the “save.” parameter name prefix is omitted here):

Split step

Splits input XHTML document, whether styled or semantic, into several pages and saves these pages to disk.

This step also generates a frameset and a table of contents used as the left frame of the frameset. While an obsolete HTML feature, a frameset makes it easy browsing the generated pages. Moreover the table of contents used as the left frame is a convenient way to programmatically list all the generated pages.

The result of the this step is the file containing the frameset.

Parameters:

Transform step

Transforms input XML document or file using an XSLT 1.0 stylesheet. The result of the this step is the save file containing the transformed document.

Unlike the load step, if the input XML file starts with a <!DOCTYPE> pointing to a DTD, then the document loader created by a Transform step will silently skip this DTD.

Parameters:

Any other parameter is passed to the XSLT stylesheet as an XSLT stylesheet parameter. Which XSLT stylesheet parameters are supported depend on the XSLT stylesheet being used.

-p edit.blocks.convert¬
"p-Shortdesc p class='p-Shortdesc'"
...
<xsl:template 
  match="h:p[@class='p-Shortdesc']">
  <shortdesc>
    <xsl:call-template 
      name="processCommonAttributes"/>
    <xsl:apply-templates/>
  </shortdesc>
</xsl:template>

-p transform.shortdesc-class-name¬
p-Shortdesc 

Web Help step

Splits input XHTML document, whether styled or semantic, into several pages and compiles these pages into a Web Help. The Web Help compiler used to do this is free, open source, XMLmind Web Help Compiler.

This step always generates UTF-8 encoded, “.html” files, no matter the parameters specifying other values.

Same parameters as the Split step, plus the following Web Help specific parameters (for clarity, the “webhelp.” parameter name prefix is omitted here):

Embedding w2x in a Java™ application

Embedding w2x in a Java™ application is as simple as:

1. Create an instance of class Processor.
2. Configure it by passing an array of option strings identical to those of the w2x command line utility to method Processor.configure or (low-level) by directly adding conversion steps and parameters to Processor.stepList and Processor.parameterMap.
3. Invoke the configured processor to convert specified input file to specified output file. This is done invoking high-level method Processor.process or low-level method Processor.executeSteps.

The reference manual (generated using javadoc) of the Java API of w2x is found in XMLmind Word To XML Java™ API.

High-level example w2x_install_dir/doc/manual/embed/Embed1.java:

Processor processor = new Processor();

int l = processor.configure(args);

File inFile = null;
File outFile = null;
if (l+2 == args.length) {
    inFile = new File(args[l]);
    outFile = new File(args[l+1]);
} else {
    System.exit(1);
}

processor.process(inFile, outFile, /*progress monitor*/ null);

• Compile Embed1.java by executing “ant”^[10] in w2x_install_dir/doc/manual/embed/.
• Run “ant tembed1” in w2x_install_dir/doc/manual/embed/. This creates w2x_install_dir/doc/manual/embed/tembed1.dita.

Lower-level example w2x_install_dir/doc/manual/embed/Embed2.java:

Processor processor = new Processor();

ConvertStep convertStep = new ConvertStep("convert");
processor.stepList.add(convertStep);

EditStep editStep = new EditStep("edit");
processor.stepList.add(editStep);

processor.parameterMap.put("edit.xed-url-or-file", 
                           "w2x:xed/main-styled.xed");

SaveStep saveStep = new SaveStep("save");
processor.stepList.add(saveStep);

processor.parameterMap.put("save.indent", "yes");

processor.process(inFile, outFile, /*progress monitor*/ null);

• Compile Embed2.java by executing “ant” in w2x_install_dir/doc/manual/embed/.
• Run “ant tembed2” in w2x_install_dir/doc/manual/embed/. This creates w2x_install_dir/doc/manual/embed/tembed2.xhtml.

Extension points

Custom conversion step

The stock conversion steps are: com.xmlmind.w2x.processor.ConvertStep, DeleteFilesStep, EditStep, LoadStep, SaveStep, TransformStep.

A custom conversion step may be implemented by deriving abstract class com.xmlmind.w2x.processor.ProcessStep. Such task poses no technical problems whatsoever. Suffice for that to implement a single method: ProcessStep.process.

See reference of class com.xmlmind.w2x.processor.Processor.

Custom image converters

Image converters are used to convert images having a format not supported by Web browsers (TIFF, WMF, EMF, etc) to a format supported by Web browsers (SVG, PNG, JPEG).

Image converters are specified by interface com.xmlmind.w2x.docx.image.ImageConverterFactory. XMLmind Word To XML ships with 4 classes implementing this interface:

com.xmlmind.w2x.docx.image.ImageConverterFactoryImpl

Image converter factory used to convert TIFF images to PNG or JPEG.

com.xmlmind.w2x_ext.wmf_converter.WMFConverterFactory

Image converter factory used to convert WMF graphics to SVG.

com.xmlmind.w2x_ext.emf2png.EMF2PNG

This image converter factory is available only on Windows. It leverages Windows own GDI+ to convert EMF (in fact, Windows metafiles of any kind, including WMF) to PNG.

This is not that great because, unlike above WMFConverterFactory which converts WMF (Windows vector graphics format) to SVG (standard vector graphics format), EMF2PNG converts a vector graphics format to a raster image format. However, having EMF2PNG is better than nothing at all.

EMF2PNG has one parameter called resolution. Its value is a real number expressed in Dot Per Inch (DPI). The default value of parameter resolution is 0.0 (see below).

The resolution parameter specifies the resolution of the output PNG file. 0 means: same resolution as the one found input EMF/WMF file; a positive number means: use this value to override the resolution found in the input EMF/WMF file; a negative number means: use specified absolute value but only if this absolute value is greater than the resolution found in the input EMF/WMF file.

com.xmlmind.w2x.docx.image.ExternalImageConverter

This image converter factory executes an external program to perform the conversion. See Specifying an external image converter.

If you want w2x to support more image formats, you’ll have to create your own ImageConverterFactory and register it with w2x using method ImageConverterFactories.register.

See reference of package com.xmlmind.w2x.docx.image.ImageConverterFactories.

Specifying an external image converter

Examples of W2X_IMAGE_CONVERSIONS specifications (see Controlling how image files found in the input DOCX file are converted to standard formats):

• Convert EMF to SVG using OpenOffice/LibreOffice:

  .emf.svg soffice --headless --convert-to svg -–outdir %~po %i 
  

• Convert EMF/WMF to PNG using ImageMagick:

  .emf.png.wmf.png magick convert -density 288 "%I" -scale 25% "%O"
  

The command executed by an external image converter may contain the following variables:

The following modifiers may be applied to the %I, %O, %i, %o variables:

Also note that “%%” may be used to escape character “%”. More generally, just like in an URL, an %HH UTF-8 sequence may be used to escape any character. Example: “%3B” is “;” (semi colon), “%C3%A9” is “é” (“e” with acute accent).

Controlling how image files found in the input DOCX file are converted to standard formats

Conversion of images found in the DOCX file (TIFF, WMF, EMF, etc) to standard formats (SVG, PNG, JPEG) may be controlled using environment variable (or Java™ property) W2X_IMAGE_CONVERSIONS.

The default value of this variable is (all specifications on a single line):

.wmf.svg java:com.xmlmind.w2x_ext.wmf_converter.WMFConverterFactory;
.tiff.png java:com.xmlmind.w2x.docx.image.ImageConverterFactoryImpl

On Windows, the default value of W2X_IMAGE_CONVERSIONS is (all specifications on a single line):

.wmf.svg java:com.xmlmind.w2x_ext.wmf_converter.WMFConverterFactory;
.emf.png.wmf.png java:com.xmlmind.w2x_ext.emf2png.EMF2PNG resolution 0;
.tiff.png java:com.xmlmind.w2x.docx.image.ImageConverterFactoryImpl

The syntax of W2X_IMAGE_CONVERSIONS is:

specifications -> “-” | specification_list

specification_list -> specification [ “;” specification ]+

specification -> “+” | image_conversion

image_conversion -> extensions S ( java_image_conversion | external_image_conversion )

extensions -> [ “.” input_file_extension “.” output_file_extension ]+

java_image_conversion -> “java:” fully_qualified_java_class_name parameters

parameters -> [ S parameter_name S possibly_quoted_parameter_value ]*

external_image_conversion -> command_line

About this syntax:

• “-” means: no specifications; hence no image conversions at all.
• “+” means: insert default value of W2X_IMAGE_CONVERSIONS at this point. Example:

  set W2X_IMAGE_CONVERSIONS=.emf.png magick convert %i %o;+
  

  where default value of W2X_IMAGE_CONVERSIONS is (on Windows):

  .wmf.svg java:com.xmlmind.w2x_ext.wmf_converter.WMFConverterFactory;
  .emf.png.wmf.png java:com.xmlmind.w2x_ext.emf2png.EMF2PNG resolution 0;
  .tiff.png java:com.xmlmind.w2x.docx.image.ImageConverterFactoryImpl
  

• Note that the image conversion specifications are considered in the order of their declarations in variable W2X_IMAGE_CONVERSIONS. In the case of the above example, it’s custom “magick convert %i %o” which is used to convert EMF to PNG and not stock “java:com.xmlmind.w2x_ext.emf2png.EMF2PNG resolution 0”.

Limitations and implementation specificities

The Convert step does not support the following MS-Word features.

By “does not support”, we mean that w2x will not generate something useful corresponding to such features. We don’t mean that using such features in a DOCX file would cause w2x to fail or to generate invalid XML documents.

• Right to left scripts.
• Enclose characters.
• Asian layout.
• Cover Page. Blank Page.
• Text wrapping of tables and pictures other than the simplest one.
• Picture formats other than GIF, PNG, JPEG, BMP, TIFF and WMF are not supported. EMF pictures are supported only on Windows.
• Clip Art. Shapes. SmartArt. Chart.
• Header. Footer. Page Number.
• Japanese Greetings. Text Box. WordArt. Drop Cap.
• Object.
• All features related to Page Layout except (to a minimal extent) page and column breaks and end of sections.
• All features related to Mailings.
• All features related to Spelling & Grammar, except of course the various languages used in the document (i.e. lang attribute).
• Comments.
• All features related to Change Tracking.

  When a DOCX file contains revision info (i.e. "Track Changes"), w2x implements its own, automatic, very crude, interpretation of "Accept All Changes". That's why, a warning is issued informing the user that she/he would better use MS-Word to manually accept or reject the tracked changes before submitting the DOCX file to w2x.

• All features related to (document) Compare, (document) Protect.
• Macros.
• Controls.

The Convert step generates XHTML+CSS documents having the following specificities:

• Tab stops are converted to <span class="role-tab"> </span>. See About tab stops.
• MS-Word document properties having no standard meta equivalent are given names starting with “ms-”. Example:

  <meta content="Hussein Shafie" name="ms-cp-lastModifiedBy" />
  

• MS-Word “styles” having no CSS equivalent are a given a “-ms-” prefix. Example:

  .p-Heading3 {
      -ms-outlineLvl: 2;
      color: #4F81BD;
      font-family: Cambria;
      ...
  

• Page breaks are translated to <?break-page?>. Column breaks are translated to <?break-column?>. End of sections are signaled by <?end-of-section?>.
• WMF pictures are converted to SVG.
• OpenXML math, for example