Follow-up Comment #11, bug #68256 (group groff): At 2026-04-20T00:44:32+0100, Deri wrote: > On Sunday, 19 April 2026 17:14:18 BST you wrote: >> Follow-up Comment #9, bug #68256 (group groff): >> Thanks for your help. I got pretty frustrated yesterday after Lucy >> swiped the football away. > > I get frustated by threats to wipe out a civilisation many times older > than the USofA, when you know someone's got a bet on oil futures!
Hah! Thanks for putting my troubles in perspective. ;-) We can all look forward to getting mad all over again as no one is ever prosecuted for any of this. At worst, Trump and his cronies will get the quiet life, each living on the top floor or two of a five-star hotel in the Middle East, maybe in one of the Emirates or KSA, like Idi Amin. >> 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. > > The conditional format is only for embolding specials, font1 must be > 'special', if you want a bold symbol/dingbat when using a bold text > font it would be useful. ...if the weight of the font it comes from is designed to blend well with that of roman, yeah. Like the C/A/T's. Just flat inapplicable in the modern world. Moreover, I checked and Kernighan is strong support for your claim; in the 1992 revision of CSTR #54, the _only_ documented means of accessing the "conditional emboldening feature" is if the first argument to `bd` is exactly "S". So yeah, I think we want to circumscribe this conditional emboldening feature as tightly as we can possibly get away with. In fact, I can see supporting three arguments to the `bd` request _only_ in compatibility mode. >> 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. > > It is only 'hobbled' in the sense you must use names not positions, I agree, and I don't regard that as a major inconvenience for users, especially given that legacy documents will _have_ to be changed for this use case anyway (or output driver or font support rigged up to resemble a C/A/T). > and the problem with offset being device dependent (which can be > avoided by using 2.4p rather than 2400(u) as the offset). I wouldn't even use points for this, but hundredths of an em (scaling unit: "M"), which would make it somewhat more like the constant-spacing (`cs`) feature. That design choice, however, is for a later ticket as noted previously. (My thinking: "thirty-sixths of an em" isn't available as a scaling unit, but at least it's a linear transformation of ones that exist. I wouldn't be opposed to reforming GNU troff such that it uses a default scaling unit of "M" anywhere it currently expects "twelfths of an em" or "thirty-sixths of an em". Off the top of my head, this would affect the `ss` and `cs` requests. I don't think many people use either. The most popular application of `ss` is to kill supplemental inter-sentence space to satisfy European esthetes and American fools, and they won't be affected thanks to the zero property of multiplication.[1]) >> 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. > > 0.1m as an offset works but it is set at the pointsize at the point of > the .bd command. So the grout 'hnnnn' commands between the double > letters is not dynamic based on changing point size. Hmmmm. Tha't a problem with my proposal, yeah. More design thought will be needed in the aforementioned future ticket. >> 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 > > Just a thought, the > > .bd S 3 3 > > hasn't come from an OCR of a printed copy of the man page source? Nope. Unfortunately it dates all the way back to McIlroy's original man macros. https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/lib/tmac/tmac.an ...and spread all over the place from there. https://github.com/ryanwoodsmall/oldsysv/tree/master $ git grep -F '.bd S 3 3' SysVr2.0_32000/SysVr2.0_32000/dwb/macros.d/an.src:.if t \{.bd S 3 3 Binary file sysv-pdp11_tape/sys_V_tape matches Binary file sysv-pdp11_tape/usr.cpio matches sysv-pdp11_tape/usr/lib/macros/an:.ift \{.bd S 3 3 sysv-pdp11_tape/usr/src/cmd/text/macros.d/an.src:.if t \{.bd S 3 3 sysv-pdp11_usr/lib/macros/an:.ift \{.bd S 3 3 sysv-pdp11_usr/src/cmd/text/macros.d/an.src:.if t \{.bd S 3 3 sysvr4/svr4/lib/zlibeti/man3/menu.3c:.ift \{.bd S 3 3 sysvr4/svr4/lib/zlibetitam/man3/tam.3c:.ift \{.bd S 3 3 sysvr4/svr4/ucbcmd/troff/troff.d/tmac.d/an:.bd S 3 3 sysvr4/svr4/ucbcmd/troff/troff.d/tmac.d/sunman:.bd S 3 3 $ cd ~/src/unix $ find . -type f -print0 | xargs -0 zgrep -F '.bd S 3 3' ./4.3BSD-Tahoe/usr/src/new/news/doc/tmac.n.gz:.bd S 3 3 \" embolden special font chars if B ./4.3BSD-Tahoe/usr/doc/usd/10.etiq/tmac.n:.bd S 3 3 \" embolden special font chars if B ./4.3BSD-Tahoe/usr/doc/usd/09.newsread/tmac.n:.bd S 3 3 \" embolden special font chars if B ./4.3BSD-Tahoe/usr/doc/smm/10.newsop/tmac.n:.bd S 3 3 \" embolden special font chars if B ./TUHS/4.3BSD-Tahoe/usr/src/new/news/doc/tmac.n.gz:.bd S 3 3 \" embolden special font chars if B ./TUHS/4.3BSD-Tahoe/usr/doc/usd/10.etiq/tmac.n.gz:.bd S 3 3 \" embolden special font chars if B ./TUHS/4.3BSD-Tahoe/usr/doc/usd/09.newsread/tmac.n.gz:.bd S 3 3 \" embolden special font chars if B ./TUHS/4.3BSD-Tahoe/usr/doc/smm/10.newsop/tmac.n.gz:.bd S 3 3 \" embolden special font chars if B ./TUHS/4.1cBSD/usr/lib/tmac/tmac.an.new:.bd S 3 3 ./TUHS/4.1cBSD/usr/doc/uprog/p.mac.gz:.bd S 3 3 \" embolden special font in context of 3 ./TUHS/3BSD/usr/lib/tmac/tmac.an.new:.bd S 3 3 ./TUHS/3BSD/usr/doc/uprog/p.mac.gz:.bd S 3 3 \" embolden special font in context of 3 ./TUHS/4BSD/usr/lib/tmac/tmac.an.new:.bd S 3 3 ./TUHS/4BSD/usr/doc/uprog/p.mac.gz:.bd S 3 3 \" embolden special font in context of 3 ./TUHS/V7/usr/lib/tmac/tmac.an:.bd S 3 3 ./TUHS/V7/usr/doc/uprog/p.mac.gz:.bd S 3 3 \" embolden special font in context of 3 ./TUHS/V7M/lib/tmac/tmac.an:.bd S 3 3 ./TUHS/V7M/lib/tmac/tmac.an.orig:.bd S 3 3 ./TUHS/V7M/doc/uprog/p.mac.gz:.bd S 3 3 \" embolden special font in context of 3 ./TUHS/V10/630/man/src/an.gz:.ift \{.bd S 3 3 ./TUHS/V10/cmd/mk/mk.bundle.gz:-.ift \{.bd S 3 3 ./TUHS/V10/cmd/mk/export/tmac.an:.ift \{.bd S 3 3 ./TUHS/V10/cmd/troff/ancient.nroff/macros.d/an.src.gz:.if t \{.bd S 3 3 ./TUHS/V10/cmd/gre/gre.bundle.gz:-.ift \{.bd S 3 3 ./TUHS/V10/man/adm/idiff.out.gz:.ift \{.bd S 3 3 ./TUHS/V10/man/adm/tmac.v10.gz:.ift \{.bd S 3 3 ./TUHS/V10/man/man0/tmac.v10.gz:.ift \{.bd S 3 3 ./TUHS/32V/usr/lib/tmac/tmac.an:.bd S 3 3 ./TUHS/32V/usr/doc/uprog/p.mac.gz:.bd S 3 3 \" embolden special font in context of 3 ./TUHS/V8/usr/lib/macros/an.gz:.ift \{.bd S 3 3 ./TUHS/V8/usr/lib/macros/oan.gz:.ift \{.bd S 3 3 ./TUHS/2BSD/upgrade/man/tmac.an.new:.bd S 3 3 ./TUHS/OpenSolaris_b135/cmd/troff/troff.d/tmac.d/an.gz:.bd S 3 3 ./TUHS/OpenSolaris_b135/cmd/troff/troff.d/tmac.d/ansun.gz:.bd S 3 3 ./TUHS/4.3BSD-UWisc/src/usr.bin/news/doc/tmac.n.gz:.bd S 3 3 \" embolden special font chars if B ./TUHS/Net2/usr/src/share/doc/smm/10.newsop/tmac.n.gz:.bd S 3 3 \" embolden special font chars if B ./TUHS/4.2BSD/usr/lib/tmac/tmac.an.new:.bd S 3 3 ./TUHS/4.2BSD/usr/doc/uprog/p.mac.gz:.bd S 3 3 \" embolden special font in context of 3 ./TUHS/Ultrix-3.1/src/cmd/troff/macros/an.src.gz:.if t \{.bd S 3 3 ./TUHS/4.3BSD/usr/contrib/icon/man/tmac.an.new:.bd S 3 3 ./TUHS/4.3BSD/usr/contrib/news/doc/tmac.n.gz:.bd S 3 3 \" embolden special font chars if B ./TUHS/4.3BSD/usr/doc/usd/10.etiq/tmac.n.gz:.bd S 3 3 \" embolden special font chars if B ./TUHS/4.3BSD/usr/doc/usd/09.newsread/tmac.n.gz:.bd S 3 3 \" embolden special font chars if B ./TUHS/4.3BSD/usr/doc/smm/10.newsop/tmac.n.gz:.bd S 3 3 \" embolden special font chars if B ./TUHS/SunOS-4.1.4/usr.lib/tmac/tmac.an:.bd S 3 3 ./TUHS/2.11BSD/doc/usd/10.etiq/tmac.n.gz:.bd S 3 3 \" embolden special font chars if B ./TUHS/2.11BSD/doc/usd/09.newsread/tmac.n.gz:.bd S 3 3 \" embolden special font chars if B ./TUHS/2.11BSD/doc/smm/10.newsop/tmac.n.gz:.bd S 3 3 \" embolden special font chars if B ./TUHS/4.3BSD-Reno/share/doc/usd/10.etiq/tmac.n.gz:.bd S 3 3 \" embolden special font chars if B ./TUHS/4.3BSD-Reno/share/doc/usd/09.newsread/tmac.n.gz:.bd S 3 3 \" embolden special font chars if B ./TUHS/4.3BSD-Reno/share/doc/smm/10.newsop/tmac.n.gz:.bd S 3 3 \" embolden special font chars if B ./TUHS/4.3BSD-Reno/src/share/doc/usd/10.etiq/tmac.n.gz:.bd S 3 3 \" embolden special font chars if B ./TUHS/4.3BSD-Reno/src/share/doc/usd/09.newsread/tmac.n.gz:.bd S 3 3 \" embolden special font chars if B ./TUHS/4.3BSD-Reno/src/share/doc/smm/10.newsop/tmac.n.gz:.bd S 3 3 \" embolden special font chars if B ./TUHS/Xinu7/lib/tmac.ad.gz:.bd S 3 3 ./TUHS/Xinu7/lib/tmac.an:.bd S 3 3 ./TUHS/2.9BSD/usr/lib/tmac/tmac.an:.bd S 3 3 ./TUHS/2.9BSD/usr/doc/uprog/p.mac.gz:.bd S 3 3 \" embolden special font in context of 3 ./SystemIII/usr/src/cmd/text/macros.d/an.src:.if t \{.bd S 3 3 ./SystemIII/usr/src/man/docs/sh_tut/sc0:.bd S 3 3 ./SystemIII/usr/src/man/docs/~u_prog.macs:.bd S 3 3 \" embolden special font in context of 3 ./SystemIII/usr/src/man/docs/~c_man.macs:.bd S 3 3 \" embolden special font in context of 3 ./SystemIII/usr/src/man/docs/c_lib:.bd S 3 3 ./SystemIII/usr/src/man/docs/advice:.bd S 3 3 ./SystemIII/usr/src/man/docs/mm_card:.bd S 3 3 ./SystemIII/usr/lib/macros/an:.ift \{.bd S 3 3 grep: ./sys3.tar.gz: binary file matches grep: ./Sun_Solaris_2.4_[Sun_SPARC]/solaris_2.4_sparc.iso: binary file matches grep: ./SunOS_3.5_(Tape)_[Sun-3]/sun3_text.tar: binary file matches ./SunOS_3.5_(Tape)_[Sun-3]/root/lib/tmac/tmac.an:.bd S 3 3 ./SysVr2.0_32000/dwb/macros.d/an.src:.if t \{.bd S 3 3 ./svr4/lib/zlibeti/man3/menu.3c:.ift \{.bd S 3 3 ./svr4/lib/zlibetitam/man3/tam.3c:.ift \{.bd S 3 3 ./svr4/ucbcmd/troff/troff.d/tmac.d/an:.bd S 3 3 ./svr4/ucbcmd/troff/troff.d/tmac.d/sunman:.bd S 3 3 ./v8/usr/lib/macros/an:.ift \{.bd S 3 3 ./v8/usr/lib/macros/oan:.ift \{.bd S 3 3 grep: ./Sun_Solaris_2.3_[Sun_SPARC]/solaris_2.3_sparc.iso: binary file matches grep: ./SunOS_3.2_(Tape)_[Sun-2]/tape3/06: binary file matches ./SunOS_3.2_(Tape)_[Sun-2]/root/lib/tmac/tmac.an:.bd S 3 3 grep: ./SysVr2.0_32000.tgz: binary file matches grep: ./SunOS_2.0_(Tape)_[Sun-2]/tape2/02: binary file matches ./SunOS_2.0_(Tape)_[Sun-2]/root/lib/tmac/tmac.an:.bd S 3 3 ./Net2/usr/src/share/doc/smm/10.newsop/tmac.n.gz:.bd S 3 3 \" embolden special font chars if B ./v10/630/man/src/an:.ift \{.bd S 3 3 ./v10/cmd/mk/export/tmac.an:.ift \{.bd S 3 3 ./v10/cmd/mk/mk.bundle:-.ift \{.bd S 3 3 ./v10/cmd/troff/ancient.nroff/macros.d/an.src:.if t \{.bd S 3 3 ./v10/cmd/gre/gre.bundle:-.ift \{.bd S 3 3 ./v10/man/adm/idiff.out:.ift \{.bd S 3 3 ./v10/man/adm/tmac.v10:.ift \{.bd S 3 3 ./v10/man/man0/tmac.v10:.ift \{.bd S 3 3 grep: ./v7.tar.gz: binary file matches grep: ./SunOS_4.0_(Tape)_[Sun-2]/tape2/05: binary file matches ./SunOS_4.0_(Tape)_[Sun-2]/root/share/lib/tmac/tmac.an:.bd S 3 3 grep: ./SunOS_4.0_(Tape)_[Sun-2]/tape1/08: binary file matches ./v7/usr/lib/tmac/tmac.an:.bd S 3 3 ./v7/usr/doc/uprog/p.mac:.bd S 3 3 \" embolden special font in context of 3 ./4.3BSD-Reno/usr/share/doc/usd/10.etiq/tmac.n:.bd S 3 3 \" embolden special font chars if B ./4.3BSD-Reno/usr/share/doc/usd/09.newsread/tmac.n:.bd S 3 3 \" embolden special font chars if B ./4.3BSD-Reno/usr/share/doc/smm/10.newsop/tmac.n:.bd S 3 3 \" embolden special font chars if B ./4.3BSD-Reno/src/share/doc/usd/10.etiq/tmac.n:.bd S 3 3 \" embolden special font chars if B ./4.3BSD-Reno/src/share/doc/usd/09.newsread/tmac.n:.bd S 3 3 \" embolden special font chars if B ./4.3BSD-Reno/src/share/doc/smm/10.newsop/tmac.n:.bd S 3 3 \" embolden special font chars if B grep: ./4.3BSD-Reno/usr.tar.gz: binary file matches grep: ./4.3BSD-Reno/src.tar.gz: binary file matches > Because it is mighty similar to > > .bd S B 3 > > Which does work (if an appropriate offset used). Or the original man > page author forgot his glasses!! Nope, but you can ask Doug why the heck he chose to do it this way. :) >> ...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 > > I'm suspicious this may be a corrupted attempt at the CSTR#54 example, > do any historical groffs handle this? (You don't need the hardware the > grout should show the character doubling with an 'h' command between). Historical groffs appear not to have handled `.bd S 3 3` at all... $ printf '.bd S 3 3\n.ft 3\nHello \\(mu world\\(r!\n' | ~/groff-1.23.0/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 ...but as noted, the input syntax is solidly pedigreed. Since groff 1.24.0, a complaint is issued: $ printf '.bd S 3 3\n.ft 3\n.Hello \\(mu world\\(r!\n' | ~/groff-1.24.0/bin/groff troff:<standard input>:1: warning: ignoring third argument to font emboldening request when first interpreted as mounting position and second as emboldening amount That's not a regression since it didn't work before. Arguably an improvement in that at least it _tells_ you that it's not honoring your request. >> 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).) > > This looks complicated. It is only troff which needs to calculate the > correct distance to send an 'hnnnn' command to grout. So the > calculation would be something like:- > > bd offset / one inch Rvalue * DESC value 'res' > > 3/432*72000=500 (ps/pdf) > 3/432*57816=401 (dvi) > > which looks suspiciously like half a point offset. Except historical troff and groff alike subtract one from the emboldening amount argument first. I'll attaching a screenshot in a separate comment; attempting an attachment in an emailed reply to <[email protected]> seems not to work. > So troff would send 'h500' > or 'h401' instead of 'h3'. > >> You could of course implement rescaling in gropdf before anyone gets >> around to doing this for the other groff drivers. ;-) > > I think it makes more sense to do this in troff so all downstream > drivers benefit. I think both places (GNU troff, libdriver) make sense for different reasons. 1. The `bd` request's specification is parochial, with one of its arguments being defined in terms of basic units. That was a design blunder. It should accept a horizontal measurement like numerous other *roff requests. 2. I twig that if we change GNU troff to assume a scaling unit of `M` for the emboldening offset, we'll get near-workalike behavior for legacy documents. An `M` is one-hundredth of an em. So... AT&T troff on the C/A/T: .bd R 3 3 - 1 = 2u / 432u -> 4.629% offset Proposal GNU troff behavior on any device: .bd R 3 3 = 3M, device res irrelevant, 3% offset relative to type size Hard to be sure, though, since my percentages aren't of the same things. As far as I know no one ever wrote a device-independent troff driver for the C/A/T, and descendants of DWB 2.0 troff (Solaris, Heirloom Doctools, DWB 3.3, Plan 9) seem to support only "post" as a typesetter,[2] and don't honor the `bd` request at all for that device. $ printf '.bd S 3 3\n.ft 3\nHello \\(mu world\\(r!\n' | troff x T post 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 HB x font 8 HX x font 9 S1 x font 10 S s10 f3 H720 V120 cH 78e44l28l28owh83Cmu w88w72o50r44l28dn120 0 x trailer V7920 x stop That's Solaris troff output. DWB 3.3 has only slight differences, none relevant to this discussion. $ diff -U0 solaris.trout dwb.trout --- solaris.trout 2026-04-20 09:12:20.675056340 -0500 +++ dwb.trout 2026-04-20 09:12:09.703100297 -0500 @@ -12,2 +12,2 @@ -x font 7 HB -x font 8 HX +x font 7 HI +x font 8 HB @@ -21,2 +21,3 @@ -78e44l28l28owh83Cmu -w88w72o50r44l28dn120 0 +78e44l28l28owh75Cmu +w80w72o50r44l28dh56Cr! +n120 0 Plan 9 seems not to let me select a typesetter at all. $ printf '.bd S 3 3\n.ft 3\nHello \\(mu world\\(r!\n' | 9 troff \ | head -n 1 x T utf Heirloom's output it a little different, and more readable, but it's the same story: `bd` not honored. $ printf '.bd S 3 3\n.ft 3\nHello \\(mu world\\(r!\n' | heirloom troff x T ps x res 72000 1 1 x init V0 p1 x font 1 R /home/branden/heirloom/lib/doctools/font/devps/R.afm 4 x font 2 I /home/branden/heirloom/lib/doctools/font/devps/I.afm 4 x font 3 B /home/branden/heirloom/lib/doctools/font/devps/B.afm 4 x font 4 BI /home/branden/heirloom/lib/doctools/font/devps/BI.afm 4 x font 5 CW /home/branden/heirloom/lib/doctools/font/devps/CW.afm 4 x font 6 H /home/branden/heirloom/lib/doctools/font/devps/H.afm 4 x font 7 HB /home/branden/heirloom/lib/doctools/font/devps/HB.afm 4 x font 8 HX /home/branden/heirloom/lib/doctools/font/devps/HX.afm 4 x font 9 S1 /home/branden/heirloom/lib/doctools/font/devps/S1.afm 516 x font 10 S /home/branden/heirloom/lib/doctools/font/devps/S.afm 1028 s10 f3 x X LC_CTYPE en_US.UTF-8 H72000 V12000 cH h7780ce h4440cl h2780cl h2780co wf10 h8330Cmu wf3 h8820cw h7120co h5000cr h4440cl h2780cd n12000 0 x trailer V792000 x stop Looks like GNU troff has some room to throw its elbows and redefine the `bd` request to suit its, and our users', needs. 3. Output device resolution rescaling is a separable issue from `bd` request semantics. I brought it up only because it promises the opportunity to get even more authentic reproduction of C/A/T output, specifically in the matter of scaling basic units as the legacy `bd` request expects, if someone's willing to put in the effort. >> 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. > > 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. As noted above, I don't think it is, and Doug McIlroy is around if you want to try to draw him out on the subject. :) > I prefer 'okular -' as a previewer for dvi/ps/pdf. It's my first choice. I sometimes use evince on my desktop machine. I got fed up with Dropbox's viewer (non-free, buggy, not only collects "telemetry" [read: feeds LLM bots and the U.S. surveillance state] but is increasingly intrusive about it) on my tablet and migrated to mupdf, which is mostly better, but I have to reload a document every 4-5 pages or so because it forgets to kick itself back into high-res rendering mode from low-res "you're panning the page" mode. Dumb. Regards, Branden [1] They would have to learn to respell `.ss 12 0` as `.ss \n[.ss] 0`; not changing the paramter you don't want to change is a good practice anyway. Maybe we should model the latter in our documentation sooner rather than later, to give ourselves room to change. [2] Heirloom Doctools troff supports the following devices: html post ps pslow psmed "html" is not a typesetter. The latter four are all PostScript drivers. All are similar. I never looked into these before. "post" uses a DWB-compatible resolution of 720. "ps" uses a groff-compatible 72,000. Hmm, "pslow" uses a C/A/T-compatible resolution of 432! ...and "psmed" uses a resolution of 3600. No comments motivate the existence of any of these. For three, I can surmise a reason for their existence. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?68256> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
