Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!gatech!emory!dtscp1!scott From: scott@dtscp1.UUCP (Scott Barman) Newsgroups: comp.text Subject: Re: Troff Macro Programming A: Part 1 [repost] Summary: How much has it really changed? Keywords: sqtroff ditroff troff DWB Message-ID: <733@dtscp1.UUCP> Date: 30 May 89 19:24:33 GMT References: <18@nx32s.anduk.co.uk> <15768@vail.ICO.ISC.COM> <20@nx32s.anduk.co.uk> <15795@vail.ICO.ISC.COM> <1989May29.165203.17889@sq.com> Reply-To: scott@dtscp1.UUCP (Scott Barman) Distribution: comp Organization: Digital Transmission Systems (a subsidiary of DCA), Duluth, GA Lines: 58 In article <1989May29.165203.17889@sq.com> murray@sq.com (Murray Maloney) writes: >While troff's use as an interchange format has always been a goal, it has >never really been a reality. Not only have successive versions of troff >included significant changes in the command set, but nroff, troff, and >ditroff have never been 100% compatible. With so many ROFF-based formatters >available, each with its personality (in the form of undocumented behavior), >one would have to be especially careful to remember what's correct with a >given version, on a given machine, attached to a given printer. I really think you need to be more precise on this statement. No version of the *roff programs have been 100% compatible, but I beleive that, at least up until DWB 2.0, there has been an attempt to make sure the programs were upward compatible. To quote Brian Kernighan [Computing Science Technical Report No. 97, "A Typesetter-independent TROFF"]: "... a great deal of software depends on TROFF--the preprocesors, the macro packages, and of course all of their documentation and our accumulated expretise. Tossing this aside is not something to be done lightly Accordingly, ... I set about to modify TROFF so that it would run henceforth without change on a variety of typesetters. The ground rule was that TROFF should retain its current specifications so that existing software... would continue to work with it." I would say, with experience, that this mission was accomplished when we (we meaning in a previous job) upgraded our environment from C/A/T-4s to an APS-u5 with typesetting done with ditroff from PWB 1.0 with the only modifications being to our own internally hacked eqn. It would be very disturbing if any new product--especially sold by AT&T--is not upward compatible. >There are, however, quite a number of requests and escape sequences that >have remained consistent since the V7 version was documented. By >restricting yourself to that set, you can be fairly confident of producing >a document that you can distribute freely. This restriction applies >no matter which version you use. That is just escape sequences--which I am assuming you mean characters. What about some of the old C/A/Tisms that has survived even DWB? We all know that typesetters can do multiple pointsizes, but what about the ol' \s command? For example, if I do a \s32X I would get a point size 32 `X' since the C/A/T could not do a point size 3 and "assumed" the 32 to be legal. Now (assuuming a typesetter can do a point size 3), has SQ changed this command of print a `2X' in point size 3? I really hope not! Just as a suggestion, one of the things I hacked into ditroff (many years ago) was to accept "legal" \s but added the ability to do a \s(xx where the xx can be any point size. I did it to test some proposed changes to our internally hacked eqn (something that would not be released to the public). The eqn changes were not made, but the change to the \s stayed and I never heard of any problems because of it. It's just a thought... -- scott barman {gatech, emory}!dtscp1!scott