[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[debian-devel:14411] Re: groff Japanese support breaks PS output for latin2
At Wed, 18 Jul 2001 03:26:11 +0900,
Nozomi Ytow wrote:
> > これは絶対必要ですね。jgroff patch では fixedkanji などを新設してますけど
> > もっと generic なものにできないかなぁ。
>
> fixedWidthHalf, fixedWidthDouble, variableWidth 程度にしておくのは
> どうですか。
いや、それなら parameter で幅の情報とかをわたせばいいような。
あるコードポイントの領域で指定できるようにするのがいいのかな。
ちなみに groff original では font/dev<devname>/<fontname> で定義しているのは
charset
! 24 0 0041
0: <charname>
1: <width>[,<height>,<depth>,<italic_correction>,<pre_math_space>,<subscript_correction>]
2: <type>
3: <code>
みたいな感じを一文字づつ定義しています。
jgroff拡張では
fixedkanji 24 0
1: <width>[,<height>,<depth>,<italic_correction>,<pre_math_space>,<subscript_correction>]
2: <type>
ですね。
fixed 24 0 0xa1a1..<end>,<start>..<end>
な感じにするのがいいのでしょうか。
charset
wchara1a1..wcharNNNN 24 0 0xa1a1..0xNNNN
みたいにする方がいいのかも?
DESC の方に
fonts 4 R I B BI
wfonts M R,I 0xa1a1..<end>,<start>..<end>...
wfonts G B,BI 0xa1a1..<end>,
みたいなformatがいいんですかね?
# というか この fontファイルに書く charname とか code は
# groffがいろんなエンコーディングを扱えるようにしようとするなら、
# どういうコードを使えばいいのでしょう?
> > 今の jgroff と同じようなやりかただと 一文字ごとに charinfo objectとか
> > 生成してるんですが、utf8 (というか とりあえず UCS2分)を全部作ろうとして
> > これがすごく遅いです。もうちょっとなんかやり方をかえないと実用には
> > 駄目っぽいですね。
>
> あるべき最低処理単位は文字ではなくグリフだろうから、一文字ごとに生成
> するのを単語ごとにして、単語分けが trivial でない言語は chank で処理、
> というあたりをさっとおもいつきますが、その程度では改善しませんか?
そうではなくて、現在の実装(とかjgroffの拡張)では文書に文字が使われていようが
いまいが、読む前に全ての文字の charinfo をまず登録しているのです。
(jgroffでは 94x94約9000文字のobjを最初に登録してます。
UCS2全部なにも考えずに 0x80-0xFFFFとかやってしまうと
約6万文字分のobjを最初に一気に生成することになってしまう…)
読んでいって on demand で object 生成するとかしないと駄目ですね という話。
# もしくは default charinfo obj を作っておいて、cflags とかすると
# copy-on-write 的に charinfo obj を生成するとか そういうことをしないと
# 駄目。
--
鵜飼文敏