Follow-up Comment #21, bug #68256 (group groff): On Saturday, 20 June 2026 07:28:09 BST G. Branden Robinson wrote: > 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.
Page 158 groff.pdf, para 2 of 2nd syntax description:-
"font1 must therefore
be a special font, configured either with the special directive in its
font description file or with the fspecial request)."
or cstr#54 page 11
".bd S f N
The characters in the Special Font will be emboldened
whenever the current font is F. This manual was printed
with .bd S B 3. The mode must be still or again in effect
when the characters are physically printed."
>> 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.
Where does our documentation say "that the feature is supported for continuity
with AT&T troff".
The conditional form is still useful (because we don't provide a bold symbol
font) when a symbol is required amongst text in a bold font.
> 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):
Kernighan (or whoever) only made a mistake if AT&T troff permitted font
positions in the conditional format as 'font2'. I know there are a few ".bd S
3 3" in your corpus of man pages but there are many more instances of ".bd S B
3". How sure are you that ".bd S 3 3" actually ever worked with AT&T troff, do
you have any grout showing bolding actually happened.
> "Why didn't you just add a new request for conditional emboldening?!"
>
Because it is unnecessary if only font names are allowed in the second form.
> [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.
In the CSTR #54 (Revised Nov 1992) There is no example for 2nd format usage,
but in the 1976 "Nroff/Troff User's Manual" by Ossanna there is an example of
".bd S B 3". I have uploaded a copy, in case you do not have this particular
edition. If you have a document which gives ".bd S 3 3" as an example I would
love to add it to my collection.
[snipped examples of ".bd S 3 3" being used]
Here's a rough count of usage:-
┌───────────────────┬───────┬────────┐
│ Command │ Count │ Format │
├───────────────────┼───────┼────────┤
│ .bd 3 │ 1 │ 1 off │
├───────────────────┼───────┼────────┤
│ .bd 2 │ 1 │ 1 off │
├───────────────────┼───────┼────────┤
│ .bd B │ 2 │ 1 off │
├───────────────────┼───────┼────────┤
│ .bd S R 3 │ 2 │ 2 on │
├───────────────────┼───────┼────────┤
│ .bd A │ 2 │ 1 off │
├───────────────────┼───────┼────────┤
│ .bd S │ 2 │ 1 off │
├───────────────────┼───────┼────────┤
│ .bd Y │ 2 │ 1 off │
├───────────────────┼───────┼────────┤
│ .bd U │ 2 │ 1 off │
├───────────────────┼───────┼────────┤
│ .bd 2 2 │ 3 │ 1 on │
├───────────────────┼───────┼────────┤
│ .bd I \$1 │ 4 │ 1 on │
├───────────────────┼───────┼────────┤
│ .bd 3 \$1 │ 4 │ 1 on │
├───────────────────┼───────┼────────┤
│ .bd S B \n(.su/3u │ 6 │ 2 on │
├───────────────────┼───────┼────────┤
│ .bd 2 3 │ 6 │ 1 on │
├───────────────────┼───────┼────────┤
│ .bd 2 \n(IB │ 7 │ 1 on │
├───────────────────┼───────┼────────┤
│ .bd 1 2 │ 8 │ 1 on │
├───────────────────┼───────┼────────┤
│ .bd 2 │ 8 │ 1 off │
├───────────────────┼───────┼────────┤
│ .bd S 3 │ 10 │ 1 on │
├───────────────────┼───────┼────────┤
│ .bd 1 3 │ 12 │ 1 on │
├───────────────────┼───────┼────────┤
│ .bd R │ 13 │ 1 off │
├───────────────────┼───────┼────────┤
│ .bd R 3 │ 13 │ 1 on │
├───────────────────┼───────┼────────┤
│ .bd S 3 3 │ 17 │ │
├───────────────────┼───────┼────────┤
│ .bd 1 │ 27 │ 1 off │
├───────────────────┼───────┼────────┤
│ .bd S B 3 │ 59 │ 2 on │
├───────────────────┼───────┼────────┤
│ .bd I 3 │ 72 │ 1 on │
├───────────────────┼───────┼────────┤
│ .bd I │ 72 │ 1 off │
└───────────────────┴───────┴────────┘
As you can see there are 17 "problem" format 2 calls, and 63 "correct"
(according to Osanna's example), the 2nd most popular bd command.
>
> 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.
A problem is only introduced if the 2nd format is permitted to use font
positions, even though this is not mentioned in the documentation, as it is
for format 1.
>> 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.
>
Except, I find the interface logical, if font positions are only permitted in
format 1.
> [...]
>
>>> $ 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`.
Its a necessary restriction, and so, not silly.
>>> $ 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.
No it couldn't, font positions are not expected in conditional embolding.
>>> 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.
Font positions are not allowed.
> 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.
Two things outstanding:-
Which version of the AT&T docs suggests using ".bd S 3 3", as you stated
above.
Is it possible to run a contemporary troff version (Plan 9) to check whether
it doubles the output of S font glyphs.
Cheers
Deri
> 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
