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 _______________________________________________ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
