Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!unmvax!gatech!emory!dtscp1!scott From: scott@dtscp1.UUCP (Scott Barman) Newsgroups: comp.text Subject: Re: What features would you like in GNU troff? Message-ID: <755@dtscp1.UUCP> Date: 9 Jun 89 17:47:11 GMT References: <742@dtscp1.UUCP> <14365@watdragon.waterloo.edu> Reply-To: scott@dtscp1.UUCP (Scott Barman) Distribution: comp Organization: Digital Transmission Systems (a subsidiary of DCA), Duluth, GA Lines: 47 In article <14365@watdragon.waterloo.edu> tbray@watsol.waterloo.edu (Tim Bray) writes: >Apologies for cluttering net-bandwidth; couldn't get mail through. > >A tiny weeny nit, but: In various troffs, including ditroff, you can't >.ss >or even >'ss >in the middle of an output line and have it take effect right there. (Bet >a substantial proportion of (even moderately serious) troff hacks don't >know what .ss does). Without looking at the manual (since I left it a home :-): .ss == set space character size where the value is entered is something like N/36 ems (or is it ens?). >This behaviour is not documented as far as I know, so it should be >documented or fixed. The reason is simple why this does not work. It is were this is interpreted. Like the .bd, the .ss is interpreted on output. I do not know the reasoning, but (as I try to remember since it has been 4 years since I hacked at troff) this number is not stored in the "magic cookie" of each character and needs to be in effect when troff tries to properly adjust the margins. It is also the same for emboldening since the widths of the characters change and it needs to know this information on output. The short of it is because it is interpreted on output and not input. Oh, and in a backward sort of way, it is... unfortunatly it assumes that the reader knows about troff internals. It is tied in with the same reasons that .bd and .cs (do *you* know what that one is) have to be in effect when you reread a diversion... because they are interpreted on output, not input. See the info on diversions (like I said, my manual is not handy). NOTE I have mentioned it once before and before I get alot of mail asking what the "magic cookie" is: it is what the internal representation of a character is in troff (I do not remember if it is the same in C/A/T troff since it has been even longer since I pulled the lid off of that beastie). In ditroff, it is a 32-bit quantity that contains size, character, font, motion, etc. informtion that is also context based (i.e. a charcter does not have spacing info, but does have width info (16-bits)). Any attempts at reimplementation should concentrate on making this "magic cookie" more flexible--or at least give us more than 16-bits to figure movement. -- scott barman {gatech, emory}!dtscp1!scott