|
目次
なめらかな輪郭
スムージングのオン/オフを切り替える方法
強調表示を行ったときに発生する問題
要約
|
Mac
OS 8.5
の“アピアランス”コントロールパネルには“なめらかな文字で表示する”チェックボックスと、アンチエイリアスをオンにするために必要な最小のテキストサイズを設定するための“サイズ”ボックスが用意されています。このテクニカルノートでは、この機能のインプリメンテーションの現状を簡単に説明し、この機能の制限と既存のアプリケーションとの間で発生する可能のある互換性の問題について詳細に説明します。また、アプリケーションによるアンチエイリアステキストの描画を可能にする新しい
API
の使い方を示します。さらに、強調表示を行ったときに（特に暗い強調表示色を使用して）、アンチエイリアステキストの画面表示が見苦しくなる理由を説明し、この問題を解決する方法を示します。
|
なめらかな輪郭
なめらかな輪郭とは
次に、フォントスムージングをオンにした場合とオフにした場合のテキストのサンプルを示します
(サンプルテキストは Textile フォントの 24
ポイントです)。
 
フォントスムージング ― オフ フォントスムージング ―
オン
次に、右側のサンプルがきれいに見える理由を（視覚的に）説明します。
文字のアウトラインをスキャンしてビットマップに変換するとき、スクリーンデバイスには解像度の限界があるため、垂直または水平ではない輪郭に沿って、いわゆる「ジャギー」が発生します。このとき、斜めの輪郭や丸くなっている端部に沿ってグレイのレベルを追加すると、人間の視覚はごまかされ、輪郭がなめらかになったように感じます。アンチエイリアステキストに対するグレイレベルのピックスマップを生成するため、Mac
OS 8.5 の新しい TrueType
スケーラではこれまで同様、要求されたサイズに対してグリッドにはめ込まれたアウトラインを使用しています。しかし、アウトラインを伝統的な白黒スキャンコンバータに渡す前に、各ピクセルは概念的に
4×4
のサブピクセルから構成される正方形に置き換えられ、オリジナル解像度の
4
倍の精度でスキャン変換が適用されます。このようにして生成された各ピクセルに対応するビットマップ正方形に含まれる黒色のドットの総数
(0 から 16 までの数) は 4 ビット (0 から 15 の値)
でエンコードされたグレイのレベルにマップされ、これがピックスマップのピクセル値になります。さらに、QuickDrawText
の blitter
は、これらのグレイレベルがテキストの前景色から既存の背景色にうまくブレンドされるように配慮します。
問題は何か
ここまでは特に問題ありません。しかし残念なことに、このアプローチにより、いくつかのやっかいな問題が発生する可能性があります
(これらの問題の一部は「Mac OS 8.5 Read
Me」ファイルの中でも言及されています)。
a)
フォントスムージングをオンにするということは、SetOutlinePreferred(TRUE)
を暗に指定したことになる。アウトラインフォントの計測値は一般にビットマップフォントの計測値とは異なるため、テキストのオーバーフロー、配置のずれ、切り捨てなどが発生することがある。
この問題は慎重に検討されたデザイン上の決定に基づいています。例として標準の
Times
フォントを考えてみましょう。このフォントはアウトラインフォントとして提供され、同時に
9、10、12、14、18、および 24
ポイントの各サイズのビットマップ (NFNT)
バージョンが付属しています。デフォルトの設定で
outlinePreferred
フラグはオフになっています。つまり、アウトラインフォントの計測値がビットマップフォントの計測値と異なるとすれば、ビットマップフォントを使用した既存の書類のオーバーフローを避けるために、このような措置がとられました
(TrueType を含む System 7
がリリースされた当時を思い出してください)。
これ以降、異なるサイズのスケーリングを行うときに、テキストのアピアランスと計測値が質的な変化を被るというあまりありがたくない現象が起こるようになりました。前述のような決定がなければ、フォントスムージングがオンになっているときの画面表示はまったく別のものになるはずです。つまり、11、13、15、16、17、19
ポイントなどのサイズがアンチエイリアステキストとして表示され、ビットマップバージョンが提供されているサイズはジャギーのある白黒テキストとしてそのまま表示されるはずです。
Mac OS 8.5
になっても、この問題に対する対応は首尾一貫していません。ビットマップバージョンが
sfnt フォーマットの内部 ('bloc' および 'bdat' テーブル内)
に隠されている場合、TrueType スケーラの現在のバージョンでは
outlinePreferred の問題をまったく考慮しません。既存の 2
バイトフォントの計測値との間に発生する他のいくつかの互換性の問題を回避するため、TrueType
スケーラではなめらかなテキストに対する要求を無視し、スムージングされていないグリフを返します。この場合、'bdat'
および 'bloc'
テーブルに含まれているビットマップそのものがグレイスケールで格納されていると、さらに別の例外が問題になります。これは、Macintosh
プラットフォームで使用するために変換された一部の Microsoft
フォントのみに当てはまるケースです。
このような問題に対処する最適な解決方法があれるとすれば、すべてのビットマップフォントのグレイレベルバージョンを提供するか、既存のビットマップフォントを対象にしたアンチエイリアスのプロシージャを開発するかのいずれかです。第
1 の選択肢が現実的でないことは明らかです。また、第 2
の選択肢はソフトウェア開発の努力に伴う時間的な制約によって採用が見送られました。また、他の解決方法も提案されていますが、それらはどれも「適切」なものとはいえません。通常、ビットマップフォントの計測値をアウトラインフォントから描画されたグリフとともに使用することは
(この逆も)、文字組みの上からも、表示の美的な観点からも明らかに不可能です。
b)
アプリケーションでは、テキストが常に白黒のビットマップで表示可能であることを前提にしている。
アプリケーションがテキストをオフスクリーン
(フリッカのない編集やスクロールなど)
で描画することには正当な理由があり、また 1
ビットの深さのオフスクリーン (メモリフットプリント)
で済ませようとすることにも正当な理由があります。このような環境でアンチエイリアステキストを描画できないことは明らかです。また、アプリケーションが、テキスト描画をスクリーン上に送る呼び出しにオフスクリーンの更新を混合させてしまうと、最終的にはアンチエイリアステキストと非アンチエイリアステキストが互いに隣同士に並んでしまうこともあります。
オフスクリーンの深さが十分である場合でも
(つまり、少なくとも 8
ビット/ピクセルの場合でも)、やはりモノクロテキストの前提により、やっかいな問題が発生することがあります。たとえば、一部のアプリケーションでは、QuickDraw
の CopyBits
を使って、オフスクリーンテキストをテクスチャを含むいくつかの背景の最前面に転送します。しかし、「黒色」のソースピクセルを保持したまま、周辺部のグレイのピクセルをコピー先にブレンドすることができる
CopyBits
の転送モードは存在しません。一般に、この処理の結果は十分に満足のいくものとはなりません。
c)
強調表示と強調表示の解除はモノクロテキストを前提にしている。
この結果、テキストの表示が見苦しくなることがあります。詳細については、このテクニカルノートの「強調表示を行ったときに発生する問題」を参照してください。
先頭ページに戻る
スムージングのオン/オフを切り替える方法
フォントスムージングをオンにした結果に起こりうるこれらの問題を検討するとき、アプリケーションがプログラムを使ってユーザの設定とのインタフェースをとる方法を必要としていることは明らかです。より明確にいえば、ユーザがフォントスムージングをオンにしていないシステム上であっても、アプリケーションにはアンチエイリアスを選択的にオンにするオプションが必要だということです。
また、アプリケーションがシステムとは異なる設定を要求するテキスト描画ジョブを処理した後で、速やかにシステムの状態をリストアする必要があることも明らかです。フォントスムージングのフラグをセットしてリストアしても、パフォーマンスのペナルティを科されることはまったくありません
(熟練した Mac OS プログラマの、8.5 より前のバージョンの
FontManager
に関する経験に基づいた予想に反して)。ただし、この処理はシステム全体におよぶグローバルな設定であるため
(GrafPort
単位またはコンテキスト単位の設定ではなく)、バックグラウンドプロセスのすべてのテキストの再描画とシステム独自のテキスト描画に影響を与えます。また、アンチエイリアステキストの描画と非アンチエイリアステキストの描画の切り替えが予想できないという点に問題があります。
次に、Fonts.h
インクルードファイルの最新バージョンに含まれている API
呼び出しを示します。
Boolean IsAntiAliasedTextEnabled(SInt16* outMinFontSize);
OSStatus SetAntiAliasedTextEnabled(Boolean inEnable, SInt16 inMinFontSize);
第 1 の関数は容易に解釈できる Boolean
値を返します。アンチエイリアスが有効になる最小のサイズに関心がある場合は、関数値が
TRUE という条件で、*outMinFontSize
が“アピアランス”コントロールパネルでユーザによって設定された値を返します。関数値が
FALSE の場合、*outMinFontSize
は定義されていません。最小のフォントサイズに関心がない場合は、パラメータとして
NULL を渡します。
第 2
の関数を使用すると、アンチエイリアステキストのステータスを設定することができます。inEnable
が TRUE の場合、inMinFontSize
パラメータはユーザが選択した最小フォントサイズの値が格納される場所に置かれます。小さいポイントサイズのアンチエイリアステキストの描画品質は現在のところ不十分であると考えられているため、12
ポイント未満の最小サイズは許可されません。実際、12
未満の値は自動的に 12 に置き換えられます。この関数は常に
noErr を返します。
次に、これらの関数を使って、アンチエイリアステキストを一時的にオフにする
(アンチエイリアステキストが有効になっている場合)
方法を示します。
//-------------------------------------------------
Boolean userWantsSmoothText ;
SInt16 previousMinSize;
userWantsSmoothText = IsAntiAliasedTextEnabled(&previousMinSize);
if (userWantsSmoothText)
(void)SetAntiAliasedTextEnabled(false, 0);
// 第 1 のパラメータが FALSE のとき、第 2 のパラメータは無視されます。
// ここでは、「ジャギー」な方法でテキストを描画し、
// その後、ユーザが選択したステータスに戻します。
if (userWantsSmoothText)
(void)SetAntiAliasedTextEnabled(true, previousMinSize);
//-------------------------------------------------
もう 1 つ付け加えれば、IsAntiAliasedTextEnabled および
SetAntiAliasedTextEnabled シンボルは、System 内にある
FontManager
のコードフラグメントからエクスポートされますが、開発ツールとともに使用している
InterfaceLib
がこれらのシンボルをインクルードしない可能性があります。リンカにエラーが発生しないようにするため、InterfaceLib
の次のリビジョンがリリースされるまでは、これらのシンボルをエクスポートし、関数の空のインプリメンテーションを含む、ちょっとした「FontManager」スタブライブラリを作成しなければならない場合があります。
先頭ページに戻る
強調表示を行ったときに発生する問題
『Inside Macintosh: Imaging With QuickDraw』の 4-41
ページから 4-44 ページには、強調表示という概念が QuickDraw
の中でどのように設計されたかが説明されています。次に、強調表示に関する
2 つの重要な機能を示します。
- 強調表示は背景色または強調表示色のいずれかを持つピクセルのみに影響を与える。
- 強調表示関数を 2
回呼び出すと、元のステータスに戻る。
QuickDraw
の当初の設計の中にアンチエイリアスが想定されていないことは明らかです。前景色から背景色に連続的にブレンドされる色のシェードを使用することでビットマップの輪郭がなめらかにされるとき、中間的なシェードを持つ輪郭は強調表示アルゴリズムに関与しません。前景色が黒色で、背景色が白色、そして強調表示色の彩度がかなり強い
(暗い青色や赤色のように)
場合を考えてみましょう。アンチエイリアステキストでは、輪郭を連続的に白色とブレンドさせるために、元の黒色のビットマップの周囲には多かれ少なかれ明るいグレイのピクセルが存在することになります。強調表示が適用されると、「周辺部」のピクセルはそれらの元の値を保持しますが、白色のバックグラウンドピクセルは比較的暗い強調表示色によって置き換えられます。その結果、輪郭の周囲は見苦しく輝いて見え、小さなサイズや特定のタイプフェースではほとんどテキストを読むことができなくなることがあります。
Apple
では、この問題の解決方法を見つけようと努力しましたが、これまでのところ有効な解決方法は見つかっていません。実際問題として、輪郭がどのようなバックグラウンドピクセル
(強調表示されているかどうかに関係なく)
にも正しくブレンドされるように前述の機能 a)
を修正しつつ、機能 b)
(既存のコードとの互換性を保つための必要条件)
を維持することは不可能です。
この問題を解決するには、強調表示に対する異なるアプローチが必要になります。テキストを強調表示領域に描画する前に、まず強調表示領域を消去して望ましいステータス
(強調表示されたステータスまたは強調表示されていないステータス)
にするか、強調表示と強調表示の解除を行う 2 つの異なる API
呼び出しを提供して、アンチエイリアステキストを考慮に入れた方法でそれらをインプリメントするか
(たとえば、ATSUnicode.h ファイルに含まれる ATSUHighlightText
および ATSUUnHighlightText
関数を参照してください)、いずれかのアプローチが必要になります。
さしあたり、見苦しさを最小限に抑えるパステル調の強調表示色を使用するか、特に粗が目立つサイズやタイプフェースのテキストを頻繁に編集する場合にもアンチエイリアステキストをオフにしておくことをお勧めします。
先頭ページに戻る
要約
Mac OS 8.5
ではアンチエイリアステキストの機能が導入され、この機能は多くのテキスト描画、とりわけ斜めに傾いたタイプフェースの表示に大幅な改善をもたらします。しかしながら、伝統的なコードの中で採用されている前提とのコンフリクトが発生する可能があることが明らかになり、さらにその他の望ましくない副作用が発生することも明らかになりました。将来、これらの問題について何らかの改善が図られることが期待されています。
もちろん、「中庸かつ賢明な喜び」を与える忠告に耳を傾けることは、日常生活のさまざまな側面のみならず、フォントスムージングの問題についても重要です。
先頭ページに戻る
|
