[debian-devel:13121] Re: inside of coming groff

[Taketoshi Sano <kgh12351@xxxxxxxxxxx>]

佐野＠浜松です。

 # linux-tech にも振ってみます。

In <200010181039.TAA30936@xxxxxxxxxxxxxxxxxxxxxxxx>,
 on "Wed, 18 Oct 2000 19:39:17 +0900",
 with "[debian-devel:13103] Re: inside of coming groff",
  Nozomi Ytow <nozomi@xxxxxxxxxxxxxxxxxx> さん wrote:

> だったら話は簡単で、
> 
> グリフと文字を分離したはずの Unicode は
> 実はそれらをごっちゃにしている部分があるから、
> roff はそんなものに依存してはダメ。
> Adobe のグリフインデクスでも使ったほうがいいんじゃない?

とりあえず

 Unicode も eucJP も eucKR も ISO-8859-<n> も含む一般のコード

を入力データとして、Unicode に変換したとしましょう。

この時「一般のコード」には文字ベースのもグリフベースのも両方
あり得るから、最初の入力として、「文字」か「グリフ」のどちらか
一方しか無いと仮定するのはダメですよね ?

で、Unicode へは iconv で変換するとして、iconv の変換ルールが
どうなっているかに依存する部分がありますが、とりあえず

 「最初のコード」→「Unicode」→「元のコード」

は元に戻るとして (この仮定はいいですよね ?)、

 groff が「入力データ」から「グリフ」を得るために変換を行なう際に

「最初のコード」→「グリフ」

に比べて

「最初のコード」→「Unicode」→「グリフ」

とした時に「失なわれる情報」というのは何があるでしょう ?

Werner (groff の開発者) は

> What determines the command option for iconv?

I suggest various possibilities.

  . By default, locales should be used.  A --locale option might be a
    good idea also since this has implications on text processing;
    example: Portuguese doesn't use fi and fl ligatures.  The problem
    is that a locale influences both input encoding and text
    processing which might not always be the right choice.

  . Another approach to influence text processing (not input encoding)
    is the OpenType way: --script, --language, --feature.

  . Command lines shall be able to override input encoding
    (--input-encoding).

  . Finally, we need to divide the -T option into a --device and
    --output-encoding.

という方針を検討しているようですから、input-encoding や script, 
 language, feature などの情報を Unicode のコードポイントで示された
情報と一緒に処理して「Unicode」→「グリフ」の変換を行なうつもりで
いるようです。

この場合、それらの付帯情報の処理が適切に行なわれるのであれば

「最初のコード」→「グリフ」

に比較しても

「最初のコード」→「Unicode」→「グリフ」

という処理をすることによって失なわれる情報は無いだろうと思います。

 # 処理が適切でなければ意味が無いのは Unicode を介在させなくても同じこと。

> だけど、現実問題としては Unicode が良い解であるサブセットも
> ありそうなので、グリフと文字の分離をきちんとした normalised Unicode を
> 定義した上で、それを使って roff をつくりましょ、

むしろ Unicode は各種の文字コードからグリフへの中継役として使うだけで、
「文字」という抽象概念に持っていくことは回避したいと考えているんじゃ
ないでしょうか。

Werner からのメールには以下のように書かれています。

  | Well, I insist that GNU troff doesn't support multibyte enodings at
                                                 ↑"multiple" 追加。
  | all :-) troff itself should work on a glyph basis only.  It has to
  | work with *glyph names*, be it CJK entities or whatever.  Currently,
  | the conversion from input encoding to glyph entities and the further
  | processing of glyphs is not clearly separated.  From a modular point
  | of view it makes sense if troff itself is restricted to a single input
  | encoding (UTF-8) which is basically only meant as a wrapper to glyph
  | names (cf. \U'xxxx' to enter Unicode encoded characters).  Everything
  | else should be moved to a preprocessor.

私は GNU troff に複数のマルチバイトエンコーディングをサポートさせたいとは
思わない。troff 自身は純粋にグリフベースで処理するべきである。
現在、入力エンコーディングからグリフ実体への変換と、その後のグリフに対する
処理とは明確に分離されていない。

モジュール化の視点からは、troff が入力エンコーディングをひとつ (UTF-8) に
制限し、基本的にはそれ (UTF-8) を単にグリフ名へのラッパーとしてのみ利用
する、というのが望ましい (Unicode でエンコードされた文字を入力するには
 \U'xxxx' を使う)。

それ以外の処理はすべてプリプロセッサにまかせるべきだろう。

  | Well, this is *very* important.  The most famous example is that the
  | character `f', followed by character `i' will be translated into a
  | single glyph `fi' (which has incidentally a Unicode number for
  | historical reasons).  A lot of other ligatures don't have a character
  | code.  Or consider a font which has 10 or more versions of the `&'
  | character (such a font really exists).  Do you see the difference?  A
  | font can have multiple glyphs for a single character.  For other
  | scripts like Arabic it is necessary to do a lot of contextual analysis
  | to get the right glyphs.  Indic scripts like Tamil have about 50 input
  | character codes which map up to 3000 glyphs!

文字コードを持たないリガチャはたくさんあるし、& というひとつの文字に
対して 10 以上のグリフを持つフォントもある。 Tamil のように 50 種の
文字から 3000 のグリフを構成する script もある。

  | Consider the CJK part of Unicode.  A lot of Chinese, Korean, Japanese,
  | and Vietnamese glyphs have been unified, but you have to select a
  | proper locale to get the right glyph -- many Japanese people have been
  | misled because a lot of glyphs in the Unicode book which have a JIS
  | character code don't look `right' for Japanese.

Unicode の CJK パートについても、CKJV のたくさんのグリフが統合されたが
適切なグリフを選択するためには locale を正しく選択しなければならない。
多くの日本人は JIS 文字コードに対応する Unicode book の中のグリフが
日本語として「正しい」とは見えないことで惑わされている。

  | For me, groff is primarily a text processing tool, and such a program
  | works with glyphs to be printed on paper.  A `character' is an
  | abstract concept, basically.  Your point of view, I think, is
  | completely different: You treat groff as a filter which just
  | inserts/removes some spaces, newline characters etc.

私にとって、groff は第一にテキスト処理のための道具であり、こういった
プログラムは紙に印刷される「グリフ」を扱うためのものだ。「文字」とは
基本的に抽象化された概念である。

> >   | This is not a problem.  Just give the proper glyph width in the tty
> >   | font definition files.
> 
> > 固定幅のフォントなら簡単そうですね。
> 
> そんなの文字コード変換依存ではないか、
> 文字数の保存性が保証できないのだから。

文字数については以下のように考えているようです。

  | For tty devices, the route is as follows.  Let's assume that the input
  | encoding is Latin-1.  Then the input character code `0xa9' will be
  | converted to Unicode character `U+00a9' (by the preprocessor).  A
  | hard-coded table maps this character code to a glyph with the name
  | `co'.  Now troff looks up the metric info in the font definition file.
  | If the target device is an ASCII-capable terminal, the width is three
  | characters (the glyph `co' is defined with the .char request to be
  | equal to `(C)'); if it is a Unicode-capable terminal, the width is one
  | character.  After formatting, a hard-coded table maps the glyphs back
  | to Unicode.
  | 
  | Note that the last step may fail for glyphs which have no
  | corresponding Unicode value.

端末デバイスに対しては、処理の道筋は以下のようになる。
入力エンコーディングが Latin1 だとしよう。もし入力文字コードが
 `0xa9' (つまり '\(co') だとすれば、これは Unicode の文字 `U+00a9' に
(プリプロセサによって) 変換される。

ハードコード化された変換テーブルにより、この文字コードは `co' という
名前を持つグリフに写像される。

ここで troff はフォント定義ファイルからメトリック情報を検索する。

もし出力装置が ASCII のみ表示可の端末であれば、このグリフに対応する
出力の幅は 3 文字 ( .char 要求により定義されるグリフ `co' は `(C)'
 [つまり左丸括弧、"C"、右丸括弧ですね] に等しくなる) 。

# ここで文字という言葉を使うのはアレな気分だが、他にどう表現するべきか ? 
#  3 出力カラム ? 3 グリフイメージ ?

もし出力装置が Unicode を表示できる端末なら、グリフの幅は 1 文字。

# うーん、、、適切な言葉がわからない。意味はわかると思うけど。

このようなフォーマット (整形 ?) 処理を経た後、ハードコード化された
変換テーブルを利用してグリフは再び Unicode に戻される。

もし整形処理の結果得られたグリフ (イメージ ?) に対して、対応する
Unicode のコードが得られない場合、最後の処理は失敗することに注意。

# ここの入力と出力で使われる「ハードコード化された変換テーブル」を
# ユーザーの好みで入れ換えられるようにしたい、とか考えてます ? > (の)

> > とりあえず固定幅のフォントだけ扱えればいい、ってことにするのかな。
> 
> リガチャがあるからそうはできない。

上記の処理の場合、リガチャをそのまま 1 つのグリフとして表示できる
端末なら出力の幅は 1 グリフ、それができない場合は 2 グリフとして
整形する、という処理を考えているのではないかと思うのですが。

 # 違うのかな。

> のぞみ＠そんなに難しい問題かなぁ、文字コード表を調べれば
> 	分かることだと思うが

もともとこの方面にはあんまり興味が無いもので。バグレポートされたから
仕方無くいろいろ調べてる (けどまだよくわかってない) という次第。

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