[debian-devel:14408] Re: groff Japanese support breaks PS output for latin2

[Fumitoshi UKAI <ukai@debian.or.jp>]

At Tue, 17 Jul 2001 22:05:30 +0900,
OKAZAKI Tetsurou wrote:

> > groff 1.17.2 base でいろいろいじってみました。
> >  http://people.debian.org/~ukai/groff/
>  
> > 今 1.17.2-1.ukai.1 が最新です。
> 
> FreeBSD port の更新作業の準備をしていて気付いたのですが、
> このパッチや debian patch で追加される、dev{ascii8,nippon}/R.proto
> には、groff-1.15 → groff-1.16 で devascii/R.proto に追加された、
> dq, cq の定義(↓)が抜けている様です。

おぉ どうもありがとうございます。修正しておきます。
Colin Watson <cjwatson@debian.org> (debian groff maintainer)
にも連絡しておきました。

At Tue, 17 Jul 2001 22:04:45 +0900,
Taketoshi Sano wrote:

> > Colin Watson さんは、週末は外出して、来週にパッチを検討してみるとの
> > ことだそうですので、別解の実装を考えていらっしゃる方がいましたら、
> > 私からでもいいですし、直接でもいいと思いますが、その意思を伝えて
> > おいたほうがいいと思います。
> 
> 鵜飼さんパッチについても Colin に要連絡 and/or BTS report かな ?

とりあえず Colin には連絡して 

| it looks excellent. I significantly prefer the new
| encoding mechanism (for what it's worth from somebody who knows less
| about that code)

という好印象がえられています。

返事がくるまでに utf8 encoding support を試しにやってみたところ
動くようにはなった(*)のですが、とんでもなく遅いという問題が…

*) ja_JP.UTF-8 を作っておいて (/etc/locale.gen に ja_JP.UTF-8 UTF-8 を
   追加して locale-gen)

 % lv -Ou8 /usr/share/man/ja/man8/dselect.8.gz |
    LANG=ja_JP.UTF-8 groff -t -Tnippon -mandoc | lv -Iu8

 で、とりあえず問題なく動いてます。

今の jgroff と同じようなやりかただと 一文字ごとに charinfo objectとか
生成してるんですが、utf8 (というか とりあえず UCS2分)を全部作ろうとして
これがすごく遅いです。もうちょっとなんかやり方をかえないと実用には
駄目っぽいですね。

あと、font/dev*/G,M とかの処理も どうするのがいいのか問題ですね。

また、src/xditview の処理も悩むところです。どうするのがいいでしょうね?

> Another problem is how to handle fonts in groff.  It seems that we
> have to extend the current font file syntax to allow ... what exactly?

これは絶対必要ですね。jgroff patch では fixedkanji などを新設してますけど
もっと generic なものにできないかなぁ。

あと 今はほとんど 入力文字コード == fontのコード で動いていますが
これがなりたたないようになると、どこかで 入力文字コードと fontのコードの
対応をやらないと駄目ですね。

> Please make suggestions.  Some ideas:
> 
>   . Glyph classes.  We'll need that for defining CJK metrics and kerns
>     in a compact way.

compact way が重要ですねぇ。

>   . Subfonts.  [I don't mean the splitting of a large font into
>     entities with, say, 256 glyphs each.]  Using a single Unicode font
>     is nonsense.  Instead, groff should provide a means to group fonts
>     into Unicode blocks.  If a new font is registered, it sets some
>     flags to indicate which block is covered.  A mechanism to provide
>     a fallback font is neeed also.  It could also be used for the
>     other way round:  Registering a huge font as many subfonts makes
>     the loading much faster.

んー fontコードブロック単位で subfont を登録という感じですかね。
DESC にそういう風に書くようにするのかな…

>   . Interaction between fonts to implement effects like kinsoku shori
>     (i.e., less space between a CJK and non-CJK character than between
>     two non-CJK characters).  It's not completely clear to me how to
>     achieve that in a simple way.

> 禁則処理の件は鵜飼さんパッチで受け入れてもらえる形になったのかな ?

最後のは禁則処理というより ASCII<->JIS X0208間のスペースの扱いの話
ですね。これは どうするのがいいのかなぁ。

> 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.
> 
> この部分。環境変数で locale をチェックして、次にコマンドライン
> オプションで入力および出力のエンコーディングをチェック (環境
> 変数による指定を override) 最終的に文書冒頭の Emacs 風なコメントで
> 入力エンコーディングを override する、と。

ふーむ、文書冒頭のコメント以外は実装するのは そんなに難しくはないかなぁ

> 鵜飼さんがおっしゃっていた処理経路が複数あるという問題は、
> 「将来計画」では preprocessor を最初にかませるという枠組で
> 解決する予定なのかな ?
> 
> よくわかってませんが、現状の groff に部分的に preprocessor を
> 入れてしまうということはできないものでしょうか ? その場合 pre
> processor の役割というか意味は本来のものとはちょっと異なってきて
> しまいますが、それを入れることで現状のデザインでもある程度各国語の
> 要求する処理に対応できるようになるのであれば、push してみる価値は
> あるかも。

今のjgroff的なやり方で単純に utf-8 で とかにすると遅くて使えませんね。
# なんとかできないか考え中。

-- 
鵜飼文敏