Follow-up Comment #19, bug #68256 (group groff): Hi Deri,
At 2026-06-13T13:08:16-0400, Deri James wrote:
> Follow-up Comment #18, bug #68256 (group groff):
>
> On Friday, 12 June 2026 20:49:33 BST G. Branden Robinson wrote:
>> Follow-up Comment #16, bug #68256 (group groff):
>>
>> Results from my working copy, using the changes alluded to in bug #68445.
>>
> Just a few notes on the temporary debug messages.
>
> Nomenclature.
> =============
>
> Case 1 = 2arg = non-conditional
> Case 2 = 3arg = conditional
>
>>
>> $ printf '.bd S R 4M\nGoodbye \(mu cruel world\[r!]
>> \n'| ./build/test-groff -Z
>> troff:<standard input>:1: debug: GBR: emboldening is conditional
>> because first argument starts with non-numeral, character 'S'
>
> In this case it is conditional but not just because arg1 is
> non-numeric, this is a valid case 1:-
>
> .bd TR 500
>
> Where arg1 is non-numeric. The test should be non-numeric AND font is
> special (since only 'special' fonts are allowed in conditional
> emboldening).
Where is that written? Someone might want to, say, embolden a
non-special font if some other font is selected.
> A further twist is that arg2 MUST be non-numeric for conditional case,
> because our documentation specifically states that a font position may
> be used in case 1, but this caveat is not given to case 2, inferring
> only named fonts can be used.
I think we need to reconsider this feature from first principles, and
would propose setting our existing documentation completely aside for
the time being, except for the part that says that the feature is
supported for continuity with AT&T troff.
I think we should refactor/revise this feature to work acceptably with
legacy AT&T documents, and if that imposes gratuitous limitations, we
can consider adding new requests to GNU troff to achieve an orthogonal
interface. Every time I dive into this ticket I find myself mentally
yelling at Kernighan (or whoever):
"Why didn't you just add a new request for conditional emboldening?!"
[snip]
> Our documentation is a bit loose here:-
Yes. One reason I want to lay it aside.
>
> .bd font1 font2 [offset]
>
> and then says:-
>
> "If the second argument is missing, emboldening is turned off for this
> particular current font."
>
> Which only makes sense if it refers to the (only optional) 3rd arg
> [offset].
>
> .bd S TR \" Turn off boldening of S when TR is current font.
>
> If you want 'font2' to be a font position as well (which is not
> specifically mentioned as it is for case 1) you create an unsolvable
> problem:-
>
> .bd S 5 500 \" bold S if TR
> .bd S 5 \" is this unbolding S if TR, or unconditional bold S by 5
>
> Problem disappears if font positions are only allowed for
> unconditional bolding, as our docs seem to imply.
>
> This is why I believe ".bd S 3 3" could be a misreading of ".bd S B
> 3".
I don't think it's a misreading. It's what people really put in their
legacy documents, following an example in CSTR #54.
$ sed 's/:.*//' ROFFDOCS | while read f; do grep -Hns 'bd S 3 3' "$f"; done
4.3BSD-Reno/src/share/doc/smm/10.newsop/tmac.n:649:.bd S 3 3
\" embolden special font chars if B
4.3BSD-Reno/src/share/doc/usd/09.newsread/tmac.n:649:.bd S 3 3
\" embolden special font chars if B
4.3BSD-Reno/src/share/doc/usd/10.etiq/tmac.n:649:.bd S 3 3
\" embolden special font chars if B
4.3BSD-Reno/usr/share/doc/smm/10.newsop/tmac.n:649:.bd S 3 3
\" embolden special font chars if B
4.3BSD-Reno/usr/share/doc/usd/09.newsread/tmac.n:649:.bd S 3 3
\" embolden special font chars if B
4.3BSD-Reno/usr/share/doc/usd/10.etiq/tmac.n:649:.bd S 3 3
\" embolden special font chars if B
SystemIII/usr/src/cmd/text/macros.d/an.src:95:.if t \{.bd S 3 3
SystemIII/usr/src/man/docs/advice:12:.bd S 3 3
SystemIII/usr/src/man/docs/c_lib:53:.bd S 3 3
SystemIII/usr/src/man/docs/sh_tut/sc0:88:.bd S 3 3
SystemIII/usr/src/man/docs/~c_man.macs:12:.bd S 3 3 \" embolden special
font in context of 3
SystemIII/usr/src/man/docs/~u_prog.macs:2:.bd S 3 3 \" embolden special
font in context of 3
svr4/lib/zlibeti/man3/menu.3c:23:.ift \{.bd S 3 3
svr4/lib/zlibetitam/man3/tam.3c:23:.ift \{.bd S 3 3
svr4/ucbcmd/troff/troff.d/tmac.d/an:425:.bd S 3 3
svr4/ucbcmd/troff/troff.d/tmac.d/sunman:424:.bd S 3 3
v10/cmd/troff/ancient.nroff/macros.d/an.src:98:.if t \{.bd S 3 3
v7/usr/doc/uprog/p.mac:4:.bd S 3 3 \" embolden special font in context of
3
v7/usr/lib/tmac/tmac.an:263:.bd S 3 3
Admittedly, it _could_ have been cargo-culted around, and as you can
guess I'm eager to rail at anyone who did so.
For completeness, I'll attach other instances of the `bd` request I can
find in my corpus of historical Unix documentation. We see some of the
usage you suggest as an alternative alongside the foregoing.
Also be advised there are some false positives because, apparently, the
pre-man(7) man page macros defined a `bd` macro that did boldfacing of
text arguments as the later `B` macro did. But those are relatively
easy to recognize because their string arguments tend to resemble
neither font identifiers nor integers.
> Same as above, non-numerical arg1 not reliable indicator this will be
> conditional form.
I agree. That's why I'm so frustrated by this request's interface.
> Should cause an error, font2 must be a font name else how would you
> know what
>
> .bd S 3
>
> means, is it undoing the above conditional or is it saying to bold
> font S unconditionally when S is being used as a text font -
> \fS\(mu\fP - useful in situations where you have more than 1 'special'
> font containing 'mu'.
Hence my desire to hop in the TARDIS, pop back to Room (1)127 in Murray
Hill in 1978 or so, wild-eyed and coated in blood, and raise hell until
they humor the madman.
[...]
>> $ printf '.bd S 3\n' | ./build/test-groff -ww 2>&1 | grep . ||
>> echo NO OUTPUT
>> troff:<standard input>:1: debug: GBR: emboldening is conditional
>> because first argument starts with non-numeral, character 'S'
>> troff:<standard input>:1: debug: GBR: embolden_font_request(): CASE
>> 2: disabling conditional emboldening of S when mounting position 38
>> selected
>
> This is ambiguous, it could be an unconditional request to bold S by 3.
I agree.
> The only way to make sense of .bd syntax is to say font positions are
> not allowed in the conditional format, only in the 2arg version where
> they are specifically allowed.
That's a silly restriction, but we might be stuck with it for `bd`.
>> $ printf '.bd 1 2\n' | ./build/test-groff -ww 2>&1 | grep . || echo NO
>> OUTPUT
>> troff:<standard input>:1: warning: interpreting second argument to
>> font emboldening request as emboldening amount; use a font name
>> instead of a mounting position as the first argument if conditional
>> emboldening desired [-w style]
>
> Why a warning, this is a perfectly valid request, as is
>
> .bd R 2
>
> which is not a conditional, but is a font name arg1.
It could be a request to stop conditionally emboldening font `R` when
font `2` is selected.
>> troff:<standard input>:1: debug: GBR: embolden_font_request(): CASE 3:
>> enabling emboldening mounting position 5 by 2
>
>> $ printf '.bd 1\n' | ./build/test-groff -ww 2>&1 | grep . || echo NO OUTPUT
>> troff:<standard input>:1: debug: GBR: embolden_font_request(): CASE 4:
>> disabling emboldening of mounting position 5
>
> This one's spot on.
I think the 2-argument form of `bd` is inherently ambiguous and there's
no way to rescue it, because an emboldening amount looks lexically
identical to a font mounting position.
I diagnose this unfortunate situation as yet another case of the Bell
Labs CSRC's allergy to strong typing causing grief for the world.
Everything's an integer--what could go wrong?
Again, I propose giving up on making `bd` make any _sense_. Let's make
it compatible with AT&T troff and mark it as radioactive in our
documentation. As can be seen I'm perfectly content to write a
fist-shaking jeremiad decrying the Labs' failure to design the feature
carefully.
Regards,
Branden
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?68256>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
