Fonty Pythonはフォントマネージャの聖杯になりえるか

 GNU/Linuxデスクトップに携わる開発者は、フォントをすぐさま有効化/無効化できるフォントマネージャの登場を待ち望んでいる。そうしたツールがなければ、膨大な量のシステムメモリをフォントのコレクションに充てるか、個別にフォントをインストール/アンインストールして必要なフォントをプロジェクトごとに手作業で管理しなければならなくなる。厄介なのは、実用的なフォントマネージャには1.0リリースどころかアドバンストベータにこぎ着けたものさえ存在しないことだ。今のところ、1.0に最も近いのが、最新バージョンが0.2のFonty Pythonである。

 Fonty Pythonでは、フォントが「pog」という集合にグループ化されており、カレントのユーザアカウントに対するフォントのインストール/アンインストールはpog単位で行われる。フォントは、読み込みが終わり次第、ほかのプログラムで使えるようになる。

 残念ながら、Fonty Pythonには、こうした基本的機能にも2つの欠点がある。まずは、TrueTypeフォントしか扱えないことだ。PostScriptおよびOpenTypeのフォーマットには対応していない。Fonty PythonのHelpページの最後に、開発者Donn Ingle氏は次のように記している。「Type-1フォントをはじめとする不可解なフォントについては、詳細な情報が手元にありません。フォントのhelp/code/informationが手に入りさえすれば、ほかのフォーマットもサポートできるのですが」

 もう1つは、Fonty Pythonの画面レイアウトが従来の方式と異なるために使いにくいことだ。ユーザは、まず画面の右側ペインでpog ― たとえ前からあったにせよ不必要な専門用語だ ― を作成してから、左側ペインでハードディスク上のファイルディレクトリを選択しなければならない。そのディレクトリにTrueTypeファイルがあれば真ん中のペインに表示されるので、ユーザはフォント名の記されたパネルをクリックしてインストールするフォントを選択する。ディレクトリ内のフォントが多くて真ん中のペインに一度に表示し切れない場合は、スクロール操作ではなく「Forward」および「Back」ボタンを使って表示の切り替えを行う。その後、右側ペインの上部からフォントのインストール先となるpogを選択したうえで、真ん中のペインの一番下にあるボタンをクリックしてそのpogにフォントをインストールする必要がある。しかも、フォントを利用するには再び右側ペインに移ってこのpogのインストールも行わなければならない。

 つまり、Fonty Pythonでは、ウィンドウのあちこちへの移動、標準的でないコントロールの利用、きわめて多くの手順の実行がユーザに求められる。インタフェースの徹底的な見直しが必要なのだが、それでも我慢できるのはほかにましなフォントマネージャが存在しないからだ。

 とはいえ、Fonty Pythonが一個人のプロジェクトであることを考慮しないわけにはいかない。Ingle氏は丹念なガイドラインを用意のうえで同プロジェクトへの貢献を求めているが、今のところ誰からも協力の申し出はなく、結果としてプロジェクトの進捗は芳しくない。

KDE4のフォントインストーラ

 今後が期待されるもう1つのプロジェクトが、KDE4に収録が予定されているKDEの改訂版フォントインストーラである。このソフトを支える開発者Craig Drummond氏は、「意見を採り入れる」ためにKDE3バージョンに変更を加えたのだが、このバージョンはもはや利用できないという。今や、彼の意識はすっかりKDE4に向けられている。現在、この変更内容を試せる唯一の方法がKDE4をコンパイルすることだが、大事な仕事を抱えている開発者にはお勧めできない。

 Drummond氏によると、KDEの新しいフォントマネージャには2つのモードがあるという。基本モードではシステムフォントとパーソナルフォント双方のインストールと削除ができるだけだが、フォント管理モードではフォントグループの作成やフォントの無効化が可能だ。フォント管理モードには、重複したフォントや壊れたフォントを見つけだすツールや、専用サイトから新しいフォントをダウンロードするツールなど、数々のユーティリティも用意される。また、どちらのモードにも、ファイル名と場所でフィルタリングできるビューと、Unicode文字テーブルを表示するフォントビューがある。

今後の展望

 十分に作り込まれたフォントマネージャは、ScribusやInkscapeのようなプロジェクトを補完し、開発者をデスクトップ環境に引き寄せるための小さいながらも不可欠な機能である。プログラマ1、2名が数か月集中して取り組めば実現できるほど開発範囲は限られているというのに、GNU/Linux用フォントマネージャが欠如していることには、とりわけもどかしさを感じる。

 いずれにせよ、そうした待ちの状態は終わろうとしている。KDE4用に予定されているKDE Control Centerのフォントインストーラに対する変更は、開発者たちが待ち望んでいたものになるだろう。概念実証バージョンが開発済みであること、そうした機能の大半はすでにできあがっているとDrummond氏が述べていることを考えると、2007年10月にリリースされるKDE4に初めての完成されたフォントマネージャが収録されることはほぼ間違いなさそうだ。その間にFonty Pythonが追加リリースをしてほかのフォントフォーマットに対応しない限り、開発者はこのKDE4のリリースをひたすら待つことになる。

コラム:貧弱な代替ツール
 Webで検索すると、いくつかのフォントマネージャの初期の状況がわかる。フォントビューアChoosefontの初期バージョンに付属のreadmeファイルには「今後Choosefontは、フォントのインストールおよび削除の機能を備える可能性があります」と記されていたが、SourceForge.netにある同プロジェクトの最新活動リストのページは3年以上も前のものだ。また、Hamster Font Managerは、バージョンが1.0.2に達しているものの、もう8年間もアップデートが行われていないらしく、必要とされるtixwish(Tcl/Tk/Tixインタープリタ)はDebianアーカイブから入手可能などれとも互換性がない。

Bruce Byfieldは、NewsForge、Linux.com、IT Manager’s Journalに定期的に寄稿しているコンピュータジャーナリスト。

NewsForge.com 原文