Many technical communicators speak of Microsoft Word in hushed tones and with a shiver down their spine, its quirks and inefficiencies often resulting in late nights and low-quality documentation. However, there are some circumstances in which it is necessary to provide documents in Word format, whether that is to adhere to regulations or to ensure that customers can access the file in a recognisable format.
Producing content directly in Word has a number of drawbacks. Communicators can expect to spend a third of their time on formatting, and the rest of it on maintaining and re-using content and templates in a tool which isn’t designed to do either. As a result, documentation takes longer to produce and is of lower quality.
Professional technical communicators responsible for producing content use tools such as MadCap Flare that enable single-sourcing, and output content to multiple different file types to provide greater flexibility.
By using a tool like Flare you get your Word document and much more besides.
Technical communicators use single-sourcing methodologies to produce outputs in various different formats using the exact same content. These output types can include not only PDF and Word documents, but also Online Help, responsive HTML sites and knowledge bases. But these different formats have their own eccentricities which make this a trickier task than first meets the eye.
Having produced Word output from Flare for a number of projects, we came across a few of these eccentricities and learned how to overcome them.
Flare is most commonly used to output to PDF and online targets such as HTML5 Help and Responsive Help.
Flare uses a topic-based approach to documentation, breaking down a single document into many reusable pieces. This facilitates single-sourcing and online-first methodologies, and encourages communicators to produce more succinct topics.
Because of this, it is better in most circumstances create and maintain content in Flare before publishing to a Word document, rather than creating that content directly in a single Word document.
But changing from PDF to Word output did involve modifying our existing content slightly, and adding a few target-specific elements.
Differences of Word output from Flare
Word targets have the following differences from the standard PDF output type:
- Different support for Page layouts – Flare 11 allows Word targets to use Page layouts like PDFs, but there are differences in which features are supported. Decoration and Image frames are not supported, and only one Body frame can be used per page. As an example, we use Decoration frames to provide a Draft stamp, which then had to be removed for our Word layouts.
- No support for images in CSS – Where the CSS specifies a background image for a particular style, this image won’t be printed in Word output. We use background images in our styles for safety notices, so had to find a work-around for this involving snippets.
- No support for image hyperlinks, image maps or embedded videos – Whereas PDF targets can have these interactive media embedded, and it is often assumed they will be read on-screen, Word outputs are still designed primarily as a printed medium. Communicators need to find ways around these differences between printed and on-screen outputs, either by rationalising the use of such features, or using Flare’s Conditional tagging feature to exclude certain content from certain outputs.
- No support for vector graphics – Vector graphic file types such as SVG and EPS can offer greater image quality than raster images- if they are supported by the output type. In Word, they are not rendered as vector graphics, and we lose image quality.
To work around these differences between Word and PDF targets, we had to design Word-friendly Page layouts and Stylesheets which produce content identical to the PDF output, but which work differently in the background.
We also had to alter our graphical content to make sure we could still make use of Flare’s powerful single-sourcing capabilities.
Once the new Page layouts and Stylesheets are in place, producing Word output from Flare is far quicker and easier than producing a Word document directly in a word-processor.
If what is required is a Word output then the time-saving and quality benefits of single-sourcing content, plus the ability to publish this same content online, make this approach far better option for both producing and managing technical content.