[debian-devel:13077] Re: jgroff patch handling on latin1(Re:linuxdoc-tools: no Korean .txt output!)

[Taketoshi Sano <kgh12351@xxxxxxxxxxx>]

佐野＠浜松です。

In <200010160828.RAA05272@xxxxxxxxxxxxxxxxxxxxxxxx>,
 on "Mon, 16 Oct 2000 17:28:05 +0900",
  Nozomi Ytow <nozomi@xxxxxxxxxxxxxxxxxx> さん wrote:

> > Debian package レベルでの対処については debian-i18n で OK でしょう。
> 
> 誤解があるようだ。(どっちに、かはわからない)

上記の「Debian package レベルでの対処」っていうのは、

   「Debian woody (開発版) で既存の jgroff パッチをメインの groff パッケージに
   統合した (つまり Debian 上で標準の groff が jgroff に化けた) ことにより、
   従来 (2.2 potato までは) -Tlatin1 で問題無く表示できた roff データ
   (ko_KR.eucKR や ru_RU.KOI8-R などでコード化されたテキスト) が、まったく
   表示されなくなってしまった (= 現状の Debian woody では groff を使って
   これらのデータを整形処理できなくなってしまった) 問題と、これに付随して
   ko, ru, pl などの manual page が端末上で (X 上でも) 表示できなくなって
   しまった問題」をできるだけ早く解消すること

を指しています。具体的には -Tlatin1 (および -Tascii8) が指定された場合は
 jgroff パッチによる影響をキャンセルして、オリジナルの groff と互換な動作
をするように戻すこと、です。

なので、文字集合変換の話とかは、これについては関係無いです。
そこまで実装されていませんから。

 jgroff patch でも単に ja_JP.eucJP なデータを通せるようにしたという
だけで、例えば ja_JP.sjis とか ja_JP.jis なデータは通せないですよね ?
試しにちょっと ja_JP.eucJP な manual page  (man/ja/man1/ls.1.gz) を
もってきて、nkf -s や nkf -j でコードを変換したものを groff -Tnippon で
処理してみましたが、エラー出まくりでしたし、処理結果も全然読めないもの
でした。

この「文字コードに依存した動作」が「現状」の実装なわけです。

で、このレベルで、とりあえず「man page が読めない」という問題を
解消しようとすると、-Tlatin1 などの条件を見て処理を分岐させるしか
無いだろうなと思ってます。


鵜飼さんと久保田さんが進めているのは、この「文字コード依存」な部分を
できるだけ減らして、とりあえず sjis, jis, utf8 などでコード化された
 roff データであっても (もちろん日本語以外の言語で書かれた、これら
以外のコードで保存されたデータであっても)、ちゃんと処理できるように
しよう、という話だと思っています。

で、このレベルの話は groff の upstream (オリジナルバージョンの
コード開発者) と一緒に作業していかないとダメだろうと思ってるわけです。

さいわいにも debian-i18n に Werner Lemberg <wl@xxxxxxx> が
フォローしてくれて、久保田さんのメールに前向きに反応してくれて
いるようなので、うまく話を持っていければこちらの方向についても
なんとか進められそうです。:) あとはどれだけ作業してくれる人が
集まるかどうか、ですね。

例えばこの作業について、作業者募集のメールを linuxtech とか
 li18nux に流すとかいうのはありだと思ってます。

> /usr/share/man/ja 
> 
> の、share って、そもそもナニ?

 FHS の規定では、異なるアーキテクチャ間で共用できるデータ、ただし
 OS が異なる場合や、同じ OS でもリリースが異なる場合には共用不可で
あっても良い、となっています。

/usr/share -- Architecture-independent data

The /usr/share hierarchy is for all read-only architecture independent
data files.  Much of this data originally lived in /usr (man, doc) or
/usr/lib (dict, terminfo, zoneinfo).  This hierarchy is intended to be
shareable among all architecture platforms of a given OS; thus, for
example, a site with i386, Alpha, and PPC platforms might maintain a
single /usr/share directory that is centrally-mounted.  Note, however,
that /usr/share is generally not intended to be shared by different OSes
or by different releases of the same OS.

Any program or package which contains or requires data that doesn't need
to be modified should store that data in /usr/share (or
/usr/local/share, if installed locally).  It is recommended that a
subdirectory be used in /usr/share for this purpose.

Note that Linux currently uses DBM-format database files.  While these
are not architecture-independent, they are allowed in /usr/share in
anticipation of a switch to the architecture-independent DB 2.0 format.

Game data stored in /usr/share/games should be purely static data.  Any
modifiable files, such as score files, game play logs, and so forth,
should be placed in /var/games.

It is recommended that application-specific, architecture-independent
directories be placed here.  Such directories include groff, perl,
ghostscript, texmf, and kbd (Linux) or syscons (BSD).  They may,
however, be placed in /usr/lib for backwards compatibility, at the
distributor's discretion.  Similarly, a /usr/lib/games hierarchy may be
used in addition to the /usr/share/games hierarchy if the distributor
wishes to place some game data there.

ネットワーク間で共用される可能性とか、CD-ROM のように read only な
場所に置かれる可能性というのは、 share に限らず /usr 全体について
適用されます。

The "shareable" distinction can be used to support, for example:

   o A /usr partition (or components of /usr) mounted (read-only)
     through the network (using NFS).

   o A /usr partition (or components of /usr) mounted from read-only
     media.  A CD-ROM is one copy of many identical ones distributed to
     other users by the postal mail system and other methods.  It can
     thus be regarded as a read-only filesystem shared with other FHS-
     compliant systems by some kind of "network".

4.  The /usr Hierarchy

/usr is the second major section of the filesystem.  /usr is shareable,
read-only data.  That means that /usr should be shareable between
various hosts running FHS-compliant and should not be written to.  Any
information that is host-specific or varies with time is stored
elsewhere.

No large software packages should use a direct subdirectory under the
/usr hierarchy.  An exception is made for the X Window System because of
considerable precedent and widely-accepted practice.  This section of
the standard specifies the location for most such packages.

こういう話でなかったらごめんなさいですが。

> >  groff についての話は groff の upstream が議論に参加してくれないと
> > 意味が無いです。
> >  groff 自体をどうすべきかについては、li18nux のほうが良いのかも。
> > ただし groff の upstream を巻き込まないといけませんが。
> 
> 文字集合間の変換の話は groff にとどまらないし、
> 変換表及びそれを指定するためのロケール名列の話は
> glibc だけにとどまりません。

 groff の upstream による構想では、groff は単純に入力データとして
 UTF-8 を仮定して、コード変換は iconv などを利用した preprocessor と
して実装しようという方針のようです。

 <http://lists.debian.org/debian-i18n-0010/msg00018.html>

  | Please bear in mind that groff shall work on non-GNU systems also!  My
  | idea is to only accept UTF8, ascii, latin1, and ebcdic as input
  | encodings (the latter three for historical reasons only).
  | 
  | Maybe on systems with a recent glibc, iconv() and friends can be used
  | to do more, but generally I prefer an iconv-preprocessor so that groff
  | itself has not to deal with encoding conversions.

  | Yes, an iconv preprocessor for GNU systems to convert input files to
  | Unicode.

この場合、「文字集合間変換の話」は groff の実装としては無関係になります。
単に iconv などによって実装された機能を利用するのみですから。

出力データについてどうするのかは書かれてなかったみたいですが、
たぶん出力も UTF-8 のみとして、コード変換にはやはり iconv などを
利用するという枠組を想定しているのではないでしょうか。

> それが、Li18nux の存在意義です。

あまりに多くの場所で分散して実装してしまうと、収拾がつかなくなるので、
各アプリケーション (groff 含む) ではなるべく iconv を利用して、一箇所
 (この場合は iconv を想定していますが) をちゃんとすればまわりも自動的に
その恩恵を蒙ることができるようにする、というのは、それなりにメリットが
あるのではないでしょうか。

Li18nux とて無尽蔵の資源を有しているわけではないでしょうから、
実装の面では特に重要な部分に作業を集中して、そこが改善されれば
まわりにも波及する、というほうが効率的ですよね ?

> > エンコーディングの異なる man page を入れようとすれば、そうなりますね。
> > でも iconv 使って重複した内容を入れなくても済むようにしようという
> > 話があったような。
> 
> iconv で処理できるならそれでも良いですね。

現状の iconv ってどこまで実装されてるんでしょうね。

 EUC-JP から SHIFT-JIS や ISO-2022-JP への変換は potato の 2.1.3 でも
 woody の 2.1.95 でも可能でしたが、EUC-JP から UTF-8 へ変換すると
 unicode が読めるはずの jvim でも lv でも読めないです。

あ、いや、なんか自動認識がうまくいかなかったみたいですね。

 jvim 起動して、空のバッファーで :set jc=t として UTF-8 に変換した
ファイルを読み込んだら、ちゃんと表示できました。

と、いうことは、一応ちゃんと変換できてるんだ、、、


うん、potato 上でも表示できます。なるほど、たいしたもんだ。

 iconv -f UTF-8 -t EUC-JP で元に戻すと、きちんと元通りになりますね。

ということは、例えば EUC-JP な manual page を iconv で UTF-8 に
変換して、groff の中で UTF-8 として処理してしまって、出力をまた
変換すれば現状の euc-jp な manual page を読むくらいのことはできるのかな ?

なんか sjis -> utf-8 したら "\" が "?" になっちゃいましたけど。
でもこれを iconv -f UTF-8 -t EUC-JP したらまた "\" になりました。
さらにこれを iconv -f EUC-JP -t SHIFT-JIS したら元のデータに戻りました。

とりあえず、コード変換については「読めなくなる」ような心配はしなくても
大丈夫そうかな。その「文字集合」に関連する問題は残るとしても。

でも禁則処理とか、hyphenation とかの処理は各言語に応じてやらないと
ダメですよね。いくら iconv でもそこまでは無理だろう、というか文章を
整形するのは groff の役目なんだから、禁則処理とかは groff がやらなきゃ
他に誰がやるんだ、ってことになるだろうな。

Werner にはそこを push しといてください (> 久保田さん)。

私は個人的には iconv で preprocessor するというのは良さそうに思うけど、
 hyphenation 処理は各言語に応じてやらないとダメだよ、って。

 # sgml-tools にも groff で整形した文章の hyphenation がおかしいっていう
 # bug report が届いてます。ヨーロッパ言語の hyphenation は英語とは異なる
 # のだけど、現状の groff の hyphenation 実装は English only らしいです。
 # まあ、しばらく前なので、もしかしたらそこの実装はすこし進んでいるかも
 # しれませんが。

以下余談:

そういえば EUC-JP -> SHIFT-JIS は nkf -s と同じだけど EUC-JP -> ISO-2022-JP は
 "/" が "／" になってしまって

-(現在のディレクトリ) を仮定する。\-d オプションは、ディレクトリを
+(現在のディレクトリ) を仮定する。＼-d オプションは、ディレクトリを

-`.' で始まる名前のファイルでも、\-a オプションが指定されていれば表示される。
+`.' で始まる名前のファイルでも、＼-a オプションが指定されていれば表示される。

-の違いは、\-f オプションが他のオプションを
+の違いは、＼-f オプションが他のオプションを

とかってなっちゃいました。

もっとも、これをもう一度 iconv -f ISO-2022-JP -t EUC-JP で戻したら
ちゃんと元のデータと同じになったみたいですが。

--
     ＃ (わたしのおうちは浜松市、「夜のお菓子」で有名さ。)
    <kgh12351@xxxxxxxxxxx> : Taketoshi Sano (佐野　武俊)