[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 を生成するとか そういうことをしないと
# 駄目。
-- 
鵜飼文敏