Thu 19 Feb 2009 10:27:31 PM UTC, comment #2:
The termcap settings you show configure less to emit colour escapes in response to things like intensity changes. I imagine that the reason this doesn't work in the configuration you describe is as follows: when groff is in SGR mode (no -c, etc.), it emits its own ANSI escapes; the -R option to less tells it to pass these straight through to the terminal. The LESS_TERMCAP_* environment variable almost certainly only take effect when less is emitting its own escape sequences in response to the old-style bold/underline sequences ('c BACKSPACE c' or '_ BACKSPACE c'). I don't see how this could possibly work given the combination of groff in SGR mode and 'less -R', unless less started deconstructing the input on the way through and guessing which termcap escapes should be used - which is, I think, expressly contrary to the documentation of -R.
This is really more a matter of groff's default configuration than man-db's default configuration, I feel. For instance, Debian's groff package puts this in /etc/groff/man.local and /etc/groff/mdoc.local (on other systems you might need to put these in /usr/share/groff/site-tmac/ or similar):
.if n \{\
. \" Debian: Disable the use of SGR (ANSI colour) escape sequences by
. \" grotty.
. if '\V[GROFF_SGR]'' \
. output x X tty: sgr 0
.\}
This has the effect of inverting groff's default behaviour as documented in grotty(1), so that instead of being able to set GROFF_NO_SGR=1 to turn off SGR escapes, they're turned off by default and you can set GROFF_SGR=1 to turn them back on.
No matter which way round the default is, though, this environment-based system seems like a fairly reasonable way to configure what you want. If you're already setting a bunch of LESS_TERMCAP_* environment variables to change less' behaviour, then setting GROFF_NO_SGR=1 as well seems like no big deal. I think I prefer this to changing man-db's defaults.
As for -Tutf8, this is a very complex area. -Tutf8 is in fact used by default in very many circumstances; for languages that are basically ASCII or ISO-8859-1, you should always find that -Tutf8 is used provided that you are using a UTF-8 locale.
However, for other languages the situation can be more complex. With versions of groff before 1.20, groff is essentially incapable of taking input in other than ISO-8859-1 (well, there were some special-case ways to approximate it, but not in any way that man-db could reasonably make use of), unless you used the Debian multibyte patch. If you were using that patch, then it was possible to more or less cope by telling groff that it needs to emit the same encoding as it got in, using -Tascii8. This isn't typographically sound, which is why it never made it upstream - groff has no idea what the characters actually are if you do that - but it was a viable stopgap measure for a wide variety of languages for some time. -Tutf8 was no good here because, while it produces UTF-8 output, it expected ISO-8859-1 input.
With groff 1.20, we have the preconv preprocessor, which converts text in any encoding you like into groff's Unicode escape syntax, thus allowing it to be understood by the groff core. Indeed, in that case, man-db will just use -Tutf8, and if necessary stick an iconv pipe on the end to convert to the encoding specified by your locale.
In short: this is a complicated area to get right and it's a serious mistake to just hardcode a single output device (a mistake that the man package commits, but nevertheless that doesn't mean I want to duplicate its mistake!). In order to determine why you aren't getting -Tutf8 and whether this is the right thing or not, I'd need to see the output of man with the --debug option.
|