Re: [groff] 03/09: tmac/an-old.tmac: Stop remapping ` and '.

[John Gardner]

>
> A different way to talk about it, maybe more clearly, would be to talk
> about a "literal mode", which would have two distinct effects:


That's already possible using the .tr and .eo requests. Best not to
duplicate existing functionality.

In man(7) - or more precisely, in man-ext - the .EX macro already does .do
> fam C .


Trouble is, many authors don't use .EX in practice. Instead, it's quite
common to see stuff like this:

.RS
.nf
\&*code*
\&*goes*
\&*here*
.fi
.RE


Stuff like this is what we should be fixing, IMHO.

On Tue, 3 Nov 2020 at 22:22, Ingo Schwarze <schwarze@usta.de> wrote:

> Hi John,
>
> this seems a bold, novel, and interesting idea to me.  I'm not yet
> completely sure whether it's viable, but it might be.  I'm not sure
> how difficult it would be to implement in groff.  In mandoc, it is
> certainly possible.
>
> The rest of this reply addresses a few details.
>
> Yours,
>   Ingo
>
>
> John Gardner wrote on Mon, Nov 02, 2020 at 11:24:49PM +1100:
>
> > I think it's time we took constant-width fonts seriously when
> > preparing output for the terminal. Here me out on this:
> >
> > You see, I've never, *ever* needed fancy typography when typesetting
> > code samples, which are invariably set in a fixed-pitch (monspace)
> > typeface.
>
> I agree.  That's often done, it's not always done, but would almost
> always be the right thing to do.
>
> > The use of a fixed-pitch font stipulates the author's expectation
> > that that verbatim input should *stay* verbatim.
>
> This may not be true in every conceivable typesetting situation.
> But in manual pages, i do agree that's a very reasonable assumption.
>
> Besides, even in the very unusual case of an author desiring
> curly quotes in a fixed-width font in a manual page, they can
> readily use \(oq...\(cq even when the rule you propose is in force.
>
> > On the other hand, nobody in their right mind would deliberately
> > write source-code in a proportional typeface, so we can trust the
> > use of Georgia or Helvetica to indicate body text - stuff
> > for reading and styling.
>
> There might be exceptions in some unusual typesetting situations
> (e.g. obfuscated code contests / ASCII art and the like), but in
> manual pages, again, i think this is a completely reasonable
> assumption.
>
> Besides, even in the very unusual case of an author desiring
> to display code in a proportional font, they can readily
> use \(aq and \(ga to get ASCII ' and ` printed.
>
> > So in all seriousness, we should be revising our man pages to produce
> > better-looking monospaced output. Have you tried viewing your average
> > man(7) user's "EXAMPLES" section as PostScript? It's rarely pretty
> > because authors don't care about switching between proportional and
> > constant-width typefaces. After all, why *would* you if you only care
> > about terminal output?
>
> While your argument makes sense, note that part of the infrastructure
> already *is* in place:
>
>  * In man(7) - or more precisely, in man-ext - the .EX macro
>    already does .do fam C .
>  * In mdoc(7), .Bd -literal .Dl .Li .Ql .Dv .Er .Ev
>    already do .nop \*[doc-Li-font]\c
>    which is \f[C] in troff mode and \f[R] in nroff mode
>
> > Currently, \f(CW is meaningless in -Tutf8 or -Tascii output, but it could
> > very well be exploited to know which quotes are appropriate to remap, and
> > what portions of an author's document to keep our grubby meathooks off
> of.
>
> From a user's perspective, that does make sense to me.
>
> A different way to talk about it, maybe more clearly, would be to talk
> about a "literal mode", which would have two distinct effects:
>
>  * set ASCII characters verbatim, even ' - ^ ` ~
>    with the only exception of \ which still needs to be \e or \[rs]
>  * use a fixed-width font
>
> What do you think?
> Is that logically sound, and is it feasible?
> In mandoc, it is clearly feasible.
>
> It also seems manageable from the perspective of maintaining large
> collections of manual pages, and it will definitely improve average
> typographic quality.
>