[bug #68256] [troff] `.bd S 3 3` doesn't work
Deri James <[email protected]> Thu, 2 Jul 2026 06:49:13 -0400 (EDT)
| Newsgroups | gmane.comp.printing.groff.bugs |
|---|---|
| Message-ID | <[email protected]> |
Follow-up Comment #22, bug #68256 (group groff):
Self follow up!
I grabbed "https://github.com/n-t-roff/Plan9_troff.git" which compiled with
warnings using fairly old gcc on Mageia (failed to compile on up-to-date
Debian). tr2post segv's, however troff does produce grout, the only device is
utf.
Things to note:-
Since the device is utf, all unicode characters are in the "current" font, so
using \(mu does not switch to Symbol font since it assumes it is present in
the current text font. This means the conditional form of .bd is obsolete
because it will never switch to a Special font.
Using this script:-
[derij@pip Plan9_troff (master)]$ cat bdtest.ms
.bd S 3 4
\fB8\(mu8\fR
The following grout produced:-
troff/nroff version March 11, 1994
invoke request ds
invoke request ds
invoke request bd
x T utf
x res 720 1 1
x init
V0
p1
x font 1 R
x font 2 I
x font 3 B
x font 4 BI
x font 5 CW
x font 6 H
x font 7 HI
x font 8 HB
x font 9 S1
x font 10 S
s10
f3
H720
V120
c8
h50Cmu
558n120 0
x trailer
V7920
x stop
There is no "bolding" and no switch to font S (f10).
Using gdb om the same input:-
Starting program: /usr/local/p9roff/bin/troff -d -t255 bdtest.ms
Missing separate debuginfos, use: debuginfo-install glibc-2.36-59.mga9.x86_64
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
troff/nroff version March 11, 1994
invoke request ds
invoke request ds
invoke request bd
Breakpoint 1, casebd () at t6.c:785
785 if (!TROFF) {
(gdb) n
789 zapwcache(0);
(gdb)
790 j = k = 0;
(gdb)
792 if (skip() || !(i = getrq()) || (j = findft(i)) == -1) {
(gdb)
798 if (j == smnt) {
(gdb)
802 if (k) {
(gdb)
806 bd1:
(gdb)
807 skip();
(gdb)
808 noscale++;
(gdb)
809 bdtab[j] = atoi0();
(gdb)
810 noscale = 0;
(gdb) p bdtab
$1 = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0 <repeats 89 times>}
NOTE: bdtab[10] (font S) is holding the second param.
(gdb) n
811 }
(gdb)
control (a=6553698, b=1) at n1.c:341
341 return(0);
(gdb) s
342 }
(gdb)
main (argc=1, argv=0x7fffffffd6d0) at n1.c:209
209 flushi();
(gdb) s
flushi () at n1.c:854
NOTE: 'flushi' discards up to new line
854 if (nflush)
(gdb)
856 ch = 0;
(gdb)
857 copyf++;
(gdb)
858 while (!nlflg) {
(gdb)
859 if (donef && frame == stk)
(gdb)
861 getch();
(gdb)
getch () at n1.c:411
411 if (ch) {
(gdb)
419 if (nlflg)
(gdb)
421 i = getch0();
(gdb)
getch0 () at n1.c:677
677 if (pbp > lastpbp)
(gdb) n
679 else if (ip) {
(gdb)
692 if (donef || ndone)
(gdb)
695 if (nfo < 0)
(gdb)
697 if (nfo == 0) {
(gdb)
704 nx = 0;
(gdb)
706 if (MB_CUR_MAX > 1)
(gdb)
710 i = getc(ifile);
(gdb)
711 if (i == EOF)
(gdb) x/c &i
0x7fffffffd498: 52 '4'
NOTE: The third param '4' has been read
(gdb) n
713 if (ip)
(gdb)
716 if (i >= 040) /* zapped: && i < 0177
*/
(gdb)
717 goto g4;
(gdb)
726 if (ismot(i))
(gdb)
728 if (copyf == 0 && sfbits(i) == 0)
(gdb)
730 if (cbits(i) == eschar && !raw)
(gdb)
732 return(i);
(gdb) s
733 }
(gdb)
getch () at n1.c:422
422 if (ismot(i))
(
(gdb) n
424 k = cbits(i);
(gdb)
425 if (k >= sizeof(gchtab)/sizeof(gchtab[0]) || gchtab[k] == 0)
/* nothing special */
(gdb) p k
$4 = 52
(gdb) n
426 return(i);
(gdb) p i
$5 = 52
NOTE: Still got the '4'.
(gdb)
$6 = 52
(gdb) s
645 }
(gdb)
flushi () at n1.c:858
858 while (!nlflg) {
(gdb)
859 if (donef && frame == stk)
(gdb)
861 getch();
(gdb)
getch () at n1.c:411
411 if (ch) {
(gdb) n
419 if (nlflg)
(gdb)
421 i = getch0();
(gdb)
422 if (ismot(i))
(gdb)
424 k = cbits(i);
(gdb)
425 if (k >= sizeof(gchtab)/sizeof(gchtab[0]) || gchtab[k] == 0)
/* nothing special */
(gdb)
427 if (k != ESC) {
(gdb)
428 if (k == '\n') {
(gdb)
429 nlflg++;
NOTE: Now got the new line, nothing has been done with the '4' (discarded)
(gdb)
430 if (ip == 0)
(gdb)
431 numtabp[CD].val++; /* line number */
(gdb)
432 return(k);
(gdb)
645 }
(gdb)
flushi () at n1.c:858
858 while (!nlflg) {
(gdb)
863 copyf--;
(gdb)
864 }
NOTE: And 'flushi' returns having consumed up to the new line.
This shows that p9roff (this version at least) does not support conditional
.bd at all because it never switches to the S font, and ignores the 3rd
parameter.
If the test script is changed so that "\fS\(mu\fB" is used rather than just "\
(mu", the grout changes:-
[derij@pip Plan9_troff (master)]$ troff -d -t255 bdtest.ms
troff/nroff version March 11, 1994
invoke request ds
invoke request ds
invoke request bd
x T utf
x res 720 1 1
x init
V0
p1
x font 1 R
x font 2 I
x font 3 B
x font 4 BI
x font 5 CW
x font 6 H
x font 7 HI
x font 8 HB
x font 9 S1
x font 10 S
s10
f3
H720
V120
c8
f10
h50Cmu
h2Cmu
f3
558n120 0
x trailer
V7920
x stop
NOTE: 'mu' is bolded by 'h2' (one less than the 2nd param) so again this is
unconditional bolding, and the 3rd arg has been ignored.
What have I learned?
p9roff does not handle '.bd S 3 3' properly.
Because the only output device is 'utf' it never has to switch to a 'special'
font, so conditional bolding is obsolete.
This is probably not the Plan 9 roff before unicode was 'invented'.
Cheers
Deri
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?68256>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
(application/pgp-signature, 228 B)
-----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQQk97aszIMMAvLLwm6qLAuaBUf3TgUCakZCKQAKCRCqLAuaBUf3 Tp1vAP9dTbhui21ZhcCecslUPsp606VZrmcB12beH9V8w6vb2QEAts4ZlMdbxUdF 15qH+ZA3EpipTazLTv5Vj4dSRPv/bQo= =P+6Q -----END PGP SIGNATURE-----