The PDF roadblock
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.)
In my 2011 tech comm predictions and recent trends webcast, I discussed a schism between factions of content creators. With PDF, I’m seeing a growing gap between audience and authors.
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
- Up-to-date
- 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.
About the author
Larry Kunz
Well said, Sarah. Much of the time, PDF stands for “Please Don’t Futz” with the way we’ve always done it. Or words to that effect.
Given that, how can we — the enlightened consultants — engage the customer about what their *real* requirements are, without offending them?
Ben
I agree; excellent post!
It seems to me that getting attractive PDF out of XML is only a serious technical challenge because things like typesetting and text flows are for the most part inherently complicated.
Also, I think it might be more accurate to say that getting attractive PDF out of DITA is a serious technical challenge. It’s much simpler (and these terms are all relative of course) to produce professional-looking PDF using the DocBook stylsheets than the DITA-OT. With DB, most tech com departments can produce PDF by setting a number of standard parameters. While some would still consider that to be a “significant technical challenge” it’s still much easier than hacking the DITA-OT.
Sarah O'Keefe
@Larry: For me, a laserlike focus on business case seems to do the trick. Doesn’t necessarily win me any bonus points with recalcitrant writers, though.
@Ben: What I’m hearing quite a lot is along the lines of, “I want my files to look EXACTLY the way they look today in unstructured FrameMaker.” And there are some things that are easy to do in unstructured FrameMaker (mixed columns on a page) that are basically impossible in XSL-FO. So then the question is just how important is that precise look and feel or is a reasonable approximation acceptable? The concerns about the technical difficulty of FO implementation is secondary — we’re still arguing about the baseline formatting requirements. And it’s my opinion that a few writers are choosing to emphasize things that FrameMaker does well in an effort to prevent anyone from taking FM out of their workflow!
Don Day
If there were one reasonable bit of rationale that I could inject into requirements before I get them, it would be “Recognize that favoring PDF also means increasing your production maintenance costs over time (ie, changing styles or branding, removing your patches as new updates of XML tools solve them, revising the perennial logo placement requests by marketing, training new production staff in running/maintaining the build integration code, and so on).”
Sarah O'Keefe
@Don: Or, in short: “PDF is expensive.” 🙂
Alan Houser
I can agree with this perspective:
You’ve been publishing in PDF. However, PDF may not be optimal for meeting your on-going business requirements, so you should re-consider it as an output format.
However, I see this just as often from DITA consultants:
You’ve been publishing in PDF. However, in this hot new architecture I’m trying to sell to you, PDF publishing is really hard. So maybe you shouldn’t do it.
The former is fine. The latter? Sad.
Sarah O'Keefe
@Alan: That’s an “interesting” way of looking at the problem. To me, the business issues need to come first. DITA for the sake of DITA doesn’t really make any sense…
Kai
I frequently meet or hear of people who can’t let go of PDF, and they may be writers, managers or customers. One way to sway them is basically the old “take over the armrest when flying economy” trick, that is, starting from the back and inch by inch:
1. Start by offering online documentation, too, if you don’t have it already.
2. Muster any argument you can find that online is really preferable, for customers, for efficiency, for cost, whatever.
3. Slowly shift the balance towards online, reassuring that “we’ll always still have PDF”.
4. Hang PDF out to dry and see how many people miss it.
Mike Starr
Just finished an assignment (budget took me off) where the documentation is XML in structured FrameMaker with the FrameMaker book as linked source for webhelp output from RoboHelp. Once the appropriate template is completed, both excellent PDF output from FrameMaker and webhelp output from RoboHelp will be pretty much single-click easy.
On my current assignment, I’m working on a user manual in Word, producing beautiful PDFs with Acrobat Professional and also linking the Word document to RoboHelp for single-sourcing webhelp from the same content.
Mike Starr
Kai… why hang PDF out to dry if it’s easy to produce? Do those pixels cost extra? If my workflow allows me to single-click create both PDF and webhelp what’s wrong with that? If some of the users want to be able to print out the documentation and review it while riding the subway or whatever, I’m all for it.
Kai
Good point, Mike! And I don’t think it’s necessary to get rid of PDF if it’s easy and cheap enogh to produce. I guess I just wouldn’t spend a lot of money or time to improve it… For example, if you’re using Flare, you can define a PDF target once and just continue to publish that. If it does the trick, there’s probably no reason to abandon it. 🙂
Debbie
I think there could be some happy medium. I’m not looking for mixed columns on a page or gradient fills in table heading rows but I would like something that didn’t look like someone’s first attempt at page layout using Microsoft Publisher. PDFs still have value. It’s hard to read online help on a subway, hard to print it out in a useful way.
Walter
The requirement for PDF often derives from needs for printing content that’s based on multiple topics and for portable content. Some customer environments are prohibited from external network connections and service staff must bring documentation (PDF) with them. Also, the requirement for PDF as good as it is now from XML is a far cry from PDF that has good content, titles, tables, and basic font styles. Pretty-good PDF is much easier/cheaper.
seo
Do you mind if I quote a couple of your posts as long as I provide credit and sources back to your weblog? My website is in the very same area of interest as yours and my visitors would certainly benefit from a lot of the information you present here. Please let me know if this ok with you. Many thanks!