TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Editorial Against PDFs (long) From:Tim Altom <taltom -at- IQUEST -dot- NET> Date:Thu, 5 Mar 1998 20:49:20 -0500
>
>This brings up a very good point. PDF is a pretty crummy way to
>publish electronic documents. It's cumbersome and it doesn't really
>DO all that much for all the time and space it occupies.
>
>However, I don't see PDF as an electronic publishing technique. I see
>it as a delivery technique. It's quick (remember how long it takes to
>deliver actual hard copy?), it's relatively easy for all concerned,
>and you can print it on non-Postscript printers.
>
>And I wouldn't worry too much about someone who is pathetic enough to
>not only allow some hack columnist to express his or her opinions for
>him/her; but to stay anonymous to boot. What a dinkus.
>
I'm afraid I don't agree that PDF is crummy. It fits neatly into a space
midway between HTML and true multimedia/hypertext.
HTML isn't capable of maintaining formatting, it depends too much on the
browser brand, and, worst of all, it can be hacked by anyone. It comes in
lots and lots of pages, rather than one single file. It's awful to
transport except over a wire. And its graphics choices are limited
(practically) to only two formats. Graphics can't be embedded, so they have
to be pushed into the transport pile too.
PDF does lock out the user, but there are several good reasons for
rendering our manuals inviolate, chief of which is legal liability for
them. Next is consistency...try talking to someone on a help desk when
you're using dissimilar manuals. Users _shouldn't_ be tinkering with their
manuals. It's the same reasoning for programmers not releasing source code.
Granted, PDF isn't really print and it isn't really hypertext, and I
wouldn't recommend it as a help file (at least partly because it can't be
made context sensitive). But when you have to beam a manual along a wire or
get by with a bargain-basement printing method, PDF is wonderful. It's
cheaper than paper, more compact, and simpler to use in long documents
because it has hyperlinks. Yet it's loads cheaper and simpler to produce
than real hypertext like WinHelp, albeit much less capable of doing tricks.
Still, PDF has its place.
Tim Altom
Vice President, Simply Written, Inc.
317.899.5882 (voice) 317.899.5987 (fax)
www.simplywritten.com
Creators of the Clustar Method (TM)
An out-of-the-box methodology for fast task-based documentation
that's easy to port to paper, WinHelp, Acrobat, SGML, and other media.
