[Top][All Lists]

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

Re: [Groff] Problems with unwanted unicode.

From: Taketoshi Sano
Subject: Re: [Groff] Problems with unwanted unicode.
Date: 12 Jul 2001 00:55:49 +0900
User-agent: Semi-gnus/6.10.12 SEMI/1.12.1 ([JR] Nonoichi) FLIM/1.12.7 (YĆ«zaki) Emacs/20.7 (i386-debian-linux-gnu) MULE/4.0 (HANANOEN)


> Date: Tue, 10 Jul 2001 11:22:59 +0900
> From: Tomohiro KUBOTA <address@hidden>
> To: address@hidden
> Subject: Re: [Groff] Problems with unwanted unicode.

> The Japanese patch seems to assume input text as EUC when devices
> other than -Tascii8 and -Tlatin1 are selected.  (I.e., using -Tps
> will enable EUC mode).  I am now planning to submit a patch which
> enable EUC mode only under -Tnippon device.
> (src/include/eucmac.h for detail.  "grep latin1 eucmac.h" will
> immediately bring you to the problematic codes.  Note again;
> use Debian source package.)
> However, this problem is come from the poor initial design of groff,
> where -T option is used for specifying device _and_ encoding.  Thus,
> my patch might annoy Japanese people because Japanese people will
> be located into the situation like you (Cannot use -Tps) with my
> patch.

I had seen some mails about future plan of groff on this list.
How do they go now ?  Any progress ?

On Linux systems, the manpages are rendered by using groff.
If groff can't handle an encoding for a language, then users
who need the manpages in that language can't have the working
online manuals in the system, and it is critical defect for

Currently, we (Japanese Debian developers) have discussion
on the way to handle this problem, and two approache is

 A) add the new groff command line option for encoding
   A-1) unify terminal device type from ascii/ascii8/latin1/
        nippon/utf8 into tty (maybe), and add the new option
        to switch various encodings.

   A-2) simply add the switch for euc-jp encoding (--eucmode)
        The patch for this has been already provided.

 B) add the new roff command such as ".x-encoding  EUC-JP"
    for input encoding switch.  With this approache, users
    do not need to specify the appropriate option for various
    encodings, since groff can handle them automatically
    according to the document (input file) itself.
I have read the mails that future groff will be able to handle
unicode well, and support for encodings are provided by pre/post-

But anyway some method to specify the enconding is required
for pre-processor, isn't it ?  And if so, then which way is
prefered, A or B above, or something else ?

 Request from users: If ascii and latin1 will remain for backward
compatibility, then please add "nippon" device as well. It is
used for years, and there are many programs (including XFree86
doctools) which use it for support of Japanese documents.
If you cut off it, then you will cut off many users at once.

  Taketoshi Sano: <address@hidden>,<address@hidden>,<address@hidden>

reply via email to

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