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:PDF vs. HTML From:David Blyth <dblyth -at- QUALCOMM -dot- COM> Date:Tue, 15 Oct 1996 22:52:01 -0700
>I could spend a lot of time and effort debating the first six words above,
>because I flat-out think they're bogus, and that their bogosity(?) should be
>obvious to anyone who truly examines PDF technology. David continues to
>repeat them; perhaps Goering had a point. But let's let them pass for now,
>and examine the proposition as if they *were* true.
Feel free to disagree all you want, but there's no need to insult me.
But lest the ghost of Goering shudder, I repeat myself. Check "The Web Page
Design Cookbook", page 547. Refering to HTML translators, W. Horton says
(and I quote exactly).
Translators can help you deliver information until you develop a
bigger, better solution - but translators have their limits. They
merely buttress the existing book-printing model.
That is, translating the source document and making it available
on the Web is like typesetting and printing. In industry, this is
sometimes called a _backend_ process, as opposed to something built
into the main process.
Although the user document may look different, the authoring processes
are pretty much the same - that is both the blessing and the curse of
translators. Their blessing is that they do not disrupt existing
workflows. Their curse is that they discourage developing new
workflows more suited to electronic media.
So, why would you need a new workflow? Perhaps you want to design
_true online information_, not just _books dumped online_. This means
breaking the content into smaller chunks, making the information more
modular and easier to access.
My only contention is that what applies to DTP-->HTML translators
applies exactly to Adobe Acrobat, because you are translating DTP-->PDF.
The Web is not Windows On-line help. HTML is not RTF. We are not in Kansas
anymore (just to be sure Goering gets some more credit.)
>Everyone wants to "define a new paradigm." Except that if you do, and your
>customers aren't there yet, what happens to your customers?
The customers are already there. Netscape is quite profitable and other
companies are cheerfully switching over to groupware intranet. Now.
One independent study by International Data Corporation found that
companies switching over to an Intranet paid themselves back in 6 _weeks_.
(See <http://home.netscape.com/newsref/pr/newsrelease260.html>. I'd
love to read the whole study, but it's apparently not posted yet. They
usually charge for these things.)
>There may indeed come a time when even your toaster has a web interface.
Precisely. I don't worry about whether or not this is a stupid idea. I
merely intend on communicating within this environment.
>There may even come a time when it doesn't take any more effort to create
>professional-quality documentation formatted in HTML than in current DTP
>tools. Neither time is, however, now.
You're right. It's next month. Adobe Pagemill 2.0 is still in Beta.
See also Navigator Gold 3.0.