『State of Text Rendering 2024』を読んだ

https://behdad.org/text2024/

HarfBuzzの筆頭開発者であるBehdad Esfahbod氏によるState of Text Rendering 2024 (2024年テキストレンダリングの現状)という記事が、今年7月に公開された。
現在のフォントやテキストレンダリングに係るソフトウェアやエコシステムについてを広くカバーした論考であり、その分野に興味がある人は一読をお勧めしたい。しかし大著であるので読むのには時間がかかるかもしれない。というか、かかった。

さて、私は当該記事を読み、自分の理解の補助とするための雑な日本語訳を作成した。後ろに記載する。
始めはまとめのつもりで書いていたが途中からだんだん翻訳に近い形になった。厳密な訳になっていない場所もある。自分はこう読みましたという理解であり、間違いも多々あるかもしれない。
この訳を公開するのは、他人を助けるというよりは、自分は読みましたよということを表明するためだけに近い。

これ単独で読むことを意図してはおらず、読む場合は元記事と対照しながら読んでください。リンクやイタリックなどは省いたところがあり、原文を参照してください。参照をしやすくするために見出しには一部原語表記を併記した。
また、試訳では原文の一文ごとに改行を行っている。これは、原文の一文を複数の文に分けている場合があるからである。

和訳の2パス目が終わり、3パス目をやる時間がないので、欠陥があるだろうが公開する。訳に対する指摘は歓迎だが、反映できる保証はないし、この記事を原文のアップデートに合わせて都度更新するつもりもない。
なお、参照したのは2024年7月8日版(initial public release)であるが、公開媒体がGoogle Docsのプレビューページであるため、訳してるうちに原文の方が変化してしまっている感じがする。2パス目は2024/9/21～2024/10/3頃にやった。

ライセンスは、元記事がCC BY-SA 4.0であるため、この翻訳についてもCC BY-SA 4.0でライセンスされる。

以下試訳↓

ライセンス / License

（オリジナルの）このテキストはCC BY-SA 4.0でライセンスされている。

概略 / TL;DR

2009年からの、OpenType標準およびオープンソースのテキストスタックとアプリケーションにおける進展について書く。さらに、現在検討されている今後の進歩についても議論する。

大まかにいうと、OpenTypeが追加したのはカラーフォント、バリアブルフォント、Universal Shaping Engineである。
フリー/オープンソーススタックでは比較的低レベル(低レベルプログラミングの低レベルの意)ではそれらをすべてサポートしているが、アプリケーションのUIとして現れるのはより後になる。
オープンソーステキストスタックは巨大なマーケットシェアを獲得した。これはAndroidとGoogle Chromeが採用したからである。
AdobeはOpenTypeシェイピングのためにオープンソーススタックの一部をPhotoshop, Illustrator, InDesignなどのフラッグシップアプリに統合している。

今後に目を向けると、テキストスタックをRustへと移行することが現在行われており、安全なプログラミング言語でフォントのコンパイルと実行が可能になる。
Incremental Font Transferによりwebブラウザにフォントをストリーミングすることが可能になる。
私の提案するWasmフォントにより、OpenTypeシェイピングモデルでは完全にサポートされていない（というか根本的にサポート不可能な）もっとも複雑な類の書記体系の正しいレンダリングを行うことが可能になるだろう。そしてまた、ラテン文字などの単純な書記体系でももっと表現力のあるフォントが作れるだろう。

ライセンス / License
概略 / TL;DR
目次
前書き / Foreword
- 献辞 / Dedication
- 前提条件 / Prerequisites
導入 / Introduction
振り返って / Looking back
これからの展望 / Looking forward
- Better-Engineerd Font Formats (より優れた設計のフォントフォーマット)
- 他の取り組み / Other efforts
  - Fontra
  - Incremental Font Transfer
分析 / Analysis
他のリソース / Other resources
謝辞 / Acknowledgements
著者について / About the author
バージョン履歴 / Version history

前書き / Foreword

2009年に私はState of Text Renderingを書いた。これはフリーソフトウェアのテキストレンダリングスタックの高いレベルのレビューであり、シェイピングに焦点を当てていて、大部分はGNOMEデスクトップの観点からのものである。
その後、12年ほど、フォントやテキストレンダリングを改善するための様々なGoogle製品に取り組んだ。それらはすべてオープンソースの成果物である。

その文章を書いた2009年での私の課題はHarfBuzzを完成させることだった。
2012年ころ、HarfBuzzは十分な完成を見て、私の興味は他に移った。
私はGoogle Internationalization EngineeringのFonts & Text Renderingチームのテックリードだった。その組織はNoto Fontsプロジェクトの立ち上げと、MonoTypeやAdobeへの外注の責任者であった。
私が実感したのは、Googleで我々はテキスト表示のすべての局面をコントロールする、つまりフォントデザインから数十億のデバイスでのレンダリングまでをコントロールする、ただしフォントフォーマット自体は除く、ということだ。
絵文字がUnicodeテキストとして登場し、テキストAPIを使ってレンダリングする需要があったことから、2013年にフォントフォーマットを拡張して色情報をサポートするようにした。
これは目を見開く様な体験であった。というのは、フォントフォーマットの制限によって妨害されないようにしなければならなかったから。
以後、フォントフォーマットの拡張は私の興味と責任の中心となった。

この時点での私のキャリアにおけるもう一つの大きな転換点は、フォントのタイプデザインの世界へと足を踏み入れ、他のものとともに、fontmakeというフォントコンパイラを作ったことだ。
そのような次第なので、フォントデザインとコンパイルを同様にこの論文に含める。

この締め切りをとっくに過ぎた更新で、私が調査したのは、OpenType標準およびオープンソースのテキストスタックとアプリケーションにおける進展についてだ。
私はまた、この分野において将来どのようなものがあるかを議論する。

and then publish a dated article that can stand as a historical artifact similar to the 2009 article.
本当の早く・頻繁にリリースするという伝統に基づいて、この文書を、含まれるすべてのアプリケーションやプロジェクトに関する調査を終わらせることなしに公開する。
多くのTODOを残しているし、この記事に含むように私の目の前に現れなかったような多くの話題やトピックが含まれないままになっている。
コメントや情報提供を歓迎する。
Google Docs版のページでコメントができるし、また、電子メール経由で私に連絡してくれてもよい。
私の連絡先は私のホームページにある。
少なくとも2024年終わりまでこの文書を更新することを予定している。その後、2009年に出した記事と同様の歴史的な遺物たり得る時代遅れの文書を公開する予定だ。

15年は更新を書くには長い時間である。その結果としてこの文章は非常に長いので、お詫び申し上げる。
この文章はおおよそ別々の章を独立して読むことができるように書かれている。前提条件がそろえば。
このために、文章には多少の冗長性がある。この冗長性のために読者が退屈して読むのをやめてしまうことがないよう願っている。

献辞 / Dedication

Emil ‘eae’ EklundとSaber Rastikerdarの思い出に捧ぐ。

Emilとともに私は何週間も過ごし、長年のChromeのテキストレイアウトを改善した。

Saberは美しいオープンソースのペルシャ語フォントを作成した。これは私の夢であった。

前提条件 / Prerequisites

読者がテキストレンダリングがどのように動くか、例えばシェイピング(shaping)とかについての知識を持っていることを前提とする。
そのようなトピックがあまり身近なものでないように感じられるなら、次のような文書を読んでおくとよいかもしれない。

State of Text Rendering (2009) https://behdad.org/text/
Modern text rendering with Linux: Overview (2019) https://mrandri19.github.io/2019/07/24/modern-text-rendering-linux-overview.html
(若干高レベル) Text layout is a loose hierarchy of segmentation (2020) https://raphlinus.github.io/text/2020/10/26/text-layout.html

導入 / Introduction

コンピュータフォントは50年を超える経歴をもつ。多くのフォント形式や枠組みが来ては去っていった。1990年代のいわゆるFont Wars（フォント戦争）が、結果としてOpenTypeフォントの導入と、デジタルテキストにおけるリンガフランカとしての支配的状況を招いた。タイプデザインと利用の両面においてである。

3つのメジャーなOpenType実装は、2024年において次のようになっている。

DirectWrite … Uniscribeの後継。Microsoftのネイティブ実装。ただしMicroisoft Edgeでは使われていない（次章で詳しく述べる）。
CoreText … ATSUIの後継。Appleのネイティブ実装。
FreeType + HarfBuzz … オープンソース実装。

Appleはまた自身のTrueTypeのオリジナルのラインをもち、それはApple Advanced Typography (AAT)へと発展した。これはOpenTypeへのオルタナティブである。2010年代からAppleはOpenTypeを新しいフォントファミリーとして採用したが、Appleのプラットフォームにおいて多くの重要なファミリーはAATフォントのままとなっている。そのようなプラットフォームにおいて、AATをオープンソーススタックでサポートすることは、円滑な体験を得るために重要である。

Adobeも独自のOpenType実装のラインをもっていたが、我々のの知る限り、彼らはメンテナンスをやめて、オープンソーススタックへと移行する途中である。

Monoypeも独自のOpenType実装のラインをもっている。そして我々の知る限り、彼らはまだメンテナンスしている。特に、組み込みデバイス（プリンターなど）のような専門家ドメインのために。
彼らはまたオープンソーススタックのサポートを顧客に販売している（というのは、そういった顧客は何かを始めるにあたってそこら辺にあるオープンソースのものを採用することがよくあり、その後要件を満たすためにソフトウェアベンダーに依頼したい必要性が大きくなるからだ）。

この論文において私が調査しているのは、オープンソースのフォントや、テキストのプロダクションとレンダリング状況の進展についてのここ15年であり、そしてこれからの行く先にあるもの光をあてた。

振り返って / Looking back

この章では、私はこの地平におけるここ15年の発展について調査していく。

OpenType

OpenTypeは2014～2016の間になかなかの活動があったが、その後休眠期に入った。というのも、エディター（Peter Constable）が別のプロジェクトにアサインされ、その後マイクロソフトを去り、後にエディターとして再加入したという経緯があった。
カラーフォントの面で最近の活動がある。そして新しい提案があるが、これは次章で記述する。

次に述べるような新しい機能は、FontTools, FreeType, HarfBuzz全てがサポートしている。

カラーフォント / Color fonts

カラーフォントは災害のような厄介なものとなった。

2012年までにAppleはすでにsbixフォーマットをemojiフォントに運用していた。標準化はなかった。これは後の2016年にOpenTypeにコントリビュートされた。
2013年に私はGoogleで独自のオープンソースのフォーマットCBDT/DBLCを作った。これは既に存在したOpenTypeモノクロビットマップの仕組みを元にしたもので、Androidの絵文字用であった。
2か月後、MicrosoftはCOLRという手法を発表した。これはベタ塗りの色のレイヤーの組合せが順番に重ねられてレンダリングされるもので、彼らの提唱するMetro design languageに沿うものだった。これはCOLRv0と現在は呼んでいる。というのは後に拡張されてCOLRv1となったからだ（下で詳述）。
最後に、AdobeとMozillaはSVGの手法に取り組んでいて、これはその後すぐリリースされた。

sbixとCBDT/CBLCはPNGビットマップベースである。COLRはベクターアウトラインだがベタ塗りのみ、SVGは任意のベクタグラフィックスをサポートするが複雑すぎると思われる外部仕様に依存している。
2016年後半において、COLRはバリアブルフォント（後述）と組み合わせるために更新の必要がなく、バリエーションをサポートする唯一のカラー形式であり、同様にまた、カラーをサポートする唯一のバリエーション形式である。
なので、すべてのユースケースを一つでカバーするような形式はない。
各形式は相当の年月をかけて、ブラウザや他のアプリケーションで利用できる様に進んでいった。
上手い名前をつけたものだと思うが、colorfonts.wtfというwebサイトは、ブラウザやアプリにおけるカラーフォントの対応状況をまとめている。

目立つところだと、ChromeとAndroidはSVGによるカラーフォントの実現をしないと方針決定をした。これはアーキテクチャ上の理由からである。この方針により、SVG形式の到達範囲が制限された。
しかしGoogleはカラーフォントのグラデーションがほしかったため、
2019年にChromeのDominik RöttschesとGoogle FontsのRoderick Sheeter (Rod)と共同して我々はCOLRv1とするための提案を開発した。
数年かかったがMicrosoftと共働することで、2022年あたりでOpenTypeに追加され、そしてすぐにChromeとAndroidなどのシステムに搭載された。しかし、Safariや、Adobeのフラッグシップアプリ、Figmaなどではいまだサポートされていない。
先輩のCOLRv0と同様に、新しいCOLRv1もバリエーションをネイティブサポートする。

Google Fontsチームはnanoemojiというカラーフォントコンパイラを作成した。これはフォントを様々な形式でビルドすることができる。
このツールはGoogleとMicrosoftのカラー絵文字フォントをビルドするのに使われている。

Universal Shaping Engine

2013年までにHarfBuzzはMicrosoftのOpenType実装に完全に追いついた(時としてバグに関しても)。インド文字のシェイピングや、より最近のミャンマー文字のシェイピングが完成したので。
Jonathan Kewと私は、SILのMartin Hoskenと協働してSouth-East Asian (SEA)シェイパーという新しいシェイパーを追加した。これはそれら用字系の単純化されたモデルを元にしている。
我々はOpenType会議においてこれを産業パートナーに提示した。この会議はシアトルで私が開催したものだ（その時からいろいろなGoogleやFacebookのオフィスで私がホストしたたくさんの会議のうちの一つである）。

2014年にサンホセのUnicodeカンファレンスにて、MicrosoftのAndrew GlassがUniversal Shaping Engineを提示した。これはSEAと似たアイデアを利用していたが、はるかに完成度の高いものだった。
それを受けて、我々はそれをHarfBuzzに実装し、SEAシェイパーを非推奨とし、取り除いた。
新しいシェイパーはUnicodeに追加された大抵の複雑な用字系を取り扱うには十分な能力があったので、それ以降に新しいシェイパーは必要とされていない。

バリアブルフォント / Variable fonts

2014年に私は1990年代のアイデアを復活させると決めた。それは、実行時にフォント補間を実行するというものだ。
これはAppleのTrueType GXやAdobeのMultipleMasters (MM)技術として存在した。しかしOpenType仕様の中に残ることはなかった。というのはMMは維持するのには複雑すぎるとみなされ、初期のOpenType仕様から削除されたからだ。
Peter KarowのIKARUS (1973)とその後のDonald KnuthのMETAFONT (1977)技術は1970年代に同様のアイデアに基づいて作られたものだが、これらはフォント生成時に行うものである。
とはいえ、フォント補間のアイデア自体は、少なくとも1885のベントン母型彫刻機まで遡れる。

2015年の間ずっと私はそのアイデアを主張し、2016年の2月にその青写真を公開した。
その後6ヶ月のAdobe, Apple, Google, Microsoftと招待した産業専門家との協働において、その機能はOpenType 1.8にフォントバリエーション（Font Variation）として追加された。そのようなフォントはバリアブルフォント(variable font)と呼ばれる。
Tom Ricknerがバリアブルフォントの背景についてこの記事でまとめている。

端的に言って、以前はOpenTypeフォントは拡縮可能(scalable)であった、つまり、フォントサイズは任意に変更できた（ベクタフォントなので）。ところがフォントバリエーションありだと、フォントの他の要素、例えばカスタム要素が、形状において滑らかに変化(vary)し得る。
そのような要素には、太さ(weight)、幅(width)、傾斜(slant)、オプティカルサイズなどがあるが、これらに限られない。

v-fonts.comというサイトにはバリアブルフォントの良質なコレクションがあり、それは提供元もライセンスにおいても多様である。これはGoogle Fontsが発注したのが最大の一つのコレクションかつ、Open Font Licenseで提供されているのと対象的だ。
v-fonts.com/supportはまた、著名なデザインソフトのサポート状況の素晴らしいリストを更新している。
スライダーを動かしてみて、バリアブルフォントが何をすることができるかをチェックしてください。
バリエーションフォントに関してのさらなる資料は、Axis-Praxis resourcesを参照。

ライブラリー・トリオ / A trio of libraries

現在のオープンソースフォントのコンパイルは、たくさんのPythonライブラリやツールでなされているが、それらはすべてFontToolsプラットフォームの上で構築されている。
一方、フォントの利用は、一般的に2つのライブラリの上に構築されている。FreeType (Cによる一般的なフォント処理、大抵はラスタライズ用)とHarfBuzz (C++による一般的なフォント処理用で、シェイピングで多く使われる)の2つ。

FontTools

FontToolsはもともとJust van Rossumが1999に始めたものであり、フォントアセンブラ/ディスアセンブラ(./ttx)、フォントテーブルを表現するXMLフォーマット(.ttx)、Python API (fonttools)として作られた。
そのXML形式は、すぐにフォントバイナリを人間可読形式で表現する事実上（デ・ファクト）の標準となった（そして今もそうだ）。
そのXML形式は、Yannis Haralambousの大著Fonts & Encodings (O’Reilly)にも現れる。
Justの意図としてはPythonを使ってFontToolsの上にフォントエディタを構築することであった。
彼の言葉を引くと、「意図したようなフォントエディタはその時点で具現化しなかった。後にいくつかの試みがあり、現在我々はFontraがある(^_^)」。

私がこのライブラリにコントリビュートしようと思った2013年まで、このプロジェクトは大部分が休止状態だった。
Justから何も返信を受け取れなかったので、私はそのプロジェクトをフォークし、Googleのチームと一緒にその開発に労力をつぎ込み、その上にfontmakeコンパイラを作成した。
2015年についに私はJustと連絡をつけることができ、彼は再びFontToolsの活発な開発者となった。そのとき私はしばらくメンテナンスしていたが、その後Cosimo Lupoへとメンテナンスを受け継いだ。彼は当時、世界最大級のフォント開発企業の一つDalton Maagに所属していて、その後Google Fontsチームに加わった。

カラーフォント、variable fonts、その他テーブルの追加をサポートすることの他に、FontToolsはかなりの数の高レベルモジュールを獲得した。さらに外部のプロジェクトから他のものを吸収した。
それらというのは、例えば、フォントサブセッタ、variable-font (partial-)instancer、Unified Font Object (UFO)フォントソース形式を取り扱うコードなどである。

fontmakeコンパイラはFontToolsモジュールの他、ufo2ft, glyphsLib, cffsubr, skia-pathops, ttfautohintなどのモジュールの上に成立している。

Adobeは2014年に、彼らのAdobe Font Development Kit for OpenType (AFDKO)をオープンソース化した。
しかし時間が立つにつれて、多くの人の興味はFontTools/fontmakeエコシステムへと移動した。

Fontmakeは小さいタイプファウンドリでも大きいところでも等しく使われている。特に再現性のあるビルドと継続的インテグレーション(CI)のために。
FontToolsは多くのオープンソースフォント形式の開発のための実験プラットフォームであることから、fontmakeは新しい機能を実現するために速やかに更新されてきた。プロプライエタリかオープンソースかにかかわらず他のコンパイラより早く。

FreeType

FreeTypeはフォントアクセスライブラリとラスタライザである。Cライブラリであり、もともとDavid Turnerが1990年代に開発したものだ。
FreeTypeはWerner Lembergによって継続的にメンテナンスされている。
このプロジェクトはAdobeからの重要な貢献を受けた。それは新しいCFFラスタライザ(2013)とCFF2バリアブルフォントサポート(2016)の形であった。
他の大きな変更としては、すべてのカラーフォント形式（最新のCOLRv1を含む; Dominik Röttschesの貢献による）をサポートできるようにしたこと、バリアブルフォントのフルサポート（小生によるたくさんの追加を含む）、新しい改善されたftinspectユーティリティ(Google Summer of Codeの学生プロジェクトだった)などである。

ファジング(fuzzing)とセキュリティバグ修正が頻繁にGoogle開発者により提供された。それはoss-fuzzとChromiumファジングエコシステムにより発見されたものだ。
FreeTypeはテキストレンダリングの中心となるコンポーネントであり、組み込み機器からすべてのモダンなLinuxデスクトップ環境まで、さらにはAndroidやChrome OSにも入り、総インストール数は数十億にまでなっている。
FreeTypeは年季の入ったCライブラリであり、
バッファオーバーフローや似たようなメモリ関係の問題がいくつかのCVEを起こし、特にApple製品においてゼロデイを引き起こした。
ファジングはそのようなバグの積極的な修正に大きく貢献したものの、より安全な言語で書かれたもっとモダンなソリューションへと移行する需要は高いままである。
いくつかの試みはあった。多くRustエコシステムで書かれたものもある。
後述する。

現在までに、FreeTypeは109個のCVEの記録をもつ。

HarfBuzz

HarfBuzzはテキストシェイパー(text shaper)であり、C++で書かれていて、C APIをもつ。
最近はOpenTypeとAdobe Advanced Typography (AAT)の両方のシェイピングモデルをサポートしている。
私は2005年からこれに取り組み始めた。
書き直された版は、harfbuzz-ngというコードネームだが、2012年前後に公共利用ができるように整った。MozillaのJonathan Kewとの共同作業によって。
それから、我々はそれを最新の状態に保っている。つまり、バグを修正し、パフォーマンスを改善し、さらにはテキストシェイピングの先の新しい機能を追加している。
より最近だと、David Corbettが東南アジア文字サポートのメンテナンスを引き継ぎ、Khaled Hosnyはメンテナンスとバグのトリアージを引き継いだ。私は現在はリードデベロッパーとなって関わっている。

2010年に私がRed HatからGoogleのChromeチームに移動したとき、私の主なモチベーションの一つは、HarfBuzzの新しいマーケットシェアを獲得することだった。というのはLinuxデスクトップ市場は、HarfBuzzへの継続的な投資を正当化できるほどには大きくなかったからだ。並びに、フォント開発者たちにとっても関連性のあるものとしつつ。
それから、HarfBuzzの使用は急速な拡散を見た。Androidがそれを搭載した時、そしてChromeとFirefoxがすべてのプラットフォームでそれを使うように切り替えた時に。
それはさらに、すべてのLinuxデスクトップ、ChromeOS、LibreOffice、OpenJDK、XeTeXや多くの他のプロジェクトでも使われている。また、プロプライエタリシステムでも使われている。例えば、AdobeのPhotoshop、Illustrator、InDesignや、PlaySation、多くのスマートTVなどで。さらにはMicrosoftのEdgeブラウザにも搭載された(Chromium経由で)。

HarfBuzzへのシェイピング以外の機能での最大の追加は、フォントサブセッタと、バリアブルフォントの(部分的-)インスタンス化器（(partial-)instancer）である。これらはそれぞれGoogleのGarret Riegerと、Qunxin Liuによって率いられたものだ。
それらは印刷の様々なアプリで使われている他、Google Fontsに燃料を与え、今後Incremental Font Transferでも利用されるだろう(次章で詳述)。

HarfBuzzはラスタライザをもたないが、draw & paint APIをもつ。それは既存のグラフィックエンジンと組み合わせることができて、モノクロフォントやカラーフォントをレンダリングできる。
これはいくつかのHarfBuzzを使うwebアプリで利用されており、またFontGogglesというオープンソースのMac専用のフォントインスペクタおよびビューア(Just van Rossumによって作られ、Google Fontsがサポートする)がある。

Chrome, Android, Google Fontsによる継続的な需要のおかげで、HarfBuzzの実行時パフォーマンスとメモリー使用はこの産業界でも最良のものとなっている。

HarfBuzzをwebで使うことが始まりつつあり、まずJavaScriptへとトランスパイルされ、より最近だとWebAssemblyへとharfbuzzjsを通じてクロスコンパイルされた。
オンラインフォトエディタのPhotopeaなどのアプリでは、そのように利用している。
Simon CozensのCrowbarはOpenTypeシェイピングデバッガーwebアプリであり、HarfBuzzのbuffer-messaging API使って作られている。
SplootはSimonによる別のwebアプリであり、フォントインスペクタである。
PreziとFigmaもまた、HarfBuzzをそれらのwebアプリで使っている。

HarfBuzzはRustやGoへと移植された。そして様々な言語で書かれた様々なシェイピングの実装に刺激を与えた。
HarfBuzzはかなりの数の言語向けのバインディング(bindings)を持っている。
Monoと.NETの統合の一環として、HarfBuzzは今や.NET APIの一部である。

HarfBuzzはoss-fuzzファジングを信仰心をもって利用してきている。
これを書いている時点で、HarfBuzzはCVEの記録が9つしかない。そのうち8つはDoS（サービス拒否）であり、1つだけがメモリーアクセスの問題であった。

メンテナンス

3プロジェクトすべて、十分健全なオープンソースの活力(life)とコミュニティをもつ。
それぞれのプロジェクトがリードメンテナーを擁し、1～2人のアクティブな開発者がいて、あまり深く関わっていないたくさんのデベロッパーとコントリビュータをもつ。

聞いたら驚くかもしれないが、これら3つの基礎的なライブラリーをメンテナンスしている3人の開発者には、興味深いバックグラウンドがあり、ちゃんとしたコンピュータサイエンスの教育を受けていない。その3人とは、Cosimo Lupo, Werner Lemberg, Khaled Hosnyである。

Cosimo Lupo
はFontToolsをメンテナンスしている。
Cosimoは人類学を専攻した後、フォントエンジニアになり、それからロンドンでソフトウェア開発者となった。
そのただ一つの理由は、彼は特定の印刷フォントが非常に好きだったからというものだ。
彼は次のように書いている。

大学時代を振り返ると、私は本の虫であり、特定のカスタムGaramond (厳密にはJannon)のタイプフェースを気に入っていた。それは高尚なイタリアの出版社(Einaudi)のものだ。私はそれが非常に好きだったので、そのフォントを自分の学位論文で使いたかった。しかしそれは売り物ではなかったので、私は結局そのフォントType1からOpenTypeへアップグレードする仕事をしている人と知り合い、切り替え式のライニング数字を自分で作ったりした(それは出版社の本で使われることはなかった)。これは学位論文を研究していた合間の余暇で行ったことだ。卒業したあと、この趣味は仕事へとなり得ることを実感し、DaMaのインターンシップを受けることができ、あとはご存知の通りだ

Werner Lemberg
はFreeTypeをメンテナンスしてもう20年になる。Wernerは経験豊かな音楽家であり、オペラ歌手トレーナーとしてドイツとオーストリーの様々なオペラ劇場で働いている。
彼の言葉によると、

1989年頃私は中国のマウス・オルガンの一種である笙についての論文を書きたかった。またテキスト組版において、コンピューターで漢字を使いたかった。手書きで書き足すの嫌だった。その時点では、MS-DOSのプログラムでできるものはほんの少しあったが、高価なものであった。そしてLaTeXがあった。LaTeXなら私がやりたかったことが実際に可能だと私は教えられた。これが私がタイポグラフィの世界に足を踏み入れた最初であった。
1990年頃、CJKビットマップフフォントだけが自由に入手できた。そしてLaTeXはCJKアウトラインフォントのサポートをしていなかった。しかし数年後、私はTrueType形式を発見し、最終的にWindows 3.1の一部として追加コスト無しで入手できる、その形式での良質なアウトラインCJKフォントを発見した。私は非常に興奮し、自由に入手できるレンダリングエンジンを書くことを考えもした。しかし、幸運なことにDavid TurnerのFreeTypeプロジェクトを1995年に発見し、それはすべての機能を持つTrueTypeインタプリターとラスタライザとなることを意図していた。そして私はすぐ活発な開発者となり、その後このパッケージのメンテナーとなり、今でも続けている。

Wernerと彼の娘がATypI 2013アムステルダムで演奏した動画を御覧あれ。

Khaled Hosny
はHarfBuzzの現在のメンテナーである。
Khaledは以前は放射線科医であった。エジプトのカイロに拠点を置く、フルタイムのフォントエンジニア・ソフトウェア開発者となるまでは。
彼のフォントへの興味はアラビア文字のナスフ体の良いフォントがほしかったことに端を発する。
これについて彼はここでツイートしている。
彼はまた、様々なオープンソースアプリをHarfBuzzを使うように切り替えるための手段となっている。

これまでに私が(何らかの形で)HarfBuzzへの移行を手助けしたのは、LibreOffice, XeTeX, Scribus, Emas, LuaTeXだ（またRaqmを通じてImageMagick, Pillowなどにも関わっている）。

Khaled Hosny - 一度に一つのアプリケーションにおいて、自由なテキストレイアウトを修正する。

アプリケーション / Applications

この章では、非常に著名なテキストレイアウトのオープンソースアプリケーションを、カテゴリごとにレビューしていく。

Fontmake代替

AFDKO
Adove Font Development Kit for OpenType (AFDKO)は2014にオープンソース化された。
しかしオープンソースの中であまり利用は増えなかった。これはfontmakeが信頼できるコンパイラの需要を素早く満たしたからだ。
AFDKOは、大部分においてCFF方式のOpenTypeフォントの制作をサポートし、(より一般的な)TrueType方式はサポートしない。
Fontmakeは両方をサポートしていて、これはバリアブルフォントの両方式でのサポートなども含む（CFF方式のコードはAdobeによって実装された）。

開発は顕著に鈍化している。というのは、このコードに関っていた影響力を持つAdobeのエンジニアの多数が退職したからだ。

FreeType代替

2010年代には、たくさんのフォントラスタライザの出現がみられたが、多くはGPU上で動くものだ。

CPUベース
FreeTypeは今でもオープンソースのフォントラスタライザでもっとも一般的に使われているものである。
これはCPUベースである。
他のCPUベースのソリューションには、stb_truetype、RustTypeやfont.rsがある。

stb_truetype
はシングルヘッダのフォントライブラリであり、CPUベースのラスタライザである。そして時々、リソースの制限された比較的小さい製品に使われる。
メモ: これは、信頼できないフォントデータをセキュアに扱うことはできない。

RustType
Redox OSプロジェクトからのものであり、Rustで書かれたFreeType オルタナティブである。ヒンティングエンジンを持たない。

font.rs
はAndroid等で著名なRaph Levienによって開発された。Rustで開発されたもう一つのCPUベースラスタライザである。世界最速のラスタライザだと主張している。
TrueTypeベース（つまり、2次ベジエ）のOpenTypeフォントのみを取り扱うことができ、CFFベース（つまり、3次ベジエ）のものは取り扱うことができない。

GPUベース
いくつかのGPUベースラスタライザが開発されたが、品質と精巧さはまちまちである。
以下にいくつか挙げるが、ほとんどのものはOpenGLシェーダーを使っており、オープンソースである。(TODO: それぞれの重要なクライアントを追加する)

現在あるCPUベースのラスター化はふつう範囲ベース(coverage-based)である。言い換えると、形状によってカバーされる各ピクセルの部分の近似を求めている。その一方で、Valveが2007に論文を出して以降、Signed-Distance Field (SDF)テキストレンダリングは研究・実験の注目のトピックとなった。

Nicolas Rougierと私はラスタライザーの現状について、2018年のSIGGRAPHのデジタルタイポグラフィーミニコースで調査した。
そのスライド資料の中にはもっと詳細な情報があり、より深く知るための資料と参考文献がある。

freetype-gl
はNicolas Rogierによるもので、SDFテスクチャベースのラスタライズである。

GLyphy
は私自身によるもので、SDFベクタベースのラスタライザである。
GLyphyは重なるグリフ形状を扱わず、そのため、重なっている部分を取り除く処理を他に用意しない場合には、バリアブルフォントを処理するのには不適である。

msdfgen
はViktor Chlumskyによるもので、マルチチャンネルの、改善されたSDFテクスチャベースのラスタライザである。

Pathfinder
は多作のPatrick Waltonによるもので、これは他と比べてはるかに高度なラスライザである。多くのテクニックとトリックの集まりを組み込んでラスタ化を高速化している。
これはMozillaのServoというwebレンダリングエンジンの一部として開発された。
残念なことに、このプロジェクトはあまり活発に開発されていないようである。

Slug Library
はEric Lengyelによるもので、有望だがプロプライエタリなラスタライザであり、解析的な手法に基づいている。

NV Path Rendering
はNVIDIAによるもので、汎用的なパスレンダリング手法であり、NVIDIAのプロプライエタリなGPUドライバに組み込まれている。
これは特にテキストを指向したものではないが、TrueTypeアウトラインをレンダリングするサポートが少し入っている。

パフォーマンス比較
この図は、Pathfinderプロジェクトによる、すでに古くなったパフォーマンス比較である。
FreeTypeのパフォーマンスはこのときより改善されてきた。FreeType開発者のAlexei Podtelezhnikovのおかげである。
ここで注意すべきなのは、ラスタ化にかかる時間が占めるのは実際のレンダリングにかかる時間のほんの僅かであるということだ。これはグリフとフォントのキャッシュを行っているためである。
この例外は、毎フレームごとにキャッシュせずラスタライズを行うGPUベースの手法である。

HarfBuzz代替

ICL Layout
ICUレイアウトエンジン(ICU LE)シェイパーは非推奨となり、そのうちICUから取り除かれた。これはHarfBuzzを使うようにしたためである。
私のicu-le-hbライブラリは、ICU LE APIをHarfBuzzの上に実装しているので、ICU LEの当座の代替として使える。

m17n
M17nシェイパーは、表現用言語としてLispを使っていたが、開発が打ち切られたようだ。

SIL Graphite
SIL Graphiteシェイパーは、高度なナスタアリーク体のシェイピングをサポートした。これは、SILのAwami Nastaliqというウルドゥー語ナスタアリーク体フォントで使われている。
HarfBuzzは、Graphiteサポートを有効にしてコンパイルすることができ、そうするとSILのオープンソースのgraphite2ライブラリを使ってGraphiteフォントのシェイピングを行う。

ChromeとAndroidはHarfBuzzへのGraphiteバックエンドを搭載していないので、市場シェアは小さいままである。
FirefoxはGraphiteをサポートするが、これはlibgraphite2を直接利用している。これはXeTeXと同様である。
LibreOfficeで使うには、HarfBuzzがlibgraphite2サポートを有効にしてコンパイルされている必要がある。

Wine
技術的にはシェイピングエンジンではないが、WineはMicrosoftのUniscribeとDirectWriteのシェイピングエンジンの実装を含んでいる。
これにより、wineは、HarfBuzz以外のシェイパー実装を使う、おそらく最大の優れたオープンソースプロジェクトとなっている。
HarfBuzzとUniscribe / DirectWrite間のAPIの不整合が、統合を困難なものとしている。

AllSorts, RustyBuzz, Swash
これら3つは、HarfBuzzに触発されたシェイパーであり、全体が安全なRustで書かれている。

AllSortsには見たところUniversal Shaping Engineなどの機能がないようだ。

RustyBuzzは現状、最新のHarfBuzzに一番追従して更新されているものである。

Swashは休眠状態のようで、開発者のChad Brokawの時間はGoogleのfontationsに費やされている。
次の章で更に述べる。

双方向アルゴリズム

次に述べる3つのエンジンは、最新版のUnicode Bidirectional AlgorithmとUnicode Character Databaseに追従している。

FriBidi
はDov Grobgeldと私によるもので、双方向アルゴリズムの産業標準的なコンパクトな実装である。

FriBidiは私が最初にコントリビュートしたメジャーなオープンソースプロジェクトである（1999年のこと）。
このプロジェクトで私はC言語プログラミングを学んだ。

ライセンスがLGPLであるため、FriBidiはプロプライエタリシステムや組み込みシステムでは、商用ライセンスなしでは簡単には利用できない。

ICU bidi
はICUプロジェクトによるもので、今でも双方向アルゴリズムのヘビー級であるが、ICUを搭載できるかICUへリンクできるプロジェクトで使われている。例えば、ChromiumやAndroidなど。

SheenBidi
はTehreerの成果によるものだが、そのエリアでの新しい挑戦者である。
この長所としては、小さいことに加え、より寛大な（伝播性のない=クローズドソースでも使える）Apacheライセンスなことがある。

印刷

近頃の印刷はグラフィックスライブラリからPDF出力するという方法でなされることが多い。
PDFはすでにレイアウトされているので、PDFを（紙またはディスプレイの上で）表示する際にシェイピングを行う必要がない。
そのようであるので、PDFへ埋め込む際に、フォントはレイアウト固有の部品を取り除くように縮小することが可能だ。

PDFがサポートするフォント形式は限られている。また、OpenTypeカラーフォントやバリアブルフォント形式をサポートするように更新されてはいない（そして多分更新されることもないだろう）。
その代わり、バリアブルフォントはPDFに埋め込む前にインスタンス化（instantiated）して静的なフォントにする必要がある。
他方カラーフォントは、PDFに埋め込むのにType 3フォントと呼ばれるものの描画コマンドをエンコードすることができる。

普通のフォントもサブセット化して利用されているグリフに限定したものとすることができる。また時には、新しいフォントが原フォントのアウトラインから新規に構成されることがある。

Cairo
Cairoという2Dグラフィックスライブラリは、生命維持状態ではあるが、信頼性の高いPDF / PS出力を持つ。これにはカスタムフォントサブセット化ロジックが含まれていて、これはAdrian Johnsonの貢献による。
AdrianとMatthias Clasenと私は、カラーフォントとバリアブルフォントのサポートをCairoに実装した。
Cairoは今でもGTKの基礎となるグラフィックシステムであり、つまりGNOMEデスクトップの基礎でもある。また、Pangoテキストレイアウトライブラリのための唯一のメンテナンスされているグラフィックバックエンドである（pangocairo）。

Skia
Skiaという2Dグラフィックスライブラリは、ChromeやAndroidなどで使われているが、信頼性の高いPDF / PS出力をもつ。これは、SkiaチームでのGoogleのBen Wagnerの貢献による。
これには、HarfBuzzサブセッタ(subsetter)を使ったフォントサブセット化ロジックが含まれる。

Skiaは、Cairoよりもよくメンテナンスされている一方で、大きくなりすぎてしまっている。
さらに非常に不安定なAPI/ABIをもつ素早く動く的であるから、比較的小さなアプリケーションで使うのは苦痛である。

Qt
Qtツールキットは、KDEなどで使われているが、印刷設備を用意している。
それには2005年くらいからカスタムフォントサブセッタが搭載されている。

Qtは、概して、カラーフォントとバリアブルフォントをサポートしている。しかし、PDFジェネレータで現在それらがサポートされているのかは、私はよく知らない。

フォントの設定・選択

Androidは、独自の、ハードコードされたXMLベースのフォント設定システムを持っていて、Minikin (以下参照)がフォントのフォールバックロジックを実装している。
他のオープンソースプラットフォームは大抵はfontconfigを使っている。
Fontconfigを使っている例としては、オープンソースプラットフォーム上のメジャーなツールキットであるGTKやQtであり、またChromeOSや、Linux版のChrome, Firefox, LibreOfficeなどである。

Fontconfig
Fontconfigは、もともとはKeith Packardによって書かれたものだが、Linuxや類似のプラットフォームにおけるフォント設定・選択ツールのデファクトスタンダードである。
私はKeith Packardからfontconfigのメンテナンスを引き継ぎ、後にRed HatのAkira Tagohへとバトンを渡した。
プロジェクトは生きているものの、変更は少ない。
私はカラーフォントとバリアブルフォントのサポートを実装した。

Fontconfigに関わる問題は、その表現性が高すぎるXML設定言語とフォント選択モデルである。
それは古い設計であり、置き換えの必要がある。
私にはアイデアがあるのだが、まだ開発されていない。
Rustへの移行は(次の章で紹介する)、fontconfigを再設計する良いタイミングかもしれない。
あるいは、我々は、Lennart Poetteringを迎え入れてもいいかもしれない。😀

レイアウトエンジン

Minikin
Minikinは、もともとはRaph Levienによるものだが、Androidのテキストレイアウトの基礎である。
HarfBuzzとICUの上に構築されており、グラフィックスシステムのSkiaと組み合わされている。
これは、Android外部ではあまり使い道がない。

Pango
Pangoは、GTKツールキットやGNOMEデスクトップなどのアプリケーションを下支えしている。
PangoはすべてのプラットフォームでFriBidiとHarfBuzzを利用している。さらにオープンソースプラットフォーム上では、FreeTypeとFontconfigを使っている。
Pangoの最初のインテグレーションで、活発にメンテナンスされている唯一のものは、pangocairoという、Cairoグラフィックスライブラリとのものである。

2010年に私がRed HatからGoogleへと移り、私がHarfBuzzだけに集中したので、Pangoはメンテナンスされなくなった。その後、Matthias ClasenというGTKのメンテナーがメンテナンスを引き継いだ。

Pangoの開発はゆっくりになっているが、私自身の新しい機能の試験台として、PangoはすべてのプラットフォームでHarfBuzzを使うようにすっかり移植された。さらに、pangocairoバックエンドには、カラーフォントとバリアブルフォントのサポートを追加した。

Raqm
Raqmはlibraqmとも呼ばれ、Omani HOSTチームによるもので、Khaled Hosnyによって率いられている。これは機敏だが重要なレイアウトエンジンであり、FreeType, FriBidiまたはSheenBidi, Fontconfig, HarfBuzzの上に構築されている。
Raqmの設計が意図しているのは、以前FreeTypeを使ってテキストレンダリングを行っていたアプリケーション（双方向や複雑なテキストのサポートなし）に簡単に組み込めるようにすることだ。

Omani HOSTチームはまた、次のようなアプリケーションをいくつか、Raqmを使うように移植した。
そのプロジェクトのホームページによると、Raqmを内部で使っているのは、ImageMagick, LibGD, FontView, Pillow, mplcairo, CEGUIなどである。
SDL_ttf, Pygame, Blenderへのパッチがある。

Skia Text
Skiaという2Dグラフィックスライブラリは、Text APIという形でテキストレイアウトを実装している。
Skia CanvasKit WebAssemblyのデモページで実際に動いているのを見ることができる。

これを利用する著名なものだと、GoogleによるオープンソースのFlutter GUIツールキットや、Zoho Writerという、ブラウザで動くGoogle Docsみたいなワードプロセッサがある。

QTextLayout
QTextLayoutはQt Projectの一部であるが、KDEなどのアプリの根幹をなすレイアウトエンジンである。
これは新しいHarfBuzzを使うように移植され、今しばらくはすべてのプラットフォームでHarfBuzzを利用している。
Qtは独自のBiDiアルゴリズムを使っており、それは最新版のUnicode仕様に完全に追従し、互換性があるはずだ。

QtはOpenTypeレイアウト機能をAPIの中でサポートしている。

カラーフォントはサポートされているが、現在はQtはすべてのプラットフォームですべてのカラーフォントをサポートしているわけではない。
Qtはそれ自身でカラーフォントのラスタライズを行うわけではなく、システムのラスタライザに依存してこれを行っている。
具体的には、MicrosoftのCOLRフォントは現在Windowsでしかサポートされていない（Freetypeによるサポートも可能なはずだが）。
また、SVGベースのカラーフォントはどのプラットフォームでもサポートされていない。

バリアブルフォントのサポートは最近拡張された。
ユーザーは、フォントの特定の名前付きインスタンス(named instance)を、以前からあったサブファミリーの選択と同じやり方で選択することができる。
加えて、どんな変化軸に対してもカスタム値を与えることができる。このAPIはQt 6.7で追加された。

3つの異なるアプローチが存在し、ラスタライズ・レンダリングに関わるユーザー設定やユースケースに応じて有効にすることが可能だ。

システムのラスタライザによって指定されたサイズでatlasへと事前ラスタライズされたグリフ（atlasはラスタライズされたグリフ一覧の画像データ）
テクスチャーの形で保存され、フラグメントシェーダでサンプルされるSDFテクスチャベースのatlas
頂点属性(vertex attributes)および曲線への距離として渡される曲率(curvature)データ（フラグメントシェーダーで計算される）。これは他より計算コストが高いが、SDFテクスチャベースの手法で起きるようなアーティファクトか発生しない。

これらの特徴についてはこの投稿を参照。

GUIツールキット

GTK
GTKは、以前はGTK+という名前だったが、これはGUIツールキットであり、GNOMEデスクトップなどのアプリの根幹をなしている。
GTK 3は2011年にリリースされ、GTK 2時代のPangoという有能なテキストレイアウトエンジンを引き継いでいる。

GTK 4は2020年にリリースされ、まだPangoを使っている。そしてグラフィックスにはCairoを使っている。
しかしグラフィックスの構成（コンポジション）はGPUへと移った。

GTK 5は今のところ設計段階にある。
GPUベースのラスタライザについての実験があったが、まだ結論がでていない。
Matthias Clasenが望んでいるのは、Pangoへの依存をなくし、Pangoに含まれるHarfBuzzベースのテキストレイアウトをGTK自体へと吸収してしまうことである。
現段階では、GTK 5においてそのような吸収は起きなさそうであるが、もし起きたらそのときは、Pangoを使っている他のものはかなり危うくなるだろう。

Qt
Qtは2つの主要なUIツールキットを持っていて、それぞれQt WigetとQt Quickという。
Qt WidgetはC++ベースで、ソフトウェアによってレンダリングを行う。Qt Quickはハードウェアでレンダリングを行い、フロントエンドはふつうQMLと呼ばれるJavascript的なマークアップ言語で書かれる。

基礎的なフォントとテキストの取り扱いは2つのツールキットで共有されていて、QTextLayoutをメインエントリーポイントとして使っている。しかし、Qt Quickはテキストをレンダリングするための更なる選択肢を持っていて、それは前述したQTextLayoutの項に挙げているものだ。
Qt Widgetsは、事前ラスタライズされたグリフatlasの手法を常に使うだろう。

Qtはフォントを列挙するのにシステム関数を使って、独自のフォントマッチングロジックを適用している。
HarfBuzzはフォント選択後のシェイピングに利用されている。

Flutter
GoogleのオープンソースのFlutterというGUIツールキットは2017年にリリースされ、当初はAndroidのMinikinレイアウトエンジン(libtxtとよばれる)をフォークしたものを使っていた。
Skia Textレイアウトエンジンに移行したため、Minikinレイアウトエンジンは使われなくなった。

EFL
EFLテキストレンダリングは、FreeType, Fontconfig, HarfBuzzの上に構築されている。
カラーフォント（主にカラー絵文字用）がサポートされていて、双方向テキストも同様である。
ラスタライズはFreeTypeに任せられており、GPU アクセラレーションを利用する場合は、レンダリングはフォントグリフのテクスチャーatlasと並べるグリフごとの三角ジオメトリペア群によってなされる。
ソフトウェアレンダリングにおいては、グリフデータは実行時にRLE 4 bit（または生の4bit、グリフサイズによる）によって圧縮され、メモリアクセスを減らすことでレンダリングを高速化している。

オペレーティングシステム

Android
グーグルのオープンソースのAndroidというモバイルとタブレットのためのオペレーティングシステムは、複雑なテキスト・カラーフォント・バリアブルフォントの素晴らしいサポートをもつ。
これは、カスタムメイドのMinikinレイアウトエンジンを使っている。Minikinはその後まずHarfBuzz.oldに移植され、さらにその後harfbuzz-ngという現行バージョンのHarfBuzzへと移植された。
それはICUを双方向テキストや他のUnicode APIのために利用している。また、FreeTypeをフォント読み込みに使っているが、これはSkiaという2Dグラフィックスライブラリを通じて使っているものだ。

ChromeOS
GoogleのオープンソースのChromeOSというノートPC向けオペレーティングシステムは、主としてChromeブラウザと、UIのためのカスタムコードをベースとしている。
ChromeOSのテキストサポートは一般にChromeブラウザのものと同程度に良いものであり、例えば複雑なテキスト・カラーフォント・バリアブルフォントの信頼できるサポートなどがある。

Linux Desktop
大抵はGNOMEかKDEデスクトップのどちらかをベースとしており、2つのうちのどちらも信頼性の高いテキストレンダリングのサポートをもつ。これは、それぞれGTK、Qtというツールキット経由で、Fontconfig, FreeType, HarfBuzzを共通部品として利用して実現されている。

Webブラウザ

Google Chrome / Chromium
Google ChromeとオープンソースのChromium ブラウザーが使っているのは、GoogleのオープンソースのBlinkエンジンである。
Googleは、AppleのオープンソースのWebKitエンジンからBlinkをフォークした。

その親であるWebKitとは異なり、BlinkはHarfBuzzを全プラットフォームで利用する。
これにより、コードベースから抽象のレイヤーを何層も取り除き、拡張とメンテナンスを単純化することを可能にした。
これが可能になったのは、HarfBuzz付属のAPIや機能を使うことで、ネイティブライブラリ(MicrosoftのDirectWrite、AppleのCoreText)で提供されないものを補ったことにもよる。
シェイパードリブン(shaper-driven)のフォントフォールバックとユニバーサルAATレイアウトサポートは、そのような機能の2つの例である。

さらには、BlinkはFreeTypeをすべてのプラットフォームで提供している。
ハイブリッドなレンダリング機構がDominik Röttschesにより考案され、これによりFreeTypeへと移行して、より新しいフォント機能(カラーフォント、バリアブルフォントとか)をラスタライズすることが可能になった。たとえOSがその機能をシステムライブラリでサポートしてないバージョンでも。
このようにしてChromeは、Safariや以前のMicrosoft Edgeなどのシステム・ネイティブブラウザに対して優位性を持つ。

Chromeのテキストレンダリングを率いているのはDominik Röttschesであり、それ以前はEmil Eklundが比較的最近にプロジェクトから去るまで務めていた。

(表: Chromeのハイブリッドテキストレンダリング機構。Dominik Röttsches。)

Firefox
オープンソースのFirefoxブラウザはMozillaのGeckoエンジンを利用している。
これはHarfBuzzをすべてのプラットフォームで使っている。
Geckoはカラーフォントサポートを自前で実装しており、他のライブラリを使用していない。
Jonathan KewはMozillaのテキストレンダリングのほとんどに対し責任を持っている。

Servoという実験的なエンジンをMozillaが立ち上げ、Geckoの後継をもくろんだものだったが、これはRustで実装されたものだ。
Mozillaは最終的にServoを放棄した。Mozilla Corporationが2020年にスタッフの1/4を解雇することを発表し、ServoはLinux Foundationへと移管されたので。その後2023年にTLF Europeへと移管された。
まだ実験的段階ではあるが、2023年からはまた活発に開発されるようになった。
Servoは今のところHarfBuzzへのRustバインディングを使っている。

Microsoft Edge
Internet Explorerの後継であり、2015年にリリースされた。これはMicrosoftのDirectWriteライブラリ(Uniscribeの後継)とMicrosoftのwebエンジンを利用している。
2018年にMicrosoftはEdgeをGoogleのオープンソースのChromiumプロジェクトへと切り替えることを発表した。
そうなった最初のバージョンは2020年にリリースされた。
この移行より後は、つまりBlinkエンジンを使っている訳で、現在のMicrosoft Edgeは同様にHarfBuzzをテキストシェイピングに使っている。

Safari
Appleのフラッグシップブラウザーであり、AppleのオープンソースのWebKitエンジンの上に構築されていて、AppleのCoreTextライブラリ(ATSUIの後継)をフォントプロセッシングに使っている。

Microsoft EdgeがChromiumへと切り替えたため、Safariは現在のところテキストシェイピングにHarfBuzzを使わない唯一の主要なブラウザである。

GNOME Web
オープンソースのGNOME Webブラウザは、以前はEpiphanyと呼ばれていたが、これおよび他のいくつかのブラウザはwebkit-gtkエンジンを使っている。webkit-gtkは、AppleのオープンソースのWebKitエンジン(AppleのSafariが使っているものだ)のバックエンドである。
webkit-gtkはFreeTypeとHarfBuzzをテキストレンダリングに使って居る。

Konqueror & falcon
オープンソースのKDE ブラウザーであり、これらは近頃Qt WebEngineを使っている。これはChromiumベースである。

ワードプロセッサ

LibreOffice
オープンソースのワードプロセッサであるLibreOfficeは、OpenOffice.orgから2010年にフォークされたものだ（もう一つのフォークであるApache OpenOfficeと混同しないように）。
最初の安定版のリリースがなされたのは2011年である。
CollaboraがLibreOfficeを支える第一の会社であり、SunのStarOfficeの他の末裔と比べて桁違いに多いユーザーを獲得した。

Khaled Hosnyをはじめとする人々の計り知れない労力のおかげで、LibreOfficeもすべてのプラットフォームでHarfBuzzを使っていて、シェイパー・ドリブンのフォントフォールバックなどの高度な機能を使うことができる。
LibreOfficeの複雑なテキストのサポートは大きく改善されてきていて、信頼性の高い双方向テキストのサポートや、シェイピング、改行処理(line-breaking)、均等割付(justification)の機能をもち、さらにOpenType機能の選択や、カラーフォント(COLRv1はまだ)、バリアブルフォント(今のところ名前付きインスタンスのみ)などもある。そして、特にPDFエクスポートにおいて、より新しい機能を実現するためにHarfBuzzを大いに活用している。

AbiWord
GNOME指向のAbiWordは、市場シェアとリソースでLibreOfficeに負けているようだ。
まだ息はあるものの、生命維持装置に繋がれた状態だと思われる。
Pangoを使うことにより、それは多少のカラーフォントサポートを持っているようだ。
他の最近の新しいフォント機能はまだサポートされていないし、おそらくこの先もずっとないままだろう。

Calligra Words
Calligra WordsはKDEのKWordを2012年に置き換えた。これはカラーフォントをはじめとする最近の新しいフォント機能をサポートしていないようだ。
これは、基本的な双方向および複雑なテキストのサポートを、Qtを使って実現しているようだ。

Google Docs
オープンソースではないが、Google Docsは言及する価値がある。というのはこれは信頼性の高い双方向テキストと複雑なテキストのサポートを持つからだ。

OpenType機能のサポートはない。
カラー絵文字は動くが、それ以外でカラーフォントは選べない。
バリアブルフォントについて、ウェイト(weight; 太さ)軸だけが利用可能な軸である。これは、（バリアブルフォント以前にサポートされていた）9ウェイトとイタリックの選択以外にはスタイル選択のためのUIが存在しないためだ。

デザインツール

Blender
オープンソースのBlenderという3D統合制作環境は、今のところ、双方向テキストや複雑なテキストのシェイピングをサポートしていない。
Raqmをテキストレイアウトに用いるためのパッチは存在している。それがもしマージされたとしたら、基本的なサポートが利用可能になるだろう。

GIMP
オープンソースでGTKベースのGIMPという画像エディタは、今のところPangoレイアウトエンジンをテキストレイアウトに利用している。
OpenType機能やバリアブルフォントのサポートはプラグインを使えばあるものの、これにはインタラクティブなユーザーインタフェースはない。
今のところ、カラーフォントは一般にフォントのデフォルトカラーか、白黒かのどちらかでレンダリングされるだろう。
OpenType機能やバリアブルフォントの可変軸、文字の置換(alternate characters)、などなどを、新しいデスクトップフォントサービスを使うことでサポートする作業が行われているが、まだ初期段階である。

Inkscape
オープンソースでありGTKベースのInkscapeというベクタ画像エディタは、Pangoレイアウトエンジンをテキストレイアウトに使っている。
少なくともいくつかのOpenType機能はサポートされている。
カラーフォントはフォントのデフォルトパレットでレンダリングされる。
しかしながら、InkscapeはSVGエディタなので、くみこみのXMLエディタを使ってCSSプロパティをSVGに追加することができ、更なる特殊効果を実現することができる。

Krita
オープンソースでQtベースのKrita画像エディタは、現在の安定版において、きわめて単純なテキストサポートを持っている。しかし、Raqmやlibunibreakなどへと移行するための作業が行われている。
現状、OpenType機能とカラーフォントはサポートされていないが、進行中の作業結果のデモが出されていて、素晴らしい結果を見せている。

Scribus
オープンソースでQtベースのScribusというDTPアプリケーションは、FreeTypeとHarfBuzzなどのライブラリを直接利用している。
OpenTypeフォント機能のサポートは開発版のリリースには存在する(1.7.0で確認)。
カラーフォントは、フォントのデフォルトの色でレンダリングされる。
バリアブルフォントのサポートはなさそうだ。

Adobe Photoshop, Illustrator, InDesign
Adobeのプロプライエタリなフラッグシップアプリは、2019年～2023年の間にアップデートされ、HarfBuzzをアプリのWorld-Ready Composerの内部で利用する様になった。

しかし悲しいことに、World-Ready ComposerはIllustratorとInDesignのデフォルトコンポーザーではない。
そのため、いまだ多くのデザイナーが、自分では読めないような複雑な用字系のテキストをデフォルトコンポーザーでタイプセットして、間違った形(shape)の出力を得ている。😡
一方Photoshopは、Unified Text Engineを用いている。
PhotoshopやInDesignとは異なり、IllustratorがHarfBuzzへと切り替えたことは広く公表されることはなかった。

皮肉のようだが、次の写真は、私が撮影した、2019年にタイのチェンマイで開催されたBITS9というタイポグラフィの国際会議での、AdobeのPankaj Joshiによる基調講演でのスライドの写真である。このスライドは、Adobe製品における東南アジアの文字のサポートに関するものだった。
(写真: 少なくともアラビア文字がぶっ壊れているのが見て取れる)

嘘じゃないよ。そのスライドの中のすべての複雑なテキストのレンダリングは壊れていた(b0rked)んだ。

Figma
Figmaはプロプライエタリなデザインツールで、webブラウザなどのプラットフォームで動く。
これはHarfBuzzをシェイピングに使っており、そしてICUのbidi (双方向)実装を使っている。

OpenType Layout機能のパネルがあり、ユーザーはそのパネルでフォント機能をオンオフすることができる。

Figmaは今のところカラーフォントをサポートしていない。
バリアブルフォントはサポートしている。

Canva
(TODO)

フォントデザインツール

FontForge
George Williamsによる立派なオープンソースのフォントデザインツールであったが、Georgeが2012年に手を引いたことから崩壊が始まった。
それからそれを生かし続ける努力はなされた（それと数個のフォーク、例えばBarry SchwartzとKhaled HosnyによるSorts Millが存在した）ものの、2010年後半にプロジェクトは休眠状態へと陥った。
プロジェクトの開発を金銭的支援するためのDave Crosslandの努力は、干上がってしまった。

FontForgeは大きな、年季の入ったC言語のコードベース(だいたい100万行)であり、頻繁にクラッシュするためこれを使って作業することが難しい。
より最近になって追加されたフォントの機能のサポートがない。

そうは言っても、FontForgeはまだLinuxで利用できる中で一番使えるフォントデザインツールであるので、そのためまだ利用されている。

GlyphrStudio
オープンソースのwebベースフォントデザインツールで、2010年ころから「ホビーユーザのためのフォントデザインをターゲットとして」いる。

Fontra
新参者の、オープンソースでwebべースのフォントデザインツールであり、オープンソースのフォントデザインツールの様相を一変させると約束している。
これについては次の章で述べる。

TruFont
オープンソースのTruFontは、Adrien Tétarによる短命な作品であり、LinuxでUFOベースのフォントエディターをビルドするためのものであった。
RoboFont (下で解説する)のある種のクローン。

BirdFont
オープンソースとプロプライエタリのハイブリッドであるフォントデザインツールであり、Linuxを含むいくつかのプラットフォームで動く。
オープンソース＆フリーなバージョンは最近のフォント技術に対応してないようだが、商用ライセンスは以下に挙げるような支配的なプロプライエタリなツールより大幅に安い。

FontLab
前チャンピオンのプロプライエタリなフォントデザインツールであるFontLabは、Font Lab Studio 5 (2005)の後で最初のメジャーリリースとして、2017年にFontLab VIを出した。
これは新しい技術へのサポートを追加していて、例えばカラーフォントやバリアブルフォントなど。
FontLab 8が現在の最新のメジャーバージョンである。

FontLabはUFO形式からの読み込みとUFO形式への書き出しに対応しており、これによりFontTools/fontmakeエコシステムとの相互運用が可能になっている。

Glyphs
タイプデザイナーのGeorg Seifertにより構築されたGlyphsは、Mac用のプロプライエタリなフォントデザインツールである。
これは部分的にはGeorgがfonttoolsフォントアセンブラをObjectiveCへと移植することによって構築された。
2010年代に、Glyphsはランキングを駆け上り、規模の大小に関らず新しいユーザーに最も一般的に使われているフォントデザインアプリとなった。

Glyphs 1は2011年にリリースされた。
Glyphs 2は2015年にリリースされ、カラーフォントのサポートをもたらし、その後2016年後半の2.xバージョンにおいてバリアブルフォントのサポートをもたらした。
Glyphs 3は2020年にリリースされ、最新のメジャーリリースである。

Glyphsは独自のテキストベースのソースファイル形式を使っている。この形式はオープンソースのglyphsLibパッケージによって読み書きができ、UFOへのエクスポートができる。これによりFontTools/fontmakeエコシステムとの相互運用が可能となっている。

RoboFont
また別のフォントデザイナーのFrederik Berlaenによって構築されたプロプライエタリなRoboFontは、Mac用のもう一つのフォントデザインツールである。fonttoolsエコシステムの上にPythonで構築されていて、Python スクリプティングに重点を置いている。
これはUFOをネイティブフォントソース形式として使って居り、これによりFontTools/fontmakeとの相互運用性がファーストクラス(最高級)の体験となっている。

RoboFontはハーグ王立美術学院でTypeMediaのMAプログラムで教えられ、その卒業生たちによって最も一般的に使われている。

RoboFontはバリアブルフォントをサポートしている。
(TODO カラーフォントは？)

ターミナルエミュレータ

オープンソースのターミナルエミュレータの多くが双方向テキストと複雑なテキストのレンダリングのサポートを追加している。
例えば、Kittyや、vteベースのターミナル(双方向テキストのみ)がある。
Wezのターミナルエミュレータであるweztermは、双方向テキストに加え、harfbuzzを使ったフォントシェイピングのサポートを持つ。

これは双方向テキストのサポートを持つターミナルの（多分古い）gist（まとめ）である。
これは最小のUnicode クラスタリングを多少サポートするターミナルのリストである。
(TODO: 他には？)

Macのターミナルも双方向テキストと複雑なテキストの出力をサポートしている。
新しいWindowsのターミナルは、ある程度の基本的な双方向テキストとアラビア文字をサポートをしているようだ。

ターミナルテキストエディタ

Emacs
Emacsは以前、複雑なテキストの処理のためのm17nシェイパーのサポートを持っていた。
Emacs 27.1から、ターミナルでないバージョンでは、デフォルトのシェイパーは今やHarfBuzzである。
しかし、EmacsはHarfBuzzを選択的に使っている――何らかの正規表現を使って、特定のUnicode範囲の場合のみシェイピングを有効にしている。
例えば、ASCIIはデフォルトではHarfBuzzを経由しない。

Emacsは、Lispによる双方向アルゴリズム実装を使っている。

Vim
Vimは組み込みの双方向テキストのサポートと、ある程度のアラビア文字シェイピングのサポートをもつ。
ターミナルでないバージョンのVimで複雑なテキストのサポートがそれよりなされているかという状況はよく知らない。

バッチ文書処理 & TeXエンジン

XMLベースの文書処理ワークフローはうまくいかなかった。少なくともオープンソースの世界以外では。
出現したバッチ文書処理システムは、TeX関連のものが目立つ。SILE、XeTeX、LuaTeXなど。

Typst
新しい、Rustベースの組版システムで、HarfBuzzのRust移植であるRustyBuzzをテキストシェイピングに使っている。
Typst開発者の一人であるLaurenz Stampflは、影響力をもってRustyBuzzを最新のHarfBuzzに追従して最新状態に保っている。

SILE
SILE Typesetterは、もともとはプロジェクト製造機であるSimon Cozensによるもので、現在はCaleb Maclennanによってメンテナンスされている、新しい組版エンジンである。
プロジェクトページから引用する。「概念の上では、SILEはTeXと似ている――そこからいくつかのコンセプトや、文法やアルゴリズムまで借用したので――しかし、似ている点はそこまでである。TeXファミリーの派生となるというよりは。SILEは新しい組版とレイアウトエンジンであり、土台から上まで最新技術を使って書かれ、InDesignのようなグラフィカルなシステムからいくつかアイデアを借用している。」

SILEは標準でLua バインディングスを通じてHarfBuzzを利用しており（他のシェイパーを使うことも可能である）、OpenType機能・バリアブルフォントのフルサポートをもち、カラーフォントの部分的なサポートをもつ。

XeTeX / XeLaTeX
XeTeXはもともとJonathan Kewによって開発されたが、これはeTeXエンジンの後裔であり、AppleのATSUIシステムライブラリをシェイピングに使っている。
2013年に、Khaled HosnyがHarfBuzzをシェイピングに使うように移植した。

LuaTeX / LuaLaTeX
LuaTeXは、pdfTeXの派生にLuaを埋め込みスクリプト言語として追加したものであり、TeXファミリーの現在の主幹（主要なもの）である。
これはpdfTeXを(凍結された)8ビットエンジンとして利用している。

LuaTeXにおける複雑なテキストのサポートはさらに込み入っている:

LuaTeXの「哲学」というのは「答えではなく、解決策を提供する」というものだ。
だから、分別あるアプリケーションがするようにHarfBuzzを組み込む代わりに、LuaTeXは拡張可能なコールバックを提供し、それによりLuaコードでTeX機構の部品（フォント読み込みやテキストのレイアウトなど）を置き換えることが可能になっている。

ConTeXtチーム（LuaTeXの後ろにいる主要な人たちである、ConTeXtがLaTeX代替となり得るマクロパッケージなので）は、全面的にLuaによって実装されたOpenTypeレイアウトを持っている（もともと使っていたのは、fontforgeの部品がLuaTeXへと組み込まれ、Luaモジュールとして露出していたもので、フォント読み込みに利用していたが、それから全てをLuaでやることにした。一方、Fontforgeのコードは今でもLuaTeXの一部となっている）。

Khaled HosnyはHarfBuzzを、LuaTeXに組み込まれたもう一つのLuaモジュールとして提供した。それから、代替手段としてそのモジュールを使えるようにLuaコードを更新した。
しかしLuaTeXチームはまず彼のコードのコントリビューションを拒否した。なのでKhaledはそれをフォークしてharftexと名づけた。しかし後にLuaTeXチームは彼のコードを統合したが、これは彼との相談なし行われたものだ。
そのためharftexは役目を終えた。

HarfBuzzの実際の使用はluaotfloadというTeX/LaTeXパッケージで起こる。そしてこのパッケージはオプショナル（任意選択式）なままだ。
Khaledが彼の仕事をまとめているこの記事を参照。

最後に、LuaHBTeXは、HarfBuzzをセットにしたLuaTeXである。
これはLuaLaTeXのデフォルトバイナリであるが、HarfBuzzを使うためにはまだ、luaotfloadパッケージを読み込んで、非デフォルトのHarfBuzz統合（インテグレーション）を有効にする必要がある。

フォント

良いオープンソースフォントは、素晴らしいテキストレンダリング体験のための必須条件である。
オープンソースの質の高いフォントプロジェクトは多数あるが、その中でも2つのフォントコレクションは名前を挙げる価値がある。その2つとは、NotoフォントとGoogle Fontsである。

Notoフォント
GoogleのオープンソースであるNotoフォント（Notoは「no tofu (豆腐)」の意）は、Androidのデフォルトフォントファミリーである。ただしラテン文字、ギリシャ文字、キリル文字については別で、Robotoを使っている。
Notoフォントは以前使われていたDroidフォントを置き換えた。
Notoは、ほとんどの評価基準において、今までに開発されたフォントファミリーのうちで最大のものである。
これは、Noto SansとNoto Serifファミリーの形で提供され、どちらも200,000個より多いグリフを収録している！

Notoフォントは、FedoraなどのLinuxディストリビューションが採用した。
いくつかの部分はApple製品にも搭載されている。

Notoは次に挙げる3つの構成部品からなる:

Noto fonts
ほとんどの書記体系のNotoフォントは、もともとMonotypeに外注されたものであった。
2014年に、Google国際化(i18n)エンジニアリングチームにいた時、同僚にRoozbeh Pournaderもいたが、我々はマネジメントチェーンを説得し、Monotypeから真のフォントソースを得て、後に我々が作るフォントコンパイラ（fontmakeである）を使ってコンパイルすることにした。

Other-Noto-fontsが近頃Simon Cozensによってメンテナンスされているが、これはGoogle Fontsが支援しているものだ。

Noto CJK
中国語・日本語・韓国/朝鮮語のNotoフォントはGoogleが共同出資し、Adobeがデザインした。Adobe自身はメジャーな東アジアのタイプファウンドリ（フォントメーカー）にデザインを外注した。
Adobeは同一のデザインのフォントを、Souce Han SansとSource Han Serifという名前でもリリースしている。

あいにく、私としては残念に思っているのだが、Noto CJKフォントとそのAdobe版は真のオープンソースではない。
それらは単に無料で（free beerのfreeの意味＝無料であって、自由という意味のfreeではない）提供されているだけで、真のソースをもたない。

Noto Emoji
Noto Emojiフォントはもともと白黒のフォントで、AndroidのDroid Emojiフォントから浮かび上がってきたものだった。
私はNoto Color Emojiをビルドするためのサポートを2013年に追加し、それからGoogle FontsチームによってCOLRv1をはじめとするカラーフォント形式をサポートするように移植された。
近頃は、白黒でバリアブルフォントであるNoto Emojiと、Noto Color Emojiが広く利用できる状態にある。これはnanoemojiを使ってビルドされている。nanoemojiはGoogleが出しているカラーフォントコンパイラだが、Microsoftなどにも利用されている。

Google Fonts
Google FontsはGoogleのフォント提供インフラであり、フォント名簿/カタログである。主にCSSウェブフォントに重点を置いているが、Google Android（AOSPではない）の一部として「ダウンロード可能なフォント」でもある。
Google DocsのソフトウェアエンジニアであるDavid Kuettelが、彼の同僚Jeremie Lenfant-Engelmannとともにこのチームを2009に始めたが、すぐに次に挙げる人たちを雇用した。Raph Levien（ソフトウェアエンジニア）、Dawn Shaikh（UXリサーチ、フォント選択に関して博士号をもっている）、Tobias Kunisch（UXデザイナー、Google I/Oでの2010年の立ち上げにおいてカタログウェブアプリのv1のデザインを率いた。さらに2011年のv2についてもデザインを率いた）、David Wurtz（プロダクトマネージャー）。
Webアプリケーションなのでこれはオープンソースではないが、それが提供するフォントはすべてオープンソースである。

Google Fontsは多数の新しいオープンソースフォントファミリーを発注しており、1700を超えるフォントファミリーをオープンフォントライセンス(OFL)のもとで利用可能としている。

Google Fontsは、Linuxディストリビューションによる千を超えるフォントファミリーのパッケージングを簡素化する潜在能力をもち、Linux Desktop / ChromeOSのフォントインストールへの密接な統合と、オンラインフォント選択と自動インストールを整備する潜在能力を持っている。
今のところ、それらのどちらの潜在能力も探求されてないが、フォントインストールを行うサードパーティアプリが存在するようだ。

Web

Webプラットフォームは新しいフォント形式の機能に追従している。

CSS
CSSは様々な新しいフォント技術をサポートするために更新された。

OpenType機能がfont-variant（とその手書き）を通じてサポートされ、明確にfont-feature-settings属性を通じてサポートされた。
カラーフォントのパレット選択がfont-palette属性を通じてサポートされた。
バリアブルフォントがフォント選択と解決システムに組み込まれた。font-size（フォントサイズ）、font-weight（wght変化軸）、font-style（slnt変化軸）、font-stretch/font-width（wdth変化軸）、font-optical-sizing（opsz変化軸）である。バリエーションはfont-variation-settingsを利用して明確に定義することもできるが、特に、その属性は他の属性がするようなカスケードをしない。

CSSはunicode-range属性を導入した。これによって、比較的大きな書字体系用のwebフォントを、より小さいチャンク（chunks; 塊）に分け、必要に応じて個別にダウンロードできるようにすることが可能だ。
このメカニズムは制限があり、すなわち、異なるチャンクをまたいだシェイピングは動作しないのだが、この機構はwebフォントの提供に役立つ。
私の願いだが、これはそのうちIncremental Font Transfer（漸進的フォント転送）技術によって置き換えられたらよいと思っている。

CSSはまたbidi isolatesをサポートするように更新された（unicode-bidiを通して）。とはいえHTMLのdir属性がHTML文書で推奨される手法である。

HTML
HTMLへ追加されたものはdir=autoである（これはのデフォルト値である）。これはisolationを適用するだけでなく、UAX#9のfirst-strongヒューリスティックを使ってisolationの方向性を決定している。
（これはアホだし間違っていることがよくある。しかし簡単に操作可能でプレーンテキストと一貫性のある結果が得られる。）

HTMLはまた静かにそのdir属性を更新し、embeddingの代わりにbidi isolationを適用した。

WOFF2
WOFF2は、Web Open Font Formatの2番目の、大いに改善されたバージョンである。
これは新しいフォントフォーマットではなく、webフォントのための圧縮形式である。
これを支えているのは、Google開発のBrotli圧縮形式と、一連のカスタムフォントテーブル変換である。
これは、生のOpenTypeや前のWOFFバージョン1と比べて、大幅なフォントファイルサイズの節約を提供する。

自動ヒント付け / Auto-hinting

自動ヒント付けはフォントデザイン/制作プロセスの一部である。
自動ヒント付けプログラムは、コンパイルされたフォントに埋め込むためのフォントヒンティング（font hinting）データを出力し、低解像度でのラスタライズ結果を改善する。

The Raster Tragedyはヒント付けについて理解するための標準的な読み物である。
最終更新は2018年である。

psautohint
は2016年にKhaled Hosnyにより、Adobeのオープンソース版AFDKOに含まれるCFF自動ヒント付けロジックを抜き出すことによって誕生した。
その後2018年にAdobeはそれを採用し、それに関するKhaledの成果に資金提供をした。
これはCFFベースのOpenTypeフォントにヒント付けをするためのデファクト標準である。

しかしこれは最近非推奨となった。それはPythonにより書き直されたotfautohintが登場したためで、これはAFDKOの一部であり、残念なことに独立したプロジェクトとして提供されていない。

ttfautohint
はFreeTypeで有名なWerner Lembergによるもので、TrueTypeベースのOpenTypeフォント向けフォント事前自動ヒント付けシステムであり、FreeTypeの実行時自動ヒント付けをベースとしている。
FreeTypeの実行時ヒント付けと似て、多様な用字系をサポートしている。これはGoogleのNotoフォントとGoogle Fontsプロジェクトのおかげである。
タイプファウンドリは大小にかかわらず同様にこれを利用している。

注意すべきは、技術的な理由で、ttfautohintはバリアブルフォントをサポートするための更新がなされていない。
デザイン空間を通じてのバリアブルフォントへの自動ヒント付けは“難しい問題™(Hard Problem™)”である。

ゲームエンジン

Godot Engine
オープンソースのGodot Engineは複雑なテキストのレンダリングをHarfBuzzを使ってサポートしている。
(TODO: 他の機能については?)

Unreal Engine
プロプライエタリなUnreal Engineは複雑なテキストのレンダリングをHarfBuzzを使ってサポートしている。
(TODO: 他の機能については?)

Unity
(TODO)

これからの展望 / Looking forward

この章で私は、フォント形式の拡張とオープンソースエコシステムにおいて、新しい開発という面で何が進行中であるかについて概観する。

Better-Engineerd Font Formats (より優れた設計のフォントフォーマット)

2021年に私はBetter-Engineered Font-Formatsというものの公開プレゼンをした(スライド / ビデオ / Simon Cozenのメモ)。その中で私は、フォント形式とプラットフォームの未来についての3通り別れた計画を用意した。その3つは、退屈な拡張(Boring Expansion)、より良い人間工学(Better Ergonomics)、エミュレーションの先(Beyond Emulation)である。
これらのアイデアは、ATypI Paris 2023でのOpenType 2.0セッションでDave Crosslandと私がプロトタイプを作り、さらにコミュニティと産業界にプレゼンを行ったものだ(より良いスライドとビデオ)。

退屈な拡張: 漸進的なフォント形式の改善

退屈な拡張(Boring Expansion)は、フォント形式に対する提案された漸進的な拡張の集まりであり、私が仕様を書き、FontToolsとHarfBuzzにプロトタイプを(実験的な機能として)2022年に実装したものだ。
それから、Google Fontsチームと協業し、またLiam Quinのテクニカルライティングの助けを得て、我々はISOのOpenFontFormatとして提案した。
もし承認されれば、それらの機能はゆくゆくはOpenTypeや他の実装への道が作られるだろう。

主な提案を以下にまとめる。モチベーションと仕様などを含む詳細はプロジェクトページを参照。

avar2
OpenType 1.8のFont Variationsモデルへの単純だがインパクトのある更新であるavarバージョン2テーブルは、現在は不可能であるような、様々な望まれるデザイン空間の設計を可能にする。

3次glyfアウトライン
3次(cubic)アウトラインがTrueTypeベースOpenTypeのglyfテーブルで使えるようになると、フォントコンパイル時の丸め誤差(rounding errors)を減らすことができ、フォントファイルのバイナリサイズを数パーセントポイント節約することができる。

バリアブル合成 / 部品
バリアブル合成 / 部品(variable composites / components)はフォントデザインの枠組みであり、その枠組みではグリフがデザイン空間を通じて変化する部品から構築される。
これによって、中国語、日本語、韓国/朝鮮語で使われるような書記体系では、フォントファイルのバイナリサイズの大幅な節約が可能になる。
韓国語（ハングル）のフォントフェースでテストしたところ、この技術を使って92%のサイズの節約を実現し、結果として現在のOpenTypeで実装したフォントの8%のサイズとなっている（！）

6万4千の先へ
6万4千の先へ(beyond-64k)の狙いは、一つのOpenTypeフォントに含まれるグリフの数について、6万4千の制限をなくすことである。
これは、完全な中国語、日本語、韓国語フォントを開発するのに重要である。これらの言語では何千もの新しい漢字がUnicode標準に登録されている。さらに、Notoフォントのような汎Unicode (pan-Unicode)フォントファミリーを作成するのに重要である。

より良い人間工学: Rust移植と統合

私のflatfontsの利用の提案が酷く失敗した一方で、フォントのビルドと利用においてのより良い人間工学(better ergonomics)というのは、GoogleのOxidizeという成果として生き続けた。これはフォントのコンパイルとフォントの利用(まずフォントアクセスし、次にシェイピングする)の両方のプラットフォームをRustプログラミング言語へと移植するものだ。
これはソフトウェアセキュリティの面で巨大なインパクトをもつ。これは、Rust言語の安全保証のおかげであり、webフォントなどに含まれる信頼できないフォントデータを取り扱う際に効果を発揮する。
さらには、Google Chromeのような一定のプラットフォームにおいて、テキストレンダリングのサンドボックス化をなくせる可能性がある。

さらに、fontationsプラットフォームは、Oxidizeが提供しているRustフレームワークであるが、これはフォントのコンパイルと利用を統合するもので、新しいフォント形式の機能を実装すべき箇所を3つ(FontTools, FreeType, Harfbuzz)から1つ(Fontations)へと減らすことができ、これによって開発コストとオーバーヘッドを減らすことができる。

Chromium Canaryは、実行時フラグによりFreeTypeと置き換えられるフォントバックエンドを搭載していて、fontationsを、あまり一般的に使われていない特定のフォント形式に対して利用している。

フォントコンパイル
Fontmakeはfontationsの上につくられたfontcで代替されるだろう。

フォントアクセスと描画
存在するソリューションの一つは、Redox OSプロジェクトによるRusttypeである。

fontationの所では、FreeTypeは、fontationsのskrifaによって置き換えられるだろう。
サブセット化はklippaによって置き換えられるだろう。
Fontationsはそれ自身はラスタライザを含んでいない（今のところ）ものの、現存するグラフィックスシステムにラスタライズを依存している。これはSkiaが（つまり、ChromeとAndroidが）今FreeTypeを使っているのと同じやり方である。

Chad Brokawはまた、FreeTypeのTrueTypeヒンター(=ヒント付けシステム)・CFFヒンター・自動ヒンター(autohinter)をfontationsプラットフォームへ移植するという記念碑的な事業の責任者である。

シェイピング
HarfBuzzはおそらくRustyBuzzによって置き換えられるだろう。RustyBuzzはYevhenii Reizner (RazrFalcon)によるもので、Rustエコシステムに属するものだ。
RustyBuzzはYevheniiのttf-parserをフォントアクセスに利用している。
RustyBuzzを変更してttf-parserの代わりにfontationsを使うという要求が存在し、これはHarfRuzzと呼ばれる取り組みである。

RustyBuzzは直接的な移植であるが、HarfBuzzのシェイピングをRustで再作成する取り組みとして唯一のものではない。
AllSortsはもう一つのHarfBuzzに触発されたRustによるテキストシェイピングエンジンであり、YesLogic社のPrinceというプロプライエタリPDFジェネレータから分離されたものである。
他にもChard BrakowのSwashというより最近に出てきたものがある。

他のレイアウトに関する取り組み
Fontationsは、モダンなテキストレイアウトシステムを組み立てるRustによる取り組みとして、唯一のものではない。
他のプロジェクト、例えばcosmic-textなどはすでに、Rustで書かれたなかなか良いテキストレイアウトシステムを提供している。

ラスタライザ
ラスタライズについて、CPUで行うものには次のようなものがある: RustType、Raph Levienの早い取り組みであるfont.rs、Chad Brokawの比較的最近のzeno。
GPUで行うものについては、Patrick Waltonの比較的早い取り組みであるPathfinderや、Raph Levienのより最近のvelloがあり、velloはより実験的要素の強い、汎用ベクタラスタライザである。

フォント設定と選択
Fontconfigと互換性のあるフォント選択の半ライブラリ(half-libraries)が存在していて、Yevhenii Reiznerによるfontdbや、fontiqueなどである。

Bidi

(TODO: 他に言及すべきどんなプロジェクトがある？)

エミュレーションの先: 全面的にプログラム可能なフォント

最後に、私が提案するのは、将来的なフォントのシェイピングと線の描画/色塗り(drawing/painting)は、完全にプログラム可能な枠組みを含むようになるだろうとういことだ。
私はWebAssembly (Wasm)を提案し、シェイピングの面でプロトタイプを作ることに取り組んだ。wasm-micro-runtimeというWasmエンジンを使ったHarfBuzzのWasmシェイパーにおいて。
Simon Cozensは、いつものように、いくつもの印象的な実例を実装した。「やっちゃいけないのかい？」という理由で(because why not)。

2つの冗談のようなHarfBuzzのWasmシェイパーの正当でない利用例が最近出てきた。Bad Appleフォントとllama.ttfである。
その2つを見てください。
はっきりさせるために言うと、Wasmシェイパーの堅実な実装において、llama.ttfのような試みは不可能になるだろう。なぜなら、CPU時間の割当て量が強制されるようになるだろうから。
Bad Appleは、我々がWasmでdraw APIを導入したら、はるかに簡単にかつ速くなるだろう。

私はこのモチベーションと設計について、独立したホワイトペーパーで掘り下げるつもりだ。このホワイトペーパーは数日かあるいは数週間中にリリースする予定である。
（TODO: ホワイトペーパーを完成させる。）

Abdul Rahman Sibahiが現在、HarfBuzzスタイルのWasm shapingをRustyBuzzに追加するという作業を進めており、wasmtimeというWasmエンジンを使っている。

線の描画(drawing)と色塗り(painting)のAPIはそのうちHarfBuzzに入るだろう。おそらく2025には。

他の取り組み / Other efforts

Fontra

オープンソースのフォントエディタを作成する試みは色々なされてきて、またwebベースのオープンソースフォントエディタの試みもあり、これらは多くの尊敬すべきエンジニアによりなされてきたが、FontraというアプリはJust van Rossumほかによる開発でGoogle Fontsによりサポートを受けていて、一番成功を収めそうなものである。

Fontraは活発な開発状態にあり、高度な機能をサポートしている。例えば、マルチユーザー・コラボレーションや可変部品(variable-components)デザインパラダイムなど。
1時間のデモ&議論のビデオをご覧ください。

Fontraは.designspaceと.ufoをデータ保存のために使っている。しかし、独自の.fontraというソース形式を利用することもできる。
.fontra形式は不安定であり、その構造は.glyphspackageと似ている。
多少の制限はあるが、Fontraは.ttfや.otf（バリアブルフォントを含む）のほか、.glyphsや.glyphspackageを読み込むことができる。
FontraのサーバーサイドはFontToolsエコシステムの上に構築されており、クライアントサイドはカスタムのJavaScriptコードを含んでいる。

Incremental Font Transfer

Incremental Font Transfer (IFT; 漸進的フォント転送)はW3Cで開発中の技術で、現在はワーキングドラフトの段階にある。
これは2018年から制作していて、現在はGoogle FontsのエンジニアGarret Riegerによって率いられている。
Goiogle FontsのRoderick Sheeter、AdobeのエンジニアのSkef Iterum、元AppleエンジニアのMyles Maxfieldもまた顕著な貢献をした。

この技術が利用可能になると、新しい文字のサポートが必要になった時に、webブラウザなどのシステムにフォントをストリーミングすることが可能になる。
これにより、webフォントを利用する帯域幅を大幅に減らすことができるだろう。特に、中国語、日本語、韓国/朝鮮語などの大きな書字体系、およびNotoフォントのような大きなフォントファミリーにおいて。これはunicode-rangeハックとは異なり、シェイピングの忠実性を保ちつつ行うことができる。
Chris Lileyの最近のITF Explainerに詳細がある。

私は、そのようなプロトコルがどう動くかについて、2018年の私のホワイトペーパーである[Faster Horse https://docs.google.com/document/d/1vDbMhZFkj52F1YbG7X7KeHCc1VUB7hRHgsx4rYwBQls/preview#heading=h.53c8lgy8uer2]で概略を述べた。
それはこの技術の動的サブセット化(dynamic-subsetting)の面での核となった。
それはプロトコルを定義し、特定のサーバーサイドの実装については規定していない（不可知論的態度をとっている）。
しかしこれが機能する一つのやり方では、高速なHarfBuzz subsetterや別の高速なサブセッタを使ってライブ・サブセット化、diffとり、Brotliフォント圧縮プラットフォームを使ったフォントパッチの送信を行う。
これは数年にわたり検討され、評価されてきた。
より最近になって、Adobeはとあるアプローチ（IFTBとよばれる）を提案したが、これは動的なweb送信を避け、静的なリソースだけを使うものだ。これによりコンポーネントの送信を単純化することができる。

これら2つの提案は今や統合され新しい仕様書となり、これもまた、動的サブセット化も、事前計算されたフォントファイルやパッチを提供することも可能である。
新しいシステムは、コンテンツ固有のサブセット化とCDNキャッシュ効率の間のより良いバランスを提供する。

早い段階のプロトコルに関する5分間のデモビデオがここにある。

分析 / Analysis

次にオープンソースフォントとテキストレンダリングエコシステムについての端的なSWOT分析を示す。まあ主にこれは私が受けたMBAトレーニングを見せびらかすためですけど。😁
（SWOT マトリックスの4要素の図）

強み(S)

2010年代を通じ、グローバル市場が要因となり、オープンソースの基礎的なテキストレンダリングライブラリであるFreeTypeや特にHarfBuzzは、巨大な（たぶん過半数の）市場シェアを獲得した。これはGoogleのAndroidとChromeに起因するものではあるが、より小規模なプラットフォームや製品の長いリストの貢献もある。
これはその後、タイプデザイナに彼らのフォントをオープンソースプラットフォームでテストすることを余儀なくさせた。オープンソースプラットフォームは以前はテスト対象に含まれておらず、これはその市場シェアがLinuxデスクトップや少量の無名なプラットフォームに限られていたからだ。

オープンソースプラットフォームのもう一つの強さというのは、その機敏性(agility)である。
フォントスタックは小さいモジュール群として提供されるので、それらのモジュールは個別の（比較的速い）スケジュールで別々に更新される。
そして多くの大きなクライアントは非常に短いリリースサイクルをもつ。ChromeやFirefoxは6週間、Androidは1年に1回、Linuxディストリビューションはほぼ即時に。
これにより新しい機能やアイデアの高速な開発と試験が可能になる。
Chromeのハイブリッドテキストレンダリングアーキテクチャが示すように、これにより、オープンソースアプリケーションが非オープンソースプラットフォーム上のプロプライエタリの競争相手に対して優位性をもちうる。

通常のオープンソースの利益が当てはまる。

弱み(W)

マーケットシェアがあったとしても、オープンソースプラットフォームには権威がない。
MicrosoftやAppleは、新しいフォント形式の機能を搭載し、その後ISO OpenFontFormatやOpenTypeへと押し込むことができる。これらにオープンソースプラットフォームも追従するが、一方でこれらのベンダーや仕様はオープンソースプラットフォームの更新に同じように追従することはない。
MicrosoftやAppleが新しいフォント形式の機能を搭載し、それから仕様書にコントリビュートを行った（変更を加えた）一方で、変更提案への抗議がそれらがすでに搭載している実装を破壊するだろうから、Google Chromeは標準化されていない機能を提供するつもりはない。これはそのintent-to-shipポリシーに基づく。
これにより、この業界のオープンソースプラットフォーム側から新しい機能が提供されるのは、標準化のライフサイクルの先頭でなく終端の方へと押しやられる。つまり、複数年の遅延が生じる。

これは皮肉なものだ。というのは、Googleは新しいオープンソースプラットフォームのフォント形式の開発に資金提供しているが、しかしGoogle Chromeはその競争相手が最初にそれらを提供開始するまでは提供することを許さない。
あれ、なんで私はこれをやるために賃金をもらっているんだっけ？
Androidはまだマシで、その中ではこれに似たポリシーに縛られていない。

機会(O)

今までより多くのアプリケーションが、ネイティブアプリかオンラインかにかかわらず、オープンソースプラットフォームへと移動してきている。
IKEAですらNotoフォントに2019年に切り替えた。
そして、AppleはNotoフォントを搭載してそのプラットフォームのフォントライブラリを仕上げ、完全なUnicode カバレッジを提供する。
これは莫大なテストとユーザーフィードバックをそのプラットフォームへともたらした。
ここには、より多くの組織が、そのプラットフォームのさらなる開発により深く関与するための大きな機会がある。

この良い例が次のものだ。RustyBuzzというHarfBuzzのRust移植がその開発者のYevhenii Reiznerから廃止予定(deprecated)だと表明されたとき、Typstの開発者であるLaurenz Stampflが尽力し、HarfBuzzのシェイピングの更新をHarfBuzzバージョン9.0.0までRustyBuzzへとバックポートした。RustyBuzzといえばその当時、Harbuzz 2.xの段階で止まっていたのだった。

脅威(T)

このエコステムの最大の脅威は、Googleが現在このエコシステムへと注ぎ込んでいるリソースを減少させることだ。
MozillaはServoとFirefox OSを中止することで、すでにその（はるかに小さい）関与を大部分削減した。
Linuxデスクトップは、GoogleのHarfBuzz, FreeTypeなどのプロジェクトへの投資から利益を得てきている。

ChromeやAndroidがまだしばらくの間我々とともにあるだろう一方、Google Fontsはこのエコシステムに最大限に投資している。つまり、フォントを外注したり（Dave Crosslandが率いる）、また開発者の時間、つまり契約作業者（これは私や、Colin Rofls、Khaled Hosny、Simon Cozensを含む）やフルタイムエンジニア（Chad Brokaw, Cosimo Lupo, Garret Rieger, Roderick Sheeter, Qunxin Liu、など）として投資している。
Googleの会社全体での予算削減がGoogle Fontsチームへと届くと、これにより最大の脅威をもたらす。

Rust移植が長期的にはそのエコシステムにとって利益があるものだとしても、短期ではエコシステムを断片化させ、C / C++やPythonプラットフォームのために使える（特にグーグルからの）リソースを減少させる可能性がある。これらの言語プラットフォームを、我々はさらに相当の年月をかけて更新する必要がある。

他のリソース / Other resources

次のリストは、他のリソースを集めたものである。

私(Behdad Esfahbod氏)のホームページは、私が長年のうちに作成した20以上のプレゼンと論文を含む。
Digital Typographyは、Nicolas Rougierと私がラスタライザの状況について2018年に調べたものである。これははるかに詳しい内容を含み、そのテーマについてより深く知るための読み物とレファレンスのリストを含む。
The Raster Tragedyは2018年に更新され、ヒント付けとサブピクセルテキストレンダリングに関する章を増やした。
The Bézier PrimerはPomaxによるもので、現在のベジエ形式でのベクターフォントを取り扱うことに興味を持っている人にとっての入門書である。
Raph Levienのブログや他の書き物は、画像処理とテキストレンダリングをRustからGPUで行うことに関する話題をカバーしている。
typo.socialというMastodonサーバーはタイプデザインコミュニティのためのSNSコミュニティである。
FontToolsとHarfBuzzのGitHubディスカッションフォーラムとissueトラッカーは、フォントのコンパイルと利用に関連する様々なトピックに関し助けを求めるための良い場所である。
いつでも私にメールしてきてください。あるいは、Xかtypo.socialで私に宛てて書いてください。私の連絡先は私のホームページにあります。

謝辞 / Acknowledgements

次に示す人々に謝辞を示します。この記事の草稿のレビューと、洞察力に富んだ議論に対して。Bianca Berning, Dave Crossland, Eskil Abrahamsen Blomfeldt, fantasai, Garret Rieger, Just van Rossum, Khaled Hosny, Lars Knoll, Liam Quin, Roderick Sheeter, Skef Iterum, Werner Lemberg, それと間違いなく書き忘れているだろう他の人たちに。
すべての誤りは私の責任です。

また、Google Fontsチームに謝辞を示します。この文書の著述をサポートし、このエコシステムに継続して投資していることに対して。

著者について / About the author

Behdad Esfahbodはイラン系カナダ人ソフトウェア開発者で、オープンソース狂であり、カナダのエドモントンを拠点としている。
彼はHarfBuzzの筆頭作者であり開発者である。さらに、オープンソースエコシステムにおいて、国際化、フォント、テキストレンダリングに取り組んだ25年以上の経験がある。
彼はGoogle、Facebook、Red Hat、FarsiWebプロジェクトで働いてきた。

ハックをしていないときは、behdadは料理、旅行、写真、短編映画作成、車、キャンプ、姪と遊ぶなどして楽しんでいる。

バージョン履歴 / Version history

2024年7月8日最初の一般公開