Re: [Groff] colorized man pages

[Steffen Nurpmeso]

Larry Kollar <address@hidden> wrote:
 |> Steffen Nurpmeso <address@hidden> wrote:
 |> 
 |>|still working with a text terminal, I'd expect escape codes to
 |>|be your daily bread and butter, not something to scoff at.
 |>|(Unless I'm missing the good-natured, approving irony here?)
  ..
 |>|> It shouldn't be too much work to instrument a few important
 |>|> man and mdoc macros and add an environment variable, say,
 |>|> MANUAL_COLOURS, in equal spirit to LS_COLORS.  In the Linux
 |>|> world there is now a dircolors(1) command which can be used
 |>|> to control LS_COLORS. ...
  ..
 |> For something semantically correct, yes, but – you know i had to
 |> think about it – as a starter being able to define several
 |> mappings wouldn't be that bad.  We have bold and underlined
 |> output, why not warp that on request to something, _if_ the
 |> terminal supports it.  I.e., /dev/tty i guess would have to be for
 |> roff.  Also i think being able to map the plain roff colour names
 |> would then be nice too, the blue that is used for URLs is really
 |> screaming on this terminal, in the context of a manual.
 |
 |AT&T nroff had what they called “drivers,” a compiled data structure \
 |that defined control codes for printer motions. In the early years of \
 |my tech writing career, I wrote one to take advantage of the NEC Spinwriter’\
 |s fractional motions; it supported stretchable spaces. GNU *roff doesn’t \
 |really have that. A custom post-processor might fill the bill, but is \
 |much more complex than a data structure.
 |
 |OTOH, a post-processor that hooked into terminfo could solve the problem \
 |almost automatically, no? If the user’s $TERM supports color, and a manpage \
 |requests color, then the user gets color. A register or string could \
 |be defined to set a color for highlighting bold body text and/or headings.

I was indeed thinking about adding support for termcap/terminfo to
the TTY output device, then.  So it would know whether there are
any #Co/#colors, how much of them, etc.  Screen dimensions (also
taking care for the standard $LINES and $COLUMNS).  It could then
of course also generate the sequences for bold etc. that the
terminal expects instead of using the standard ISO 6429 ones.

(The tty driver seems to use explicit SGR_ITALIC..SGR_NO_ITALIC,
so that there is an exact feature on/off mapping, which should
make this really easy to implement here.  In my own things i have
never done it like that but always presumed ISO 6429, where all
attributes can be turned off with a single command.)

And we surely could have a "simple" mapping mechanism that passes
in some font attribute or colour and gets back something modified.
This may become more complicated the more you look into it because
of the versatile set of output devices.  But this is C++ so this
may even be object based fun in the end.

--steffen