Hi Anton, At 2023-11-19T14:53:24+0300, Anton Shepelev wrote: > `groff -man -Tutf8' does not seem to handle font > styles on my terminal. I have made sure that plain > `groff' works as expected: > > This is > .ft B > strange > .ft R > indeed. > .pl \n[nl] > > The word `strange' above is typeset in bold, which > on my terminal looks both bright and bold. A test > man-page, however, is output all in the same default > font style and color: > > .TH 3 test > .SH Section > This is > .B strange > indeed. > > whereas `man -l` renders the same source correctly, > with the words `Section' and `strange' highlighted > and bold. > > The incorrect output from -man shows that it tries > to make characters bold by typing them over, e.g.: > > s^Hst^Htr^Hra^Han^Hng^Hge^He
Yes, that's the overstriking convention originally developed for paper-based terminals. People have clung to it like grim death. By default, groff uses ECMA-48 SGR escape sequences to change the font styles for terminals. (Specifically, grotty(1) handles this, and its man page has a discussion of the issues.) However, this default has been unpopular in some quarters despite the silliness of having nroff prepare output for a _paper_ terminal when writing to a terminal emulator that is set up _specifically_ to emulate a _video_ terminal (often, something like a DEC VT100, which supports many ECMA-48 features). The short version is that distributors sometimes modify groff to force the overstriking convention, for a variety of (IMO, bad) reasons. I hadn't heard of anyone making this change only for man pages, though. Some new deviltry may be afoot on your system. > instead of using ANSI control codes, and this has no > intended effect. How can I cause `-man -Tutf8' to > use ANSI codes? Check your environment for variables named "GROFF_SGR" (a Debianism) and "GROFF_NO_SGR". Unset them both and try "groff -man -Tutf8" again. Regards, Branden
signature.asc
Description: PGP signature
