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: Survey: how do you use PDFs From:Tom Murrell <trmurrell -at- yahoo -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Wed, 9 May 2001 10:16:32 -0700 (PDT)
--- "Brierley, Sean" <Sean -at- Quodata -dot- Com> wrote:
> Hallo:
>
> > -----Original Message-----
> > From: Sandy Harris [SMTP:sandy -at- storm -dot- ca]
> > Tom Murrell wrote:
> > >
> > > Regarding PDFs. I don't like 'em.
> >
> > I agree, though I'd state it more strongly. I detest attempts to pretend
> > PDF
> > is a usable online documentation format. It is a print format which can,
> > at
> > a pinch, be read online.
> >
> Oh, I disagree completely. By formatting your PDFs for the screen, by
> chunking your information appropriately, by using hypertext navigation, by
> creating specific navigation elements in your PDF, and by using features
> that enhance the doc, such as rollovers and pop-ups, PDF can most certainly
> be a very usable and useful online format!
I think you missed my point...and Sandy's. I will concede that if you:
A) Format your PDFs for the screen
B) Chunk your information appropriately
C) Use Hypertext navigation
D) Create specific navigation elements in your PDF
and overall use the features of PDF to enhance the document, it CAN be a
useable document for the user. Problem is that these things aren't done
consistently (I'm tempted to say 99% of the time, but that may be too
subjective). And because these things aren't done consistently, often at all,
PDFs are worthless for online use. You might as well give me a ZIP file (or
compression utility of your choice) and let me unpack it and print it myself.
My gripe with PDFs is, admittedly the way they're created, or rather not
created, with the user, the user's experience, or even the user's needs in
mind.
In fact, looking back over the list above--your list, by the way--it seems to
me that these things aren't done because it's not that easy to do. It's real
easy to run Acrobat and turn a print-designed document into a mediocre PDF. So
we have TONS of mediocre PDFs out there. I don't like 'em. (You'll notice that
I haven't even attempted to discuss the relative merits of other choices being
superior to PDFs. That's not because I can't, but I see no reason to stir the
coals of that old Holy War.)
> > > They're the most difficult things online to read online. Invariably they
> > > arrive fuzzy and poorly sized for the screen. (You can't size things for
> > > every screen with PDF, I don't believe.)
> >
> > I think the error is sizing things at all, rather than leaving to the user
> > and the browser to make it fit an available window.
> >
> I am not sure to what you refer.
>
> If you refer to screen captures, consider the source and the output and you
> will realize the problem lies not with PDF. In brief, a dialog box can be
> resized on screen and display perfectly because a program is controlling the
> look of the dialog box dynamically. A screen capture is a painting, it is
> fixed in time. Screen captures are limited by the resolution of the monitor
> and by the size of what you are capturing, in pixels. Screen elements and
> software are not designed to be documented, so frequently they are larger
> than our text columns and too large for our online Help, PDF, and other
> output media. Resizing screen captures changes the number of pixels in the
> image, or resolution, or both. On screen, a 600x600 pixel dialog box
> comprises 360,000 pixels and, at 96-dpi, is 6.25-inches square. If you take
> a screen capture of that, and resize or resample it, you have to be aware
> that any change in the 600x600 pixel dimensions or 96-dpi resolution
> **will** unavoidably affect how that image displays in a fixed, 96-dpi
> environment. Because, while a program can resize and dynamically refresh a
> dialog box, a screen capture is merely a picture without the dynamics
> available to the software program.
Sean, again I think you miss the point. In fact, you make my point for me.
We're talking about what, if anything, PDFs are good for. Most of the time,
they're no good for online viewing, yet they're touted as the online
alternative (I'm tempted to say superior because so many believers want it to
be so) to HTML. Yet the question we were asked (I'm paraphrasing here) is how
do you use PDFs? Do you use them for online viewing? My answer is "Not if I can
help it, because they suck online."
> > > They're hard to navigate, and everything everybody else says about them
> > > is true, too.
> >
> > Slow to load, twice as large as equivalent HTML file, harder to manage in
> > a revision control system, ...
> >
> Manage the source files for the PDF, not the PDF.
As a user that's not my problem. As a developer of the PDF, that's YOUR
problem. It should be your problem that I don't like PDFs because you do a poor
job of developing them. (Stop. I'm not referring to you, Sean. I'll stipulate
for the sake of the argument that you are a wiz at developing PDFs that are
useful to your audience. Stipulating so, you're one of the few. Judging from
what I see, one of the damn few, if you are.) If you can't use the tools so
that the output is useful to ME, the user. Stop using the tool and telling me
it's a great tool.
> > > I don't like 'em. Don't like 'em at all.
> >
> > > That said, if I have to have the information and the only way to get it
> > is a
> > > PDF, I'll print it out. They usually exist because the developing
> > organization
> > > finds shipping PDFs cheaper than shipping the printed counterpart. They
> > shove
> > > the printing cost onto their audiences. In fact, now that I think about
> > it,
> > > everything about a PDF document seems to be for the convenience of the
> > > developer/developing organization not the convenience of the user.
> >
> If you distribute printed documentation, and the subject of that
> documentation changes, how costly or easy is it to get updated documentation
> to the reader? Do you ship a set of pages with which the reader is supposed
> to replace an existing page set? If so, assuming the pages actually make it
> to the guy with the book, how often does the guy with the book replace the
> affected pages? Or, do you ship a replacement printed book?
>
> PDFs can be conveniently downloaded to replace existing PDF documentation.
> In the case of software, the PDF can be updated automatically as part of an
> upgrade or patch. The capability of updating a book or document set by
> download is very convenient versus the alternative, paper-based solutions.
>
> I am not saying PDF is perfect, or the end-all of electronic documentation.
> I just suggest that those who pigeon-hole it as strictly a print-only medium
> are looking at PDF with blinders on.
Again, you make my point. For whom is the PDF "convenient?" It's convenient for
you, the developer. In the overwhelming cases, PDFs are NOT convenient for me
the user. It doesn't impress me that you are saving your company tens of
thousands of dollars or millions of dollars. That's irrelevant to me, the user.
I have to go through all sorts of contortions to end up learning that the
damnded document didn't even have the answer to my question. But to find that
out, first I have to open the PDF. Oops, I need a new plug-in. More time wasted
while I download it. Now I open the document. Damn, I can't search! And the
writer didn't bother to give me hyperlinks off the TOC or Index. Hunt, hunt.
Search, search. Now, just to throw it across the room in disgust I have to
print it first.
*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available now at http://www.devahelp.com or info -at- devahelp -dot- com
Sponsored by Information Mapping, Inc., a professional services firm
specializing in Knowledge Management and e-content solutions. See http://www.infomap.com or 800-463-6627 for more about our solutions.
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
