Update of bug #68256 (group groff):
Assigned to: gbranden => deri
_______________________________________________________
Follow-up Comment #23:
[comment #21 comment #21:]
>>> 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)."
Yup, I see it.
> 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."
That, I remembered. Plus "Ignored in nroff." :)
>>> 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".
It doesn't say those words exactly. Here's what the current version of the
manual in Git says.
"Some requests and escape sequences apply simple transformations to glyph
shapes, or draw rules beneath the text baseline (underlining). These features
are largely vestiges of the days when output devices lacked a wide variety
of fonts, and when nroff and troff were separate formatters. GNU troff
retains support for them even though they are seldom needed nowadays."
("5.19.7 Font Effects and Underlining", p. 156)
> 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.
Theoretically. Trouble is, it's been broken for a long time and apparently
few people noticed.
In AT&T _troff_, "a long time" suggests since DWB 2.0 circa 1984, since every
surviving version of AT&T device-independent troff with source code available
fails to implement the conditional emboldening feature, per my experiment
below.
Maybe in Kernighan's private version of troff, it worked.
If _groff_ broke it, recently or otherwise, I think it should live again only
under a new name that avoids the ambiguous semantics that have been
frustrating me.
>> 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
Moreover, as a recent ticket (bug #68497) points out, this "rare" control line
occurred in the _man_(7) macro package of AT&T _troff_, making it among the
more common specimens in existence.
> but there are many more instances of ".bd S B
> 3".
When counting lexically, maybe. When counting by execution traces, I suggest
that's extremely unlikely.
> 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.
I was not sure, and I am increasingly confident that it either never actually
did, or has been broken for decades.
$ cat EXPERIMENTS/bd-S-3-3.roff
.if \nB .bd S 3 3
.ft B
Had we world enough +\(mi\(mu\(di\(** time.\|.\|.
$ cat /tmp/68256
$ solaris10 troff -rB0 EXPERIMENTS/bd-S-3-3.roff >|solA
$ solaris10 troff -rB1 EXPERIMENTS/bd-S-3-3.roff >|solB
$ dwb troff -rB0 EXPERIMENTS/bd-S-3-3.roff >|dwbA
$ dwb troff -rB1 EXPERIMENTS/bd-S-3-3.roff >|dwbB
$ 9 troff -rB0 EXPERIMENTS/bd-S-3-3.roff >|p9A
$ 9 troff -rB1 EXPERIMENTS/bd-S-3-3.roff >|p9B
$ heirloom troff -rB0 EXPERIMENTS/bd-S-3-3.roff >|heirA
$ heirloom troff -rB1 EXPERIMENTS/bd-S-3-3.roff >|heirB
$ diff -u heir* && echo SAME
SAME
$ diff -u sol* && echo SAME
SAME
$ diff -u p9* && echo SAME
SAME
$ diff -u dwb* && echo SAME
SAME
-verbatim-
>> "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.
Why not be flexible here, and scotch the three-argument form?
> 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.
I do. I have the 1976, 1981, and 1992 editions.
> If you have a document which gives ".bd S 3 3" as an example I would
> love to add it to my collection.
https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/lib/tmac/tmac.an
https://www.tuhs.org/cgi-bin/utree.pl?file=32V/usr/lib/tmac/tmac.an
https://www.tuhs.org/cgi-bin/utree.pl?file=4BSD/usr/lib/tmac/tmac.an.new
https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/lib/macros/an
https://www.tuhs.org/cgi-bin/utree.pl?file=Ultrix-3.1/src/cmd/troff/macros/an.src
https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/lib/macros/an
https://www.tuhs.org/cgi-bin/utree.pl?file=pdp11v/usr/lib/macros/an
> 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.
That's a good analysis of lexical relative frequency. The prevalence of ".bd
S 3 3" in the man(7) package means that it was _executed_ many times.
Apparently uselessly. I do observe that late 4.xBSD fixed it and adopted your
preferred form.
> 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.
This could be a case of cargo-culting blunder. However I further note the
following.
$ cat EXPERIMENTS/bd-S-B-3.roff
.if \nB .bd S B 3
.ft B
Had we world enough +\(mi\(mu\(di\(** time.\|.\|.
$ solaris10 troff -rB0 EXPERIMENTS/bd-S-B-3.roff >|solA
$ solaris10 troff -rB1 EXPERIMENTS/bd-S-B-3.roff >|solB
$ dwb troff -rB0 EXPERIMENTS/bd-S-B-3.roff >|dwbA
$ dwb troff -rB1 EXPERIMENTS/bd-S-B-3.roff >|dwbB
$ 9 troff -rB0 EXPERIMENTS/bd-S-B-3.roff >|p9A
$ 9 troff -rB1 EXPERIMENTS/bd-S-B-3.roff >|p9A
$ heirloom troff -rB0 EXPERIMENTS/bd-S-B-3.roff >|heirA
$ heirloom troff -rB1 EXPERIMENTS/bd-S-B-3.roff >|heirB
$ diff -u sol* && echo SAME
SAME
$ diff -u dwb* && echo SAME
SAME
$ diff -u p9* && echo SAME
SAME
$ diff -u heir* && echo SAME
SAME
So the feature appears to be stone broken in AT&T _troff_, whether one employs
the "more correct" syntax or not.
>> 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.
I don't find the interface logical when just about every place one can specify
a font identifer, a font mounting position is accepted instead. It makes the
code more complex to add special request-specific parsing rules.
The `fzoom` request hand-waved around these difficulties, and a result
exhibited bizarre and buggy behavior for years. See bug #64505.
>> [...]
>>
>>>> $ 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.
Only necessary if you're wedded to fulfilling a promise AT&T _troff_ decided
it wasn't worth keeping.
I don't think having special rules that _sometimes_ font mounting positions
can be used in lieu of identifiers is a good direction for the
comprehensibility and maintainability of the language.
I'd sooner see if I can fix `fzoom` to accept a mounting position as an
argument (but still reject it if that position corresponds to an abstract
style) than to let this camel's nose any further into the tent.
> No it couldn't, font positions are not expected in conditional embolding.
They are according to a long tradition of _man_ macro package authorship.
But at the same time, it seems few people actually expected conditional
emboldening to work at all, because they didn't notice when it didn't.
> Font positions are not allowed.
**Why**? Don't say "because they don't work". Lots of stuff didn't work in
AT&T troff.
Tell me why a newcomer to troff would expect that exception to the language's
rules.
> Two things outstanding:-
>
> Which version of the AT&T docs suggests using ".bd S 3 3", as you stated
> above.
Just a bunch of examples in the most famous macro package of all; see above.
> Is it possible to run a contemporary troff version (Plan 9) to check whether
>
> it doubles the output of S font glyphs.
Yes!
[comment #22 comment #22:]
> Self follow up!
>
> I grabbed "https://github.com/n-t-roff/Plan9_troff.git"; which compiled with
> warnings using fairly old gcc on Mageia (failed to compile on up-to-date
> Debian). tr2post segv's, however troff does produce grout, the only device is
>
> utf.
>
> Things to note:-
>
> Since the device is utf, all unicode characters are in the "current" font, so
>
> using \(mu does not switch to Symbol font since it assumes it is present in
> the current text font.
Right. So in that sense, this was not a valid experiment. However, as far as
I can tell it reached a conclusion consistent with "proper" typesetter
behavior.
> This means the conditional form of .bd is obsolete
> because it will never switch to a Special font.
Right. I think the conditional form of `bd` is obsolete for additional
reasons.
> Using this script:-
> [derij@pip Plan9_troff (master)]$ cat bdtest.ms
> .bd S 3 4
> \fB8\(mu8\fR
> The following grout produced:-
> troff/nroff version March 11, 1994
> invoke request ds
> invoke request ds
> invoke request bd
> x T utf
> x res 720 1 1
> x init
> V0
> p1
> x font 1 R
> x font 2 I
> x font 3 B
> x font 4 BI
> x font 5 CW
> x font 6 H
> x font 7 HI
> x font 8 HB
> x font 9 S1
> x font 10 S
> s10
> f3
> H720
> V120
> c8
> h50Cmu
> 558n120 0
> x trailer
> V7920
> x stop
> There is no "bolding" and no switch to font S (f10).
Yup. In my examples shown above, the "trout" **does** change if I don't
switch to font "B": all the horizontal motions get a little smaller. Just as
we'd expect, since bold fonts are "fatter".
> This shows that p9roff (this version at least) does not support conditional
> .bd at all because it never switches to the S font, and ignores the 3rd
> parameter.
>
> If the test script is changed so that "\fS\(mu\fB" is used rather than just
> "\
> (mu", the grout changes:-
> [derij@pip Plan9_troff (master)]$ troff -d -t255 bdtest.ms
> troff/nroff version March 11, 1994
> invoke request ds
> invoke request ds
> invoke request bd
> x T utf
> x res 720 1 1
> x init
> V0
> p1
> x font 1 R
> x font 2 I
> x font 3 B
> x font 4 BI
> x font 5 CW
> x font 6 H
> x font 7 HI
> x font 8 HB
> x font 9 S1
> x font 10 S
> s10
> f3
> H720
> V120
> c8
> f10
> h50Cmu
> h2Cmu
> f3
> 558n120 0
> x trailer
> V7920
> x stop
>
> NOTE: 'mu' is bolded by 'h2' (one less than the 2nd param) so again this is
> unconditional bolding, and the 3rd arg has been ignored.
> What have I learned?
>
> p9roff does not handle '.bd S 3 3' properly.
>
> Because the only output device is 'utf' it never has to switch to a 'special'
>
> font, so conditional bolding is obsolete.
>
> This is probably not the Plan 9 roff before unicode was 'invented'.
All the evidence I can gather suggests that the feature's been broken for
about 40 years.
Except, maybe, in Kernighan's unobtainium private version, which apparently he
no longer maintains, as he's on record as a _groff_ user--at least when
collaborating with others.
_The Go Programming Language_ says in its colophon:
"Typeset by the authors in Minion Pro, Lato, and Consolas, using Go, groff,
ghostscript, and a host of other open-source Unix tools".
I move that we ditch the three-argument form of the `bd` request and thus the
conditional emboldening feature. I can add a footnote to our manual
explaining the wretched history.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?68256>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
