groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] Re: man page encoding


From: Bruno Haible
Subject: Re: [Groff] Re: man page encoding
Date: Fri, 8 Jul 2005 13:14:03 +0200
User-agent: KMail/1.5

Andries Brouwer wrote:
> The very long pipeline contains invocations of
> refer, ideal, pic, tbl, eqn, ditroff
> but also lots of preprocessors of my own. If the groff version of refer
> or tbl decides to turn my Latin-1 into UTF-8, then my own preprocessors
> later on in the pipeline will no longer be able to handle the input.
> On the other hand, if they turn stuff into \[...] or \N[...] escape
> sequences, then again my preprocessors are confused since this syntax is
> not traditional troff syntax, and unexpected in the input.

Don't worry here: we don't plan to change 'refer' or 'tbl' to convert
Latin1 input to something else. The plan is that when a user invokes
groff, the constructed pipeline contains an invocation to 'gpreconv'.
A pipeline that you construct by yourself will continue to work.

> Now you say "tough luck", and I don't mind, but if the idea is that groff
> has a compatibility mode ...

The compatibility mode is made for compatibility to AT&T UNIX troff.
At that time, Latin1 as an encoding didn't exist. Therefore it's hard to
argue that -C should imply interpretation of non-ASCII input as being Latin1.

> >   2) We would have low acceptance from the people who produce man pages
> > in EUC-JP, with the consequence that these "-Tnippon" hacks in groff (or
> > equivalent hacks in "man" in some distributions) would need to stay
> > forever.
>
> But you talk as if you are forced to change groff in ugly ways because
> man is set in stone. But it is very easy to change man.

It is not easy to change the opinion of many Japanese people, regarding the
issue of EUC-JP vs. Unicode.

Bruno





reply via email to

[Prev in Thread] Current Thread [Next in Thread]