Follow-up Comment #12, bug #68256 (group groff): At 2026-04-18T11:49:22-0400, G. Branden Robinson wrote: > So GNU _troff_ has, since its birth, for practical purposes, been > ignoring the `bd` request when formatting C/A/T-era inputs for > PostScript or PDF. Technically, it hasn't (always) ignored them, but > the result has been invisible, at least on video displays. Ink-based > rendering might still work.
These claims were a mixture of truth and falsehood. They were not based
on empirical observation of program behavior, but my _understanding_ of
the source code (imperfect in any case, no doubt due both to its
complexity and the viscosity of my cerebral porridge).
GNU troff has ignored `bd` in its "conditional emboldening"
configuration at least since groff version 1.22.3 (November 2014).
$ printf '.bd S 3 3\n.ft 3\nHello \\(mu world\\(r!\n' |
~/groff-1.22.3/bin/groff -Z
x T ps
x res 72000 1 1
x init
p1
x font 38 TB
f38
s10000
V12000
H72000
md
DFd
tHello
wx font 11 S
f11
h2500
Cmu
wf38
h7990
tw
H112390
torld
Cr!
h3330
n12000 0
x trailer
V792000
x stop
Attend to the lines starting "t".
As Deri pointed out, we should see each glyph show up twice if
overstriking is occurring.
For ease of comparison, let's hash that output:
$ printf '.bd S R 3\n.ft 3\nHello \\(mu world\\(r!\n' |
~/groff-1.22.3/bin/groff -Z | cksum
3273620363 184
...and compare it to hashes of other inputs.
$ printf '.bd S R 3\n.ft 3\nHello \\(mu world\\(r!\n' |
~/groff-1.22.3/bin/groff -Z | cksum
3273620363 184
$ printf '.bd S TR 3\n.ft 3\nHello \\(mu world\\(r!\n' |
~/groff-1.22.3/bin/groff -Z | cksum
3273620363 184
There seems to be no way to exercise the conditional emboldening
feature. The situation remains unchanged through every _groff_ release
since.
$ for v in 1.22.4 1.23.0 1.24.0 1.24.1; do echo $v; printf '.bd S 3 3\n.ft
3\nHello \\(mu world\\(r!\n' | ~/groff-$v/bin/groff -Z >| /tmp/more.grout;
diff -U0 68256.grout /tmp/more.grout; done
1.22.4
1.23.0
1.24.0
troff:<standard input>:1: warning: ignoring third argument to font emboldening
request when first interpreted as mounting position and second as emboldening
amount
--- 68256.grout 2026-04-20 15:53:58.156091297 -0500
+++ /tmp/more.grout 2026-04-20 15:56:27.463309586 -0500
@@ -8,2 +7,0 @@
-V12000
-H72000
@@ -11,0 +10,2 @@
+V12000
+H72000
1.24.1
troff:<standard input>:1: warning: ignoring third argument to font emboldening
request when first interpreted as mounting position and second as emboldening
amount
--- 68256.grout 2026-04-20 15:53:58.156091297 -0500
+++ /tmp/more.grout 2026-04-20 15:56:27.487309462 -0500
@@ -8,2 +7,0 @@
-V12000
-H72000
@@ -11,0 +10,2 @@
+V12000
+H72000
Recalling comment #11:
>>> So, I ventured a lot of ideas in the foregoing. What to actually
>>> do about this ticket? I guess the following:
>>>
>>> 1. Own (and explain/document) the "incompatibility" arising from
>>> emboldening of "special" characters. This is just what GNU
>>> troff does, and slavish AT&T fidelity would buy almost nothing
>>> since today's symbol fonts are populated with glyphs
>>> differently than the C/A/T's "S" font was.
...and as the screenshots in comment #1, comment #6, and comment #7
show, and as Deri explained, any glyphs resolved while the selected
font is emboldened will also be emboldened. So in GNU troff there is
_no need_ for conditional emboldening. If you have configured
emboldening of the current font, glyphs from "special" fonts get
emboldened already.
However, your choice of emboldening/overstriking amount must suffice to
make the effect visible.
>> Agreed.
>>
>>> 2. Decide on a disambiguation scheme for the two `bd` request
>>> semantics. If one can scheme supports Ossanna's `.bd I 3`
>>> (unconditional) and `.bd S B 3` and System V's `.bd S 3 3`
>>> without requiring the request handler to scan ahead, that's
>>> the way to go.
>>
>> If .bd S 3 3 is not just a mistake.
I believe I've established that this usage is not a mistake. However
I don't think it's something groff can usefully act upon.
So I'm amending my planned remedy.
2. `#if 0`-out all the code having to do with conditional emboldening.
3. Simplify the `bd` request handler to always interpret its first
argument as a font mounting position or identifier (like `ft`)--this
is already the case--and the second argument always as an
emboldening offset in basic units.
4. In the `bd` request handler, if compatibility mode is enabled and an
argument is still pending after interpreting the second, throw a
warning in category "style" advising the user that conditional
emboldening is not supported, and treat the request as a no-op.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?68256>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
