Publisher vs FrameMaker

[Kent_Wada at mtsg.ubc.ca]

I would like to address the points made in v7n34 by
<chuck at trantor.harris-atd.com> on the Publisher vs. Frame Maker question,
and in the original item by <root at helios.ucsc.edu> in v7n20. Mr.
Musciano's comments were clearly made in accordance with a set of criteria
which he uses to judge how effective a given product will be for the type
of work he does. That is of course how we all function, but I think that
what is not reflected in his item is the recognition that there is an
astonishingly diverse set of text processing applications, needs, and
requirements on this planet, and that no one product is going to solve all
the problems effectively, let alone optimally. I like Publisher because it
suits the types of work I do, and because I believe in the basis upon
which it was built; but for Heaven's sake if PC-WRITE produces results
that are satisfactory in terms of time spent, effort involved, and results
produced, use it!

An observation about the points Mr. Musciano raises: many of them
transcend product-specific issues. Publisher and Frame Maker just happen
to embody many of the qualities that people argue about...  like `WYSIWYG
or not.'

>Do you really care what the internal representation of your
>document is?  What does it matter if it is TeX, PostScript, or C/A/T?

On to the specifics. The simple answer to Mr. Musciano's first question
above is `yes'. Not perhaps that it uses PostScript, or TeX, or SGML as
its underlying paradigm, but that it follows a philosophy of adhering to
standards--ISO, ANSI, de facto, whatever--as far as possible. In this
context, it means that authors are able to share documents, and all that
that implies. If co-authoring or otherwise sharing documents in
geographically and/or electronically disparate environments is not a
requirement, this may not be as much of a concern. There are, however,
many people to whom this is very important. I might add that this is one
the reasons the use of TeX has become so widespread (in the domains for
which it was designed).

>Publisher is not a WYSISYG package.  It is a compose/preview package.
>This is completely unacceptable in my book.
>...
>Overall, Publisher seems targetted to people who know TeX.  Why do you
>want to hang on to old technology when all this wonderful new stuff is
>coming out?  Do you really care what the internal representation of your

I am intrigued by Mr. Musciano's implication that TeX is old technology.
Is `all this wonderful new stuff' a reference to his earlier mention of
WYSIWYG systems? There is certainly no consensus on whether WYSIWYG
authoring systems best solve all text production needs. Likely there would
be unanimity for the case that WYSIWYG interfaces are wonderful for many,
but not all, applications.

As for Publisher being targetted to people who know TeX... One of the
reasons I like Publisher is because it offers me an interactive,
TeX-independent presentation interface, while retaining the benefits
derived from using TeX--such as availability on a large number of systems
and printing devices, use of a de facto standard allowing portability
between authors, quality of output, and markup language capabilities. Of
course there are import/export facilities for those who use TeX, LaTeX, or
SGML directly, but it does not diminish the capabilities of the software
as a stand-alone text production tool if they are not used.

>I found Publisher to be a backwards step from Frame.  First, it failed
>Musciano's Law of New Software: I sat down without the manual and tried to
>do something productive.  I got nowhere.  I couldn't figure out how to
>create a simple document.  With Frame, I did all sorts of things,
>multi-column documents, line art, different text flows, and never picked
>up the manual.  Strike One against Publisher.

Another of the philosophical differences that people have is how averse
they are to reading documentation. I do not particularly enjoy reading
instruction manuals, but do not begrudge having to read a certain amount
of it--if only to acquire a `feel' for how the product works. If the
software is well designed, only a moderate amount of documentation need be
read at first: the rest should follow intuitively, and the documentation
used primarly as a reference tool. Both points are important: it should
not be necessary to look up a manual for every little thing, but some
formal basis in the operation of a product (if only to be able to use the
product fully and effectively) is critical.

>The user interface is poor.  Commands which do one thing in the compose
>window do another in the preview window.  ...
>I don't want to learn two tools in one!
>...
>The drawing programs are separate tools.  Again, I don't want to learn N
>tools, I want to learn one.  Frame is fully integrated, except for table
>of contents and index generation (which bothers me, but is outweighed by
>other features).  Strike Four.

I do not argue about the merits of having a uniform user interface;
patently, it is a desirable goal. However, I think it is too much to
expect a single tool to do everything. Publisher's approach using separate
graphics, table, and equation editors is perhaps imperfect in
implementation, but not in intent. I would rather have ArborText spend the
time expanding their integration capabilities with other packages--so
that, for example, I can use my favourite graphics package to generate my
pictures, as opposed to being limited to using what is provided--instead
of trying to retrofit more and more capabilities onto a single piece of
software. Would it not be wonderful if there was seamless integration
between packages like Mathematica, Leonardo, and Publisher, and--dare I
say it--all on a NeXT machine? Just _think_ of the possibilities! But one
could not even begin to consider the thought without a basis rooted in
standards...

>Frame is, I believe, $995/station at educational rates.  With the floating
>license server, you can actually get away with much less.  For example,
>suppose, you have 15 stations, but actual use of Maker is about four
>simultaneous users.  Just buy four licenses, and share them among the 15
>Suns.  The license server idea is one which needs to be picked up by other
>companies.

There is no reason to believe that the floating licence server concept is
implemented only by Frame Technologies. The copy of Publisher I use
resides on our server, but is usable from any of the Sun workstations that
are connected to our network.

>Finally, why don't you just check it out for yourself?

I could not agree more! We all know computer products tend to evolve
stressfully apace, particularly new products (one need only look at the
quantum leap between what I call Publisher's `concept prototype', version
1.0 from only a year ago, and their latest, version 2.1). Mr. Musciano's
suggestion about evaluating such competing software is really the only
rational strategy: analyse what is required (and what is desired), see
what is out there, and try them out!

I will give into the temptation to include a (very abbreviated) Publisher
features list: based on standards (TeX, SGML, and PostScript); great table
and equation editors; TeX-quality output (`for the creation of beautiful
documents'); multilevel `undo' facility; import/export of TeX, LaTeX, and
SGML documents; tons of fonts (including complete math fonts);
bibliography support; graphics editors, screen capture and scanner
support, import facilities for Sun bitmaps, PostScript graphics, MacPaint,
MacDraw and Excel graphics; and ASCII terminal support.

-Kent

>After all my postings about Frame, I should make clear that I don't work
>for Frame, but I do like their product.

I suppose I should mention that I do not work for ArborText. I do like
Publisher an awful lot, but not exclusively! I would be glad to continue
this discussion, but perhaps elsewhere? Maybe the desktop-publishing list?

kent_wada at mtsg.ubc.ca (Internet) |Computing Centre/The University of
USERWADA at UBCMTSG (BITNET)        |British Columbia/6356 Agricultural
Telephone: (604) 228-6496        |Road/Vancouver, British Columbia/
Facsimile: (604) 228-5116        |Canada  V6T 1W5