> > 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 <schwa...@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. >
