troff cs problem stumps local experts

chris at mimsy.UUCP chris at mimsy.UUCP
Tue Feb 10 20:09:48 AEST 1987


In article <2459 at jade.BERKELEY.EDU> strong at amber.berkeley.edu (Tom
Strong) writes:
>.cs "mode must still or again be in effect when the characters are
>physically printed." (pg 10, troff manual)
>I believe the multiple KS/KE on one page are the problem.
>Try using DS/DE.  Also possible to use \!.cs.

Alas, as the manual says, that mode `must still or again' be set:
using \!.cs (if I properly understand what it does) is insufficient.
Using .cs *and* \!.cs will work if the keep is evaluated exactly twice.
The more often the keep is reevaluated, the more `.cs's are needed.

Troff stores diversions and strings by scanning the input with the
regular input code, but stashing the result in a buffer somewhere
instead of typesetting it.  All other processing (e.g., number
register expansion) is done immediately.  When the string or
diversion is called forth, input is redirected to the buffer, then
takes place as though nothing special were happening.  All processing
(e.g., number register expansion) is done immediately.  This
repeats *ad nauseam* until the result is finally typeset.

For much text, this little detail is irrelevant: a page number
expands immediately to a string of digits, which then forever
remains a string of digits.  A diversion, though, might have been
made with `\\(ddt)' as input text.  At reevaluation, this reads
`\(ddt)', which is interpreted as `\(dd' (double dagger) followed
by `t)'.  On occasion, this is even what one wants.

I may have some of the particulars wrong, for it has been some time
since last I dealt with troff.  This sort of headache was one reason
I switched to TeX:  Making it reevaluate things is harder, and
tends not to occur by accident.  (And, sometimes, not when it
should, either.  TeX's evaluation rules also are not entirely
straightforward.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP:	seismo!mimsy!chris	ARPA/CSNet:	chris at mimsy.umd.edu



More information about the Comp.unix.questions mailing list