[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: /usr/pkg/man/ja_JP.EUC

SODA Noriyuki wrote:
> 私は、ISO-10646 全体をサポートしたフォントというもの自体が
> bad idea だと思ってます。時代の流れとして ISO-10646 のサポートは
> 必要だと思いますが、X11 のようにリッチな環境で、ISO-10646 全体
> をサポートした1個のフォントを用意する意味はありません。
> 本当は、JIS X0208 でも広すぎで、もっとも小さなフォントの集合と
> してサポートした方が、複数の種類のフォントを使い分けた場合に、
> より小さな使用資源で済む筈です。(だから、これに関する XFree86-4.X
> での変更も好きじゃありません。)
> 
> ただし、コンソールのように資源が限られた環境は例外で、こういう
> 貧弱な環境でだけは、ISO-10646 フォントも意味があると思います。
コンソール以外にも、更に貧弱な環境として組み込みマイコンで多言語表示があるので、
数MBのメモリーのリソースで用途に応じてフォントを組替える用途だと、
でかいのが一つあると、やっぱりどうにもならなくなります。

> > out of kmem_mapになり
> > メモリー空間が足りず、多言語同時表示を使用するには
> > options NKMEMPAGES=2048等を指定する必要があるなど、
> > 必要とするリソースが大規模になる傾向があり、
> > 組み込み用機器などに用いる場合、実用に耐えなくなる恐れがあります。
> > またISO-10646を完全に実装したbdfフォントを私は知りません。
> 
> 16x16 でも、UCS-2 の範囲であれば、必要なメモリは 16*16/8*65536byte
> すなわち 2MB しか使用しないで済むようにできるので、NKMEMPAGES を増やす
> 必要はありませんよね。
フォントがbitmapデータだけでよいのなら2MBですが、
これだと固定幅である上、基点の補正もできません。
どこまでサポートするかにもよりますが、
bdfなどでBBX等対応させるとそれだけリソースを必要とします。
（今のuwsconsの仕様でUCS-2を読み込もうとしたらout of kmem_mapが出たという事です）

> > #ここらへんの実装についてはuwscons用に書き掛けてほっといた物があるので
> > #NetBSD-3.0が出た時に出す、uwsconsのpatchの中に入れておきます。
> > #(現在、uwsconsに関しては問題が多すぎて本家のコードにmergeできません)
> 
> すばらしい。期待しています。
コメント行なんで、あんまり期待しないでくださいね。
フォント等の議論は、叩き台に動くものがないと論点が判りづらいので
仕様を決める前にある程度のものを作っておきたかったのですが、
議論始めてしまったら、大規模なコード修正の点から、しばらく凍結するかも。

なお、今でもuwsconsでも複数のフォントを同時にメモリーに置けるし、
表示言語の切り替えは変数一つでできるので、
複数のencodeの同時表示はencode指定の変数を切り替えながら行えばいいだけなので、
問題は、結局の所、どんな仕様にするかなんです。

> > 多言語が国際化の拡張であるISO-2022-JPなどはまだ汎用性がありますが、
> > 個人的な意見としてISO-10646とSJISはやめてほしいです。
> 
> 国際的なプロジェクトで、ISO-10646 はやめろという意見を通すのは、
> 現実的には無理だと思います。そういう方針で戦うと、ISO-10646 と
> ISO-8859-1 だけサポートすれば充分だみたいな結果に終わるのが落ち
> でしょう。
> 可能な戦略は、「特定の文字コードを特別扱いするのをやめろ」すなわち、
> 「codeset independent にソフトウェアを作成しろ」という主張だけ
> でしょう。
> ソフトウェアとしては、ISO-2022-JP も、ISO-10646 も、SJIS も、なんでも
> 選択できるように作っておいて、「必要なものを選んで使ってね」とするのが
> 合意できる唯一の選択ではないでしょうか。

エンドユーザーがISO-10646を使うなとは言いませんが、
表示仕様制定の段階でISO-10646を考えるとまともな実装ができなくなりそうです。
UCS-2の最大の問題は要求するリソースが大きいにも関わらず、
一つの国ではより優先度の高い文字を表示できないという
一国の要求も満足に満たしていない、すべてにおいて中途半端な所だと思っています。
(CNS11643-[1-7]やJISX0213)

結局の所、実装段階では表示させる側の文字コードに関する問題は、
場合によっては変換すればいいだけの話ですが、
ドライバー側の内部コードに関してはbitmap側の仕様に依存することになり
全てのbitmap dataがそろっていないencodeに対しては考慮対象外にしかなりません。

あと現在のuwsconsでUTF-8に関しては
先人の努力によりCJK以外の表示はできるようになっていますが、
全てを表示させるときの最も大きな問題はフォントが無いことです。

最後にuwscons用に書いた私の作業のTODOの文章を最後に付けます。

--
大石　修

〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜ここから〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
【コンソールでの多言語表示についての指針】

『前提項目』
1. CJKを扱うときに8bit空間だと足りないので16bit以上に拡張する必要があるが
   32bitにすると一度に扱う単位が大きくなりすぎるため、
   8bitと16bitの2つのモードで行う。
2. カーネルのコンソールドライバとフォントが読み込まれるまでは16bitコードを表示できないた
め、
   初期状態では8bitを維持する必要がある。
3. 文字コードは既に各言語体系では実用上16bitで対応できるように作ってある。
   (中国語等で拡張部分が必要な場合も複数の16bitコードで対応可能CNS)
   bdfフォントなども既にそろっている。
4. 16bit空間は全ての言語の文字を同時に扱うには狭すぎるので、
   16bitで全言語を扱おうとする文字コードは利点よりも弊害の方が多すぎる。
   (ISO-10646やtron codeは初期の構想通りに
    言語毎に面で区分してあればまだ使えたのですが、
    全言語を扱うには文字数が足りない上、
    組み込用途などの場合は単一言語で用いる用途では必要なメモリが大きすぎる。)
5. 扱うフォントの空間が大きすぎると、複数のグリフを作るに多大な労力を必要とする。
   (ISO-10646の全空間を網羅したbdfフォントは現在まだ存在しておらず、
    この状態でISO-10646をサポートしようとすると不完全なままのサポートとなり、
    エンドユーザーに混乱を与える。)

『方針』
1. 8bit空間及び16bit空間のフォントの一つまたは複数をメモリー上に読み込み、
   文字集合の種類、文字コード、コンソール上の表示位置を変数として、コンソール上に表示す
る。
   (複数の文字集合の同時表示)
2. 32bitコードがどうしても必要な場合は
   16bit空間を1区画として区画毎のフォントを読み込んで対応する。
3. 現在のISO-10646などの16bitコードは各言語の拡張という形で最終的には使用可能にするが、
   多言語表示の仕様を決める過程では考慮対象外とする。
   (NetBSD GENERIC-kernelでISO-10646を読み込むとout of kmem_mapになりメモリー空間が足りず
    多言語同時表示を使用するには
    options NKMEMPAGES=2048等を指定する必要があるが、
    さらに複数のグリフ(フォント)を使用する場合は、実用に耐えなくなる。)
4. 実際の用途でのユーザーレベルの価値判断において、
   多言語の表示は複数のグリフの表示よりも低いこともあるので、
   フォント読み込みに用いるメモリ空間の使用選択性はユーザーにまかせる。
   (多言語にするのも、単一言語でnomal, bold, italicを用いるのもユーザーによる選択)
5. コンソールドライバで扱う文字コードの幅は32bitビット以上とする、
   16bitの文字コードとencode(及びfont)の状態指定16bit以上を表示文字毎にもたせて、
   メモリー上に格納した全てのフォントを同時表示可能とする。
   この状態からISO-2022-JPにencodeすることは容易なので、必要な言語のみの多言語表示は可能。
6. 16bitフォントのビットマップデータをメモリー上に格納するときに
   文字コードが連続である文字集合の場合はそのままメモリー上に格納し、
   文字コードが不連続な文字集合の場合は格納アドレスを指すテーブルを用意してポインタ型で読
み込む。
   (テーブルの大きさは16bit空間x16bitアドレスなので、1フォントあたり131kbyte)
7. 表示文字にグリフ指定、encode指定、文字コード、文字の大きさ、色まで指定して全ての文字を
同時表する場合
   すべての言語を含んだ多言語表示が可能となる上、ユーザーが使用用途で使い分ける事が可能と
なるが、
   この場合は1文字の状態を指定するコード長は32bitでは少なすぎるため、
   1文字128bit以上のコードにするか、構造体として扱う。
8. コンソールは1画面のbitmap構造(グラフィック)として考え、画面上にtextの概念は用いない。
   カーソル位置は表示された文字の基点で指定する。
   (日本語の縦書き(アラビア語の右から左の記述を含む)への対応は
    専用グリフを用いたグラフィックコンソール上の絶対位置表示で可能)

『現在、カーネルが読み込むフォントとしてサポート予定の文字集合』
16bit
CNS11643-[1-7]
GB2312
JISX0208(JISX0213)
KSC5601

8bit
JISX0201
ISO8859-[1-15]

『未解決の問題点』
1. インド、その他の言語の文字集合が含まれていないのをなんとかしないといけない。
2. 表示フォントのdot数
   JISX0208等は16x16dotで認識可能だが、
   CNS11643-7等は画数が多いため完全に認識するには32x32dotが必要となる。
   vgaに表示できる文字数は640x480で固定されるため文字の解像度が上がるほど文字数は減少す
る。
3. グリフの異なる同一文字コードの同時表示
   ルビ、上付き、下付き、等の扱い。
4. 画面のバッファー数
   2画面以上のバッファーで色指定までできるようにすると、必要なリソースが大きくなる。