Getting attractive PDF output out of XML is a serious technical challenge. But in some organizations, the PDF requirement is being used to prevent to unwanted workflow changes.
(Keep in mind that nearly everyone I talk to has reached a point where bringing in a consultant is looking like a Good Idea. I don’t often hear from the people who are happily chugging along and don’t need any changes.)
Among content professionals, especially those who began work in a print-primary world (that’s code for “over 40”), there is great appreciation for pages that are copy-fitted, use proper typographical marking (en dash, em dash, ellipsis), and avoid sins such as awkward hyphenation, lines that contain only a word fragment, and unbalanced headings.
I am one of those people. I began my technical communication career as a production editor, so my primary responsibility was to manage proper document formatting for print. I was not responsible for content, which is fortunate because I didn’t have any useful domain knowledge. Instead, I focused on what Michael Müller-Hillebrandt calls the technical quality of the files—correct application of templates, correct management of exceptions, balanced pages, and the like.
Unfortunately for us print snobs, the world is moving in a different direction. The content priorities are:
- Visible to Google
- Produced quickly and efficiently
These requirements point toward an XML-based workflow.
Some technical writers are exploiting stringent PDF requirements as a bulwalk against change. They argue that the current standards for print/PDF production must be met or exceeded in any new workflow. This is generally code for:
I don’t want change and I definitely don’t want XML.
XML-based workflows tend to emphasize speed and formatting automation, both of which reduce costs. There is also an assumption that the reader prefers reasonable formatting today over pristine formatting next month.
In our work, it is important to distinguish between legitimate PDF requirements and obstructionist barricades. For example, the following are some typical legitimate requirements:
- Regulations or industry standards. For example, typical safety warnings have a standard look and feel. It would be unwise to replace the exclamation mark inside a triangle with a pink unicorn.
- Corporate identity or branding concerns.
- Audience needs or expectations. An audience that cares about typography (such as technical communicators!) may require closer attention to formatting quality than the general public.
- Market requirements. If the market demands pristine print/PDF and the product won’t sell without it, then stellar formatting is the way to go.
More often, though, what we find is closer to “that’s the way we’ve always done it.” The tech comm group refuses to compromise the PDF formatting. Ironically, the established formatting is often…less than attractive. Worse, we find out that the organization is deferring features that customers want because of the resources required to produce the PDF.
I suspect that this devotion to PDF has more to do with our needs as writers than with our readers’ needs. In the olden days, a technical writer produced a book. Occasionally, a team of technical writers might jointly produce a book; in that case, each technical writer typically owned a chapter. Today, a writer might contribute a few topics to a help system, update some wiki pages, and create content for the corporate web site.
The power of PDF, like print, is as an artefact of the writing process that is self-contained and seems less emphemeral than some of the other deliverables. It’s hard to claim a wiki page for your portfolio when it was updated and rewritten by someone else a week later.
Once again, we have to look at the organization’s business requirements. What sort of output formats are needed most? What’s the best way to create those output formats? What sort of PDF can we produce and at what level of effort? The battle for workflow change is won or lost in the planning stages when the requirements are determined. If the pro-PDF forces succeed in inserting “PDF identical to what we produce today” into the initial requirements, your options are going to be seriously limited.
Your requirements should reflect your regulatory requirements and your users’ needs—not authors’ personal preferences.
Obligatory disclaimer: Like last week’s post on tech comm versus tech support, this post describes a common organizational pattern and not any specific company.