Re: Using FrameViewer to deliver docs

[Dan Emory <danemory@xxxxxxxxxxxx>]

At 11:50 AM 4/9/99 -0700, Robin Whitmore wrote:
FrameViewer is not free. If you are distributing the docs to many users,
you'll have to set up an OEM agreement with Adobe. The last time I heard
(about 18 months ago) they were requiring $50,000, payable at the time the
agreement is signed, which would be applied against license purchases over
the period of the agreement. You might be able to get the unit cost of a
license down to about $30.00 under such an agreement. Based on the foregoing
requirements, however it would appear that Adobe isn't interested in making
any OEM agreement that doesn't involve thousands of FrameViewer licenses.
There was, 18 months ago anyway, an alternative method whereby you could buy
FrameViewer in packs of 100, but the price was sky-high.

Also, you would need an iron-clad guarantee from Adobe that the FrameViewer
product will be avilable on all of the platforms where you need it, and
that, when the next major release of FrameMaker comes out, either the
current version of FrameViewer will be compatible with it, or that a new
version of FrameViewer will be released by Adobe concurrent with the new
FrameMaker release. This kind of guarantee is needed because there is a
strong suspicion that Adobe is tempted to discontinue FrameViewer as they
did FrameReader (the free version). In fact, the for purchasing FrameViewer
as described in the first paragraph above are much harsher than they were
before Adobe purchased Frame Technology, and there's a suspicion that those
new terms are intended to discourage people from using it, so that there is
not a large installed base out there to howl when the product it
discontinued. Adobe's first-line solution (PDF) will be offered as a
substitute in that case, but if the installed base is using link types other
than those supported in Acrobat, they'll be out in the cold. 

FrameViewer also comes (or used to, anyway) with a catalog option for
implementing full-text search and retrieval. It's not, however, very
user-friendly.

FrameViewer, in my opinion, is superior to PDF/Acrobat in the following
ways:

1. It's much easier (or at least is was) to develop a context-sensitive API
client that displays the relevant page of a Frame file in response to a
context-sensitive help request. The Frame files can be installed on a
network file server, or on the individual platforms. You will need to
explore with Adobe, the current capability to develop such an API client
that will work on a network, as it used to, using remote procedure calls.

2. As you mentioned, the link types (e.g., popups, matrixes, messages to
other applications) available in FrameViewer are far more robust than in
Acrobat.

3. All the headaches associated with conversion to PDF are eliminated. If a
document reads OK and the links all work in FrameMaker, it's guranteed to
work the same way (including the viewing quality of all graphics) in
FrameViewer, provided the relative or absolute paths remain the same for the
graphics and the external links.

4. If you use conditional text in the Frame docs, you can implement an API
client that allows the end user to select which text is shown or hidden when
the document is displayed in FrameViewer. This would allow you to implement
a method where the displayed information is determined by the competency
level of the end-user, the spoken language of the end-user, or any other
criterion you might like to use.

There are, however, some drawbacks:

1. Since fonts are not embeddable in Frame documents, you must restrict the
Frame docs to fonts that are certain to be available on all platforms where
the software installs, otherwise, font substitution will occur.

2. If you use imported graphics, they will probably have to be imported by
reference, else the Frame documents will become so large that they will take
too long to open. Consequently, you must import them by reference. That
means the relative or absolute paths to those graphics must be preserved on
all platforms. The same goes for any text insets that are imported by reference.
============================================================================== 
>(I tried to find answers in the Framer's archive, but it doesn't seem to be
>working at the moment, so please forgive me if this has already been
>discussed.)
>
>I am writing user manuals for Java-based e-commerce software. The software
>will be sold as separate components that form a suite. For this reason, the
>docs also need to be "componentized." We have also decided that the docs
>will be provided in electronic version with the products. If a customer
>wants a printed version, they will be charged extra. We also will provide
>online help for step-by-step procedures done in the GUI.
>--------------------Snip
     ====================
     | Nullius in Verba |
     ====================
Dan Emory, Dan Emory & Associates
FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Voice/Fax: 949-722-8971 E-Mail: danemory@primenet.com
10044 Adams Ave. #208, Huntington Beach, CA 92646
---Subscribe to the "Free Framers" list by sending a message to
   majordomo@omsys.com with "subscribe framers" (no quotes) in the body.


** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **