Follow-up Comment #13, bug #68256 (group groff): On Monday, 20 April 2026 22:18:06 BST G. Branden Robinson wrote: > 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). >
[derij@pip build (master)]$ printf '.bd S R 4M\nGoodbye \(mu cruel world\[r!]
\n'|groff -Z
x T ps
x res 72000 1 1
x init
p1
x font 5 TR
f5
s10000
md
DFd
V12000
H72000
tGoodbye
wx font 11 S
f11
h2500
Cmu <---
h399 |--- the mumu
Cmu <---
wf5
h7990
tcruel
wh2500
tw
H149159
torld
Cr!
h3330
n12000 0
x trailer
V792000
x stop
> $ 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.
You are correct, conditional .bd using a font position (3) as 'font2' has
never 'worked', but using font names with a sensible offset (not 3 - .003 of a
point) it does, and is useful in the following case:-
.ps 18
.vs 22
.nf
.ft B \" using TB
This is bold
3 \[mu] 3 = 9
lets strengthen the symbol
.bd S B 4M
3 \[mu] 3 = 9
Not perfect but I think an improvement. (See attached)
> 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.
It works perfectly if font1 and font2 are font names, and sensible offset, and
has real life usefulness if your text font is bold and you don't want any
specials to appear under-weight.
> 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.
Currently first arg MUST be a font name to work, so adding code to also accept
a font position is not a simplification. Have you examples of '.bd 3 3' in the
wild?
> 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.
>
But it is supported (see above - the mau-mau are uprising!), what is not
supported is using font-positions rather than names.
Cheers
Deri
(file #58490)
_______________________________________________________
Additional Item Attachment:
Name: bd.png Size: 5.0KiB
<https://file.savannah.gnu.org/file/bd.png?file_id=58490>
AGPL NOTICE
These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://savannah.gnu.org/source/savane-f290f6b25beb8cb99bbe243a6cd2c5fef79ffcde.tar.gz
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?68256>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
