玩式草子─ソフトウェアとたわむれる日々

第97回 そろそろ出しますPlamo-7.0

この記事を読むのに必要な時間:およそ 3 分

文字コードのデフォルトをUTF-8に

Plamo Linuxでは日本語を表示するための文字コードにEUC-JP(ja_JP.eucJP)を用いてきました。EUC-JPはExtend Unix Code for JaPaneseという名前が示すように,UNIX用に考案された日本語の表示方式で,1980年代からUNIXワークステーションで広く利用されてきました。

EUC-JPは日本語1文字を2バイトで表すと共に,最初のビットが立っているか否かでASCIIコードと区別できるように工夫されており,英語にしか対応していないソフトウェアでも,比較的簡単な改造で日本語メッセージを表示することができました。

Plamo Linuxはそれら日本語化されたソフトウェアを積極的に採用し,AfterStep ClassicやQvwmといった日本語に対応したウィンドウマネージャを使って,X Window System上で自由に日本語を使える環境を他に先駆けて提供していました。

しかしながら,インターネットが普及して世界中で同じソフトウェアが使われるようになるにつれ,英語と日本語にしか対応できない日本語化はむしろ不便で,はじめから世界各地の言語に対応した多言語化が求められるようになりました。そこで採用されたのが,存在する全ての文字を整理しようというUnicodeの規格と,それを効率よく表現するためのUTF-8という符号化方式です。

元々,Unicode/UTF-8は多言語化に対応したソフトウェアの内部表現形式として利用されていましたが,次第に画面表示やファイルシステムに保存する際のファイル名にも使われるようになり,新しく開発されたソフトウェアではたいていUTF-8がデフォルトの文字コードになっています。

そのような状況を鑑み,Plamo-7.0ではデフォルトの文字コードをUTF-8(ja_JP.UTF-8)に変更しました。もっとも,glibcのロケールデータを追加するなど,UTF-8を使うための環境整備は以前から進めており,普通に使っている範囲ではほとんど違いには気づかないと思います。

しかしながら,EUC-JPを前提にした古い「日本語化」ソフトウェアはUTF-8環境では正しく動かないため,この機会にまとめて削除することにしました。具体的にはPlamo-6.2の03_xclassicsカテゴリに入っていた,afterstep classicやqvwm,tgif, emiclock等のソフトウェアは,Plamo-7.0では採用されていません。

多言語化に対応した最近のソフトウェアを使っている限り,文字コード(ロケール)の変更をそれほど意識することはありません。しかしながら,ファイルシステム上に保存した日本語ファイル名は異なる文字コード間では使用が困難になります。詳細については別途取りあげようと考えていますが,とりあえず手元では文字コード変換機能を持ったファイルシステムであるsamba(cifs)を介して日本語ファイル名を扱うようにしています。

ビットマップフォントの廃止

元々X Window Systemでは,画面に表示する文字はドットで構成されたビットマップフォントを前提にしていました。しかし,ビットマップフォントは拡大/縮小するとギザギザが目立って見苦しくなるので,Sunの開発したNeWSのような後発のウィンドウシステムでは,拡大/縮小してもアラが目立たないベクターフォント(TrueTypeフォント)を使うようになりました。

この仕組みはfreetypeと呼ばれるフォントエンジンを用いてXにも輸入され,最近のX用のソフトウェアはほぼ全てfontconfigとfreetype経由でTrueTypeフォントを使うようになっています。

白黒のドットから構成されるビットマップフォントに比べて,ベジェ曲線で曲り方を指定するTrueTypeフォントは作成が面倒なものの,FontForgeといった作成ツールが開発されたり,情報処理推進機構(IPA)が開発してフリーで公開したIPAフォントやGoogle/Adobeが開発したNotoフォントなど,高品質でフリーな日本語TrueTypeフォントも整備されてきたので,Plamo-7.0ではビットマップフォントを廃し,TrueTypeフォントのみを使うようにしました。

図3 Notoフォントの表示例

図3 Notoフォントの表示例

この結果,TrueTypeフォントに対応していないソフトウェアは動作しなくなるものの,それらはUTF-8環境では動作しない,前述のX用の古いソフトウェアと重複するようです。

とりあえず64ビット版のみ

最近のx86系CPUはたいていx86_64アーキテクチャを採用した64ビット版になっており,わざわざ32ビット版の開発環境を用意するのも面倒なので,Plamo-7.0ではx86_64版のみを開発しています。そのため,ライブラリを32ビット版と住みわける必要が無くなり,Plamo-6.xで採用していた/lib64や/usr/lib64等のライブラリ名を廃し,/libや/usr/libに戻しました。

もっとも,かっては/usr/lib64を使うためのパッチが必要だったのに対し,最近では64ビット環境は/usr/lib64がデフォルトで,/usr/libに戻すためのパッチが必要になったりしているので,このあたりは再変更するかも知れません。

もっとも「x86_64にしか対応しない」というのは単純にメンテナのリソース不足というレベルの問題なので,将来的にはPlamo-6.xのように32ビット版やARM版のPlamo-7.xが公開されるかも知れません。

ビルドスクリプトの標準化

Plamo Linuxのパッケージを作成するためのスクリプトは,"PlamoBuild.foobar-x.y.z"というファイル名のシェルスクリプトで,/usr/share/docs/foobar-x.y.z/ディレクトリに収められています。

Plamo-6.xまでは,それぞれのメンテナが自分好みのスタイルでビルドスクリプトを作っていたものの,メンテナ以外の一般ユーザーがビルドスクリプトをチェックする際には,ある程度スクリプトのスタイルを統一した方が分かりやすいだろうと考え,Plamo-7.0では汎用的な処理を外部に括りだすことでビルドスクリプトを単純化,標準化することにしました。

このあたりの詳細も改めて本連載で紹介する予定ですが,Plamo-7.0の環境では展開済みのソースコードに対してmake_PlamoBuild.pyを実行すれば,そのコードに応じたビルドスクリプトが作成でき,たいていの場合,そのままバイナリパッケージを作ることができます。

このように作成したバイナリパッケージはPlamo Linuxのパッケージ管理ツールであるinstallpkg/removepkg/updatepkgで簡単にインストール/アンインストールできるので,DVDイメージ等には含まれていないパッケージをユーザーが自由に追加して,Plamo Linuxを自分用にカスタマイズすることも簡単になったと思っています。こうして作成した「自分用パッケージ」を提供いただくことで,メンテナの裾野が広がることを現在のメンテナ一同,期待しています(苦笑⁠⁠。


今回は簡単な概要紹介でしたが,Plamo-7.0は/usr/lib64を廃したことなどに伴い,全てのパッケージをビルドし直した全く新しいPlamo Linuxです。しかしながら,Plamo Linuxの特徴である見通しのよさやイジり易さは従来同様,あるいは古い設定を整理した分,よりわかりやすくなったと思っています。

「変らないために,変り続ける」というのは使い古された言葉なものの,ディストリビューションの世界にも通用する名言でしょう。

著者プロフィール

こじまみつひろ

Plamo Linuxとりまとめ役。もともとは人類学的にハッカー文化を研究しようとしていたものの,いつの間にかミイラ取りがミイラになってOSSの世界にどっぷりと漬かってしまいました。最近は田舎に隠棲して半農半自営な生活をしながらソフトウェアと戯れています。

URLhttp://www.linet.gr.jp/~kojima/Plamo/index.html