Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!cornell!uw-beaver!rice!sun-spots-request From: Kent_Wada@mtsg.ubc.ca Newsgroups: comp.sys.sun Subject: Re: Publisher vs FrameMaker Message-ID: <1353093@mtsg.ubc.ca> Date: 14 Dec 88 17:42:20 GMT Sender: usenet@rice.edu Organization: Rice University, Houston, Texas Lines: 144 Approved: Sun-Spots@rice.edu Original-Date: Fri, 9 Dec 88 13:51:02 PST X-Sun-Spots-Digest: Volume 7, Issue 54, message 2 of 3 X-Issue-Reference: v7n34 I would like to address the points made in v7n34 by on the Publisher vs. Frame Maker question, and in the original item by 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@mtsg.ubc.ca (Internet) |Computing Centre/The University of USERWADA@UBCMTSG (BITNET) |British Columbia/6356 Agricultural Telephone: (604) 228-6496 |Road/Vancouver, British Columbia/ Facsimile: (604) 228-5116 |Canada V6T 1W5