Hi onf, [replying to 2 messages] At 2025-01-02T15:29:59+0100, onf wrote: > I don't know why it took me so long, but I think what you're looking > for is this: > \fC\f(CRLorem\fR Not a bad idea, but while you're there, given Ihor's ambitious portability objectives, you might as well scoop up the population of troffs that named the font `CW`.[1] So you'd emit `\fC\fCW\fCRLorem\fR`. > Note that I've used the syntax \f(, not \f[], because older > implementations of troff (such as Plan9 troff iirc) don't support it. Right. Plan 9 troff (whether original or "from User Space"), Solaris 10 troff (also used by Illumos)[2], and DWB 3.3 troff, which as far as I know is not used by anyone for real typesetting purposes, but is a valuable specimen for exploring Kernighan troff behavior. At 2025-01-02T22:51:47+0100, onf wrote: > You might find it easier to omit the \fP escapes, since they have > little effect here anyway. Situation might be different if you're > targetting non-troff man processors too, though; no idea how > robust their handling of font changes is. The only one I'd think of trusting is mandoc(1), and since that project consciously limits its own scope, I wouldn't necessarily expect support for a lot of fancy font tricks. > But I agree; I would track each style change (bold -> not bold, > italic -> not italic) and emit an appropriate \f sequence that > would match the currently active styles after each such change, > like so: > code & bold & italic \f[CBI] > code & bold \fC\f(CB > code & italic \fC\f(CI > code \fC\f(CR > bold & italic \f(BI > bold \fB > italic \fI > none \fR > > Note that \f[CBI] will break in old troffs due to the "new" \f[] > syntax, so a warning should probably be emitted. And I have no > idea how good support for {bold,italic} Courier is in older troffs > either. Poor, in general. Where Courier bold-italic existed, it was sometimes called "CX". > (That is assuming Org-mode markup allows code to be styled like that.) > > Also note that if a change involving italic happens between two > non-whitespace characters, like so: > groff(/7/) > > ...an italic correction should be emitted to prevent the two glyphs > colliding into each other: > groff(\,\fI7\fR\/) > where: > \, is left italic correction > \/ is right italic correction So another thing to know here is that these italic correction escape sequences are, yet again, GNU troff extensions. A legacy formatter is likely to render them as if the backslash were absent, which is very much not what you want in your output. I reiterate that Ihor's objective of "everything working everywhere" is a tall challenge. My advice is to the org-mode project is to limit its compatibility horizon to groff, Heirloom Doctools troff, neatroff, and mandoc. I say that not for self-serving reasons[4] but because other implementations are moribund or not aimed at general-purpose use.[5] If org-mode did that, it could ignore the `CW` font whose history I just went to the trouble to explore, and the problem with `\,` and `\/` escape sequences as well. With a little more research we might find that org-mode could disregard `\fC` as well. Having now seen org-mode's man(7) output in the flesh from my own input, I see plenty of room for easy wins and improvements. I'll venture those in a separate discussion as I make time, or as someone throws me questions to answer or problems to solve. Regards, Branden [1] `CW` was the name used for a long time by Kernighan troff as distributed in Unix System V and therefore overlapped with, or was identical to DWB 2.0 troff. (I'm a little unclear on the precise history.) Anyway, that name was supported on some, but not all, devices. $ git grep -w CW | grep DESC SysVr2.0_32000/SysVr2.0_32000/dwb/troff.d/devX97/X97.tim10p/DESC:fonts 5 R I B S CW SysVr2.0_32000/SysVr2.0_32000/dwb/troff.d/devX97/X97.tim12p/DESC:fonts 5 R I B S CW SysVr2.0_32000/SysVr2.0_32000/dwb/troff.d/devaps/DESC:fonts 8 R I B H CW S S1 GR SysVr2.0_32000/SysVr2.0_32000/dwb/troff.d/devi10/DESC:fonts 8 R I B H HI HK CW S SysVr2.0_32000/SysVr2.0_32000/dwb/troff.d/devi10/rasti10/aps-i10/DESC:fonts 55 R I B H CW S S1 GR R.S R.bld I.S I.bld B.S B.bld H.S H.bld S.R GR.R PA.S PA.bld PB.S PB.bld PI.S PI.bld CE.S CE.bld CI.S CI.bld HI.S HI.bld HB.S HB.bld G.S G.bld GI.S GI.bld BI.S BI.bld SM.S CT.S C.S C.bld SC.S TB.S TB.bld GS.S GB.S MR.S MR.bld MI.S MI.bld MB.S MB.bld MX.S MX.bld sysvr4/svr4/cmd/lp/filter/postscript/buildtables/devpost/DESC:fonts 10 R I B BI CW H HB HX S1 S sysvr4/svr4/cmd/lp/filter/postscript/font/devpost/DESC:fonts 10 R I B BI CW H HB HX S1 S sysvr4/svr4/cmd/lp/filter/postscript/font/devpost/DESC.big:fonts 10 R I B BI CW H HB HX S1 S sysvr4/svr4/cmd/lp/filter/postscript/font/devpost/DESC.small:# space. biggestfont is set to the size of the CW font, and will accomodate all sysvr4/svr4/cmd/lp/filter/postscript/font/devpost/DESC.small:fonts 10 R I B BI CW H HB HX S1 S sysvr4/svr4/cmd/lp/filter/postscript/font/devpostaps/DESC:fonts 8 R I B H CW S S1 GR sysvr4/svr4/ucbcmd/troff/troff.d/devaps/DESC:fonts 8 R I B H CW S S1 GR In this System V archive, I get hits on `C` in "DESC" files, but not as font names. (The special character name `*C`, capital Greek gamma, is a common hit.) I get no hits on `CR` (in "DESC" files) at all in this archive. The `CW` font name seems to have originated in Unix System III (1980) but my copy of it doesn't have any "DESC" files. Yet it "does" ship the "Addendum to the NROFF/TROFF User's Manual" (April 1980) document that seems to reflect some of Kernighan's changes (like "compacted macros", a feature later dropped). It's very strange to me to see this accompany a "DESC"-less troff installation. I guess I need to consult an AT&T commercial Unix historian. Another note is that DWB 3.3 retained "CW". Oddly, the dev202 support is stripped out from the Free Software version of DWB 3.3. I don't know why that is. Maybe at the time it was released, Mergenthaler Linotron (or its successor-in-interest) was still unhappy with Bell Labs (or Lucent Technologies, its then successor-in-interest) for reverse engineering their fonts.[3] $ git grep -w CW | grep DESC postscript/devLatin1/DESC:fonts 10 R I B BI CW H HI HB S1 S postscript/devopost/DESC:fonts 10 R I B BI CW H HB HX S1 S postscript/devpost/DESC:fonts 10 R I B BI CW H HI HB S1 S text/devnroff-12/DESC:fonts 5 R I B CW S text/troff/makefile:DFILES=dev202/DESC dev202/R dev202/I dev202/B dev202/S dev202/CW [2] Solaris 11 uses groff for its troff. [3] https://princeton-staging.elsevierpure.com/en/publications/revisiting-a-summer-vacation-digital-restoration-and-typesetter-f [4] It is true that Heirloom Doctools troff, neatroff, and mandoc support the most important/disruptive syntactical extensions of GNU troff. But that situation eventuated before I joined groff development--by several years in most or all instances. groff's dialect of *roff is as close to a lingua franca for this application domain ("traditional Unix typesetting") as we have. [5] I admit I'm a little fuzzy on Plan 9 from User Space's objectives for its troff. I can say that the pace of its development is not swift. I don't think Plan 9 advocates pick up the system to use its typesetter.