2006年01月20日
GUI d-iのフォント問題、再び
必要なグリフを抽出したCJKフォントパッケージの導入でひとまず安心、あとは台湾中国韓国の翻訳100%を待つだけと思っていたのだけど、d-iの改良の副作用の影響をモロに受けることが判明(薄々気付いてたとも言うが…)。
etch d-iは、1st stageの段階でこれまで2nd stageでやっていたほぼ全部のことを行うようになった。パスワードの設定、時間の設定、パッケージの選択と設定。ん、「パッケージの選択」?そう、インストール済みの環境をchrootとして、taskselを呼び出してタスクの選択ができるわけだ。
不吉な匂いがしてきたかな? タスクで自由にインストールできることは即ち、何が入るか予想がしづらい。現状のタスク一覧をベースに予想できないことはないのだが、タスクは環境・時代によって変わる可能性があるし、もしaptitudeも起動できるようにすることになったら(というか今はtasksel呼び出し部のバグのために出てこないだけのような…。常に優先度highでdebconf表示されるし)、使われ得るグリフを抽出するというのは非現実的だ。
場当たり的な対処としては、1. 現状のを元に使われているグリフを入れる→スケーラビリティがなく容易に破綻する。2. 完全なTTFをinitrdに入れる→拒否されること確実。3. お帰りなさい、中国語ビットマップフォント→勘弁していただきたい。ということで、どれもできるだけ避けたい。
1つ考えた案としては、CJKのときにはそれぞれ固有の完全版ttf-*フォントをbase-installerのpostinst時にtarget環境にインストールさせ、これに/usr/share/fontsにある(shrinkされた)実体フォントをsymlinkに変えて参照させるようにすることでなんとかならんかな、というもの。
GTK+が動いているときに実体フォントを変えられた場合にうまくいくのか、もしパーティションフォーマットし直しが発生した場合にはどうshrinked実体フォントに戻すのか、が課題か。頭痛い。
![[hatena]](http://d.hatena.ne.jp/images/b_entry_de.gif)
![[RSS]](/d/rss10.png)