ian@sq.UUCP (02/17/87)
Several people have asked me, in response to my previous posting on SoftQuad Troff, for a detailed answer on why SoftQuad originally chose troff over TeX. ``Small is beautiful'' (although I use the term loosely when talking about troff internals). Troff proper is smaller (because it is intentionally designed to delegate gruntwork to pre- and post-processors). Because it is smaller, there are fewer design decisions imbedded in the code. Troff's operating mode conforms to UNIX program conventions. It does not ask you for filenames, nor does it put its output into magic filenames (InputFileName.dvi, etc). As a result, it works well in pipeplines, resulting in an abundance of pre-processors. These are relatively easy to write (as opposed, say, to trying to add the corresponding functionality to TeX). See Bentley, ``Programming Pearls: Little Languages'', CACM, August 1986, V29, N8, page 711, for detailed discussion - I have used up enough net bandwidth already, and Bentley gets the ideas across better than I might. The founders of SoftQuad, like the troff software, had a long history of experience with phototypesetters, which are the machines then used by most commercial printers. By contrast, TeX appeared to be primarily oriented towards raster printers (300 dpi laser printers in particular) for which it could download CM fonts. At that time, the CM fonts were, uh, not as well-formed as they are today. We needed to get good quality letter forms; TeX did not produce them in the quality needed, and appeared to be wired in to use of downloading CM fonts. While TeX did have kerning, that too depended on the raster fonts; to drive phototypesetting machines, we needed the ability not only to set type using manufacturer's fonts without downloading CM, but to kern those existing fonts. To my *limited* understanding, this could only be done by building TFM files (or whatever) for those fonts. It seemed at least as easy to slightly modify ditroff's font.OUT files as it would have been to build TFM files from scratch (not using Metafont79). Also, TeX was written in a slightly-non-standard dialect of Pascal, rather than in WEB, so there were issues of portability to consider (recall that the early UNIX TeX tapes - in circulation until quite recently - could only go to UNIX-source-licensed sites because they contained modifications to the Pascal compiler needed to make that version of TeX compile). Troff by contrast was known to run on many flavors of UNIX, and was written in fairly portable C. Of course today's TeX runs on about the same range of systems as Troff does, so portability is no longer an issue. One desirable property of ditroff's intermediate language is that it is amenable to ``postprocessors'' other than those for specific devices. For example, you might want to use grep, awk, etc., on the intermediate language. Clearly one could hack up TeX to print readable DVI files, but then it wouldn't be TeX anymore. We hacked up ditroff to print more-readable intermediate files, and it isn't ditroff anymore - hence that product is called SQtroff. We have backwards compatibility with all previous versions of troff (including a filter in our standard software that generates ditroff-compatible intermediate language from our format, so a user with existing ditroff postprocessors can continue to use them with our SQtroff). The decision to use ditroff instead of TeX was made in 1983 (before I even thought of coming to work for SoftQuad). Some of the reasons are no longer applicable, but most of them are. We would probably make the same decision today. Ian F. Darwin, Director, Research & Development, SoftQuad, Inc., Toronto, Canada ian@sq.com, ian@sq.uucp, utzoo!sq!ian
ken@rochester.UUCP (02/20/87)
|Troff's operating mode conforms to UNIX program conventions. It does |not ask you for filenames, nor does it put its output into magic |filenames (InputFileName.dvi, etc). As a result, it works well in |pipeplines, resulting in an abundance of pre-processors. This is a mere interface detail. Unix TeX allows you to type in the first line as a command argument. It could also be made to output to stdout. I do wish there was a flag to shut up the verbose messages though. Ken