Re[2]: HTML v. Acrobat (was Electronic File Transfer)

Subject: Re[2]: HTML v. Acrobat (was Electronic File Transfer)
From: David Blyth <dblyth -at- QUALCOMM -dot- COM>
Date: Tue, 12 Mar 1996 10:58:03 -0700

To continue the running discussion....

dblyth>>The customer gets what they need a lot faster

Arlen> You've obviously not visited some of the web pages I've been forced to
Arlen> endure in order to get information. ;{>}

Alas, I probably have. ;) Sigh. But PDF also downloads slowly - at
least on a Mac - on _each_ Acrobat page.

dblyth>>The customer can link to other useful applications or functions
dblyth>>(not provided by Acrobat) without increasing overhead.

Arlen>I've not tried this (yet) but Adobe has an Acrobat Plug-in which links to
Arlen>URL's on the web, so this capability may already be here.

I whole-heartily endorse Adobe Amber. It's a good plug-in to an umbrella
application (the browser).

>Besides, I'm wondering what the effects of Internet-related OpenDoc parts
>may have on all this (Cyberdog is one example of this). It could easily
>end up that the choices will not be "either/or" for a given document, but
>rather "both/and."

I agree. But again, these events are browser-driven. The browser has
become an operating system to the Internet. Not Adobe Acrobat.



David (The Man) Blyth
Technical Writer & Web Site Designer
Qualcomm

The usual disclaimers apply - I don't speak for QUALCOMM, they don't speak
for me....


Previous by Author: Re: HTML v. Acrobat (was Electronic File Transfer)
Next by Author: Zippy, no sig.
Previous by Thread: Re[2]: HTML v. Acrobat (was Electronic File Transfer)
Next by Thread: Re: Making Manuals User Friendlier


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


Sponsored Ads