Windows 7 でのタイポグラフィーとテキスト・レンダリングの進歩

PCで画像とビデオを観ることは非常に普及していますが、私たちの多数は大部分の時間をテキストを見て対話することに費やしています。私たちはテキスト表示品質向上のためのテクノロジーを追求していきます。この領域では引き続き、ディスプレイ、グラフィックス カード、そして開発者が利用できる API レベルで、向上したテクノロジーを活用することができます。Windows 7 では、GDI でのテキストとフォントのサポートを、互換性とアプリケーションのサポートの基礎として引き続き提供します。現代の DirectX グラフィックス インフラストラクチャの基礎に基づいて、Windows 7は Direct Write を使用して開発者が利用できるテキスト出力を拡張します。これは新しい API サブシステムで、Microsoft やソフトウェア開発者のアプリケーション、および Windows 自体でも、より長期にわたり広く採用されることでしょう。この投稿では、Clear Typeとフォントの向上点に (両方ともGDI ベースのテキスト API の向上点の部分として利用可能)関しても取り上げます。この取り組みは PDC (投稿の下記を参照のこと) で紹介されました。この投稿は Walachia Chaoweeraprasit (私たちのグラフィックス フィーチャー チームの開発リーダー) によるものです。 --Steven

Windows 7 の大きな目標の 1 つは、より優れたグラフィックス、より高い忠実度を備えたグラフィックスを用意することでもあります。この目標に向かい、私のチームは、Windows で最も基本的なグラフィックの要素のうちの1つ、つまりテキストを向上させる方法を研究しています。テキストは常に目の前にありますが、気にならないほど自然な存在であって欲しいと思います。

よいテキストの必要性

ユーザーは PC の使用において約 80% を読み書きに費やします。コンピューターは実質的にユーザーにテキストで対応するため、これは驚くべきことではありません。コンピューターが人間の脳へ直接考えを伝えられるようなテクノロジーを持つまでは、テキストが引き続きコンピューター画面から情報を受け取る方法です。

研究によると、よいテキストはより高い生産性につながります。私たちは人間として、実質的に単語をキャプチャーし、それらの間を信じられないほど滑らかに、そして迅速に移行することが得意です。それが、読み取りのベースとなっています。私たちはその能力に非常に長けており、テキストがそのプロセス用に最適化されていれば、それらは信じられない速度で、しかも無意識に行うことができます。なぜ多くの人が本を短時間でさっと読むことができるか、またコンピューター画面をしばらく凝視した後すぐに疲労してしまう人がいることを、これによって説明できると思います。しかし、読み取りプロセスを妨げるようなあらゆる視覚的な関連要因が、実際に私たちの読み取り速度を遅くします。したがって、よいテキストとは可能なかぎり注意をそらす要因が少なく、ユーザーの読み取りプロセスをサポートするために調整されたテキストです。

各文字、単語、行および段落を囲む白地の均等さは、読み取りのペースを保つために非常に重要な役割をはたします。一方、黒い要素は、私たちの注意を集中させます。長すぎる行、詰まった単語、不均等な段落、およびこのような条件は、読んでいるメッセージからますますユーザーの注意をそらし、それを伝える単なるメディアにどんどん注意を向けさせます。テキスト アートとは実質的に、テキスト自体は目の前から消え、その結果、それが伝える考えがあなたの頭の中で再生させることです。適切なテキストを準備する方法に関する研究は、タイポグラフィーとして知られています。また、タイポグラファーが言うように、よいタイポグラフィーは“見ることができない”のです。よくないものだけが見えます。プラットフォームとしての Windows の役割は、優れたテキストのプレゼンテーションの提供、およびソフトウェア開発者向けに、開発しているソフトウェアのコンテキストで可能な最良のプレゼンテーションを作成するための優れたツールを提供することです。

現在の技法の向上

ユーザーは習慣によって行動する傾向があり、しばしば時間とともに、これらの習慣は優先的な方法になります。その行動がありきたりであるほど、私たちはより容易にその習慣にとらわれてしまい、それを変えるのがより困難になります。スクリーンのテキストに関していうと、ユーザーは一日中同じ画面を見ています。それが一夜にして完全に変化すると、たとえそれがよい方向への変化であっても、即座に厄介なことになるかもしれません。そうなると、ユーザーがそれほど使い慣れたものを、私たちはどのように向上させられるでしょうか。私たちは確実に、そこにあるものをサポートし、また既存のメソッドをサポートしながらそれを向上させたいと思います。しかし、向上点を理解する前に、最初に現在の実装、およびこの数年にわたって存在している課題をより詳細に見ていきましょう。

現在の実装はデバイス ピクセルに基づいたテキスト レンダリング設計の製品です。特定のサイズのテキストのディメンションは、最終的にデバイス面の水平および垂直方向のピクセル定数へ変換されます。10ポイントのテキストは、通常の 600dpi のプリンター デバイス上でおよそ 80 のピクセルの高さに変換されます。一方、同じテキストが、96dpi モニター上では単に 13 のピクセルになります。 この物理的な画面状況は、画面上のよいテキストのために必要な品質としては、ほとんど適切ではありません。

幸運にも、過去十年における Clear Type の出現は、主に品質における明瞭さの側面を向上させました。Clear Typeは、LCD ピクセル構造の分析に影響を与え、人間の視覚的なシステムを活用しました。個々のピクセルを構成する LCD の通常の 3 つのカラーのチャンネルにおいて、全体のディスプレイ ピクセルで近隣のサブピクセルにエネルギーを配分することにより、視覚的な幻覚を作成し、低い解像度のデバイス上でより高い解像度ラスター品質をもたらします。結果として、Clear Typeテキストは LCD ディスプレイ上の通常のテキストより大幅に鋭く見え、そのあとで非常にポピュラーになった表示テクノロジーに関する品質問題の大部分を軽減しました

Windows の最初の Clear Type の別の設計は、それがアプリケーション互換性を弱めることなく、テキストの明瞭さを向上させたということでした。すなわち、それはどちらの方向でも個々のグリフの実寸法を変えず、隣接した 2 つの間の距離を変えません。これにより、ユーザーはドキュメントやアプリケーションで選択されたオプションを「格納する」必要なく、自由に切り替えることができました。それは、完全にユーザーごとのレンダリング リファレンスです。Windows 7 では、さらにユーザー自身が PC エクスペリエンスをコントロールするというテーマにそって、ClearType をチューニングする場合により詳細な選択肢を提供することにより、ClearType Text Tuner を向上させました (今までどおりそれをオフにできます)。

しかし、世界の他の多くの場合と同様、コインには 2 つの面があります。下位互換性を保持していますが、技術を向上させたその独自の機能によって制限を受けます。個々のグリフの幅と高さおよび隣接した2つの間の名目距離は、所定のサイズでのスクリーン ピクセルの丸められた数に修正されたままです。

私たちが Windows 7 でもたらしたグラフィックスの向上点の 1 つは、かつての物理ピクセル モデルから移行し、代わりに、いわゆる「デバイスインディペンデント ピクセル」単位 （または「DIP」）、浮動小数点データ型で 1 インチにつき 96 分の 1 である「仮想ピクセル」に関連して新たな設計を行ったことです。このモデルでは、グリフ (あるいはこれに関する他の幾何学的なプリミティブ) を、断片的なピクセルにサイズ変更でき、2 つのピクセル間のどんな場所にも位置することができます。新しい Clear Type 向上点は、グリフのサイズ変更および配置によって、画面のサブ ピクセルを最も理想的な状態に近づけるのを可能にしました。より自然に見える字形を作成し、画面上のテキストを印字品質により同じに見えるようにします。

下図で、従来あるいは現在の Clear Type (上) および Windows 7 の向上点 - Natural Clear Type (下) による同じ単語を並べて示しました。なお、Natural Clear Type は、レンダリング用の新しい API の呼び出しが必要です。単語内の文字の幅および文字間の広さ、さらにより一貫した幅および間隔が全単語の全体的な外観を向上させていることに注目してください。文字はすべて標準間隔で配置され、カーニング調整は適用されていません。高度な読み取りテクノロジー チームの研究者であるケビン・ラルソンによる優れた論文において、単語認識の科学的な側面が詳述されています。

自然なテキストの画面配置へ近づけるという機能は、さらに非常によい副産物をもたらします。それは、実際のディスプレイ デバイスの解析度を考慮することなく、テキストを行の上に配置できるという事実です。それは、ユーザーが持っているディスプレイ デバイス型にかかわらず、ある画面で見えるのと同じに、他のすべての画面でも同じに見えることを前提に、UI 設計者がアプリケーション UI を設計できることを意味します。この事実は、翻訳されたテキストが同じレイアウトで至るところに作成されるソフトウェア ローカリゼーションにとって特に便利です。

この向上点は、さらに画面上での印刷ドキュメントのより現実的なビューを提供します。画面ドキュメントをそれに相当する印刷に近づけることができます。それはさらに、ドキュメントのズームの品質も向上させることができます。実際の印刷物を目に近づけたり遠ざけたりして見るようにできるキュメントのズームを想像してください。これにより、オンラインでの読み取りがよりよいエクスペリエンスになります。

フォントおよびフォント管理

“フォト”がフォトグラフィの要であるように、“フォント”はタイポグラフィの要です。Windowsでより多くのフォントが出荷されていますが、さらに多くのフォントが世界中で開発されています。Windows Vista は、Windows XP に比較すると、40 % 増のフォントを出荷しました。Windows 7 でも傾向は踏襲され、40% 多い新しいフォントを出荷すると予想されます。さらに、関連フォントの大きなライブラリとの協力を向上させるために、Windows 7 エクスプローラを使用するいくつか表示/分類機能を追加しました。

既定の共通コントロールのフォント ダイアログおよび Windows 7 リボンのフォント チャンクも、どのフォントを現在のユーザー プロファイルのユーザーに存在させるか、よりインテリジェントに選択できるように更新されます。現在の UI 言語、ユーザー・ロケールおよびキーボード入力ロケールの現在のセットなどの複数の設定に基づいて、フォント一覧は、異なる文化とロケールのユーザーには通常使用されない言語のフォントを非表示にします。たとえば、混乱を減らし、生産性のレベルをより上げるためにメモ帳、ワードパッドおよびペイントのような共通のシステム アプリケーションでは、すべての国際的なフォントは自動的に通常の英語ユーザーから隠されています。リボンあるいは共通コントロールのフォント ダイアログを利用するサード パーティ アプリケーションでも、同じ利点があります。ユーザーは、Windows 7 コントロール パネルのフォント アプレットで明示的にそれをマークすることにより、どのような希望のフォントもビューに選択できるオプションを保持します。

この増加は、向上のいくつかの新しい機会をもたらします。私たちは長い間フォントをシステム全体のリソースとして扱ってきました。それはコンピューター上に「インストールされ」、オペレーティング システムのコア部分によって管理される単一の水平な名前空間中で維持されます。不思議と思われる方もいると思いますが、「Arial Balch」は、実際には「Arial」あるいは「Arial Narrow」とは同じグループではありません。つまり、オペレーティング システムに関係する限り、それらは異なる名前を備えた異なるフォントなのです。また、フォントはその名前によって一意に識別されるので、同じフォントの複数のバージョンを同時に持つことができません。

フォントはシステム リソースであるため、ドキュメント内で埋め込みフォントのようなフォントの非伝統的な使用、およびアプリケーションで排他的に使用されたフォントは、個人のインストールとして既知の機構によって行われます。それにより、フォント名がそれをプログラム的にはインストール前には一意ですが、他のフォントを非表示にすることによってそのように機能します。プライベート フォントは、内部オペレーティング システムに関する限り、パブリックにインストールされたフォントと同じです。

Windows 7 の新しいフォント形式の重要な向上点は、パーティション分割によって、同じ使用をフォント分離した名前空間へ共有するのを可能にする「フォント集合」の概念です。システム集合は、現在存在するものに似ており、システムによって作成および管理されます。カスタム集合は、必要に応じて、完全にアプリケーションプログラムによって、作成および管理されます。これにより、ドキュメントに独自のローカル フォントのセットを持つことを可能にし、サード パーティ アプリケーションあるいはプラグインを、プログラム内で排他的に使用される独自のフォントと共に出荷できるようにします。このパーティション分割は、不要なシステム全体のフォント更新を減らすだけでなく、更新がローカルに必要な場合にのみ起こるようにできます、さらに、異なる集合内の同じフォントの複数のバージョンへのアクセスを可能にします。

新しいフォント形式は、フォントが集合内に整理される方法を向上させ、ウェイト幅傾斜バリエーションの概念をサポートします。ウェイト幅傾斜バリエーションでは、同じ文体ルートを持っているが、ウェイト (太い、細い、黒など)、幅 (広い、狭いなど)、傾斜 (イタリック、斜体) において異なるフォンが、同じフォント ファミリー内に一緒にグループ化されます。たとえば、「Arial Narrow」は、「Arial」ファミリの 1 つのバリエーション、つまり書体です。このグループ化モデルはCSS推奨事項によって提唱されています。

フォント アート

フォントは、アート(芸術) および芸術的な表現にもなります。したがって、フォントの作成を支援するテクノロジーは、芸術家が表現するためのツールとなります。過去 10 年の間に、OpenType と呼ばれる重要なテクノロジーが登場しました。これにより、活字デザインを実現できる新しい方法が可能になりました。OpenType を使用することで、デザイナーは、製作の段階でグリフをどのように組み合わせて、変形するのかを定義できるようになりました。その結果、デザイナーは、この機能を、アプリケーションプログラム可能なアクセス用の「フォント機能」と呼ばれる実行可能な単位として公開することができます。

OpenType は、マイクロソフトが 1994～95 年に開発した TrueType オープン テクノロジーから派生したものでした。TrueType オープン テクノロジーでは、TrueType フォーマットに、GSUB、GPOS、BASE、JSTF、および GDEF テーブルが追加されました。当時の主な用途は、Arabic フォントの作成を支援することでした。この作業には固有の複雑さがあったからです。マイクロソフトは 1996 年にこのテクノロジーを OpenType という名称に変えることにしました。そして、Adobe は同じ年に、このテクノロジーに、彼らの CFF グリフ アウトライン フォーマットを追加しました。現在、OpenType は、さまざまな言語において、テキストの読みやすさを向上させる共に、新しく刺激的な活字デザインを表現するために使用されています。

しかし、長年存在し続け使用可能な状態にあったにもかかわらず、Windows 業界における OpenType の用途の大部分は、特殊なプログラムに限られたままでした。Windows ネイティブのグラフィックス システムでは、OpenType をテキストに対するその本来の用途として、十分には活用していませんでした。この物足りなさが多くのデザイナー達をがっかりさせています。その理由は、Windows に、彼らが作成した機能をテストする標準的な方法がないからです。同様に、公開が制限されているため、本来のアプリケーション開発者の発見可能性が促進されません。この状況を改善し、この改善されたレンダリング技術に移行することは、(互換性がないものとして紹介されてしまう可能性のある) 混乱状態を最小限に抑えながら、利益を最大にするために実施させるため、いくつかの段階を経る必要があり、そのためいくつかのリリースにまたがっていくことになるでしょう。Windows 7 では、この目的に対して別の手段をとっています。この領域に深い関心を持つ大多数の人たちには、より迅速に移行したいという強い願望があるということを私たちは知っています。私たちは、移行のスピードと、互換性を維持したいという願望とのバランスをとるために、最善を尽くしています。

Windows 7 の新しいテキスト システムでは、利用可能な OpenType 機能を内部で使用するだけでなく、高レベルのプログラミング インターフェースにおけるフォントで利用可能な機能へのアクセスも可能なり、アプリケーション開発者が本来のシナリオで簡単に、フォント機能を発見して用いることができるようになりました。Windows 7 には、広く尊敬されているタイポグラファーの John Hudsonが開発した最新のOpenTypeフォント「Gabriola」も搭載されています。Gabriola では、文脈依存の字形を多用しており、状況に応じで異なるフォントを使用するために、前例のない程多くの数の文体のセットが用意されています。下の図は、このフォントで利用できるすべての文体のセットを列挙したものです。各々の文体のセットを識別する微妙な点とそれほど微妙でない様式に注意してください。

また、下の図は、Gabriola の文体のセット (「ss07」) の 8 番目の表現における文脈依存の字形が持つパワーを示しており、同じ単語をレンダリングする場合でも、行内の配置場所に応じて、さまざまな様式が生み出されています。

新しい API

テキストをレンダリングすることは、簡単なように見えても、実際は複雑です。おそらく、文書でテキストの書式設定を行う方法には何百もの方法があり、多くの場合、最終的に同じ結果を生み出す多数の道筋があります。HTML/CSS は複雑な規格であり、テキストを書式設定して活字化する方法の豊富さの良い例となっています。言語の要件、つまり言語を記述するルールは、書式設定のロジックの下にあります。Windows は、長い間 Unicode (グローバルなデータ交換のためのもう1つの複雑な規格) をサポートしてきました。Windows は、すべての単一リリースで、増大しつつある Unicode スクリプトをサポートしています。入力テキストからフォントの最終的なグリフへのマッピングには、複雑な変形が要求され、フォントデータの解析と言語記述パターンの分析が必要になります。一旦グリフが確定されれば、ラスタライズ、マージ、およびフィルタリングが行われ、最終的にディスプレイ装置に表示されます。

このステージング特性のために、テキスト システムからは、アプリケーションの種類ごとにそれぞれ異なるサポートが必要になります。伝説的な「Hello world」タイプのアプリケーションのような、代表的アプリケーションは、ユーザーに単にテキストを見せるだけの機能であれば満たすことができます。しかし、Microsoft Word や Adobe InDesign などの文書作成システムでは、このレベルのサポートでは、全く不十分です。より成熟した一部のアプリケーション・コードベースでは、さまざまなグラフィックシステムに対処できることも必要になります。このため、Windows エコシステム内の多種多様なアプリケーション全体で広く役に立つにようにすることは、特定のグラフィクス モデルに結びついたテキスト システムには、実際には非常に困難なこととなります。

テキスト処理は均一なものではなく、さまざまな種類のアプリケーションが、それぞれ異なるニーズを持ち、異なるレベルのサポートを必要としている、ということが、Windows 7 の計画の初期段階で明らかになりました。テキスト機能への、適切なレベルでのプログラミング・アクセスが、機能そのものと同じくらい重要となります。Windows 7 の新しいテキスト システムは、DirectWrite と呼ばれている自給自足のシステムにまとめられています。APIは、4 つの層 (フォントデータ用のインターフェース、レンダリングのサポート、言語処理および活字設定) で提供され、それぞれの層は別の層の上に構築され、低位の層は上位の層に対して要求を行わず、特定のグラフィック モデルに依存するものはありません。後者のポイントを例示するために、下の図では、Direct2D と呼ばれる Windows 7 の新機能でもある 2D グラフィックス環境から押し出され塗りつぶされた 3D ジオメトリとして最終的なレンダリングが行われる間、新しい活字設定インターフェースと言語プロセッサを使用する、サンプルアプリケーションを示しています。両方のシステムが、Windows 7 に基づく新しいグラフィックの基盤として、 PDC 2008 に導入されました。

DirectWriteは、3 つの重要な側面で、GDI や GDI+ などの既存のテクノロジーへの開発者の投資をサポートします。まず第一に、DirectWrite の前に述べた階層化設計により、テキストの配置とレンダリングという 2 つの基本的なプロセスの間を明確に分けることができます。これにより、複数のアプリケーションが DirectWrite を使用して、テキストを、GDI や GDI+ のような従来のグラフィックサーフェイス上でレンダリングしながら、配置することができるようになりました。また、必然的に、GDIを使用して、DirectWrite を通してテキストをレンダリングしながら、配置するという、逆のシナリオもサポートされています。互換性に関する第2の側面は、DirectWrite は、GDIで見つかるテキストの配置とレンダリングを行うすべての既存の方法もサポートしているという事実から生じています。DirectWrite アプリケーションは、DirectWrite を使用して、実際に GDI を使用せずにGDI が行う場合と同様に、テキストの配置とレンダリングを実行することができます。この互換モードの下で配置とレンダリングが行われたテキストは、ユーザーの視点からは、GDI テキストと見分けがつかず、GDI テキストと同じように、アプリケーション UI とテキスト文書の既存のレイアウトを維持しています。最後に、DirectWrite は、GDI と相互運用する一連の API を公開しています。GDI フォント オブジェクトを選択しているアプリケーションは、それを DirectWrite のフォント オブジェクトに変換することができます。逆変換も可能です。フォント システムは、DirectWrite API 層の最低位にあるので、高度なデータの維持と正確さを確保するのに欠かせない最適な相互運用ポイントを提供します。一旦アプリケーションが DirectWrite のフォント オブジェクトを取得できれば、それ以降は、DirectWrite フォントを必要としている他のどの DirectWrite APIでもそれを使用することができます。DirectWrite のフォント オブジェクトからGDIフォント オブジェクトへの再変換機能を使用することで、残りの GDI ベースのアプリケーションを変化なく機能させながら、DirectWrite の新しく改善されたフォントモデルを使用することによる利点を獲得することもできます。実際のいくつかの例のように、Windows 7 の XPS 印刷ラスタライザは、DirectWrite の最上位に実装されており、DirectWrite の相互運用 API を利用し、非XPS プリンタ・ドライバの XPS ベースの印刷ジョブの変換の一部として、GDI フォントへの再変換を行います。また、Windows 7 XPS Viewer は、画面表示のためにGDI+グラフィックレンダリングと同時に、DirectWrite を使用します。

API には説明すべき詳細事項がまだたくさんあります。上記にリンクされているPDCセッションでは、Leonardo Blanco と Kam VedBrat が、DirectWrite と Direct2D、およびこのようなアプリケーションを開発する方法の詳細を説明しています。

Windows NT 3.1 (または後続の API 追加機能)の TextOut や ExtTextOut など、Windows GDI の最初のテキストAPI以降、世界は大きく変わりました。テキストのサポートの進化は、Windows 7の基盤の重要な部分です。私たちは引き続き、グラフィック・オペレーティングシステムのこの最も「基本的な」要素を改善し、テキストをレンダリングするのに用いられる言語、スクリプトまたはデバイスに関係なく、Windows が、開発者にとって非常に有益なツールと API のセットを提供し、エンドユーザーには素晴らしい体験を提供できるようにしたいと考えています。

--Worachai