james@inset.UUCP (James Dalby) (12/12/85)
I wonder whether anyone has come across this problem before, or knows the cause of it. The following ditroff input: .de W .nr f \\$1 .tm f is \\nf .if \\nf==0 .tm f should be 0, is \\nf .if \\nf==1 .tm f should be 1, is \\nf .if \\nf==2 .tm f should be 2, is \\nf .. .W 0 .W 1 .W 2 when run with troff foobar > /dev/null gives this output (honestly) f is 0 f should be 1, is 0 f is 1 f should be 0, is 1 f is 2 f should be 0, is 2 I know it looks the wrong way round, but it's really true (on my troff). It works as expected with my nroff. I tried a few other varieties, and it seems to be only the single letter register f that mucks everything up. James.
jaap@mcvax.UUCP (Jaap Akkerhuis) (12/13/85)
In article <819@inset.UUCP> james@inset.UUCP (James Dalby) writes: > I wonder whether anyone has come across this problem before, or knows the > cause of it. Yep, you will find this in all versions of troff. I think I've fixed it in every new unix version the last five year. I call in the 123-bug, since if you do: .nr f 2 1\nf3 you wil get 132 It doesn't happen when the ligature mode is of (.lg 0). The fix: Dive into n4.c. Look in setn(). Note it does something like if((i = cbits(ii = getch())) == '+') (Old troff probably looks like: if((i=getch() &CMASK) == '+') but I don't remember exactly.) Well, the getch of course expands ligatures. Change the "getch()" in "getach()". Try your test again. Note the problem went way. jaap