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

[Nozomi Ytow <nozomi@xxxxxxxxxxxxxxxxxx>]

> > fixedWidthHalf, fixedWidthDouble, variableWidth 程度にしておくのは
> > どうですか。
> いや、それなら parameter で幅の情報とかをわたせばいいような。

その手もありますね。効率はさておき。

> あるコードポイントの領域で指定できるようにするのがいいのかな。

そういう意味かと思って読んでいましたが。
文字レパートリとコード領域とグリフ幅がうまく対応しているかどうか、
というのはありますけど、効率から言って文字レパートリをキーに
領域わけるのが良いだろうと思います。


> fixed 24 0 0xa1a1..<end>,<start>..<end>
> な感じにするのがいいのでしょうか。
> wchara1a1..wcharNNNN 24 0 0xa1a1..0xNNNN
> みたいにする方がいいのかも?

あるいは Juliusz の X のフォント関連実装の様に全ての文字について表を作
って力業でいくか。グリフの幅でまとめるか文字でまとめるか、というのは
結構難しい点ですね。しかし 24 とか数字が埋まっているのはいやだな。
もうちょっと抽象化できないかしらん。


> fonts 4 R I B BI
> wfonts M R,I 0xa1a1..<end>,<start>..<end>...
> wfonts G B,BI 0xa1a1..<end>,
> みたいなformatがいいんですかね?

これは X でいうところの fontset の考え方ですね。


> # というか この fontファイルに書く charname とか code は
> # groffがいろんなエンコーディングを扱えるようにしようとするなら、
> # どういうコードを使えばいいのでしょう?

roff が何のエンコードを扱う必要があるのか、という点を考えると、
roff の内部はグリフコードで持つ必要がありますから、入力の文字コードを
内部のグリフコードに変換して、処理して、また文字コードにして出す、
という処理になるでしょう。そうなると font ファイルはグリフコードなので、
たとえば CID などが視野に入って来ますね。


> そうではなくて、現在の実装(とかjgroffの拡張)では文書に文字が使われていようが
> いまいが、読む前に全ての文字の charinfo をまず登録しているのです。

ああそんな X のどうしようもないフォントまわりの様な....

> 読んでいって on demand で object 生成するとかしないと駄目ですね という話。
> # もしくは default charinfo obj を作っておいて、cflags とかすると
> # copy-on-write 的に charinfo obj を生成するとか そういうことをしないと
> # 駄目。

了解。ハッシュなキャッシュ持つのが正解かも。キーは UCS と CID かな。
roff 等のためのグリフサーバとか X のライブラリだけ使う、というのは
禁じ手でしょうね、やっぱり。


いずれも X ではいつかきた道かつ未だに出口のない道なので、
久保田さん、佐野さんあたりに期待しつつ時間をかけて
じっくりやるしかない、と思います。

--
のぞみ