Ubuntu日和
【第32回】フォントと日本語入力の、ホントの話
2023年8月5日 06:24
今回はこの1枚から始めよう。
左側に表示されているのは、16年前にリリースされた「Ubuntu 7.04」だ。右側に表示されているのは、見た目を近づけた「Ubuntu MATE 23.04」だ。7.04で表示されているワープロは「OpenOffice.org Writer」で、「LibreOffice」のベースとなったものだ。
16年間の進化にはただただ驚くばかりだが、とにかくフォントの表示品質が全然違うことに気づく。いまさら7.04を使いたいとは思わないだろう。
今回はつまりそういう話で、Ubuntuを日本語環境で使用するのに重要な要素であるフォントと日本語入力についての歴史をたどり、どのようにして現在のようになっていったのかを紹介していくこととする。
フォント
フォントそのもの
フォントの表示品質を決めるのは大きく2つの要素があり、1つはもちろんフォントそのものの品質だ。Ubuntuの日本語対応は6.06 LTSからだが、当時デフォルトフォントに選ばれたのは東風フォントだった。
厳密には東風フォントにあった問題を解消したバージョンで、どうしてこのフォントになったのかは、筆者も意思決定に携わったはずだが忘却の彼方である。7.04の段階でもこれであり、今日日見なくなったビットマップ埋め込みフォントは懐かしさしか感じない。
その後さざなみフォント、VLゴシックを経てTakaoフォントとなり、Ubuntu 16.04 LTSからはNoto Sans CJK JPとなっている。18.04 LTSからはNoto Serif CJK JPも加わって現在の形となった。
TakaoフォントはIPAフォントの派生版で、長らくUbuntuのデフォルトフォントだった気がしたが、今となってはNoto Sans CJK JPのほうが長く使用していることになってしまった。なおTakaoフォントは10.04 LTSから15.10までで、Noto Sans CJK JPは16.04 LTSからデフォルトのフォントだ。TakaoフォントとIPAフォントは、今もUbuntuのリポジトリからインストールできる。
加えてデフォルトではインストールされないものの、23.04からはBIZ UDフォントも利用できるようになっており、ドキュメントを制作する際には積極的に利用していきたい。なお筆者が用意した22.04 LTS向けのバックポートパッケージも存在する。
何をもってきれいなフォントとするかは個々人の感覚にもよるので難しいところだが、グリフとウエイトが統一されているというのは真っ先に挙げられるところだ。一人ないし少数のデザイナーが同一のポリシーでグリフを作成すると、文字が揃っていてきれいに見えるし、それがどの太さであっても統一されていれば尚更だ。その点、Noto Sans/Serif CJK JPは申し分ない。
フォントのレンダリング
もう1つのフォント表示の品質を決定づける要素は、フォントのレンダリングだ。フォントから抜き出された文字列を実際に表示する、と一言で説明してしまえばそれだけだが、実際にはいろいろとややこしく、さまざまなライブラリが用いられている。アルファベット圏のようなシンプルな文字から、日本語のような複雑な文字、さらに縦書き横書きがあり、右から読み始める言語もある。文字が複雑なら文字の表示も複雑になるのはむべなるかなだ。
言語の複雑さをさておくと、最終的にディスプレイに表示する際はラスタライズ(ビットマップ化)を行なう。これが表示の品質に大きく影響を与える。Ubuntuほか多くのOSではFreeTypeというライブラリが使用されている。
品質に大きく作用するということは特許に絡みやすいということでもある。FreeTypeはFreeType & Patentsというページをわざわざ用意しているくらいだ。ここで取り上げられているのは2つの特許で、AppleのBytecodeの特許は2010年に切れている。もう1つはClearTypeの特許で、こちらは2019年と比較的最近切れている。
Bytecodeの特許で保護されていた機能はすでにデフォルトで使用されている。一方ClearTypeの特許で保護されていた機能はUbuntu(厳密にはアップストリームであるDebian)のパッケージ単位で有効にされている。ClearTypeはWindows XPに搭載された機能で、特許が切れるような期間(20年間)が経ってしまったと考えると時の流れは恐ろしい。
日本語入力
日本語入力の構成
便宜上日本語入力としているが、実際には多言語入力で、たくさんの言語が入力できる。何なら言語ではないが絵文字の入力もできる。
日本語入力の仕組みをインプットメソッドというが、狭義と広義があり、狭義では入力された文字をアプリケーションに渡す仕組みのことである。
入力されたよみがなを漢字に変換する、場合によってはその逆の役割を果たす変換エンジンもある。ただし必須ではなく、変換エンジンを使用せずに分節を自分で区切って辞書による変換を果たすSKKや、キーボードから直接漢字などの文字を入力する漢字直接入力(漢直)なんて方式もある。この場合は変換エンジンは不要だ。
インプットメソッド(狭義)は汎用的に作られているので、変換辞書やさまざまな入力方式に対応したプラグインを必要とする。これをインプットメソッドエンジンと呼ぶ。
とはいえ、このあたりは統一された用語があるわけではないので、大まかにそんな役割分担があると覚えておけばよい。
そして広義のインプットメソッドとしては、これらの3つの総称だ。
日本語入力の変遷
インプットメソッド(狭義)は、歴代のUbuntuではSCIM、IBus、Fcitxが採用されて、現在はIBusが採用されている。またFcitx5も使用できる。筆者は自前でビルドしたFcitx5を使用している。
変換エンジンは、AnthyからMozcになって長い。MozcはGoogle日本語入力のオープンソース版として有名だ。筆者は自前でビルドした(非公開)Mozcを使用している。
Mozcのバージョンとオープンソースのポケット
Mozcは現在活発に開発されている。本稿の執筆時点のバージョンは2.29.5160で、Ubuntu(Debian)のリポジトリにあるバージョンは2.28.4715だ。かれこれ1年ちょっとバージョンアップが行なわれていない。
Mozcは現在ビルドツールとしてGYPとBazelをサポートしているが、前者はメンテナンスモードで、さまざまなモジュールがビルドできないようになっている。Mozcの性能を引き出すにはBazelが必要だが、Ubuntu(Debian)には古いバージョンしかなく、Mozcがビルドできない。筆者が試したところではMozcのビルドに必要なBazelのバージョンは6.2だが、Ubuntuのリポジトリには4.2.3しかない(本稿執筆時点)。
Bazelのバージョンを上げるように要望も出されているが、望みは薄そうだ。
ここで取り得る手段としては、Bazelのバージョンを上げた上でMozcをBazel対応に変更することだが、とてつもない労力が必要だ。実はFedoraも同じ問題があり、現在開発版であるFedora 39ではかなりがんばってGYPのままアップデートを行なっている。Mozcの変更によりGYPではibus-mozcがビルドできなくなっているが、ビルドできるように戻す修正が施されているのだ。
筆者は手元でBazelに対応したMozc(バージョン2.29.5160.102)をビルドし、使用している。原稿を執筆する関係で新しいバージョンをビルドするモチベーションはあるものの、かなり無理矢理ビルドをしているので公式のパッケージにするようなクオリティには程遠い。
Mozcパッケージはさしずめモチベーションとスキルというオープンソースのポケットに落ち込んでしまっているのが現状であると筆者は見ている。もちろん実際は異なるのかもしれないが。