[comp.text] ArborText vs Interleaf, FrameMaker

lark@tivoli.UUCP (Lar Kaufman) (12/20/90)

Last week, I received the following email from a representative of 
Arbortext, Inc.  I have examined it and found it substantially worth 
posting.  In my opinion it is too long to post intact with all the 
quotes of my original posting incorporated.  Therefore, I have omitted 
repeating the original posting except where I find the information 
pivotal to understanding this posting.  If you would like to see the 
entire message, send me email and I will forward a copy to you.  All 
original materials from Arbortext have been left intact.  Omissions 
are marked with a string of dots.

I must reiterate that the original posting was a modified internal-use 
document, and that I posted it for informational purposes only, with an
acknowledgement that there might be errors, and that I was expressing 
opinion.  I am pleased to be corrected where I was wrong, and to the 
extent that any errors in fact or opinion  may have caused any distress 
to individuals or corporations, I sincerely apologize.  I emphasize 
that the posting is my responsibility only and not that of TIVOLI 
Systems, Inc.

It is certainly true that had I had the information that follows, I would 
have given Arbortext's products much greater consideration in my report.  
Perhaps the recommendations would have been different.  The Publisher will
be given serious consideration for meeting our continuing documentation 
development requirements.  I regret that I did not know more about 
ArborText, and I assume that if I didn't, perhaps many of you also do 
not know of it.  (I think I am relatively  well, if broadly, informed on 
issues in Unix, publishing systems, and document conversion.) 

The original posting and this response have been posted simply to 
further inform readers and to encourage discussion and sharing of knowledge,
in the best spirit of Usenet.

-lar 

 = = = = (begin enclosure) = = = =

Dear Mr. Kaufman,

Below is a copy of a comp.text newsgroup posting we would like to see
made to update the comparison of FrameMaker and Interleaf.  Our intention
is not to criticize your report, which was well balanced and reasonable.
Rather, we need to correct some inaccuracies regarding ArborText and its
products. Ordinarily we do not respond to postings on the net. Your report,
however, explicitly names ArborText and excludes our products from the very
market we address best.

We wish we had placed information so that you could have found our SGML
publishing products during your survey phase.  We have been written up
in a number magazines and journals, although some tend to emphasize our
TeX connections rather than our SGML publishing. Would you be willing to
accept a phone call from Carole Porter (cmp@arbortext.com), who is our
Manager of Marketing Communications?  She would like to identify ways to
improve our communication to people in situations such as yours.

We would very much like your support in presenting the facts about our
products. If you feel that you could extend your review to include a more
extensive evaluation of The Publisher (based on product literature,
conversations, press clippings, etc.) and post your evaluation as an
addendum to your report, we would be most grateful, and would refrain
from posting our own response.

Jim Salois
Director of Product Marketing
ArborText, Inc.
(313) 996-3566
jfs@arbortext.com

====== BEGIN POSTING ================================================

As a leading developer of SGML publishing software, we were surprised and
dismayed at some of the content in the recent Frame versus Interleaf
comparison. Since we have commercial interests in publishing software,
we do not normally comment on network traffic about publishing software.
In this case, however, we are concerned that inaccuracies about ArborText
are now being propagated throughout the network.

We feel compelled to set the record straight with respect to ArborText,
our products, SGML, and the CALS initiative. For those who are interested
in our SGML and CALS comments and disinterested in our product comments,
you may search this text for the information which is tagged <SGML> and/or
<CALS>.

Jim Salois
Director of Product Marketing
ArborText, Inc.
(313) 996-3566
jfs@arbortext.com

For the record:

    ArborText, Inc. has been and continues to be our company name.

    We have two lines of business:

    	SGML publishing software -- based on our system, The Publisher,
			and its variants CALSPublisher, SGMLPublisher, and
			SGMLEditor.

	TeX Software -- TeX, DVI, and Preview utilities for a wide variety
			of platforms.

Specific comments are made below in the context of Mr. Kaufman's report.
A number of passages have been omitted to reduce the length.

  [lk> The following report is edited for reasons of confidentiality and 
  [lk> fairness, and no warranty of accuracy or professional expertise is 
  [lk> implied or expressed; because of time limitations, there are likely
  [lk> some inaccuracies.  It is supplied solely for those curious about 
  [lk> factors that affected our decision to purchase a particular set of 
  [lk> documentation tools, because of requests for such information from 
  [lk> usenet readers.  The author does not claim to be totally unbiased, and 
  [lk> this report is offered as my opinion only.
  [lk> - Lar Kaufman 12/5/90

 .............

The Publisher is a publishing system for UNIX workstations. (DEC, HP/Apollo,
and Sun). It supports a full array of standards including X11, SGML text,
IGES and CGM graphics, and Postscript output. The Publisher supports both
SGML markup and full WYSIWYG views into documents. 

<SGML>
Of the products listed in Mr. Kaufman's report, only The Publisher and
Author/Editor use SGML as their native markup.
</SGML>

ArborText uses SGML not just for text, but for tables and equations as
well. Publisher graphics and output formats also conform to standards,
official or de facto: for graphics, TIFF, EPSF, and X11 bitmaps are currently
supported with IGES, CCITT Group 4 and CGM support available early next
year; for output, PostScript.  As for UI/GUI, The Publisher is a well-behaved
Athena-based X11 application.  Support for both OpenLook and Motif are
forthcoming.

 .............

The formatting engine shipped with The Publisher is a TeX-based engine,
though some customers are applying their own formatting engine to the SGML
documents they produce with The Publisher. As those familiar with TeX know,
the quality of the typography and the degree of control offered by a TeX
based engine rivals some of the best high-end dedicated typesetting engines.

 .............

The Publisher features a universally praised WYSIWYG Equation Editor.
Over 500 symbols are offered including the AMS-TeX symbols. Formatting of
mathematics is based on the TeX engine, acknowledged for its excellence in
typesetting math. Equations are also stored as SGML, making them portable
to other SGML compliant systems.

 .............

The Publisher supports a multilevel undo (to last save operation).

 .............

ArborText distributes the Island Graphics' Paint and Draw programs with
The Publisher. The Publisher's OpenLink graphic interface allows other
[UNIX based] graphics editors to be used within The Publisher.

<CALS>
CALS requires graphics transmission in IGES, CGM and CCITT Group 4 format.
</CALS>

The Publisher will support these formats in the first quarter of 1991.

 .............

The Publisher includes a WYSIWYG table editor. Table functions include
cell-by-cell formatting, horizontal and vertical spanning, shading,
designated column headings, and various rule styles.  Cells may incorporate
any combination of text, graphics and mathematics.  Again, tables are
stored or exported as SGML (for use, say, with EBT's Dynatext or other
SGML compliant systems).

 .............

<SGML>
With respect to SGML syntax, the Maker Interchange Format (MIF) is not a
valid ISO 8879 SGML format.  Frame Technologies, to their credit, does
not claim that MIF supports valid SGML syntax.

It is more accurate to say that MIF is a proprietary format tagging system
with similarities to SGML.

However, even this weaker statement begs the question somewhat.  The
purpose of SGML tags is to define objects within documents.  Formatting
is NOT a direct consequence of SGML and requires an additional standard
such as the Formatted Output Specification Instance (FOSI), Document
Style Semantics and Specification Language (DSSSL), or a proprietary
formatting function.

<CALS>
Of these format types, only the FOSI type is defined under CALS.
</CALS>

With respect to achieving SGML syntax by adding a few element tags, it
is true that one can attain a smattering of valid SGML by having element
tags named correctly, but it is dangerously misleading to describe that
process as "fully-compliant SGML."

SGML defines objects within documents using Document Type Definitions
(DTDs).  A DTD may define any number of arbitrarily named elements as
well as defining the context of those elements.

If a document instance contains a tag which is not declared in the DTD, or
contains a tag "out of context" (e.g., placing a <chapterhead> inside of
a <section>), or omits a required tag (such as a title), then the document
is not compliant, even though SGML syntax is used to mark it up.  Likewise,
if a publishing system cannot interpret any DTD and apply it in real time
to the document during the writing process (so as to enforce the context rules
defined by the DTD), its SGML-compliance is weak.
</SGML>

<CALS>
In summary, to be minimally CALS compliant, the text of the document instance
(remember, graphics have their own set of standards) must contain valid SGML
syntax for the DTD required by the contract. To remain CALS compliant over
time, however, the publishing system:

	1. needs to be able to read and write SGML for any and every
	   government DTD,

	2. should ensure in real time that the SGML tagging is valid for
	   the DTD, and
	   
 	3. should be able to format the document using a FOSI.
</CALS>

 .............

The Publisher has a full range of import filters, but the ideal method for
text interchange, SGML, is its native format.

 .............

The Publisher has an extensive command language which allows Publisher users
or their documents to query, retrieve, and manipulate information in the
user's environment. This means the ability to form SQL queries based on
the content of a document or a user's responses and to retrieve and update
a document automatically, based on the results of the query. The Publisher
will read and write data via UNIX pipes allowing users to execute custom
scripts, programs or other applications directly on data used in your
documents.

The Publisher also allows users to configure the editing environment to meet
their specific needs. As needs change over time, The Publisher can be easily
reconfigured to support the changes. Menus can be configured to allow or
disallow any menu or menu item according to the user's preference, skill
level, or job function. Menus can be rearranged, renamed, and can have
additional functions added to them. Keyboard and mouse buttons are also
completely configureable, allowing emacs users to replicate emacs functions
in the editor. WordPerfect or vi users can likewise customize their keyboards.
Publisher command macros can also be created to shortcut tedious and repetitive
operations.

 .............

The Publisher is available on the most widely available Unix workstations: DEC,
HP/Apollo, and Sun.

 .............

The Publisher currently employs several DTDs which allow the creation of
Hypermedia documents through SGML. Users are able to mark up hypermedia
elements in their documents and to test and execute the links as they edit.
In terms of delivering electronic books, several ArborText customers are
currently using The Publisher as the authoring tool of choice in producing
Dynatext [EBT] books. 

 .............

<SGML>
SGML is the optimal text exchange mechanism in use today. Any publishing
system which reads and writes a full range of SGML will be able to exchange
information with other publishing systems.
</SGML>

 .............
  [lk> 
  [lk> The Rest of the Story
  [lk> 
  [lk> 
  [lk> We considered all known viable options for creating documentation.  Some of 
  [lk> these are worthy of consideration as supplemental tools for our selections.
  [lk> 
[text omitted]
  [lk> 
  [lk> 
  [lk> o TeX tools.  This is an appealing option, as the developers and most of 
  [lk>   management is familiar with TeX and LaTeX.  TeX is a powerful formatter, 
  [lk>   with excellent publishing features.  The problem of having no supported or 
  [lk>   integrated package of tools can be partially addressed by using Arbor 
  [lk>   Publisher (Arbor), formerly known as ArborText.  [omission] 
  [lk>   The potential of TeX is blunted by the high learning curve and the low 
  [lk>   productivity rate to accomplish sophisticated production.  (Much of the 
  [lk>   formatting power of TeX cannot be harnessed from the macro packages 
  [lk>   available, and thus working in raw TeX is necessary.) An effort 
  [lk>   to integrate TeX tools is now taking place at the Free Software 
  [lk>   Foundation... [omission] with excellent hypertext potential.
  [lk>   [omission]
  [lk> 

As per our notes at the beginning and throughout this file, the preceding
information about ArborText is substantially incorrect.

 .............

ArborText distributes Island Graphics' Paint and Draw as optional programs
for The Publisher.

-------------------------------        -----------------------------
James F. Salois                        ArborText, Inc.
Director of Product Marketing          535 W. William St., suite 300
ArborText, Inc.                        Ann Arbor, MI 48103
                                       Ph. (313) 996-3566
jfs@arbortext.com                      Fx. (313) 996-3573
-------------------------------        -----------------------------

 = = = = (end enclosure) = = = =

I want to close with a comment on the function of Usenet and this newsfeed:
I know we don't want Usenet to become a commercial vehicle.  However, I doubt 
if the Usenet administrators would have found Mr. Salois's comments 
objectionable.  We are here to learn and share information.  Initially, I 
found the above message intimidating, but I have decided that Mr. Salois 
was simply being scrupulous about Usenet rules on commercial use.  I suggest 
that a little more open discussion by interested parties would benefit us all,
and I see no reason why employees who work in an area discussed in a newsfeed 
should not directly participate in net discussions.

I received this message a week ago.  I regret that I couldn't rectify my 
earlier posting with this contribution until now: I had urgent production 
deadlines through Thursday, and I was in a car wreck on Friday.  Today, 
Wednesday, is my earliest opportunity to address this issue.

Sincerely,

-lar

-- 
Lar Kaufman            I would feel more optimistic about a bright future
(voice) 512-329-2455   for man if he spent less time proving that he can
(fax)   512-329-2755   outwit Nature and more time tasting her sweetness 
lark@tivoli.com        and respecting her seniority.  - E.B. White