Re[2]: PDF vs HTML (Act II)

Subject: Re[2]: PDF vs HTML (Act II)
From: Arlen -dot- P -dot- Walker -at- JCI -dot- COM
Date: Tue, 23 Apr 1996 09:34:00 -0600

Perhaps I misunderstood what Netscape told me - which was that you
get to some fixed point of RAM and won't need more, despite the
number of plug-ins you have. Plug-ins are definitely cheaper than
running helpers.

This might be true, but Netscape is demanding more than 8 MB of RAM (my
current setting is 10MB, but the insufficient one was less than 8) for me
right now. I haven't added many plug-ins since Shockwave, so I don't know if
more RAM will ever be required after this point.

I'm not up on the technical details of Netscape's plug-in technology, but
the plug-ins vs helpers issue would depend a lot on how much overhead an
unused helper is taking up. It would seem quite possible that a batch of
plug-ins would create more overhead than a single helper app would. How
many is a "batch?" I wouldn't have any idea where the optimum point might be
in that particular continuum.

Is this true of Acrobat?

Probably.

You didn't respond to the seamlessness issue. Do you conceed this
point?

I haven't found *anything* off my computer's desktop to be *completely*
seamless. Netscape and Acrobat included. :{>}

The point about the Netscape vs MS and the extra "features" coming isn't
about plug-ins, nor about how worried Netscape is or should be. It was and
remains that the two browsers *right now* cannot read the same pages and be
guaranteed to produce readable results, much less similar results. And
there's been no indication that this trend will do anything other than
accelerate as they try to outdo each other in the browser arena.

Then our disagreement revolves around to what _extent_ the future of
technical communication revolves around malleable information
display.

And around how much of the TC field is involved in producing documentation
that can be useful over the net. Maintenance manuals, for example, have
limited applicability over the net, as few sites have the luxury of
positioning net boxes near every piece of machinery in a manufacturing
plant.

As for database publishing: that sort of thing can be done as easily with
Acrobat and some good scripting as it can via HTML. Yes, it looks wonderful
to have the script which builds the HTML page execute when someone wants the
page. But it gives no better result than a script executed after revising an
entry in the database, and that script will only need to be executed once,
as opposed to the constant re-executions of the scripts in your examples.

My part in this has never been to demonstrate that PDF is perfect, or that
it's the only (or even always the best) way to publish material that belongs
on-line. My personal expectation is that it will prove far more stable over
the immediate future than HTML will be, but that's mainly grounded in
pessimism over how MS turns communications in every arena it enters into
babble so that it can turn a profit from making communication simpler (but,
unfortunately, never as simple as it was before they came along). This
pessimism is hardly something that can be objectively demonstrated, and I
know better than to try. (BTW, when MS produces an Acrobat clone, I'll be
just as pessimistic about PDF as well.)

Put the documents in the place and in the format that makes the most sense.
The question to be answered is not "What format is absolutely best?" nor
even "What format is the wave of the future?" These questions are no more
relevant to technical communications than Word vs AmiPro or Frame vs
Interleaf vs Quark vs Pagemaker. Our first concern is not for the people we
will be communicating with next year; it should be for the poeple we are
trying to communicate with today. The *real* question is "What format
reaches the people this particular information needs to reach with maximum
clarity and minimum bother?" And that question can *never* be properly
answered in the general case.

Speaking generally, I prefer Acrobat to HTML as a more robust and
communications-freindly medium. It's just not possible today to create a
well-organized and designed manual which reads that way in every HTML
browser. That having been said, there are still areas where using HTML for
your presentation makes more sense, and in those areas I will use HTML.

Have fun,
Arlen
Chief Managing Director In Charge, Department of Redundancy Department
DNRC 124

Arlen -dot- P -dot- Walker -at- JCI -dot- Com
----------------------------------------------
In God we trust; all others must provide data.
----------------------------------------------
Opinions expressed are mine and mine alone.
If JCI had an opinion on this, they'd hire someone else to deliver it.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Post Message: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
Get Commands: LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU with "help" in body.
Unsubscribe: LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU with "signoff TECHWR-L"
Listowner: ejray -at- ionet -dot- net


Previous by Author: Re: Re. Nonstandard HTML
Next by Author: Re[2]: Nonstandard HTML
Previous by Thread: Re: PDF vs HTML (Act II)
Next by Thread: Re: Re[2]: PDF vs HTML (Act II)


What this post helpful? Share it with friends and colleagues:

Sponsored Ads


Sponsored Ads