Working with template systems (as opposed to individual templates) requires attention to detail and planning before execution. The rewards of planning come from ease of maintenance, and flexibility to change. The blog looks at formatting and design questions in Document Assembly system.
A raw Word document is a document assembly program. Forget about HotDocs or GhostFill codes. It is a set of instructions to the computer to take a text string and convert it formatted and printable text. Under the hood in a word document are a series of tags, paragraph objects and instructions on how to format them. An understanding of those structures and how they work is fundamental to being a good document assembly programmer.
Defining the terms:
Paragraph Style: These styles define the base format of a particular paragraph. They can cascade, be based on named paragraph styles, inheriting their properties, or stand independent.
Character Styles: These styles are “variations” off the underlying paragraph style. View them as switches. For example, if you base paragraph text is bold, and you choose to “bold” a word in that paragraph, it will actually unbold. You can name and apply character styles.
Normal Style and WYSWIG: Most Word users depend on the normal style and hand markup their templates. This is like taking a pen or paintbrush to a blank canvass. In the hands of an artist, the result is a unique piece of work. In most others, it is a mishmash of inconsistent instructional codes. When combined with document assembly, the result is often a mess.
How to Plan a Word Document
If you view a word document as a “program”, instead of formatting text, you begin to view a series of “objects” which can be programmed. Word lets you create a style sheet. Any web developer knows about Cascading Style sheets. If you look at the “html” tag when you bold a word you will see < b > and < / b >. The effect of the “b” can be defined to be bold or something else entirely.
In reviewing you word documents, you can abstract most documents into a dozen or so defined styles. My rule of thumb is that every formatting option in a document (or family of documets) must be formatted with a defined and named style. And better, these styles must be based on a base style, so that changes to that base style can “cascade” into the other dependent styles.
Benefits of Cascading Styles
You may ask why all this work for a simple document? The answer is seen when it comes to changing the styles. On an ad hoc basis, I can open the Style Editor, change the base style from “Time Roman” to “Arial” and the entire document is updated. Alternatively, I can change the “em” character style form “underline” to “italic small caps”. This is done in a matter of seconds, rather than hours. I can also run a macro to search for “em” tagged phrases, and add them to a document index.
Now the real fun comes in document assembly, where you wish to use the same document, but display it in different formats depending on the jurisdiction or some other rule based criteria. Here, in HotDocs, you can run a macro to “Add a Style Template” to the document that contain a different set of defiinitions for the exisiting named styles. If all your formatting is stored in named styles, then this instantly transforms your document. In GhostFill, there is a templates-set command that achieves this end, without the use of a macro.
In at least one case, I went even farther. Rather than having a separate template for each family of formatting options, we embedded document assembly codes in the very “RTF” template that contained the formatting definitions; it was pre-assembled as a Text File, and then used as an RTF file to provide formatting.
The benefits are clear. All document assembly projects could benefit from following such planning guidelines.