Re: [BUG] "\fC" macro in ox-man.el [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.2/lisp/org/)]

["G. Branden Robinson" <g.branden.robinson@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 7650 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]