Re: [Groff] Problems with unwanted unicode.

[Werner LEMBERG]

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

No progress yet, sorry.  I have still a lot of bug fixes to apply to
the 1.17 series which takes almost all my time.

> 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 beginners.

If you have followed the discussion about the pre- and postprocessors
to convert anything to and from Unicode, you already know the solution
we've found and which will be eventually implemented.

> Currently, we (Japanese Debian developers) have discussion on the
> way to handle this problem, and two approache is considered.
>
>  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.
>
> [...]
>
> But anyway some method to specify the encoding is required for
> pre-processor, isn't it?  And if so, then which way is prefered,
> A or B above, or something else?

Both methods.  First, groff will look into the environment, checking
the locale.  Then there will be two command line options to select the
input and output encoding, overriding the environment.  Finally, there
will be an Emacs-like syntax comment (`-*- coding: ... -*-') at the
beginning of the file itself to override the input encoding.

> 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.

I think that it shouldn't be too difficult to integrate it as soon as
Unicode support is here.


    Werner