Follow-up Comment #9, bug #68256 (group groff): Hi Deri,
Thanks for your help. I got pretty frustrated yesterday after Lucy
swiped the football away.
At 2026-04-19T10:41:10-0400, Deri James wrote:
> Follow-up Comment #8, bug #68256 (group groff):
>
> Using the first form of .bd my understanding is that groff treats
> current text font as the glyphs in the current font plus any glyphs
> available in specials, i.e. all glyphs available without switching
> text fonts.
That's certainly how it looks. I never knew that, nor anticipated it.
> So if you 'bd' the current text font all the glyphs available at that
> point will appear bolded, including specials, but if you switch to a
> non-bd font the same special glyph is not bolded. See line 8.
Right. That seems to kill off most or all of the justification for the
"conditional emboldening" feature.
And maybe it should stay dead, or hobbled in the way that it is, in GNU
troff, since legacy documents have no hope of portability using `bd`
requests without alteration anyway. The emboldening amount is
inherently unportable not just among devices, but with respect to the
type size.
I find myself wanting to make GNU troff's `bd` accept a numeric
expression for the emboldening amount (if it doesn't already), and
revise it to assume scaling unit 'M', and revamp any internals as
necessary, so that the overstrike offset you specify scales with the
type size. And then I could get rid of the lugubrious subtraction of
'1' from the specified value as well.
> I can't get the second form to work without using font names rather
> than font positions.
>
> .bd S 3 2400
>
> Yields the warning:-
>
> troff:bd.trf:15: warning: ignoring third argument to font emboldening request
> when first interpreted as mounting position and second as emboldening amount
>
> So I have to use:-
>
> .bd S TB 2400
>
> To achieve the conditional emboldening.
Yup. That's intentional. troffs are pretty much strict left-to-right
parsers, meaning no look-ahead.
Exhibit:
The input
.bd S 3 3
...at one point during lexical analysis looks like this:
.bd S 3
...at which point the request handler has to decide what to do. Is that
"3" an emboldening (offset) amount, or a font mounting position?
I've dithered on how to resolve the ambiguity. We could try scanning
ahead in the input stream, uniquely (or nearly so) among request
handlers, and at some cost in code complexity, or we could decide that
if the first argument is a number, then we _must_ be doing unconditional
emboldening.
Attestations of field usage are scarce.
The ".bd S 3 3" example comes from real Unix System V man pages. The
Ossanna version of CSTR #54 (1976) has the following examples:
.bd I 3
.bd S B 3
...so, if we want to maximize fidelity with historical troff, that
forecloses another principle of disambiguation:
"If the first argument is a font _identifier_ (not a mounting position),
then we _must_ be doing conditional emboldening."
> I don't have a problem with the logic if you document that the first
> form of bolding applies to all glyphs available when the text font is
> selected, which includes any specials.
Well, that's the least-effort aspect of this whole thing since it's what
GNU troff already does. ;-)
I'm not enthusiastic about changing that, either. Which glyphs come
from a symbol is largely unpredictable, and conditional emboldening a
crude instrument.
> And the second form requires both font1 and font2 to be by name not
> position.
That would foreclose an attested historical example:
.bd S 3 3
While I maintain that that request is nearly dead-ass useless on GNU
troff even if interpreted with complete fidelity to AT&T troff
semantics, because the device resolution is way higher than 432
units/inch, I'm not keen to break compatibility with AT&T troff "just
because". I prefer to buy something valuable for GNU troff in exchange.
I don't want to rule out the possibility that someone will write a C/A/T
simulator as a GUI app and then we can write a "grocat" output driver
for it. (John Gardner pretty much did the former, but unfortunately it
was/is in JavaScript.)
Another, possibly equally remote possibility, is that someone will
follow up on a trail of bread crumbs that Bernd Warken left regarding
adding some kind of machinery (I guess in "libdriver") for rescaling of
device output at rendering time. That would probably be the best
solution for folks like Clem Cole who are applying groff to the task of
re-rendering 1980s Unix documentation. I don't think he cares much
about the C/A/T per se, since he's producing PDFs.
So if he could do something like this:
$ groff -t -C -M ./HISTORY/MAN/1983-01-SystemV -m ansvr1 \
-T ps -P -R 432 \
SPECIMENS/clem-man-page/750ops.8 \
| ps2pdf > SPECIMENS/clem-man-page/750ops.8.pdf
...I think that would largely meet his use case, where `-R` is a
notional new option for troff-mode output drivers that tells them to
interpret measurements in the grout stream as being with respect to the
device resolution stated in its argument instead of that declared in the
"DESC" file. (I think that would also require recomputation of other
measurements read from the "DESC" file. But not font metrics, because
those are effectively dimensionless: see groff_font(5).)
You could of course implement rescaling in gropdf before anyone gets
around to doing this for the other groff drivers. ;-)
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.
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.
Future tickets:
A. Apply new semantics to the "emboldening amount". Accept a scaling
unit. Default it to "M" when not in compatibility mode. Do not
subtract 1 from the argument, even if basic units are explicitly
specified.
In compatibility mode, preserve existing behavior.
i. Default the scaling unit to "u", rejecting others.
(If you want groff's better semantics back, use `.do`.)
ii. Subtract 1 from the emboldening/offset amount when storing it.
iii. Add 1 to the value of the `.b` register when reporting it.
(If you want the true value, use `.do`.)
B. Request output device rescaling to an overriding resolution. If we
do this, maybe we can make gxditview(1) exercise the feature, making
it a previewer for any device?
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?68256>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
