[Groff] Re: man page encoding

[Andries Brouwer]

On Wed, Jul 06, 2005 at 01:50:31PM +0200, Bruno Haible wrote:

Hi Bruno,

Some of your answer sounds as if you interpret my reply differently
than I had intended. On the other hand, I do not disagree with
your proposed plan.

One wants something like (1) a system-wide default, (2) a user locale
that can override (1), (3) coding reported in the file itself, probably
overriding (2).

We have some form of (1) and (2), and you want to add (3), so that is good.


I don't know why you object to labelings of the form
"all files in this directory tree are in this coding".
They are a useful stage in-between a system-wide default
and a user locale.
For example, probably almost all of my old saved mail is in iso-8859-1.
It would be silly to start editing those files and adding a coding line
everywhere. A charset marker file is just fine in such a situation.


> > (2B) Maybe this does not have to work - the requirement is that "man ls"
> > works, not that "groff [options] ls.1" works.
> 
> No, the goal is really that "groff [options] ls.1" works. When a
> translator or man page author wants to view a man page, s/he should
> be able to do so without installing the file in particular directories.

Thanks for being so concerned with my former occupation.
However, I can assure you that I always used man and never groff.
And of course it was never necessary to be in special directories.
Sometimes I had to start an xterm with appropriate font.

A system has lots of text files, and it is unreasonable to want
encoding information in all of them. Especially since many of
these files are automatically generated and parsed again by
other programs.

Somehow we cope. Mostly by having a system-wide default.
And mostly by using programs that are not character-set sensitive.

Since man has to look at the man page, decide whether a decompressor
is needed, decide whether tbl and/or eqn must be invoked, etc,
it seems that inserting an invocation of iconv after the
decompressor and before tbl is also an appropriate job for man.
It seems un-Unix-like to build knowledge about the input character set
into groff, when also iconv exists.


I am not really aware of use of groff other than as a backend to man.
(I have a 1989 monograph in troff, but groff does not handle it -
too many GNU improvements, even compatibility mode is not compatible),
and there is a definite movement away from console/xterm and towards
the use of browsers. If man has to feed text to a browser, it will
also have to add charset info.


Such examples seem to show that putting this input charset handling into groff
is the wrong way to go.

Andries