Archの人たちは本当に熱心だ。

Infinalityといえば、フォントの美しさにこだわるLinuxerにとってかけがえのないキーワードであり、定番テクニックだった。

FreeType2が2.7になったとき、同時にInfinalityも消滅した。

これは、FreeType2がInfinality相当のフォントレンダリングを取り込んだから…でもあるが、実は作者失踪のため、でもある。 FreeType2がInfinality相当のサブピクセル計算方法を取り込んだから十分だと考えたのか、それともやる気を失ったのか、いずれにせよ公式にInfinalityの役割を終了することなく…つまり、Infinalityのまざまな機能は取り込まれなかったが計算式だけは取り込まれる形でInfinalityは消滅した。 もちろん、Infinalityはそれ以前に終わっていたのだが、FreeType 2.6の間は機能していた。2.7になって互換性がなくなり、機能しなくなったのだ。

これに対して不満を持つ人は多かった。

まず、Infinalityが終了したことに気づかず、トラブルに巻き込まれた人、というのがとても多い。

そして次に、FREETYPE_PROPERTIES="truetype:interpreter-version=38"は十分ではないと考えた人もまた、いたのだ。

実際、私もFreeType 2.6 InfinalityからFreeType 2.7になってフォントレンダリングの質は落ちた、と感じた。 だが、upstreamの方針ならそれもまた致し方なし…と考えたのだ。

しかし、そうではなかった。 FreeTypeはInfinalityの機能を取り入れる予定はなかったし、別にInfinalityパッチが不要のものになったわけでもなかった。

そしてついにFreeTypeパッチは蘇った。

AURにあるfreetype2-infinalityはFreeType 2.9に対応した新しいInfinalityパッチつきFreeTypeである。 cairo-infinality-ultimate, fontconfig-infinality-ultimateが新たなる対応ソフトウェアとして登場している。 なお、Java用のInfinalityパッチとlib32のFreetypeパッチは投げ捨てられたままだ。

freetype-ultiamte5はInfinalityではない、さらに別のパッチである。 TomaszGasior氏の作で、Infinalityを使わず、直接にFreeTypeにパッチを当て、Infinality Ultimate5相当のレンダリングを得ているという。 fontconfigやcairoにinfinalityパッチを当てる必要もない、なかなか効率的なパッチだ。

FreeTypeはClearTypeのフォントレンダリングを取り込もうとしているらしい。 だが、特許上の問題から今のところ難しいらしい。

この機能自体は実装はされていて、しかし有効にできないオプションとなっている。

Technically, no. The patents cover the whole process of generating and displaying sub-pixel images. Since the font engine doesn’t do the display part, it cannot infringe. Apart from that, FreeType has provided the capability of converting vector shapes into un-filtered sub-pixel images for a long time.

By default, FreeType’s scan-line converter returns ‘gray’ sub-pixel images, where for each pixel the color components are equal (this is, R=G=B). The result is visually identical to gray anti-aliasing and cannot infringe any of the ClearType patents.

Similarly, the LCD-specific filtering API is disabled by default, which means that it returns an error and doesn’t alter sub-pixel images.

You can override these limitations by activating option FT_CONFIG_OPTION_SUBPIXEL_RENDERING in FreeType’s ftoption.h configuration file, but you should do that at your own risk.

この機能を(自己責任において)有効にした状態でビルドしたものがfreetype2-cleartypeである。

そしてこのいずれも、最も劣悪にまで落ちてしまったLinuxのフォントレンダリングを改善してくれる。

リスク順に考えてみよう。

freetype2-cleartype

特許上の問題がある。設定オプションを変更しているだけなので、Infinalityパッチ環境で2.7に上がったときのような問題は起きないと思われる。

技術的には最も安全。特許状の問題は、個々の環境で有効にする分には問題はない…?

freetype2-ultimate5

小規模なパッチで、取り残される心配は作者が投げない限りはなさそう。

動作もinfinalityに比べれば軽く、戻すのも比較的簡単。 ぜひともupstreamに取り込んで欲しい逸品。

freetype2-infinality

fontconfigとcairoにも依然としてパッチを当てる¹必要がある。 動作も重く、やや不安定。

現状では問題なく動作しているが、リスクは最も高いように思われる。

freetype2-ultimate5とinfinalityパッチは関係がないはずだか、freetype-ultiamte5 + fonconfig-infinality-ultimate のほうが美しいように感じた。

なお、これらのパッケージはAURのものであり、Arch、あるいはAURを利用する他のディストーション(Anterogos, Manjaro)以外においては導入は難しいかもしれない。

追記。実際に比較してみた。

設定を全くせずにインストールだけするとfreetype2, freetype2-cleartype, freetype2-infinalityの結果は全く同じだった (composite -compose Difference afile bfile difffileとidentify -format "%[mean]" difffileで確認)。

freetype2-ultimate5は異なるレンダリングをしている(見た目にも明らかに濃い)が、fontconfig-infinality-ultimateによる違いはなかった。

繰り返すが、これはあくまで「設定は一切せずに」比較している。

ただ、結局はfreetype2-ultimate5がよさそうだという感触なのだが。