図1は、特に、低解像度の表示装置を有するシステム上で、ウェブブラウズ、及び/又は、他の種類のコンピュータによって生成されたコンテンツの表示を改善するために、本発明の幾つかの特徴に従って使用される可能性のある、基本的な処理及びデータ表示を示す高レベルの図面である。
図1の最上部に図示された1つ又は複数のビットマップ画像102及びテキスト104を含むデジタルコンテンツ100は、その図面の最下部に表示されたサブピクセル最適化され縮小されたフォーマット106で表示されている。
本発明の一実施形態において、ステップ108で構成される差分処理は、テキストコンテンツの表示をサブピクセル最適化するために使用されるというよりは、むしろ、ビットマップ画像102の表示をサブピクセル最適化するために使用される。ステップ108は、特に、カラービットマップからのサブピクセル最適化された画像の生成に適したサブピクセル最適化ルーチンを使用している。また、処理108は、現在殆どのウェブコンテンツが表示されている解像度よりも低い解像度を有するスクリーン上での表示のために、ビットマップを縮小する。
デジタルコンテンツ100に含まれるテキスト104は、ステップ110及び112を使用することによって、低解像度サブピクセルアドレス可能スクリーン上での表示を行うために処理される。ステップ110は、通常テキスト表示に使用されるフォントを、サブピクセル最適化スクリーン上で低解像度の表示を行うために最適化されたフォントと置換する。ステップ112は、例えばフォント形状の定義に一般的に使用される数学的に定義されたアウトラインの様な、同一色の形状の高解像度画像の表現に特に適したサブピクセル最適化ルーチンによって生成された代替フォントからのフォントビットマップを使用する。
本発明に関する一つの利用方法としては、インターネットからダウンロードされているマークアップ言語によって表現された、画像、及び/又は、テキストを表示するポータブルで、低解像度のウェブブラウザのコンテンツに於ける利用がある。
現在まで、多数の所謂マークアップ言語が存在している。最も古く、最も支持された言語の1つがSGML(Standard General Markup Language)である。SGMLは、データに関する情報を提供する記述的な「メタデータ」を用いてデータを「マークアップ」するために使用可能なテキストベースの言語である。例としては、データが意図する目的、又は、データが配置される文書の視覚的提示の範囲内の位置を示すためにマークアップメタデータを使用することが出来る。また、それは、テキスト中、又は、マークアップ言語で記述された文書中の所定の位置に挿入される、例えば画像のような他の種類のデータへのリンクを示すために使用可能である。今日一般的に使用されている、例えばHTMLやXML等の幾つかのマークアップ言語は、SGMLから派生したものである。
本発明の最良の一実施形態に於いて、上記図1において参照されたデジタルコンテンツ100は、例えばHTMLのようなマークアップ言語で表現された画像、及び/又は、テキストを含む標準的なウェブコンテンツであっても良い。おそらくウェブサイトのホームページを表現する、この標準的なウェブコンテンツ100は、図2乃至図4に図示されたポータブル低解像度ブラウザ装置200上に表示するために、下記に記述された様々な装置及び方法でダウンロードすることが可能である。ブラウザ装置200上に表示する前に、デジタルコンテンツ100は、判読性向上のために、例えば以下に記述するような様々な方法や処理によって拡大/縮小、及び/又は、サブピクセル最適化される可能性がある。
図2は、本発明の一実施形態に従って実施される、ネットワークコンピュータ環境を図示している。薄型クライアントブラウザ200のプログラムは、例えば液晶表示装置(LCD)スクリーンのような小型表示スクリーン上にテキスト及び/又はグラフィックの取り込み、及び、表示を実行することが可能なハンドヘルドコンピュータデバイス、又は、他の小型コンピュータデバイスに於いて実行される。このブラウザによって、ユーザはリモートソース(例えばインターネット)からのデジタル情報を要求し、それをスクリーン上に表示させることが出来る。
図2に図示された本発明の実施形態に於いて、ユーザは薄型クライアントブラウザ200のコントロールボタンを操作することによって、画像、及び/又は、テキストを含むデジタルコンテンツの取り込み、及び、表示を要求する。要求されるデジタルコンテンツは、インターネットを介してアクセス可能な特定のウェブページであっても良い。そして、薄型クライアントブラウザ200は、例えばLAN、WAN、又は、インターネットであり得るネットワーク138上で物理的に遠隔にあるプロキシサーバ210を介してコンテンツに対する要求202を実行する。
プロキシサーバ210は、ユーザによって要求されたデジタルコンテンツ100を有する物理的に遠隔にあるウェブサーバ220に対応する要求214を生成することによって、デジタルコンテンツの要求に対するプロキシプロセス216を実行する。プロキシサーバ210に対するネットワーク138上のデジタルコンテンツ100のダウンロード222によって、サーバ220はプロキシサーバの要求214に応答する。
次に、プロキシサーバ210内のプロキシプロセス216は、図1に図示された機能108及び110の実行を含む、デジタルコンテンツ110を拡大/縮小、及び、サブピクセル最適化するための計算リソースを使用する。拡大/縮小、及び、サブピクセル最適化は、小型表示装置上で例えばテキスト及び/又はグラフィックのような画像の判読性向上を生み出す本発明の特徴である。これらについては、次のセクションに於いてより詳細に議論する。
プロキシサーバ210は、ここで拡大/縮小され、サブピクセル最適化されたコンテンツのブラウザ200へのダウンロード212を完了させる。この時点で、ユーザはブラウザ200のスクリーン上でコンテンツを見ることが出来る。
図2に図示された本発明の実施形態に於いて、デジタルコンテンツのテキスト部分は、1つ又は複数の文字の文字列、及び、フォントファミリー、フォントサイズ、及び、他のフォント属性の関連指定を含む形式でブラウザにダウンロードされる。個々のサブピクセル最適化されたフォントビットマップで構成された画像を用いて文字列を表示することによって、薄型クライアントブラウザは、図1に図示された関数112を実行する。指定されたフォントサイズ及びフォントファミリーに於けるそうした文字列で、任意の文字に対するビットマップを有していなければ、薄型クラインアントはフォントサーバ230から一つ又は複数のそうしたビットマップを要求する。図2乃至図8に図示された本発明の様々な実施形態に於いて、プロキシサーバはそうしたフォントビットマップを提供することが可能であり、又、薄型クライアントは(ブラウザソフトウェアのサイズを増大させることになるが、)それらのビットマップをソフトウェアの標準的な部分として有することも可能である。他の実施形態に於いてもなお、フォントはアウトラインフォントになり得る。フォントビットマップの一つ利点は、フォント取り扱い業者の中には、そうしたフォントのアウトラインに比して、それらのフォントのビットマップをより自由に頒布可能にすることを望む傾向の強い業者が存在するという点である。
本発明に関する代替実施形態の一つが図3に図示されている。この実施形態に於いては、図2のプロキシサーバ210及びウェブサーバ220が1台のリモートサーバ220Aに置き換えられている。薄型クライアントブラウザ200は、ネットワーク138上のリモートサーバ220Aに対して、デジタルコンテンツ100の要求202Aを実行する。例えば、ネットワーク138はインターネット又はLANであっても良く、デジタルコンテンツ100は特定のウェブページであっても良い。リモートサーバ220Aは、要求されたデジタルコンテンツ100を有しており、要求202Aに応答するプロキシプロセス216Aを実行する。プロキシ処理216Aは、クライアントブラウザ上に表示するために、ウェブコンテンツを動的に拡大/縮小、及び/又は、サブピクセル最適化するサーバ上で実行される如何なる処理であっても良い。プロキシ処理216Aは、保存されたデジタルコンテンツ100に対して実行され、図1のステップ108及び110を実行することによって、デジタルコンテンツ100を図1に図示された形式106に動的に変換する。リモートサーバ220Aは、薄型クライアントブラウザ200への拡大/縮小、及び/又は、サブピクセル最適化されたコンテンツのダウンロード212を完了する。
本発明に係る他の代替実施形態は図4に図示されている。図3と同様に、薄型クライアントの要求は、ネットワーク138上で、リモートサーバ(ここでは、サーバ220B)に直接要求される。
この実施形態に於いて、リモートサーバ220Bは、標準的なブラウザコンピュータで使用される標準形式100と、拡大/縮小、及び/又は、サブピクセル最適化されたコンテンツ100Aとの両方の状態で、要求されたデジタルコンテンツを有している。標準的なデジタルコンテンツ100から拡大/縮小、及び/又は、サブピクセル最適化された形式への変換は予め実行されており、これにより、プロキシ処理が動的にそれを変換する必要がなくなる。薄型クライアントは、要求されたコンテンツの拡大/縮小、及び/又は、サブピクセル最適化されたバージョンを受け取るはずだということを示す情報をサーバに提供する。リモートサーバ220Bは、薄型クライアントブラウザ200に対して、拡大/縮小、及び/又は、サブピクセル最適化されたコンテンツ100のダウンロード212を完了する。
さらなる代替実施形態が図5に図示されている。ブラウザ200Aは、拡大/縮小、及び/又は、サブピクセル最適化処理510をさらに含むフルスケールブラウザである。ブラウザ200Aは、ネットワーク138上のリモートサーバ220Cに対して、デジタルコンテンツ100の要求202Bを行う。サーバ220Cは、ブラウザ200Aに対して要求されたデジタルコンテンツ100のダウンロード212Aを完了する。デジタルコンテンツ100の拡大/縮小、及び/又は、サブピクセル最適化された形式への変換は、ブラウザ200Aで実行される処理510によって取り扱われる。
図6は、デジタルコンテンツ100を拡大/縮小、及び/又は、サブピクセル最適化することが可能な単一のコンピュータシステム600を図示している。この最良の実施形態に於いて、デジタルコンテンツは予めコンピュータシステム600に於いて生成されるか、又は、読み込まれている。コンピュータシステム600は、サブプロセス640を拡大/縮小、及び/又は、サブピクセル最適化することを含む、ブラウザ処理620を有している。ここで、ユーザは、付属の入力装置(例えばキーボード又はマウス)によって、コンピュータシステム600に対してデジタルコンテンツ100を表示する要求を行う。ブラウザプロセス620は、コンピュータシステムの記憶素子(例えば、電気的なメモリやディスク記憶装置)の1つから、要求されたデジタルコンテンツ100を取り込む。次に、ブラウザプロセス620は、デジタルコンテンツ100を取り込んだ時点で、これを拡大/縮小、及び/又は、サブピクセル最適化するサブ処理640に送信する。変換が完了すると、変換されたコンテンツは、コンピュータシステム600の表示スクリーン上に表示される。本発明に係るこの実施形態は、ネットワーク又はリモートサーバを必要とすることなく動作する。
図7は単一のコンピュータシステムに関する代替実施形態を図示している。この実施形態に於いて、コンピュータシステム700は、予め形成、又は、読み込まれている(例えば、特定のウェブページのコンテンツ)等のデジタルコンテンツ100、プロキシ処理740、及び、ブラウザ処理720を有している。プロキシ処理740は、拡大/縮小、及び/又は、サブピクセル最適化プログラム760を実行する。ブラウザ処理は、デジタルコンテンツ100を表示するためのユーザ要求をプロキシ処理740に送信する。次に、プロキシ処理740は、コンピュータシステム700の記憶素子からデジタルコンテンツ100を取り込む。デジタルコンテンツ100が取り込まれた時点で、プログラム760は、後にコンピュータシステム700の表示装置で表示するためのブラウザプロセス740に送信される、拡大/縮小、及び/又は、サブピクセル最適化された形式にデジタルコンテンツ100を変換する。
図8は、単一のコンピュータシステムに関する第2の代替実施形態を図示している。ここでは、コンピュータシステム800は、拡大/縮小、及び/又は、サブピクセル最適化されたウェブコンテンツ810を有している。ブラウザ処理820は、ユーザからのコンテンツ100Aを表示する要求を処理し、コンピュータシステム800の記憶素子からそれを取り込み、コンピュータシステム800のスクリーン上にこれを表示する。
上記に示した本発明に係る実施形態に於いては、ソースの画像の解像度からサブピクセルでアドレスされたスクリーンの解像度への画像の拡大/縮小は、部分的に、ソース画像及びサブピクセルでアドレスされた表示スクリーンの各解像度によって決定されている。
本発明の幾つかの実施形態に於いて、ソース画像の解像度とサブピクセルアドレス可能表示スクリーン上に表示される解像度との間の倍率決定は、ブラウザ装置のユーザにより特定可能である。この実施形態に於いて、ブラウザのユーザは、記憶装置から読み出される画像を縮小する処理に倍率を伝達することにより、複数倍率の中から倍率を選択する。次に、記憶装置から読み出された画像を縮小する処理は、選択された倍率に比例する水平及び垂直方向の倍率で、画像を縮小、及び/又は、サブピクセル最適化する。
殆どの他のユーザがブラウザ装置に入力する場合と同様に、このような縮尺の選択は、物理的な又はGUIのボタン、メニュー項目、ダイアログボックス、又は、ブラウザ装置上のその他周知のユーザインターフェース装置を使用することにより実行可能である。
そうした幾つかの実施形態に於いて、ブラウザ装置のユーザは、画像が以前に記憶装置から取り込まれ、第1倍率でサブピクセル最適化された形式で表示された後、デジタルコンテンツが再度、拡大/縮小、及び、サブピクセル最適化されて、再表示されることに応じて、複数倍率の中から第2倍率を選択しても良い。
そうした実施形態に於いて、第1の拡大/縮小、及び、サブピクセル最適化された表示に於いて使用される倍率は、デフォルト又は所望の倍率の結果生じたものであっても良く、又、ブラウザ装置のユーザによって以前選択された倍率の結果生じたものであっても良い。ブラウザ装置のユーザは、ブラウザ装置の入力装置を操作する方法で、デジタルコンテンツを再表示する複数倍率から倍率を選択しても良い。そうしたブラウザ装置の入力装置の操作によって、第2の選択された倍率に従って画像が表示される。
そうした第2の拡大/縮小は、ブラウザ装置内、又は、物理的に離れたサーバ内の何れかで実行される処理の結果生じるものとしても良い。ブラウザ装置のユーザは、引き続き再表示するために複数倍率の中から倍率を継続して選択しても良い。
整数倍の縮小では、ソース画像に於ける整数のピクセルを結果として生じる縮小画像に於ける所定のピクセルに適合させる整数倍によって、デジタル画像を縮小することが最も簡単である。例えば、640×480解像度から320×240解像度への縮尺は、倍率2の縮小である。本発明に係る幾つかの実施形態では、非整数の縮小倍率を含む複数の縮小倍率からユーザが倍率を選択することが出来る。非整数の縮小倍率の例は、640×480解像度のソース画像の480×360ピクセル部分を、320×240解像度表示スクリーン上に表示するために拡大/縮小、及び/又は、サブピクセル最適化する、縮小倍率2分の3の例である。
本明細書に於いてウェブページの解像度について言及する場合、通常、レイアウトを実施するブラウザプログラムがウェブページのコンテンツをレイアウトするよう要求されている解像度のことを意味する。下記に示す通り、特定の最小レイアウト幅を必要とする複数要素を有するウェブページもあり、ウェブページをそうした最小レイアウト幅よりも短い幅で表示するよう要求される場合、要求されたレイアウト幅よりもその幅が長い場合であっても、それらの要素は自身に必要な最小幅でレイアウトされる。
例えば陰極線管(CRT)のようなコンピュータグラフィック表示装置や、液晶表示装置(LCD)スクリーンは、ほぼ例外なく色空間に関するRGBモデルを使用している。但し、該発明は、例えばCMYKカラーモデルのような他のカラーモデルに適用可能である。RGBモデルでは、加法3原色、赤、緑、青が混合され、人間の目で認識されるように所望の色を形成する。
ほとんどのポータブルコンピュータデバイス、又は、画像装置は、RGBモデルを使用するLCDスクリーンを有する。そうしたLCDスクリーンは、何千ものグリッド素子からなるピクセルと呼ばれる矩形配列で構成されており、該ピクセルは全体として認識される場合には画像を形成し、各ピクセルはRBG色空間からの多くの色値の内、一つを表示可能である。LCDスクリーンは、該スクリーンが有する水平及び垂直ピクセルの数により特徴付けられている。
同様に、各ピクセルは、ここではサブピクセルと称す、個々にアドレス可能な3つのサブコンポーネントによって構成されている。最も一般的には、サブピクセルは赤、緑、青の矩形要素である。最も一般的な実施形態に於いて、赤、緑、青の3つのサブピクセルは、サブピクセルが混合されてピクセル全体が所望の色に見えるように、各々に光度の値が割り当てられている。同様に、LCDスクリーン上の全てのピクセルが混合され、所望の画像が見えるようになる。
該サブピクセルは個々にアドレス可能であるとされているが、これは、個々のピクセルに割り当てられた色値が、別々の赤、緑、青のカラーコンポーネント、又は、輝度値を有しており、ピクセルの赤、緑、青のサブピクセルによってそれぞれ表示されるからである。それ故、ピクセルに割り当てられた色値に於いて、関連付けられたカラーコンポーネントの輝度値の値を制御することによって、各サブピクセルの輝度を別々に制御することが可能である。
LCD装置、及び、例えばカラーLED(有機発光ダイオード(OLED)を使用するスクリーンを含む)やガスプラズマ表示装置のような、他の「サブピクセルアドレス可能」表示装置では、各サブピクセルのそれぞれが、表示上に固定の既知の位置を有する。例えば、殆ど全ての陰極線管(CRT)等の多くの表示装置は、サブピクセルアドレス可能ではない。例えば、CRTの各ピクセルは赤、緑、青のカラーコンポーネントのそれぞれに対して個別に輝度値を有しているが、それらの異なる色値に関連する光を生成する要素のそうした各ピクセル内での正確な物理的配置は、通常知られていない。これは、スクリーンの個々の発光パターン、水平及び垂直スキャンの解像度、個々のピクセルがスクリーン上に描画される正確な位置を制御する電圧に関する現在の正確な状態、に関する関数に比例するからである。
図9は、複数のピクセル行(R1−R12)、及び、ピクセル列(C1−C12)で構成されるLCDスクリーン900の12×12の部分を図示している。行と列のそれぞれの交点がピクセル要素を構成している。実際のLCDスクリーンは、任意の数の行列を有することが可能である。但し、頻繁に見られるのは、320×240、640×480、800×600、1024×768、1280×1024のグリッドである。
波線の円部910内にピクセルR1−C1が図示されている。ピクセルR1−C1は、それ自身が3つのピクセルサブコンポーネント(以下、サブピクセル要素と称す)で構成されている。ピクセルR1−C1の拡大図は、図9の最下部の拡大されたピクセル920として図示されている。サブピクセル要素902は赤として表示され、サブピクセル要素904は緑として表示され、サブピクセル要素906は青として表示される。個々のサブピクセル要素902、904、906は、幅がピクセル全体の約3分の1の幅であり、高さがピクセル全体の高さに等しい。
LCDスクリーン900に図示されているように、そうした複数ピクセルが格子状に配列される場合、垂直のカラーストライプがLCDスクリーン900上に現れる。この周知のピクセル配列は、垂直RGBストライプと呼ばれることがある。他の周知の配列では、水平ストライプが生じるような直角方向で、ピクセル要素がレイアウトされる(この場合、スクリーンを90°回転することによって、水平ストライプスクリーンを垂直ストライプスクリーンに変換される)。
一般的な使用に於いては、ピクセルの3つのサブピクセル要素に関する光度は、ピクセルが人間の目に所望の色合い、彩度、及び、明度で認識されるように設定される。RGBサブピクセル要素は、表示される画像の1つのサンプルを表現するために、単一のカラーピクセルを形成するために同時に使用される。
本発明の1つの特徴は、例えば320×240、又は、240×320(この場合、320×240の解像度を有するために、90度回転することが可能)の行列ピクセル比を有する表示のような低解像度スクリーン上での、ダウンロードされたウェブコンテンツ、テキスト及び画像を含むその他のデジタルコンテンツの可読性の向上に関する。詳細に議論し、図示した本発明に係る実施形態の多くは、640×480の仮想レイアウト解像度から320×240ピクセル解像度を有するスクリーン上に画像及びテキストをマッピングする。しかし、他の解像度スクリーンに本発明を使用することが出来る。ほんの2、3例を挙げると、512×384解像度スクリーンで1024×768解像度を見るように凡そレイアウトされたコンテンツを表示するために使用可能であり、又、400×300スクリーンで800×600ピクセルを見るように凡そレイアウトされたコンテンツを表示するために使用可能である。他の実施形態に於いては、本発明はパーソナルコンピュータのスクリーン上で一般的な偶数比の水平ピクセル次元、及び/又は、垂直ピクセル次元以外のピクセル次元を有する比較的低解像度の表示で使用される。
概して、低解像度スクリーンについて言及する場合には、所定のデジタルコンテンツやデジタルコンテンツの所定のレイアウトが通常表示される予定のスクリーンよりも低解像度のスクリーンを意味する。また、そうした小型スクリーンによって そうした低解像度を有する、例えば、より大型のスクリーン上のウインドウ等、大型スクリーンの一部を含むことを意味する。
図10に於いて、画像コンテンツ105、及び/又は、テキストコンテンツ107は、図1のサブピクセル最適化された表示の一部を示している。図1に図示された画像は、テキスト及び画像の両方のサブピクセル最適化された表示に関連した実際の色値のグレースケール拡大図である。図10の矩形部1000内の画像コンテンツ105の部分は、個々のピクセルをより見易くするために1020で拡大図示されている。これに対応して、矩形部1040内に含まれるテキストコンテンツ107の一部が1060で拡大図示されている。
1020及び1060で図示されたピクセルがピクセル全体を表現していることに留意しておくことが大切であるが、これは、画像1020及び1060を生成するために使用されるソフトウェアが、全ピクセルのそれぞれに関連付けられたRGB色値に対応するグレースケールを単に表現しているからである。サブピクセル拡大表示1020A及び1060Aは、それぞれ、拡大表示1020及び1040における各ピクセルに関連付けられた3つのサブピクセルの各々の明度を表現しようとしている。1020Bは、縮尺及び位置が拡大表示1020A及び1020に対応する拡大表示である。そこでは、画像のピクセル格子が相対的に太い線で表示され、それぞれの各ピクセル内の3つのサブピクセル区分が相対的に細い線で表示されている。この合成格子は、拡大表示1020及び1020Aに図示されたピクシレーションパターンが由来する図1の元々の高解像度カラービットマップ画像102の最上部に重ね合わされる。図示された特定の画像において、カラービットマップ102の解像度は、垂直及び水平方向の両方向において、図10の最下部に図示された画像105に於ける全ピクセル解像度の2倍程度の解像度である。
拡大表示1060Bは、含まれる1つ又は複数の文字の高解像度フォントアウトラインの適用を受ける各サブピクセルの領域の一部を決定することにより、サブピクセル最適化されたフォントの画像が如何に生成されるかを図示している。
サブピクセル解像度の拡大表示1020A及び1060Aと、それぞれに対応する全ピクセルの拡大表示1020及び1060とを比較することから分かるように、サブピクセル解像度での画像及びテキストのサブピクセル最適化された表現による表示は、より適切な空間解像度を提供する。
図11は、標準的なウェブコンテンツを320×240カラー表示上で表示した際に、本発明の一実施形態によって提供される可読性の質を表現するものである。同図の最上部に図示されたビットマップ1100はグレースケールであり、ウェブページ「princeline.com」の一部の標準的な640×480レイアウトから生成された実際のビットマップに関する全ピクセルの拡大表示である。この画像は、図11の最下部に図示されたウェブページの全画面320×240画像に図示された矩形部1130内に含まれるウェブページの一部に対応している。同図の真ん中に図示されたビットマップ1120はグレースケールであり、上記320×240画像の同一部分のカラービットマップの全ピクセルの拡大表示である。図11の最下部に図示された200Bは、図2に関して記載された種類の薄型クライアントブラウザとして機能するハンドヘルドコンピュータ装置を表している。ウェブページの640×480レイアウトを表現する320×240サブピクセル最適化ビットマップの表現が、このブラウザのスクリーン上に図示されている。図10の拡大表示1020のように、図11の最下部に図示されたビットマップ1130は、全ピクセルの平均輝度に対応するグレースケールレベルで個々のピクセルを図示している。図10に於ける拡大表示1020A及び1060Aに示されているように、横方向に於ける垂直サブピクセルストライプを有する320×240スクリーン上でこの画像を見ると、実際の画像は、むしろ高解像度を有するように見える。
本発明の多くの特徴に関する目的に対して、カラービットマップのサブピクセル最適化された画像を得る任意の周知のアルゴリズムを使用することが出来る。本発明の一実施形態に於いて、所定の色の所定のサブピクセルのそれぞれに割り当てられた輝度は、所定のサブピクセルに関連するソース画像に於ける矩形ウインドウ内に完全、又は、部分的に存在するソース画像のそれぞれのピクセルに於ける所定の色値の平均強度で決定される。このソース画像ウインドウは、その縮小された画像に於ける所定のサブピクセルの位置を中心に存在する縮小画像に於ける全ピクセルの領域に対応するソース画像に関連したサイズ及び位置を有している。サブピクセルに割り当てられた平均強度は、全体又は部分的にソース画像ウインドウを覆う各ソース画像ピクセルの強度と、そうしたソース画像ピクセルのそれぞれによって覆われたウインドウの領域の割合との乗算によって算出される。
図12は、解像度が低減された表示装置のサブピクセルグリッドへの、より高解像度のソース画像102のマッピングを図示している。この図は、図1に図示された元のより高解像度のカラービットマップ102の一部に重ねられているサブピクセルグリッド1210を図示している。円部1220は、所望のより低解像度の表示装置に於ける1ピクセルに対応するグリッドの領域を囲んでいる。グリッドパターンの位置及びサイズは、より高解像度のソースビットマップ画像と、結果として得られるサブピクセル最適化画像のピクセルグリッドとの関係によって決定される。図12に図示された特定のグリッドパターン1210は、カラービットマップ画像102のピクセル解像度から、水平及び垂直方向の両方向においてソース画像の2分の1程度のピクセルを有する表示スクリーン解像度への拡大/縮小を表現している。この拡大/縮小の一例として、640×480表示上の表示に適切なピクシレーションを有する画像を、320×240表示スクリーン上に比例して表示するために縮小する例がある。このように、グリッドパターン1210のそれぞれの太い線の区分は、カラービットマップ画像102の4ピクセルに及んでいる。破線円部1220は、4つのより高解像度のソースのソースピクセルを含む、そうした太い線の区分の一つを囲んでいる
図13は、図12のサークル1220を中心とした9つの太い線の区分(即ち、9つの全ピクセル)の拡大図である。円部1300内のピクセルは、所望の表示装置の1つのピクセルを表現している。図13が明らかにしているように、グリッドパターン1210の太い線の区分のそれぞれは、4つのより高解像度のソース画像を囲んでいる。また、図13は、所望の表示装置のそれぞれのピクセルが、夫々「R」、「G」、「B」とラベル付与された赤、緑、青のサブピクセルを含む、3つのカラーサブピクセルで構成されていることを図示している。
図14、15、及び16は、それぞれ、所望の表示装置に於ける、赤、緑、青のカラーサブピクセルの輝度が決定されるソース画像に於ける矩形ウインドウの位置を説明している。そうした各ソース画像ウインドウの領域は、輝度を算出するために使用されるサブピクセルに対応するソース画像の一部を中心とした、縮小画像に於ける全ピクセルの領域に対応する。
図14の矩形部1400は、より低解像度の表示装置の赤色サブピクセルの輝度を算出するために使用されるソース画像ウインドウの領域を囲んでいる。同様に、図15及び図16は、所望の表示装置の緑及び青色サブピクセルのそれぞれ対応するソース画像ウインドウを囲んでいる。
上述したように、所定の色のサブピクセルに割り当てられた輝度は、以下の関数、又は、関数の近似によって決定される。この輝度は、全体又は部分的にサブピクセルの対応するソース画像ウインドウ内にあるソース画像の各ピクセルに於けるピクセルの色の強度と、そうした各ソース画像ピクセルよって覆われたウインドウの領域の割合との乗算に一致するように設定される。
図17、18、及び19において、赤、緑、青のサブピクセルの輝度は、所定のサブピクセルに対応するソース画像の一部を中心とした、ソース画像ウインドウ内に含まれた全体又は部分的なソース画像ピクセルの各色の輝度に関する関数である。これは、ウインドウ領域1700がそのサブピクセルに対応するソース画像の一部を中心とする赤色(R)サブピクセルに関して、図17に図示されている。図18のウインドウ1800は、緑色(G)サブピクセルに対して同一内容を図示しており、図19のウインドウ領域1900は、青色(B)サブピクセルに対して同一内容を図示している。
各サブピクセルに対するソース画像ウインドウ間に於ける移動の結果として、各サブピクセルに対して得られる色値は、全体としてそのピクセルの位置に対応するというよりは、むしろ、各サブピクセル自体の位置に対応するソース画像の位置に於けるサブピクセルの対応する色を表している。その結果、所定のピクセルの異なるサブピクセルに対して異なるソース画像ウインドウを使用することによって、結果として生じる画像の空間解像度が向上する。
図17、18、及び19に図示された本発明の実施形態では、何れのピクセルがサブピクセルのソース画像ウインドウに含まれるか、及び、そうしたピクセルが覆うウインドウの割合は、そうしたソース画像で覆われた水平及び垂直方向のスキャンラインの割合に基づいて決定される。図17では、赤色サブピクセルの色値は、個々のソース画像ピクセルに覆われた水平カバレッジライン1720及び垂直カバレッジライン1740の割合と、そうした各ピクセルの赤色の色値とを乗算した結果として決定される。これは、各色値に関して、即ち、図18の拡大/縮小された画像の緑色(G)サブピクセル、及び、水平及び垂直カバレッジライン1820及び1840のそれぞれ、並びに、図19の拡大/縮小された画像の青色(B)サブピクセル、及び、水平及び垂直カバレッジライン1920及び1940のそれぞれに関しても同様である。注目すべきは、水平カバレッジライン1720、1820、1920は、それらに対応する矩形領域の垂直方向に於ける中点の上方及び下方の垂直位置を表すことを目的としているということである。このため、カバレッジラインは、垂直ピクセル間の境界を表すソース画像に於ける位置とは完全に一致しない。同様に、垂直カバレッジライン1740は、矩形領域1700の水平方向の中点の直左及び直右の水平位置を表すことを目的としている。
上記で定義されたカバレッジラインは、所定のサブピクセルに関連付けられた元の画像の領域が、所定の色又は形状で覆われる程度を決定するための連続関数(例えば、5ビット解像度、又は、それを越えるビット解像度を有するもの等、連続関数に相当する任意の適度に高解像度であるものを含む)の使用に関連する本発明の1つの特徴に関する実施形態を表している。連続カバレッジ関数に於いては、カバレッジ値がサンプリングではなく、むしろ、1次元、又は、それを越える次元で所定のカバレッジが開始、及び、終了する境界位置を決定し、そうした1つ又は複数の境界間、又は、そうした境界と所定のサブピクセルに関連付けられたソース画像ウインドウの境界との間の、長さ又は面積の関数としてカバレッジを計算する数学的な関数によって決定される。
図17、18、19、並びに、図30、31、32に図示された本発明に関する実施形態に於いて、この連続カバレッジ関数の計算は、ウインドウ内の1つ又は複数のソース画像のピクセルのそれぞれによって覆われたソース画像ウインドウ内の一つ又は複数のスキャンライン部分を決定することにより、所定のサブピクセルに対応するソース画像ウインドウ領域に存在する各ソース画像ピクセルの領域を評価することによって、加速される。所定のピクセルによって覆われたウインドウのスキャンライン全体の長さの割合は、そのピクセルに於けるサブピクセルの色値で乗算される。そうした計算結果は、サブピクセルの色値を生成するために、任意のウインドウのスキャンラインを覆う全ピクセルに対して総和される。このようにして、カラービットマップの拡大/縮小された画像の生成時に、サブピクセルの輝度を決定するために「ラインカバレッジ」型の連続カバレッジ関数を使用することが出来る。
図20、21、22は、より低解像度の表示スクリーンに於ける赤色(R)サブピクセルに関連するソース画像ウインドウ2000内の単一の水平カバレッジライン、及び、単一の垂直カバレッジラインの使用を図示している。図21に於いて、水平スキャンライン2020に関連付けられたカバレッジ値は、ブラケット(括弧)2120で覆われたピクセルの赤色の値と、ブラケット(括弧)2120によって覆われた図20の水平スキャンライン2020の1/3の部分との乗算値)+(中ブラケット2140によって覆われたピクセルの赤色の値と、ブラケット2140によって覆われた水平スキャンライン2020の2分の1の部分との乗算値)+(ブラケット2160によって覆われたピクセルの赤色の値と、ブラケット2160によって覆われた水平スキャンライン2020の6分の1の部分との乗算値)によって得られる合計である。
同様に、垂直スキャンライン2040に関連付けられたカバレッジ値は、(ブラケット2220によって覆われたピクセルの赤色の値と、ブラケット2220によって覆われた図20の垂直スキャンライン2040の2分の1の部分との乗算値)+(ブラケット2240によって覆われたピクセルの赤色の値と、ブラケット2240によって覆われた垂直スキャンライン2040の2分の1の部分との乗算値)によって得られる合計である。
赤色サブピクセルに対する全カバレッジ値は、水平スキャンラインについて計算されたカバレッジ値の2分の1と、垂直スキャンラインについて計算されたカバレッジ値の2分の1との和である。
同様に、図23、24、25は、より低解像度の表示スクリーンに於ける緑色(G)サブピクセルに関連付けられたソース画像ウインドウ2300内にある単一の水平カバレッジライン、及び、単一の垂直カバレッジラインの使用を図示したものであり、図26、27、28は、より低解像度の表示スクリーンに於ける青色(B)サブピクセルに関連付けられたソース画像ウインドウ2600内にある単一の水平カバレッジライン、及び、単一の垂直カバレッジラインの使用を図示したものである。
図29は、上記図17乃至28に関して記載された種類のラインカバレッジを使用するソースビットマップ画像から、拡大/縮小された、サブピクセル最適化された画像を得るための、アルゴリズム2900に関する高度に簡略化された擬似コード表記である。
このアルゴリズムは、出力画像(即ち、拡大/縮小され、サブピクセル最適化された画像)の各ピクセル行に対して、ループ2901を実行する。
このループは、現在の行に於ける各ピクセルに対して、インナーループ2902を実行する。そうした各ピクセルについて、ループ2902は、ループ2904及び関数2914を実行する。
ループ2904は、ループ2902の現在のピクセルの各サブピクセルに対して実行される。ループ2904は、例えば、図17乃至28に図示されたスキャンライン等、現在のサブピクセルのスキャンラインのそれぞれに対して実行されるインナーループ2906で構成されている。
ループ2906は、関数2908及びループ2910を含んでいる。関数2908は、スキャンラインとピクセル境界との各交点を計算する。通常、そうした交点計算、及び、このアルゴリズムに於けるその他の計算は、そうした演算処理に関する記憶容量及び計算要件を低減するために、例えば、6〜8ビットの精度等、限られた精度で実行される。
その後、ループ2910は、スキャンラインの両端、スキャンラインの端部、及び、ピクセル境界、又は、両ピクセル境界に於いて生じるスキャンラインの各部分に対して関数2912を実行する。関数2912は、ループ2910の現在の部分に覆われたスキャンラインの割合に、現在のサブピクセルの色に対応する部分を覆うピクセルのカラーコンポーネント値を乗算したものの倍数をサブピクセルのスキャンラインの数で除算し、ループ2904の現在のサブピクセルに関連付けられたカバレッジ値に加算する。
ループ2904が現在のピクセルの各サブピクセルについてサブピクセル輝度値を計算した時点で、関数2914は、それらの計算されたサブピクセル輝度値に等しい赤、緑、青のコンポーネント値を有する複合RBG値を備えた色と同様に現在のピクセルの色値を設定する。
本発明に係る他の実施形態に於いて、例えば、24ビット、16ビット、12ビットの色値等、異なる長さの色値を使用することが出来る。このシステムは、限られたカラーパレットで使用することが可能であるが、赤、緑、青のサブピクセルのそれぞれについて、少なくとも4ビットのばらつきを有するトゥルーカラーで最適に機能する。通常、赤色と青色に5ビットを割り当て、(緑色に対して目が敏感であるため)緑色に6ビットを割り当てる16ビットカラーは、より良好な視覚効果を提供する。
上記図17乃至28で記述された本発明に関する実施形態では、単一の水平スキャンラインと単一の垂直スキャンラインを利用しているが、本発明の該特徴に関する他の実施形態では、より多くのスキャンライン、及び/又は、水平及び垂直方向以外の方向のスキャンラインを使用しても良い。
図30は、サブピクセル最適化された画像の赤色(R)サブピクセルに関連付けられたカラーカバレッジ値を評価するために使用可能な、ソース画像ウインドウ3020内の2本の水平カバレッジラインと2本の垂直カバレッジラインの使用を図示している。
図31は、サブピクセル最適化された画像の緑色(G)サブピクセルに関連付けられたソース画像ウインドウ3120内にある2本の対角カバレッジラインの使用を図示している。
図32は、サブピクセル最適化された画像の青色(B)サブピクセルに関連付けられたソース画像ウインドウ3220内にある2本の対角カバレッジライン、1本の水平カバレッジライン、1本の垂直カバレッジラインの使用を図示している。
言うまでもなく、図30乃至31の各図に図示されたカバレッジラインの各配置は、赤、緑、青のサブピクセルに使用することが可能である。
図33乃至38は、サブピクセルの輝度値を計算するラインカバレッジ法が、ソース画像のサイズ、及び、結果として生じるサブピクセル最適化された画像のサイズとの間に於ける、より広い範囲の異なる拡大/縮小に適用することが出来ることを図示している。例えば、多くのサンプリング技術と比較しても、ラインカバレッジ法がラインカバレッジをかなり高解像度で測定するので、このことは正しいと言える。これは、非整数比の倍率の使用時に多くの場合生じるように、サブピクセルのソースピクセルウインドウに於いて部分的にのみ存在するピクセルのカバレッジの測定が比較的上手くいくことを意味している。
本発明のこの特徴に関する実施形態に於いて、7ビット解像度がラインカバレッジ値の計算に使用され、十分な結果を生んでいる。より高解像度、又は、より低解像度を使用することは可能であるが、通常、ラインカバレッジ解像度は、16(4×4)〜256(16×16)ポイントの配列で、サブピクセルのソース画像ウインドウ内のサンプリングカバレッジによってカバレッジを計測する技術に使用される、2〜4ビット/次元の解像度よりも高解像度であることが望ましい。
図33は、ソース画像解像度から、水平ピクセル及び垂直ピクセルの半分を有する目的のピクセル最適化された画像へのマッピングのために、青色(B)サブピクセルに関連付けられたソース画像ウインドウ内の様々なソース画像ピクセルによる2本の水平カバレッジラインのカバレッジを図示するために、ブラケット(括弧)を使用している。図34は、そうしたサブピクセル輝度計算方法を用いて使用される2本の垂直カバレッジラインについて同一の内容を図示している。図33及び34は、ソース及び低減された画像におけるピクセル数間の整数比を図示している。
図35及び36は、低減されたサブピクセル最適化された画像がソース画像の約40%の水平及び垂直ピクセルのみを有している倍率に対して、同一ソース画像のピクセルによって、水平及び垂直スキャンラインのカバレッジをそれぞれ図示している。
図37及び38は、サブピクセル最適化された画像がソース画像の約66.66%の水平及び垂直サブピクセルを有する倍率に対して、同一内容を図示している。
図33乃至38に図示されたスキャンラインカバレッジ技術は、比較的少ない演算能力で、それぞれの異なる縮尺の各ソース画像に覆われた各ソース画像ウインドウの割合に関する正確な推定値を提供することが分かる。
図39及び40は、「領域」タイプの連続カバレッジ関数に関する図を図示している。本発明の幾つかの実施形態に於いては、それぞれの関連するソース画像ピクセルで覆われた所定のサブピクセルのソース画像ウインドウの割合が、上述したラインカバレッジ近似ではなく、むしろ、サブピクセルのソース画像ウインドウ内に位置するそうした各ソース画像のその部分の領域の実際の計算によって算出される。そうした各ソースピクセルに対して、現在のサブピクセルの色に対応するピクセルのコンポーネント色値が決定される。次に、各サブピクセルの輝度値は、カバレッジ値の割合の倍数と、そのソース画像ウインドウ内に現れる各ソース画像ピクセルに対するサブピクセルの色値とを合計して算出される。
図39は、青色(B)サブピクセルに関連付けられたソース画像ウインドウ領域3900を図示している。ソースピクセル3920は、8つの他のソースピクセルの一部と同様に、ソース画像ウインドウ3900内に含まれている。ソースピクセル3920によって覆われたソース画像ウインドウ3900の割合は、全ソース画像ウインドウ4000の領域に対する図40の網掛け部4020の領域の比率を獲得することによって計算される。同様に、そこに含まれる他のソースピクセルによって覆われたソース画像ウインドウ4000の割合は、ウインドウ4000の異なる網掛け領域によって示されているように、ソース画像ウインドウの全領域に対するソース画像ウインドウ内に存在するそれらの領域の割合を獲得することによって計算される。
図41は、図39及び40に関して議論された種類のエリアカバレッジ関数を実行するために使用可能なアルゴリズム4100に関する高度に簡略化された擬似コード表記を提供している。
このアルゴリズムは、生成されるサブピクセル最適化された画像に於いて各ピクセル行に対して実行されるループ4102を含んでいる。そうした各行に対して、ループ4102は、その行に於ける各ピクセルに対するインナーループ4104を実行する。
このインナーループ4104は、ループ4106と関数4116で構成されている。ループ4106は、ループ4104の現在のピクセルに於ける各サブピクセルに対して実行される。このインナーループ4106は、関数4108及びループ4110とで構成されている。関数4108は、上述したように、ソース画像のどのピクセルが、サブピクセルに関連付けられたソース画像ウインドウ内に存在するかを決定する。これが実行された時点で、ループ4110は各ソース画像ピクセルに対して実行される。
ループ4110は、関数4112及び関数4114とで構成されている。関数4112は、ループ4110の現在のソース画像ピクセルによって覆われたサブピクセルの対応するソース画像ウインドウ領域の割合を計算する。ステップ4114は、ループ4106の現在のサブピクセルに対して計算されている輝度値に、現在のソース画像ピクセルで覆われたサブピクセルのソース画像ウインドウ領域の割合の倍数と、現在のサブピクセルの色に対応するソース画像ピクセルのカラーコンポーネント値とを乗算したものを加える。
ループ4106が現在のピクセルに於ける各サブピクセルに対して実行された時点で、
関数4116は現在の画素の色値を、ループ4106で計算された赤、緑、青のサブピクセル輝度値に一致するRGBカラーコンポーネント値を有する色と同様に設定する。
図42乃至53は2色サブピクセル最適化された画像に関する本発明の特徴に関する。
「2色」画像は、個々のピクセル色が2つの異なる色値の間で変化する画像である。一般に、これらの2つの異なる色値は黒と白であり、ソースのピクセル及びサブピクセル画像のピクセルは、黒及び白に限定された値を有しており、場合によっては、黒及び白の中間のグレースケールに限定された値を有する。しかしながら、幾つかの実施形態に於いて、2つの異なる色値によって、任意の均一な前景色及び背景色と、それらの中間色とを表現することが出来る。多くの場合、テキストの表示は前景色及び背景色を含む色で色付けされているので、多くの場合、2色画像がテキストを表現するために使用される。しかし、他の2色形状、2色ビットマップ、色づけされた多色ビットマップの一部、又は、例えばグレースケール画像のような2色出力で表現される多色ビットマップを表現するために、2色画像を使用することも可能である。例えば、3色コンポーネントの各々の平均輝度に対応するグレースケール値を有するピクセルのそれぞれを単に処理することによって、グレースケール画像として多色ソース画像を処理することが可能である。
そうした2色サブピクセル最適化された出力画像を使用する利点は、多くの場合、該画像が多色サブピクセル最適化された出力画像に比して、より高度な空間解像度を提供することが出来るという点にある。そうしたより高度な解像度は、2色が黒及び白、グレースケール値、又は、不透明及び透明である場合に許容されるが、これは、そうした各2色ペアの各色が、赤、緑、青の同等のコンポーネントを有しているので、各サブピクセルが、そうした2色ペアの前景及び背景の両方を他のものと同様に表現することが可能であるからである。カラーバランスを実行する必要を除いて、以下に示すように、各サブピクセルの輝度は、出力画像中の自身の領域に一致するソース画像の一部が前景色又は背景色で覆われる程度に関する関数として決定される。より小さなソースウインドウ(即ち、ピクセルのサイズよりも、むしろサブピクセルのサイズに一致するソースウインドウ)をこのように使用することによって、ソース画像のより正確な空間解像度を実現することが出来る。
前景色及び背景色が黒及び白ではない場合、前景色及び背景色のそれぞれが比較的輝度の等しい赤、緑、青の値を有し、可能な限り異なった前景色及び背景色の平均輝度を有すれば、2色サブピクセル最適化画像で生成される解像度は最良となる。実際、2色サブピクセル最適化画像に関する本発明の特徴に関する幾つかの実施形態に於いては、出力画像の空間解像度を向上させるために、対応するグレースケール色に移行することで、出力の2色の一方又は両方が、対応する入力の2色から変更される。
2色サブピクセル最適化された出力画像のサブピクセルが前景色を表示する程度は、アルファ値、又は、不透明値によって表現されることがある。そうしたアルファ値は、サブピクセルの輝度が前景色又は背景色に於けるサブピクセルのカラーコンポーネントに対応すべき程度を示している。アルファ値「1」は、サブピクセルのカラーコンポーネント値が、前景色に於ける対応するカラーコンポーネントに等しくなることを意味している。アルファ値「0」は、サブピクセルのカラーコンポーネント値が、背景色に於ける対応するカラーコンポーネントに等しくなることを意味している。中間のアルファ値は、サブピクセルのカラーコンポーネント値が、前景色及び背景色の両方に於ける対応するカラーコンポーネントの加重された混合値となることを意味している。サブピクセル最適化ビットマップがアルファ値の観点で表現される時点で、異なる前景色及び背景色を使用する所定のパターンの2色画像を表現するために、アルファ値を使用することが出来る。フォントの表示に於いて、所定のサイズの所定の文字フォント形状のビットマップパターンは、多くの場合、異なる前景色及び背景色で表示されるので、これは一般的にフォント形状を表現するために使用される。
ビットマップ画像の2色サブピクセル最適化に関する本発明の特徴に関する幾つかの実施形態に於いて、ビットマップ画像の拡大/縮小されたサブピクセル最適化された画像は、以下の(a)〜(c)の関数として、前景又は背景2色カバレッジ値と、拡大/縮小された画像の各サブピクセルとを関連付けることによって生成される。即ち、(a)サブピクセルの領域に対応するソース画像ウインドウに於ける各ソース画像ピクセルに対する前景色又は背景色の比率、(b)そうした各ソース画像ピクセルによって覆われたそのウインドウの割合、(c)カラーアンバランスを低減するためにサブピクセルカバレッジ値を分散するカラーバランス関数、である。2色出力画像がグレースケール入力画像、又は、多色入力画像に対して生成される場合には、そのソース画像ウインドウを覆うソース画像ピクセルの全ピクセル輝度に関する関数として、個々のサブピクセル対して計算されるカバレッジ値を獲得することが出来る。幾つかの実施形態に於いては、所定のサブピクセルのソース画像ウインドウに関連付けられた所定の輝度値が他のサブピクセルに分配される程度は、輝度値がカラーアンバランスを発生させる程度に関する関数である。
図42乃至44は、ビットマップ画像のグレースケール2色画像の各サブピクセルの輝度を決定する方法に関する。図42に於いて、矩形部4200は、拡大/縮小された画像の赤色(R)サブピクセルに関連付けられるソース画像のウインドウを囲んでいる。そうした赤色(R)サブピクセルに関連付けられた輝度は、そうした各ソース画像ピクセルによって覆われたソース画像ウインドウの割合でそれぞれ乗算された、ソース画像ウインドウ4200を覆う1つ又は複数のソース画像ピクセルの全ピクセル輝度に関する関数である。そうしたカバレッジの割合を計算又は推定する任意の周知の方法を使用することが出来る。
図42に図示された実施形態に於いて、ソース画像ウインドウ4200は、2本の水平スキャンライン4210及び4220、及び、2本の垂直スキャンラインをそれと関連付けている。図43及び44は、緑色及び青色のサブピクセルのそれぞれに対する、ソース画像ウインドウ4300及び4400に対応するカバレッジラインを図示している。前述の通り、ソース画像ウインドウ領域がソースピクセルによって覆われた程度を推定するために、各スキャンラインに沿って所定のカバレッジが開始及び停止する境界位置を決定する数学的な関数が実行される。1つ又は複数のそうした境界の間の長さ、又は、そうした境界と所定のサブピクセルに関連付けられたソース画像ウインドウの境界との間の長さに関する関数として、カバレッジが計算される。これは、図29に於いて上述した方法と同様の方法で実行することが出来る。
2色サブピクセル最適化された画像の計算時に、カラーアンバランスが発生する可能性がある。これは、2色法が前景色及び背景色、及び、ソース画像が中間色を有する場合には、前景色及び背景色との間のスペクトルに於ける色のみで構成されているものとして、ユーザに知覚される出力画像を生成しようとしているからである。しかし、ピクセルの個々の赤、緑、青のサブピクセルのカバレッジ値は、そうした各サブピクセルに於ける前景色の割合によって決定され、このことは、多くの場合、個々の出力ピクセルの色が、そうしたカラーバランスの無い状態で、所望の2色スペクトル(通常はグレースケール)とは関連性が無いことを意味している。
例えば、グレースケール画像では、ソース画像が、サブピクセル最適化された出力画像に於ける赤及び緑のサブピクセルの間の境界に対応する位置で、全体的に白色から全体的に黒色に変化する場合、出力画像に於ける対応するピクセルは、そのサブピクセルを全体的にオンの状態に切り換える傾向のある赤色サブピクセルカバレッジ値と、そうしたサブピクセルを全体的にオフの状態に切り換える傾向のある緑色及び青色サブピクセルカバレッジ値とを有する。この例では、出力画像がグレースケール画像であるということになっているのだが、これによってピクセルに対する視認可能な赤色が生じる結果となる。
図45乃至47は、2色ビットマップから生成されるカバレッジ値をカラーバランスするために、フォントアウトラインのラスタ化に基づいて計算されたサブピクセルカバレッジ値をカラーバランスするための従来技術で使用されている種類の従来の線形カラーバランス法を、如何にして使用することが出来るかを図示している。
図45は、RGBグリッド4600下での一組のグレースケールソース画像ピクセルを図示している。グリッド4600は、太い線の区分で囲まれた4つのピクセル領域を有する。そうした各ピクセル領域は、出力画像が表示されるサブピクセルアドレス可能スクリーンに於ける全ピクセルに関連付けられている。各ピクセル領域は、サブピクセルアドレス可能スクリーン上で関連付けられたピクセルのサブピクセルに関連付けられた3つの領域にさらに分割される。サブピクセルに関連付けられた領域4610は、赤色(R)サブピクセルに関連付けられており、サブピクセルに関連付けられた領域4612は、緑色(G)サブピクセルに関連付けられており、サブピクセルに関連付けられた領域4614は、青色(B)サブピクセルに関連付けられている。同様に、サブピクセルに関連付けられた領域4616乃至4632は、それぞれの表示スクリーンサブピクセルに関連付けられている。
サブピクセルに関連付けられた領域4614乃至4630は、今回の例では黒色の前景色の様々な程度に対応する、非白色輝度値を有するソース画像ピクセルによって、全体的又は部分的に覆われている。サブピクセルに関連付けられた領域4614乃至4630のそれぞれに於けるソース画像ピクセルの黒色輝度値の合計(白色を差し引いた値、又は、通常の輝度値に相当)は、図46のRGBグリッド4700に於ける対応するサブピクセル領域にマッピングされる。各サブピクセル領域4744乃至4760内の斜線領域の高さは、対応するサブピクセル領域4614乃至4630の非白色輝度値の合計によって決定される。
図46の最下部は、例えば、サブピクセル4750等、所定のサブピクセルに関連付けられたカバレッジ値を、その所与のサブピクセル4750を中心とする5つのサブピクセルに対して分配するために使用可能な、中央部重点対称カラーフィルタの使用を図示している。サブピクセル4750のカバレッジ値の9分の3は、サブピクセル4750自身に分配される。サブピクセル4750のカバレッジ値の9分の2は、サブピクセル4750の直左及び直右にそれぞれ位置するサブピクセル4748及び4752に分配される。サブピクセル4750の色分配を完了するために、カバレッジ値の9分の1は、それぞれ、サブピクセル4750の左側2つ目のサブピクセル、及び、右側2つ目のサブピクセルであるサブピクセル4746及び4754に分配される。
概して、カラーバランスは、近傍のサブピクセルの近傍圏内にある色値を割り当てる。例えば、図46に示された実施形態等、多くの実施形態に於いては、そうした割り当てが実施される近傍サブピクセルは、輝度が割り当てられているサブピクセルからピクセル一つ分の距離に過ぎないが、今回の例では、輝度が割り当てられているサブピクセルからピクセル2つ分に相当する距離内にあるものとして近傍サブピクセルが定義されている。
図47は、図46の中央部重点対称カラーバランスフィルタが、図46の上半分に図示されたサブピクセル4744乃至4760のそれぞれに対して計算されたカバレッジ値に、直線的に適用された場合の結果を図示している。
図47に於いては、図47の最上部に図示された各サブピクセル4744乃至4760に関連付けられたカバレッジ値は、自身のサブピクセルに対して、そして、図46に図示されているように、左側及び右側にある2つのサブピクセルに対して、同一の比率でカバレッジ値が分配されるカラーバランスフィルタを使用して分配される。図47の中央のグリッド4802は、そうした分配がサブピクセル4740乃至4762のそれぞれに対して行われる寄与分の大きさを図式化して説明している。所定のサブピクセル4744乃至4760のそれぞれに関連付けられた分配は、各サブピクセルの直下に位置する垂直コラムを中心に配置されている。
図47の最下部に図示されたRGBサブピクセルグリッドパターン4804は、中央のパネル4802に図示された全てのカバレッジ値の分配によって行われた、全ての寄与分を合計することによって、サブピクセル4740乃至4762のそれぞれに対して計算される輝度値を図示している。この方法を完了するために、グリッド4804に於ける各ピクセルの赤、緑、青のサブピクセルの輝度値が、そうした各サブピクセルの色を特定する3つのカラーコンポーネント値として使用される。
この線形法で拡大/縮小された画像のカラーアンバランスは低減されるが、これは空間解像度に於ける実質的な低下を代償に実行される。これは、サブピクセル最適化された出力画像に於けるサブピクセル輝度値を表す図47の最下部のRGBグリッドパターン4804における値と、出力画像のサブピクセルに対応する領域に於けるソース画像ピクセルに関する、輝度又は前景色カバレッジを表す図47の最上部に位置するRGBグリッドパターン4800に於ける値とを、比較することによって理解することが出来る。図47から判る通り、出力画像の空間解像度はソース画像の空間解像度に比して不鮮明である。
本発明は、サブピクセル最適化出力画像に関する類似のカラーバランスを提供するが、多くの場合、出力画像に関して不鮮明度をより少なくしてカラーバランスを提供する技術革新を含んでいる。これは、非線形カラーバランスフィルタリング法の使用により実行される。該非線形フィルタリングを適用する方法は、図48及び49に図示されている。
図48のRGBグリッドパターン4900は、図46のRGBグリッドパターン4700の複写である。今回の場合も、総合輝度、又は、前景色カバレッジ、即ち、関連するサブピクセルに対応するソース画像ピクセルの値は、斜線領域の高さで表現されている。
非線形カラーバランス法の第1段階が、図48に図示されている。前述の通り、RGBグリッドパターン4900は、太い線の区分によって4分割されており、4等分された各部分、即ち、括弧4902、4904、4906、4908は、拡大/縮小された、又は、出力された画像の全ピクセルに関連付けられている。ピクセル領域4902、4904、4906、4908のそれぞれは、生成される出力画像に於けるサブピクセルに対応するサブピクセルソース画像ウインドウにさらに分割されている。各ピクセルに対して、サブピクセルの対応するソース画像ウインドウの何れが最も低いサブピクセル輝度、又は、前景カバレッジ値を有しているのかが決定される。最小輝度/カバレッジ値に等しい輝度(又はアルファ)値は、図48の下半分に図示されたRGBグリッドパターン4910の出力画像ピクセル4912、4914、4916、4918の各サブピクセルに対して計算される輝度/アルファ値に加算される。
図48の上部半分に於いて、破線4920は、ピクセル領域4902の最小輝度値/アルファ値がゼロであることを示しているが、これは、そのピクセルの最初の2つのサブピクセルソース画像ウインドウが輝度値「ゼロ」を有しているからである。このように、図48に図示されたステップは、ピクセル4912の赤、緑、青のサブピクセル領域に対して輝度値/アルファ値をゼロに設定する。同様にして、ピクセル領域4904の最小輝度値は、ピクセル4904の赤色サブピクセルソース画像ウインドウ4922の値によって決定される。この最小輝度値は、同図の下半分に図示された対応するピクセル領域4914にマッピングされる。同様に、ピクセル領域4906及び4908の最小輝度値は、図48の下半分に図示されたピクセル領域4916及び4918にマッピングされる。このステップの完了後に生じる部分的に計算された輝度値/アルファ値は、図48の最下部のRGBグリッドパターン4910によって表されている。
非線形カラーバランス法の第2段階は、図49に図示されている。第2段階に関するこの例では、関連するピクセルの最小輝度値/アルファ値を超える各サブピクセルの輝度値/アルファ値の一部は、図46及び47に関して上述された種類のカラーバランス分配フィルタを利用することによって、RGBグリッドパターン4910にマッピングされている。
図49の最上部のピクセルグリッド5000は、対応するピクセルに対する最小サブピクセル輝度値/アルファ値の値(低密度の斜線で示す)が除かれた後に残存する各サブピクセルの輝度値/アルファ値(高密度の斜線で示す)の部分が表現されている点を除いて、図48の最上部のピクセルグリッド4900に対応する(そして、同一サブピクセル4740乃至4762を有する)。
図49に於いては、高密度の斜線を有する図49の最上部に図示されたサブピクセル輝度値/カバレッジ値の超過部分のみが、図46に図示された種類のカラーバランスフィルタを使用して分配されるという点を除いて、 図49の中央に位置するサブピクセルグリッド5002は、図47の中央に位置する類似の形状のピクセルグリッド4802に対応している。
同図のこの部分から判る通り、各サブピクセルに対する超過分の輝度値/アルファ値は、図46に図示された同一の比率のフィルタを使用して、そのサブピクセル自身、左側の2つのサブピクセル、及び、右側の2つのサブピクセルに分配される。図49の最下部近傍の数字5004が付与された部分は、非線形法に関するこの例に於いて、サブピクセル4740乃至4762のそれぞれに分配される輝度値/アルファ値のそうした超過分の合計を図示している。
図49の最下部に図示したように、出力画像に於ける各サブピクセルに対して使用される輝度値/アルファ値の合計を生成するために、各サブピクセルに対して計算された輝度値/アルファ値の超過分の合計は、図48に図示されたステップによって以前にそのサブピクセルに加算された最小輝度値/アルファ値に加算される。非線形カラーバランス処理を完了するために、RGBグリッドパターン4910の各サブピクセルに対して合計された輝度値/アルファ値は、それが関連付けられたピクセルの赤、緑、青のカラーコンポーネント値を決定するために使用される。そうした表示に於ける個々の各ピクセルの赤、緑、青の色値は等しくない可能性があるが、ピクセル行の5つ分程度隣接するサブピクセルの任意の近傍における赤、緑、青の色値の合計は、実質的に等しい、又は、バランスが取れているはずだ。
線形及び非線形カラーバランスフィルタリング法の使用により達成された結果の比較は、図50、51、52に図示されている。
図50は、図46のRGBグリッドパターン4700、及び、図48のRGBグリッドパターン4900に最初にマッピングされたように、元々のフィルタ処理されているソースピクセル輝度値/カバレッジ値を図示している。
図51は、図49の最下部に図示されているように、非線形フィルタリング法の結果を示している。
図52は、図47のRGBグリッドパターン4804に図示されているように、線形フィルタリング法の結果を示している。
図51が示すように、非線形カラーバランス法の出力は、図52に示されている線形法の結果よりも、図50の輝度値/アルファ値に関する元々の空間分布によく似ている。図51の非線形法によって生成された輝度値は、かなり不鮮明度が低く、これにより、線形法で生成された出力よりもより高度で可視的な空間解像度を提供する。これは、比線形法が空間解像度をぼかす有害な結果を有するカラーバランス分配を実行しようとしており、カラーアンバランスを防止するためにそうした分配を必要とする、サブピクセル輝度値/カバレッジ値のそうした部分に対してのみ実行しようとしているからである。これは、図49の数字5004で示されるような、非線形方法を使用して各サブピクセルに分配されたサブピクセル輝度値/カバレッジ値の合計と、図47の最下部の各サブピクセルに対して図示されたクロスハッチ模様の領域全体で示されるような、線形法を使用して各サブピクセルに分配された対応する合計とを比較することで理解できる。
図53は、非線形カラーバランス法を使用して、ビットマップソース画像からサブピクセル最適化された2色出力ビットマップを生成する方法の一実施例を、高度に簡略化した擬似コード記述で表したものである。
同図に於けるアルゴリズム5300は、画像の各ピクセル行に対して実行されるループ5301で構成されている。このループは、各ピクセル行に対して、2つのサブループ5302及び5322を実行する。
ループ5302は、ループ5391の現在の行に於ける各ピクセルに対して実行される。そうした各ピクセルに対して、ループ5302はループ5304、関数5314、及び、ループ5316を実行する。
ループ5304は、ループ5302の現在のピクセルに於ける各サブピクセルに対して実行される。そうした各サブピクセルに対して、ループ5304は、関数5306及びループ5308を実行する。
関数5306は、ソース画像の何れかのピクセルが、拡大縮小された画像に於けるサブピクセルの領域に対応するソース画像のウインドウ内に位置するかを決定する。これは、図17乃至44に関して上述したものを含む、任意の周知のカバレッジ計算及び推定関数によって実行することが可能である。
関数5310及び5312で構成されるループ5308は、現在のサブピクセルのソース画像ウインドウ内に全体的又は部分的に含まれる各ソース画像ピクセルに対して実行される。関数5310は、ソース画像ピクセルの領域によって覆われたソース画像ウインドウの領域の割合を計算する。関数5312は、ソース画像ピクセルによって覆われたウインドウ領域の割合の倍数と、ソース画像ピクセルの平均前景色強度との乗算を、現在のサブピクセルに対して計算された輝度値/カバレッジ値に加える。
2色画像がグレースケール画像である場合には、前景色強度(上記に於いて、多くの場合、輝度、又は輝度値/カバレッジ値、と称した)は、白又は黒のそれぞれが前景色であるかに応じて、全ソース画像ピクセルのそれぞれに関する一般に輝度と称されるものか、一般に輝度と称されるものの逆数の何れかに対応することが可能である。ソース画像が多色画像である場合、関数5312の目的のために前景色強度の計算する際に、ソース画像ピクセルに対して使用可能な輝度値を決定するために、各ソース画像ピクセルのカラーコンポーネントの平均輝度値を使用することが出来る。
図46に図示された種類の輝度値/カバレッジ値を決定するために、ループ5304を使用することが出来る。
ループ5304が現在のピクセルに於ける各サブピクセルに対して実行される時点で、関数5314は、図48の上半分に図示されているように、現在のピクセル対して計算された最小のサブピクセル輝度値/カバレッジ値を求める。
これが実行された時点で、関数5318及び5320で構成されるループ5316は、現在のピクセルに於ける各サブピクセルに対して実行される。
図48の下半分に図示されているように、関数5318は、サブピクセルに対して計算されている輝度値/アルファ値を、関数5314によって当該ピクセルに対して決定された最小のサブピクセル輝度値/カバレッジ値に設定する。
図49に示されているように、関数5320は、ピクセルの最小のサブピクセル輝度値/カバレッジ値を超過する、サブピクセル輝度カバレッジ値の一部を、カラーバランス分配フィルタを使用して現在のピクセル行に於けるサブピクセル及び近傍のサブピクセルに対して計算されている輝度値/アルファ値に分配する。
本発明の一実施形態に於いて、所定のサブピクセルに対して実行されたそうした分配の合計が、最大限に許容された輝度値/出力値を超える場合、サブピクセルの輝度値/アルファ値はその最大値に制限される。こうしたクリッピングによって何らかのカラーアンバランスが生じる可能性があるが、本発明者には、結果として生じるアンバランスが殆ど注目に値しないものであることが判っている。
輝度値/アルファ値が当該行の各サブピクセルに対して計算され、ループ5302が完了した時点で、ループ5322によって、関数5324が当該行の各ピクセルに対して実行される。この関数は、ピクセル色値を、ピクセルの赤、緑、青のサブピクセルのそれぞれに対して計算された輝度値/アルファ値に対応する赤、緑、青のコンポーネント値を備えた複合RGB値を有する色に等しくなるように設定する
図54は、ソース画像から生成されたサブピクセル最適化された画像が、多色サブピクセル最適化処理又は2色サブピクセル最適化処理によって生成される範囲に於けるトレードオフを、表示装置のユーザが動的に実行可能な本発明の1つの特徴を図示している。この例に於ける2色サブピクセル最適化によって、グレースケール出力画像のみを生成可能である一方で、多色サブピクセル最適化により生成された出力画像によって、妥当な色の精度で縮小カラー画像を表現可能である。しかし、場合によっては、そうしたグレースケール出力画像は、多色サブピクセル最適化によって生成された出力画像に比して、より精度の高い空間解像度を有し、特にソース画像がくっきりとした縁部を備えた白色部分及び黒色部分を有する場合には、知覚し難いカラーアンバランスを有する。
拡大/縮小、及び、サブピクセル最適化されたグレースケールビットマップ5440を生成するために、例えば図42乃至53に関して上述された一例など、2色サブピクセル最適化法を使用する関数5410及び5430を利用することによって、カラービットマップ画像5400を拡大/縮小、及び、サブピクセル最適化することが出来る。拡大/縮小、及び、サブピクセル最適化されたカラービットマップ5450を生成するために、図17乃至41に関して上述された一例など、多色サブピクセル最適化法を使用するプロセス5420によって、カラービットマップ5400を拡大/縮小、及び、サブピクセル最適化することも可能である。
図54に図示された本発明の実施形態によれば、表示装置のユーザは、カラービットマップ5450及びグレースケールビットマップ5440の混合を実現するために、関数5460を使用して、例えばポインティングデバイス、キーボード、又は、他の入力装置など、表示装置の制御装置を操作することが可能である。例えば、スライドバーの操作によってこれを実行することが出来る。関数5480は、グレースケールビットマップ5440及びカラービットマップ5450と、ユーザが選択したカラー/グレースケールトレードオフ情報を受け付け、ユーザが選択したカラー/グレースケールトレードオフ5460の関数として、各々の色値に重み付けをして、グレースケールビットマップ5440及びカラービットマップ5450からの対応するピクセルの色値を混合する。
図54に図示された種類の幾つかの実施形態に於いて、ユーザがカラー/グレースケールスペクトルの何れかの極限でトレードオフ値を選択する場合、この処理によって、選択された極限に対応するビットマップ5440又は5450を計算するだけで、演算処理を低減することが出来る。
本発明の該特徴に関する利点は、カラーバランス、及び/又は、位置的精度が最重要である場合、又は、それがより容易に読み取り可能な表示を求めるためにトレードオフ選択を単純に変化させる場合に、それが最重要であるか、色に正確であれば、表示装置のユーザがそれを支持することが出来るという点にある。
本発明の全ての特徴がサブピクセル最適化されたテキストを必要とする訳ではなく、そうするものの多くは、サブピクセル最適化されたフォントのフォント形状を生成する従来技術の方法を使用することが出来る。しかしながら、本発明の幾つかの特徴は、サブピクセル最適化されたフォントビットマップを生成するための改良された方法に関する。
図55乃至97は、サブピクセル最適化されたフォントビットマップの形成及び使用に関連する本発明の特徴に関する。
図55は、フォントアウトライン5500を図示しており、この例では、タイムズローマンフォントの大文字「B」のアウトラインを図示している。このアウトラインは、それぞれが赤、青、緑のサブピクセル5506、5508、5510をそれぞれ含む個々の全ピクセル5504を複数用いて構成されるサブピクセルグリッド5502上に重ねて表示されている。
図55に図示されたフォントアウトラインは、比較的通常のテキストサイズでの表示に使用可能なアウトラインであり、本発明者のサブピクセル最適化文字フォント形状の方法が、広範囲のアプリケーションで適用可能であり、図11の最下部に図示された種類の小型スクリーン表示に限定されないことを示している。しかしながら、本発明のこの特徴が小型スクリーン表示、及び/又は、極めて小さいピクセルサイズでのフォントの表示に適用される場合、例えば、幾つかの実施形態では10ピクセル/emまたはそれ未満のサイズで、そして、他の実施形態では8ピクセル/emまたはそれ未満のサイズで、使用されるフォントを小さなサイズで表示するために最適化することが望ましい。
図56は、サブピクセルアドレス可能スクリーン上に於けるそうした小型表示のために最適化されたフォントを図示したものである。図57は、同一ビットマップを2倍のサイズで図示している。残念ながら、図56及び57に図示されたビットマップの印刷物は、全ピクセルの平均輝度を表示しており、そうしたビットマップがサブピクセルアドレス可能表示上に表示された際に可能となる、より高い解像度を獲得することが出来ていない。
図56及び57に図示されたフォントは、選択された個々のフォントアウトライン境界を、ピクセル境界、サブピクセル境界、及び、サブピクセル境界間の水平及び垂直次元の中間に変更するヒンティング処理によって生成されている。そうした高解像度ヒンティングは、サブピクセル表示上で最適な可読性を達成するために使用される。文字がそうした小型フォントサイズで表示される際に、文字が可能な限り鮮明であるとユーザが比較的満足感を覚えるまで、フォントデザイナーに様々なヒンティング値を用いて個々の文字のサブピクセル最適化ビットマップを見させることによって、これを実行する。そうしたフォントヒンティングの有識者が理解しているように、フォントは、そのフォントの全てのサイズのレンダリングを越えてフォントアウトラインの個々の部分の配置を命令するヒントと、特定のピクセルサイズで文字フォント形状に適用される特別ヒントを有することが出来る。図56及び57に図示されたフォントは、8ピクセル/emでのそれらの表示を最適化するようにヒンティングされており、それらの幾つかは、そうした小さなサイズでのみ適用される特定のヒントを有している。
実際、本出願の同図に図示された、320×240ピクセル解像度のスクリーンショットに於ける殆どのフォントは、そのサイズで表示するために特別にヒンティングされた8ピクセル/emのフォントである。比較的高水準の可読性が可能となる一方で、これらのフォントによって、比較的大量のウェブテキストは小型スクリーン上に適合可能である。これらのフォントによって、ラテンアルファベットの小文字の大多数を、隣接する文字同士を隔てるスペースが在ればそれを含んで、4ピクセルコラム又はそれ未満で表示することが出来る。これらのフォントによって、大文字の大部分は5ピクセルコラム又はそれ未満で表示することが出来る。
そうした小さなフォントの可読性は、サブピクセル最適化、又は、アンチエイリアスの何れかを使用することによって大幅に向上されるのであるが、これは、これらの技術によって、文字形状が所定のピクセルを覆う程度に関する情報が、全ピクセルレベルでの2進法表示以上の方法で表現可能であるからである。実際、サブピクセル最適化はアンチエイリアスの一種であるが、これは、従来のアンチエイリアスと同様に、サブピクセル最適化によって、フォント形状により部分的に覆われたピクセルが、そうしたカバレッジの程度に関する関数に比例する色値を有するからである。
図58及び59は、本発明によって生成されたサブピクセル最適化ビットマップを、フォントアウトライン、及び/又は、フォントビットマップとして表現することが可能であるということを図示している。フォントアウトライン記述5802は、好ましくは、文字アウトラインの境界を1つ又は複数の異なるフォントサイズで最適に配置するように設計されたヒンティング情報と共に、所定のフォントの1つ又は複数の文字の形状に関する数学的幾何学的記述を含んでいる。これらのフォントアウトラインは、例えばここで議論されたような、サブピクセルアドレス可能表示上で最適にレンダリングされるように設計され、及び/又は、サブピクセルアドレス可能表示上で表示するために最適化されているヒンティングを有するものであっても良い。
以下に記述されるように、フォントレンダラ5806をそうしたアウトラインからサブピクセル最適化ビットマップ5804を生成するために使用することが出来る。
本発明の幾つかの実施形態に於いて、図58に図示されているように、コンピュータ5808、及び/又は、そのコンピュータ上で実行するアプリケーションは、フォントサーバ5812からコンピュータネットワーク5814を介してアクセスされたフォントビットマップ又はフォントアウトラインを使用して、テキストを表示する。他の実施形態に於いて、図59に図示されているように、コンピュータ5900、及び/又は、そのコンピュータ上で実行されるアプリケーション5902は、それらの中に保存されたテキストをレンダリングするために必要なフォントビットマップ5804を有している。そうしたコンピュータ、及び/又は、アプリケーションは、フォントビットマップのみを保持可能であるか、又は、それらは拡大/縮小可能なフォントアウトライン5802を保存し、異なるサイズで随時フォントビットマップ5804をレンダリングすることが出来る。
フォントビットマップのみを保存する利点は、コンピュータ5900上にフォントアウトライン及びフォントレンダラを保存する必要性がなくなる点にある。また、それによりフォントレンダリングに関わる演算も必要性なくなる。さらに、多くのフォント業者は、フォントビットマップが比較的自由にインターネット上で使用可能になり、その後フォントアウトラインも使用可能になることをさらに望んでいる。
フォントアウトラインを保存する利点は、ユーザが各種サイズでフォントをレンダリングすることに関心を持っている場合、全ての異なるサイズの文字に対してフォントビットマップを保存することに比して、フォントレンダラに必要なコードを保存することと、拡大/縮小可能なフォントアウトライン記述を保存することの方が、実際には効率的であるという点にある。
図58に図示されているように、フォントサーバからフォントを受信する利点は、それによって、クライアントコンピュータ5808が、例えば図58に表現されているように、大容量のフォントライブラリを保存する必要なく、随時そうしたフォントをダウンロードすることによって、多数の異なるフォント及びサイズの任意のもので、テキストを表現することが可能であるという点にある。クライアントコンピュータ5808は、文字列を表示しようとする度にネットワーク5814を介して通信する必要がないように、妥当な数の文字フォントビットマップをキャッシュすることが望ましい。
図60は、サブピクセル最適化フォントビットマップの生成に関する本発明の特徴に関する幾つかの実施形態で使用されたアルゴリズム600の高度に簡略化された擬似コード記述である。このアルゴリズムは、図48及び49に関して上述された種類の非線形カラーバランスを使用している。そうしたサブピクセル最適化アルゴリズムは、テキスト文字の表示に使用する際に特に最適であるが、これは、全ピクセル境界を有するテキストアウトライン境界の配置が、ヒンティングの使用のために、ラスタ化されたフォント形状に於いて極めて一般的であるからである。
図60のアルゴリズム6000は、所定のピクセル解像度での個々の文字フォント形状のラスタ化に於いて、各ピクセル行に対して実行されるループ6002を含んでいる。このループ6002は、各ピクセル行に対して順次実行される3つのサブループ6004、6008、6020で構成されている。
ループ6004は、ループ6002の現在の繰り返しが実行されているピクセル行に於ける各サブピクセルに対して実行される。そうした各サブピクセルに対して、ループ6004は、画像が生成されている文字フォント形状によって覆われるサブピクセルの領域の割合に関する関数として、そうした各サブピクセルに対するカバレッジ値を決定する、関数6006を実行する。
図61乃至90は、図60のステップ6006における各サブピクセルのカバレッジ値を決定するために使用可能な方法を議論するために使用される。
図61、62、63に示されているように、そうしたカバレッジ値が所定のピクセル5504に対して計算される、文字フォント形状の画像に於ける領域は、赤、緑、青のサブピクセル5506、5508、5510によってそれぞれ表示される画像の領域に対応している。これは、上記図14乃至16に於いて示されているように、通常、各サブピクセルに対応するソース画像ウインドウがより大きいサブピクセル最適化された多色画像の場合とは異なっている。図60の方法で使用されたソース画像ウインドウは、図42乃至44に関して上述された2色ビットマップに使用されたソース画像ウインドウの領域と同一サイズを有する。
そうしたより高い解像度のソース画像ウインドウを使用可能であるのは、殆どのフォントアウトライン記述によって記述された文字フォントの形状は、前景色(殆どの場合、アルファ値「1」で表現される)に関連していると見なされるフォントアウトラインと、背景色(殆どの場合、アルファ値「0」で表現される)に関連している画像の全ての他部分とに覆われた領域を備えた2色画像であるからである。
図60の関数6006に於けるカバレッジ値の計算は、図55に図示されたグリッド5502のサブピクセルの解像度と同一の空間解像度を有するピクセル配列に関連して、文字フォントアウトラインをラスタ化可能な任意の従来技術の方法を使用して実行することが出来る。
図64乃至67は、フォント形状6402によって覆われたラスタ化グリッドに於けるユニットの割合を計算するために使用されている従来の方法の幾つかを図示している。この従来技術に於いて、ラスタ化ユニット6400は、通常、出力画像に於ける全ピクセルに対応している。図60の方法に於いては、それは出力画像のサブピクセルに対応している。
図64は、フォント形状6402によって覆われたユニットの領域を正確に計算するための数学的技術を使用するラスタ化ユニット6400のカバレッジ値を決定するための一方法を図示している。これは比較的コンピュータの費用がかかるので、かつて殆ど使用されたことはない。
実質的によりコンピュータを効果的に使用出来る方法は図65に記載されており、この方法は、フォント形状の境界に関する区分的線形近似6504を使用することによって、フォント形状6402で覆われたラスタ化ユニット6400の割合を計算する。
図66は、実質的により制度の低い結果を生み出しているが、さらにコンピュータを効果的に使用できる方法を図示している。この方法により、サンプルポイント6600一式がどの程度の割合でフォント形状6402内に収まるかを決定することによって、ラスタ化ユニット6400のカバレッジ値の割合が決定される。
図67は、図66の方法と同一の、比較的低度の演算処理に対してより正確な結果を提供するカバレッジ値を決定する方法を図示している。それは、フォント形状6402によって覆われた多数のスキャンライン6700及び6702の平均的な割合に関する関数として、ラスタ化ユニットのカバレッジを決定する。
図68乃至87は、ラスタ化ユニットのカバレッジ値を計算する、コンピュータを極めて効果的に使用可能な方法を図示しており、該方法は、例えば同一量の演算処理に対して図66に図示された方法など、サンプリング法に比して一般的に良い結果を生む。
この方法に関する一実施形態は、本発明の発明者の一人、サンポ・ジェイ・カーシラの名義で出願された米国特許出願に於いて、より詳細に記載されている。この米国特許出願は、出願番号09/363,513である。該米国特許出願は、1999年7月29日に出願され、名称は「Systems For Rapidly Performing Scan Conversion With Anti−Aliasing Upon Outline Fonts And Other Graphic Elements」である。この出願は、2002年8月20日付けで、米国特許第6,437,793号として特許が発行された。また、この出願は、PCT出願「PCT/US00/21559」で公開された発明の開示を有している。この出願及び該出願から取得された特許は、それらの全文を参照することにより本書に組み込まれる。
図68乃至87の方法に於いて、ラスタ化ユニットに対するカバレッジ値は、フォントアウトラインの形状6402によって覆われる2本のスキャンライン、即ち、水平スキャンライン6804又は垂直スキャンライン6802の1本の割合によって決定される。カバレッジ値がラスタ化ユニットに対するカバレッジ値として使用されるスキャンラインは、より中間的なカバレッジ値を有するスキャンラインである。例えば、水平及び垂直スキャンラインのカバレッジが0〜126の値の範囲で計算される実施形態に於いて、選択されるスキャンラインは、50%のカバレッジを示す、値が63に最も近いスキャンラインである。
図68乃至71に於いて、ラスタ化ユニット6400のカバレッジの割合を表すために使用されるのは、垂直スキャンライン6802のカバレッジの割合である。図72乃至75に於いて、最も中間に近い値を有するのは水平スキャンライン6804であり、それ故、それは全ラスタ化ユニットに関する実際のカバレッジの割合を表現するのに使用されるかバレー時の割合を有している。
図76乃至87の残り全てに於いて、より中間に近いカバレッジ値を有するスキャンラインのカバレッジ値は、通常、全ラスタ化ユニットに対する実際のカバレッジ値に非常に近く、それは、通常、全ラスタ化ユニットに関する実際のカバレッジ値から25%以上は決して変化しないということがわかる。
図88乃至90は、それらのラインカバレッジ値がより多くの中間カバレッジ値を有する関数として、それらの関連するラスタ化ユニットに関する推定されたカバレッジ値に対して、個々のスキャンラインに関するカバレッジ値の寄与を重み付けする方法に従って使用可能な、スキャンラインの他の組み合わせを示している。そうした方法に於いて、全ラスタ化ユニットに対して計算されたカバレッジ値は、各スキャンラインのカバレッジ値の合計と、そのカバレッジラインの中間とを乗算し、各スキャンラインの中間の合計で除算したものに等しく設定することが出来る。この計算では、スキャンラインの中間は、スキャンラインの真ん中の取り得る割合のカバレッジ値から、真ん中の割合のカバレッジ値とスキャンラインの実際の割合のカバレッジ値との差の絶対値を減算したものに等しい。
図91は、ピクセル5504の行9100の赤、緑、青色のサブピクセル5506、5508、5510のそれぞれに対してマッピングされた、仮想フォントアウトライン9102を図示している。
図92は、行9100におけるサブピクセルのそれぞれに対して計算されている、対応するカバレッジ値9202を図示している。
図93は、個々のサブピクセルに対して決定されたカバレッジ値が、線形カラーバランス法を使用して、どのように分配することが可能かを図示している。ビットマップソース画像のサブピクセル最適化表示というよりは、フォントアウトラインのサブピクセル最適化表示に適応されている点を除いて、該線形カラーバランスは、図46に関して上述したものと同一である。
ここで再び図60を簡単に参照すると、同図のステップ6006が1行の各サブピクセルに対するカバレッジ値を計算又は推定した時点で、図92に示されているように、ループ6008がその行における各ピクセルに対して実行される。このループ色は、1行のサブピクセルに対して計算されたカバレッジ値のバランスをとる。それは、図93に図示され、図46及び47に関して上述された種類の線形カラーバランスルーチンを使用しない。その代わりに、それは、図48乃至53に関して上述された技術に類似した非線形カラーバランス技術を使用することによって、より高度に知覚可能な空間解像度を達成する。
ループ6008は、そうした各ピクセルに対して、2つの関数6010及び6012と、ループ6014を実行する。
関数6010は、現在のピクセルのサブピクセルがそのサブピクセルに対して計算された最小カバレッジ値を有していることを求める。次に、ステップ6012は、この最小カバレッジ値を、現在のピクセルの各サブピクセルに対して計算されている、暫定的なアルファ地、又は、不透明値に加算する。これは、図48に図示された関数に類似している。
次に、ループ6014は、現在のピクセルの各サブピクセルに対して関数6016及び6018を実行する。関数6016は、ループ6014の現在のサブピクセルに対して、サブピクセルが一部を成すピクセルに対して求められた最小カバレッジ値を超える、それに対して計算されたカバレッジ値の超過分を決定する。次に、関数6018は、この超過値を、現在のピクセル行に於ける現在のサブピクセルと、その左側の2つのサブピクセルと、その右側の2つのサブピクセルに対して計算されているサブピクセルアルファ値に分配する。この関数は、図49に関して上述された関数に対応する。
図94及び95は、本発明の一実施形態に於いて使用される、2つの異なるカラーバランス分配フィルタを図示している。この実施形態に於いて、図94に図示された非対称中央部重点カラーバランスフィルタが、赤色及び緑色のサブピクセルに関連付けられたカバレッジ値を分配するために使用される。一方、図95に図示された非対称カラーバランスフィルタは、青色のサブピクセルに関連付けられたカバレッジ値を分配するために使用される。それ故、本発明のこの実施形態は、ある色に対して、他の色に対する分配フィルタとは形状が異なる分配フィルタを使用している点で、図49に関して上述された処理とは異なっている。
本出願の発明者の一人は、人間の目では青色に比して緑色を知覚し易いので、異なる色のサブピクセルに関連するカラーバランスカバレッジ値は、そうした異なる分配フィルタを使用するはずだということを発見した。非線形カラーバランス(2色画像に関する非線形カラーバランスを含む)に関連する本発明の異なる実施形態に於いて、異なるカラーバランスフィルタを、各異なるサブピクセル色に対して使用することが可能な、同一カラーバランスフィルタを、そうした色のすべてに対して使用することが可能であり、対称カラーバランスフィルタ、又は、非対称カラーバランスフィルタの何れかを使用することが出来る。
図94及び95に図示された特定のカラーバランスフィルタは、0〜126の尺度で計算されるカバレッジ値を用いて使用するために設計されている。0〜126の値を有する所定の計算されたカバレッジ値は、テーブルの左側にある関連するカバレッジ値が、それ自身のカバレッジ値に最も近い、図94及び95のテーブルの右側にある、5つの分配値から成る分配値一式に関連付けられている。例えば、所定の赤色又は青色のサブピクセルに対して計算されたカバレッジ値が126である場合、所定のサブピクセルの左側2つ、及び、右側2つのサブピクセルに対して計算されているアルファ値に「1」加算され、所定のサブピクセルの左側1つ、及び、右側1つにあるサブピクセルに対して計算されているアルファ値に「3」加算され、所定のサブピクセル自体に対して計算されているアルファ値に「4」加算される。この特定の実施形態では、アルファ値は0〜12のスケールで計算される。
図94及び95の最後の行に図示されたカラーバランス分配の相対的なサイズは、所望の分配比率をより正確に反映している。これは、これらの最後の行のそれぞれに於いて分配されたより大きな値が、最後の行のそれぞれの上方に位置する行で見られるよりも、大きな数値の解像度を許容するからである。
当然のことながら、バランスがとられているカバレッジ値又は輝度値を記述するために、より高い数値精度を使用する幾つかの他の実施形態において、広範囲の輝度で使用されるバランス分配は、図94及び95の最後の行に於いて反映されたそれらの比率にむしろ近い、異なるサブピクセルへの寄与間の比率を有する。このことが特に当てはまるのは、図94、及び/又は、図95に図示された一般的な種類のフィルタが、図48乃至52に関して上述されているように、画像の2色サブピクセル最適化に関するカラーバランスに使用される場合である。これは、ビットマップ画像に関するそうした2色サブピクセル最適化に於いて、サブピクセル最適化されているビットマップに於いて使用されるものに比して、低い解像度で出力画像の輝度を算出することが、一般的に望ましくないからである。
図60のループ6008によって、ステップ6018が1行の各ピクセルの各サブピクセルに対して実行された時点で、そうした各ピクセルは、その3つのサブピクセルのそれぞれに対して計算された別々のアルファ値を有し、そうした各アルファ値は13の不透明度レベルの内、1つを有する。このことは、各ピクセルが異なる2197の取り得る結合アルファ値の内、一つ(即ち、13の2乗)を有することが可能であることを意味する。本発明の他の実施形態に於いては、より高い又はより低い解像度を有するアルファ値を使用することが出来る。
本発明の多くの実施形態に於いて、特に、制限された演算能力を有するコンピュータ上に於いて、又は、フォントビットマップを保存又はダウンロードするために必要な回線容量又は記憶容量を低減することが望ましいシステムに於いて実行するように設計された実施形態に於いては、そうしたカラーバランス後に取り得る異なるサブピクセルアルファ値の2197の組み合わせである比較的大きな色空間から、より小さな色空間にマッピングすることが好ましい。
図60に於ける本発明の実施形態は、ループ6020に於けるそうしたマッピングを実行する。ループ6008が現在の行に於ける各ピクセルに対して実行された時点で、ループ6020はそうした各ピクセルに対してさらなる関数6022を実行する。関数6022は、ピクセルのサブピクセルのそれぞれに対して計算された3つのアルファ値を取得し、それらを、ピクセルの3つのアルファ値の取り得る組み合わせによって定義された2197の取り得る色値のそれぞれから、122の値の内、1つの値にマッピングするルックアップテーブルの入力値として使用する。この実施形態に於いては、色空間はそうした少数の色に低減されている。その結果、256値の色空間を有する機械装置が、そのように制限された色空間の半分以上をその他で利用するために、なお有している一方で、サブピクセル最適化されたフォントの表示に於ける使用のために選択された122の値のそれぞれを表示することが出来る。フォントビットマップを表示するためのそうした小さなカラーパレットを使用することによって、そうしたフォントビットマップを保存するために必要とされるビット数が低減され、ダウンロードするためにより効率的になる。本発明のこの特徴に関する他の実施形態に於いて、そうしたマッピングで使用されるソース及び送信先の色空間は、異なるサイズを有する可能性がある。
図96は、本発明の一実施形態に於いて、そうしたカラーマッピングを生成するために使用されている方法9600を図示している。当然のことながら、他の実施形態に於いては、他の種類のマッピングを使用することが可能である。幾つかの実施形態に於いては、より小さな色空間へのそうしたマッピングを全く必要としない。
図96の方法は、図60乃至95に関して上述した非線形カラーバランスサブピクセル最適化アルゴリズムによって計算される制限された色空間を使用してビットマップが表示される、一つ又は複数のフォントから複数文字を実行するステップ9602で始まる。これが実行される場合、ヒストグラムは、それぞれの取り得る2196の異なる複合ピクセルアルファ値が任意のピクセルに対して計算される回数を保持する。このヒストグラムは有用であるが、これは、サブピクセル最適化ビットマップに於けるピクセルに対して計算された3色のアルファ値の殆どが、2196のそうした3色アルファ値の取り得る色空間全体の様々な小さな領域に集中する傾向があるからである。この集中は恐らく非線形カラーバランスに関してより顕著になるが、これは、それがカラーバランスに起因する輝度分配の量を実質的に低減するからである。
次に関数9604は、関数9606及び9608を実行することによって、この例では122色を有する制限されたカラーパレットを生成する。関数9606は、形成されているパレットの一部として、各サブピクセルが13のアルファレベルの内、1つのレベルを有することが可能な場合、全ピクセルアルファ値に対して取り得る、13のグレースケール値を選択する。次に、関数9608は、以前ステップ9602によって計算されたヒストグラムに於ける最も頻繁に出現する109の他の色を選択する。
制限されたカラーパレットが選択された時点で、ループ9610が2196の取り得る全ピクセルアルファ値のそれぞれに対して実行される。そうしたそれぞれの取り得るアルファ値に対して、条件9612は、その入力色が122色の内の1色と正確に一致するかを確認するためにテストを行う。一致する場合、関数9614は、入力色と、構成されたルックアップテーブルに於けるその同一出力色とを関連付ける。条件9612が満たされない場合、ループ9618及び関数9628は、ループ9610の現在の入力色に対して実行される。
ループ9618は、パレットに於ける122の出力色のそれぞれに対して実行される。それは、マッピングされる入力色の赤のアルファ値とループ9618の現在の出力色との差(ri−ro)が、現在の入力色の緑のアルファ値と現在の出力色に対する緑の出力アルファ値との差(gi−go)と同一符号であるかを確認するためにテストを行う条件9620を有している。また、条件9620は、現在の出力色に関する赤のアルファ値と緑のアルファ値との差(ro−go)が、入力色に関する赤のアルファ値と緑のアルファ値との差(ri−gi)(いくらかの余裕を持たせる為に、取り得る値Xを加算)よりも小さいかを確認するためにテストを行う。入力色と該入力色がマッピングされる出力色間の比較的顕著な差を防止することを目的とした、これら2つの条件が満たされる場合、関数9622乃至9626が実行される。
関数9622は、入力色から出力色までの距離を計算する。関数9624は、その距離が現在のループ9618に於ける入力色までのこれまでで最短距離であるかを確かめるためにテストを行う。関数9624のテストが満たされる場合、ステップ9626はループ9618の現在の出力色を、許容可能な最も近いパレット色として保存する。ループ9618が制限されたパレットの122の出力色のそれぞれに対して実行された後、ステップ9628は、ループ9610の現在の入力色を、ループ9618で計算された許容可能な最も近いパレット色に関連付ける。
ループ9610が、取り得る入力色のそれぞれに対して実行された時点で、それらの入力色のそれぞれは、122出力色の1色にマッピングされる。
図96に図示された特定のカラーマッピングスキームでは、カラーバランスによって生成された非グレースケールピクセルの色値がステップ9608で選択された109の最も頻繁に発生する非グレースケールの色値の内の1つにマッピングされなければ、グレースケールの色値にマッピングされる。一般に、これは全てのビットマップをグレースケールアルファ値で表示する従来のアンチエイリアスと、少なくとも同程度に良好な結果をもたらす。
図97は、図60及び96の方法で生成される種類のフォントビットマップをサブピクセルアドレス可能スクリーン上に表示するために使用されるアルゴリズム9700を図示している。
関数9704と、ループ9706及び9714で構成されたループ9702は、表示される各文字列に対して実行される。
関数9704は、文字列が、その文字列に対する平均背景色値を決定するために描画されるビットマップの矩形に於けるポイント一式をサンプリングする。他の実施形態に於いては、背景色が各文字に対して、又は、各文字の各ピクセルに対して別々に決定されるが、図示された実施形態に於いては、演算処理を節約するために背景色が各文字列に対して1回だけ決定される。
文字列に対する背景色が決定された時点で、ループ9706は、図96に関して上述された122の全ピクセルアルファ値のそれぞれに対して、サブループ9708及び関数9712を実行する。
ループ9708は、3つのサブピクセル色のそれぞれに対して関数9710を実行する。この関数9710は、現在のサブピクセル色に対応する現在の全ピクセルアルファ値のコンポーネントに関する関数として、現在のサブピクセル色に対して輝度値を算出する。
関数9710は、算出している輝度値を、描画される文字列の前景色に於ける現在のサブピクセルの対応する色に関する輝度によって乗算されたサブピクセルのアルファ値に、関数9704によって決定された背景色に於ける現在のサブピクセルの対応する色に関する輝度によって乗算された現在のサブピクセルのアルファ値を減算したものを加えた値に等しく設定する。
このループが3つのサブピクセルのそれぞれに対して実行された時点で、関数9712は、ループ9706の現在の全ピクセルアルファ値を、ループ9708で計算された3つのサブピクセル輝度で構成された全ピクセルの色値にマッピングする。
次に、ループ9714は、サブピクセルアドレス可能な表示上に表示される現在の文字列の各文字に対して、関数9716及びループ9718を実行する。
関数9716は、現在の文字に対するフォントビットマップにアクセスする。次に、ループ9718はそのビットマップの各ピクセルに対して、関数9720及び9722を実行する。関数9720は、文字のフォントビットマップに於ける現在のピクセルに対して示された、ループ9706によって現在の全ピクセルアルファ値にマッピングされている色値を求める。この色値が求められた時点で、関数9722は、サブピクセルアドレス可能表示に於ける対応するピクセルを全ピクセルの色値に設定する。
ループ9718が文字列の各文字の各ピクセルに対して実行された時点で、文字列がサブピクセル最適化法で完全に表示される。
図98乃至101は、画像及びフォントの拡大/縮小、及び、サブピクセル最適化に関する技術が如何にうまくいくかを図示している。図98及び100は、一般的なブラウザプログラムを使用して、640×480ピクセルでレイアウトされ、表示された2つの異なるウェブページの概要を図示している。図99及び101は、それらの画像及びテキストが320×240表示上に適合するように上述した方法で拡大/縮小された後に於ける、同一ウェブページを図示している。残念ながら、320×240ピクセル画像は全ピクセルの平均輝度によって決定されたグレースケール値で印刷されおり、それ故、サブピクセル解像度によって加えられた実際の明瞭さは、これらの画像に於いて示されていない。
図102乃至113は、本発明の一実施形態に於けるプロキシサーバと薄型クライアントコンピュータとの間の相互作用をより詳細に図示している。
図102は、図2に関して上述した種類のプロキシサーバ210及び薄型クライアント200を含むシステムの高度に概略化したブロック図である。
プロキシサーバ210は、完全なウェブブラウザの標準機能を実行するためのプログラム10202を含むブラウザ10200を有している。このプログラムが変更されているのは、ブラウザが薄型クライアントに対するプロキシとして動作するからである。プロキシブラウザが要求されたウェブページのHTML記述10204をネットワーク上で受信する場合、それはそのウェブページの2次元レイアウト10206を生成する。
図103は、表示が図98及び99に図示されたウェブページのHTML記述の一部を図示している。図103に図示された数字10300は、図98及び99に図示されたウェブページの左側コラムに図示されたHTMLに於けるテキスト部分を図示している。数字10302は、同一コラムに図示された単語「Section」を表示するために使用されたビットマップを識別する画像タグを指し示している。
プロキシブラウザコードがウェブページのダウンロードを受信する場合、それは仮想レイアウト解像度でウェブページのレイアウト10206を作成しようとする。仮想レイアウト解像度は多くの場合、それがウェブページの全て又は一部を表示しているとプロキシブラウザが見なすウインドウのサイズとなっている仮想スクリーンサイズの幅に対応する。それがウェブページを表示しているとブラウザが見なすウインドウを、仮想スクリーン10208と呼ぶことにする。
図104は、図98及び99に図示されたウェブページのレイアウト10206を図示しており、それは、黒色太線矩形部10208に於いて、そのレイアウトへの仮想スクリーン画面のマッピングを図示している。レイアウト10206に対する図104に図示され仮想スクリーンの位置を前提として、10220は薄型クライアント上に表示された仮想スクリーン画像を図示している。
今日のウェブページの多くは、記載例のシステムに於いて使用された640×480の仮想スクリーン解像度よりも大きな要素を有している。そのレイアウトは、ウェブページのオブジェクトをレイアウトするために必要な最小ピクセル幅、又は、仮想スクリーン幅の何れかの内、何れか大きい方を有する。例えば、今日、多くのウェブページが800ピクセルの最小可能幅の解像度でレイアウトされることは一般的である。この場合、仮想画面はレイアウトよりも小さなピクセル幅を有する。これは、図104に図示された例の場合である。仮想レイアウト幅を前提として、仮想レイアウトの高さは、ウェブページのすべてを表示するために必要な高さである。
図102に図示されたビューウインドウ10210は、薄型クライアントのスクリーン上に実際に表示される仮想スクリーンの一部を表している。図99、101、104に図示されたビューに於いては、ビューウインドウは仮想スクリーンに相当する。
しかし、ユーザが仮想スクリーンの部分上で拡大表示する場合、図102に図示されたズームの倍率制御10216が変化し、ビューウインドウは仮想スクリーンのサブセットにマッピングされる。
図102に図示されたスクロール制御10218によって、ビューウインドウはレイアウトに対応して移動する。ビューウインドウが仮想スクリーン上の現在位置に位置していないレイアウトの部分を含むように移動される場合、仮想スクリーンをスクロールするためにブラウザソフトウェアに命令が送信される。イベント待ち行列10220は、イベント、即ち、薄型クライアント上で受信され、ブラウザによって対応するアクションに対するプロキシサーバにアップロードされているユーザ入力を保存する。薄型クライアントのスクリーン上で発生するイベントは、ビューウインドウを介して仮想スクリーン上の対応する位置にマッピングされ、その後、プロキシブラウザのイベント待ち行列に配置されるので、プロキシブラウザは、あたかもそれが映像出力装置上に直接描画していると見なす仮想スクリーン上の適切な位置で受信されたかのように、そうした入力に対応する。
図102のブラウザプログラム10202は、それが仮想スクリーン上にオブジェクトを描画しているとみなす度に、ダウンロード表示リスト10212に於ける、これに対応する拡大/縮小された位置に、対応する縮小されたオブジェクトを生成するように変更される。
この表示リストは、ネットワーク10222を介して、数字10212Aによって示されるように、表示リストを保存するクライアントコンピュータにダウンロードされる。この表示リストによって参照される縮小された画像10214もダウンロードされる。薄型クライアント上に位置するプログラム10218は、表示リストに含まれる文字列、画像、及び、他の要素を、薄型クライアントスクリーン10221上に表示する。ユーザが薄型クライアントスクリーン上でクリックする場合、薄型クライアントのオペレーティングシステム10222は、薄型クライアントスクリーン上でのそうしたクリック、及び、クリック位置を、イベント待ち行列10224にセットする。薄型クライアント上でローカルに取り扱われるプログラムに関係しないそうした各イベントは、上述の通り、プロキシサーバのイベント待ち行列10220にアップロードされる。
図105A乃至110は、薄型クライアントがプロキシを介してウェブページをブラウズすることが出来るように、これらの相互作用を制御するために設計された、ブラウザ及び薄型クライアントコンピュータ上のプログラム及びデータ構造に関する高度に簡略化された擬似コード記述である。
図105A及び105Bは、薄型クライアントに対するプロキシとして機能することを促進するために使用される、図102に図示されたブラウザのコード10202の一部に関する高度に簡略化された擬似コード表記である。
これらの図で図示された特定の実施形態に於いて、通常使用するために設計された大規模ウェブブラウザは、それがプロキシとして機能するようにパッチ修正されている。当然のことながら、本発明の他の実施形態に於いて、プロキシとしてブラウザを動作させるのに必要な機能を、より密接かつ見事にブラウザのコードに統合することが出来る。さらに他の実施形態では、オペレーティングシステムに於けるコード、又は、オペレーティングシステムの呼び出しに割り込む関数に於けるコードは、薄型クライアントに対するプロキシとして標準ウェブブラウズプログラムを動作させるために使用することが出来る。
図105Aに図示された実施形態に於いて、プロキシブラウザがウェブページに対する薄型クライアントからの要求を受信する場合、ステップ10502及び10504は、その要求を当該要求のURLに示されたサーバコンピュータに伝達する。
ブラウザが図102に関して上述された仮想スクリーン10208の描画又は再描画を完了したという指示を自身のコードから受信する場合、関数10506及び10510は、図106A乃至106Cに図示されたスクリーンキャプチャ及びダウンロードルーチンを呼び出す。
図106A乃至106Cは、スクリーンキャプチャ及びダウンロードルーチン10600に関する高度に簡略化された擬似コード記述である。
このルーチンが、前述の図105Aの関数10510によって呼び出される場合、そのステップ10602は、仮想スクリーン内に全体的又は部分的に適合するウェブページのレイアウトに於ける各要素を描画するためのルーチンがブラウザによって呼び出される、スクリーン再描画をブラウザに対して要求する。図106A乃至106Bのルーチンは、これらの描画呼び出しの各々に含まれる情報を記録し、図102に図示されたダウンロード表示リスト10212を生成するためにこれを使用する。
ブラウザが図106Aの測定文字列ルーチン10606を呼び出す場合、このルーチンによって関数10608乃至10618が実行される。そうした呼び出しは、仮想スクリーンにレイアウトしようとしているテキストのサイズを決定するために、ブラウザによって形成される。図示されていないが、図106A乃至106Bに図示されたスクリーンキャプチャ及びダウンロードルーチンが実行中ではないとしても、これら同一の関数10608乃至10618は、ブラウザが文字列のサイズを測定するために呼び出しを行う際は何時でも実行される。これにより、ウェブページの全ての仮想レイアウトは関数1068乃至10618によって提供されたフォントマトリクスを使用する。
関数10608は、測定文字列呼び出しに於いて特定されたフォントを、異なるフォントファミリー、及び、異なるフォントサイズを有するフォントにマッピングする。このフォント置換は、数字10610乃至10616によって示された3つの事項によって制御される。
事項10610は、測定文字列ルーチンに対する呼び出しに於ける、要求されたフォントサイズの関数として、置換フォントに対するサイズを選択し、表示倍率を選択しようとする。
表示倍率は、ビューウインドウが薄型クライアント上に表示される同一次元に沿った、ビューウインドウ及び解像度に対応する仮想スクリーン1028の一部に関する所定の次元に沿った解像度の比率である。場合によっては、表示倍率は水平及び垂直方向に沿って使用される異なる縮尺比率を表すための異なるコンポーネントを有するが、多くの場合、表示倍率は、水平及び垂直解像度の両方に対して使用される単一縮尺比率で構成される。
記載されている特定の実施形態に於いて、ウェブページのレイアウトが実行される場合、該レイアウトは非ズーム表示倍率に対して実行される。非ズーム表示倍率は、図102のビューウインドウ10210が仮想スクリーン10208と同一サイズである倍率である。その結果、非ズーム表示倍率は、仮想スクリーンが表示されるスクリーンの解像度に対する、仮想スクリーンの解像度の比率と等しい。ウェブページの表示後、ユーザがレイアウトの一部に於いて拡大表示を行う場合、ビューウインドウ10210は仮想スクリーンの下位部分にのみ対応し、表示倍率は レイアウト要素がより大きなサイズで表示される事実を反映させるために、その非ズーム値から変更する。現在の実施形態は、仮想スクリーン全体の表示に対して、テキストのレイアウトを最適化するための非ズーム表示倍率を使用する内容をレイアウトするのだが、これは、このようにしてユーザが一般にレイアウトを見たいと考えているのだということを仮定しているからである。他の実施形態に於いて、仮想レイアウトを非ズーム表示倍率以外の表示倍率に対して最適化することが出来る。
図102に図示された実施形態に於いて、この倍率がズーム/倍率制御10216に保存されている。仮想スクリーンが640×480の解像度を有し、ビューウインドウが仮想スクリーンのサイズに等しく、ビューウインドウが320×240表示の全体に表示される場合、倍率は「2」であり、このことは、ブラウザがその仮想スクリーン上に要素を描画しているとみなす2分の1ピクセル解像度で、薄型クライアントのスクリーン上に要素が描画されることを意味している。
図106Aの事項10612は、事項10610のみによって選択されるフォントの平均ピクセルサイズよりも狭く高いフォントファミリーで、薄型クライアントスクリーン上に表示された場合に小さくなる、全てのフォントサイズを置換する。640×480仮想スクリーンから320×240表示スクリーンに低減する場合、ビットマップ形式とは対照的に、これは文字に於いて表現された殆ど又は全てのウェブページテキストを有することが出来る。この置換が実行されるのは、一つには、本発明の本実施形態を用いて使用されるサブピクセルアドレス可能表示が、垂直方向に於けるサブピクセル解像度に比して、3倍の水平方向に於けるサブピクセル解像度を有するからである。この理由により、文字幅の低減は、文字高の低減に比して、可読性に与える負の影響が少ない。このように、そうしたサブピクセルアドレス可能表示スクリーン上に比較的容易に読み取り可能なテキストの最大量を表示するために、この置換によって、文字幅が表示倍率を超える倍率で効果的に縮小され、そうした文字の高さは、表示倍率未満の倍率で効果的に縮小される。例えば、図56、57、99、101、168、169、172、173、174に図示された小型スクリーン表示のフォントは、そうした方法で拡大/縮小されたフォントによって全て置換されている。
これらの図中のフォントは、8ピクセル/emのピクセルサイズを有している。このフォントに於ける殆どの小文字は、4ピクセルコラム又はそれ未満のアドバンス幅内に適合する。4ピクセル又はそれ未満の幅は、あるとすれば、そうした幅を有する文字の形状の間に発生する間隔を含む。これらの特別なフォントでは、ローマ字の小文字の内、80%を越える小文字がそうしたアドバンス幅内に適合する。これらの文字は、一般に幅よりもかなり高くする、4ピクセル行以上の高さ「x」を有する。一般に、そうした比較的幅の狭いフォントは、幅の広いフォントに比して、所定の可読性レベルで所定の領域内にあるより多くのテキストを表示することが出来る。
数字10614及び10616によって表現された事項は、最小フォントサイズを制限するためにフラグが設定されているか否かを確かめるためにテストを行うが、このテストは、所定のピクセルサイズ未満で薄型クライアントの表示上に表示されるフォントは存在しないはずだということを示している。一般に、このフラグは、小さ過ぎて読むことが出来ないテキストの表示を防止するために設定される。仮想スクリーンサイズを有する表示上に実際に表示される場合、ウェブページテキストを通常、どのように表示するかということに関して、より正確な縮小表現をユーザが見たいと考える際には、それは設定されない。表示倍率が大きい、即ち、テキストサイズに対してそうした最小制限を行うことで、ウェブページのレイアウトの概観を劇的に変化させる場合、そうした要求が特に起こり易い。
大抵の場合、システムが最小フォントサイズを制限している場合、ステップ10614及び10616は、置換フォントサイズが最小ピクセルサイズ未満になることを防止する。本発明の現在の実施形態に於いて、この最小ピクセルサイズは8ピクセル/emである。本実施形態の開発者は、7ピクセル/emでのサブピクセル表示用のヒントフォントを開発し、そうしたフォントが比較的読み易いと考えたのだが、そうした小さなフォントは読み難いというフィードバックを他のユーザから受け付けた。
最小フォントサイズへの制限は、多くの場合、ウェブページの様々なサイズのフォントが実際に表示される相対的なフォントのサイズを実質的に変更する。
本発明の幾つかの実施形態に於いて、全てのウェブテキストは1つのフォントサイズで表示される。殆どのウェブページに於いては、実際に大きなフォントがビットマップによって表現されるので、実際にこの方法は殆どのウェブページで非常にうまくいっている。
測定文字列ルーチンが呼び出されたフォントが何れのフォントファミリーとフォントサイズに置き換わるのかを、関数10608が決定した時点で、その測定が非ズーム表示倍率によって拡大された後に、置換されたフォント及びフォントサイズにおける文字列の個々の文字のサイズを前提として、関数10618がルーチンが呼び出された文字列の文字列測定に戻る。
この値に戻ることによって、ブラウザのレイアウトエンジンは、非ズーム表示倍率、即ち、仮想スクリーンが薄型クライアントスクリーン上に表示される仮想スクリーンの解像度と実際の解像度の比率によって、それらの文字が実際に表示されるピクセルサイズに関連して、拡大/縮小される文字に対するフォントマトリクスを使用するウェブページをレイアウトする。このことは、仮想スクリーンが、そのレイアウトの結果として表示される実際のフォントマトリクスとは異なるフォントマトリクスを使用してレイアウトされていることを意味している。
スクリーンキャプチャ及びダウンロードルーチンが、図106Aの文字列描画ルーチン10620に対する呼び出しを受信する場合、このルーチンによって関数10621及び10624が実行される。
関数10621は、文字列の描画が始まるスクリーン位置を文字列が最終的に表示される薄型クライアントスクリーン上の対応する位置に変換する。この変換は、ビューウインドウ10210、及び、図102に図示された仮想スクリーン10208との間のマッピングを考慮している。このマッピングは、制御10216によって保存された現在のズーム設定と、図102に図示されたスクロール制御10218によって保存された現在のスクロール設定の両方を反映している。
関数10622は、数字10606乃至10618に関して上述された、測定文字列ルーチンに対する以前の呼び出しによる、文字列に関連付けられた置換されたフォントファミリー及びサイズと、現在の文字列を表示するために要求された任意の他の属性とが、そうしたフォント属性に対する現在の値と異なるかどうかを確認するためにテストを行う。そうした各フォント属性に対する現在の値は、図102に図示されたダウンロード表示リスト10212に既に記録されたフォントコマンドによって定義された、そうした各属性に対する最後の値によって決定される。そうした相違が発見される場合、関数10623は、そうしたフォント属性を現在の文字列の表示に適した属性に変更する表示リストの現在の最後に、フォントコマンドを保存する。
関数10624は、文字列描画ルーチンが呼び出された文字列と、図102に図示された、ダウンロード表示リスト10212の最後に、ステップ10622によって計算され、変換されたスクリーン位置を保存する。図108に関して後述するように、文字列の変換された開始位置とその文字を含む表示リストに於ける文字列コマンドを設定することによって、これを実行する。
スクリーンキャプチャ及びダウンロードルーチンが矩形描画ルーチン10626に対する呼び出しを受信する場合、このルーチンによって関数10628乃至10634が実行される。異なる背景色を有するウェブページの領域を生成するだけでなく、テキストの下線、又は、ウェブページのレイアウトの別々の部分の間の境界として使用可能な水平及び垂直ラインを描画するために、通常、ブラウザが矩形描画コマンドを呼び出す。
関数10628は、呼び出しに含まれた幾何学的な値を、対応する矩形が薄型クライアントの表示上に描画される、対応する幾何学的な値に変換する。これは、矩形の開始スクリーン位置、矩形の幅、及び、矩形の高さを変換することを含む。
関数10630は、矩形の色が、表示リストに於ける現在(即ち、最後)の矩形色と異なるかどうかを確認するためにテストを行う。異なる場合、関数10632は、現在の背景色を矩形描画ルーチンに対する現在の呼び出しに於いて指定された色に変更する表示リストの最後に背景色コマンドを追加する。
次に、関数10634は、矩形と、矩形の変換されたスクリーン位置、幅、高さを、矩形コマンドとともに、ダウンロード表示リストの最後に保存する。
スクリーンキャプチャ及びダウンロードルーチンが、図106Bに図示されたビットマップ描画ルーチン10636に対する呼び出しを受信する場合、このルーチンによって、関数10638乃至10670が実行される。図形、フォントの図形、バナー広告、及び、ホットゾーン及びページの他のグラフィカルユーザインターフェース(GUI)ビットマップに関連した画像を表示するために、ブラウザはビットマップ画像ルーチンを呼び出す。
幾つかの実施形態に於いて、ウェブページを表示するために必要な回線容量を低減するために、所定のアニメーションに関する第1スクリーンのみがダウンロード表示リストに取り込まれ、記録される。他の実施形態に於いては、特に、より高度な回線容量リンクに対してそうした制約を適用する必要はない。
図106A乃至106Cに関して上述された本発明の実施形態に於いては、特定のグラフィカルユーザインターフェース(GUI)に関連付けられたビットマップ描画が無視されるが、これは、薄型クライアントのプログラムがそうした制御に対してサブピクセル最適化され、縮小されたビットマップを保存するからである。
ステップ10638は、ビットマップ描画ルーチンが呼び出された画像のURLが、ダウンロード表示リストにおいて参照された画像のそれぞれを含むダウンロード画像リスト(図示せず)に既に存在するかどうかを確かめるためにテストを行う。存在しない場合、要求されたビットマップは、まだ現在のダウンロードに対して処理されておらず、関数10642乃至10662をそれに対して実行する必要はない。
関数10642は、ビットマップがカラービットマップかどうかを確かめるためにテストを行う。カラービットマップの場合、関数10642によって、関数10644乃至10654が実行される。関数10644は、それぞれが単一の2色スペクトルからの色のみを含む別々の処理を正当化するために、十分なサイズの1つ又は複数の個々の領域に対してカラー画像をスキャンする。2色スペクトルは、RGBカラーキューブにおけるラインにある色一式に対応する(即ち、赤、緑、青の値によって定義されたカラーキューブは、3つの主要な次元のそれぞれに分布している)。
個々の処理を正当化するには十分大きいと思われる画像の2色部分のそれぞれに対して、関数10646によって、関数10648及び10650が実行される。関数10648は、画像の現在の部分に於いて、その前景色及び背景色として、その2色スペクトルの最も極端な端部を使用し、それが画像のその部分を縮小する程度を決定するための現在の表示倍率を使用して、図42乃至53に関して上述した種類の2色サブピクセル最適化を実行する。下記の数段落に記載されたステップ10654及び10658に於いて実行されるサブピクセル最適化は、プロキシブラウザの仮想レイアウトに於ける画像の解像度と、薄型クライアントのスクリーン上に表示される解像度との比率である表示倍率によって画像を縮小する。
このサブピクセル最適化が実行された後、関数10650は、前景色が色彩的にあまりにもアンバランスであるかどうかを決定する。即ち、それが純粋な赤、緑、又は、青に近いということである。この場合、そうした色の純粋さによって、それがカラー画像の空間解像度を表示可能な精度が低減される。この場合、グレースケール値により似通った対応する色によって、前景色を置換することが可能であり、それ故、より正確な空間解像度を可能にする。
本発明の幾つかの実施形態に於いて、そうした前景色の置換は使用されないが、これは、それによってカラー画像の色のバランスが乱されるからである。一般に、前景色がカラー画像全体のかなりの部分に現れていない限り、そうした前景色の置換を使用しない方が良い。小型フォント又は他の形状が最適化されているビットマップ画像によって表現されている場合、そうした色の置換が最もうまくいく。 本発明の他の実施形態に於いて、2色画像に関連付けられた背景色を変更することが出来る。しかし、ウェブページ上で画像の背景色を変更することは、多くの場合勧めることは出来ない。
現在の画像の非2色部分のそれぞれに対して、関数10652によって、ステップ10654は、現在の表示倍率でビットマップのその部分に於いて、図14乃至41に関して上記した種類の多色サブピクセル最適化を実行する。
ビットマップ描画ルーチンが呼び出されたビットマップが、グレースケールビットマップである場合、関数10656によって、ステップ10658は、現在の表示倍率で前景色及び背景色として黒及び白を使用するビットマップ上で、2色サブピクセル最適化を実行する。
関数10662は、縮小され、サブピクセル最適化されたビットマップを、固有の画像ID、そのURL、及び、拡大/縮小された幅と高さとともに、画像リストの最後に保存する。
ビットマップ描画ルーチンが呼び出された画像が予め画像リストに存在したか否かに関わらず、プログラムが関数10664まで進む時までには、それはそのリストに存在し、ID番号、及び、変換された幅及び高さが割り当てられている。この時、関数10664は、ビットマップ描画ルーチンが画像に対して呼び出されたスクリーン位置を、薄型クライアントのスクリーンに適用可能な位置に変換し、次に、画像の画像ID、その変換されたスクリーン位置、及び、ダウンロード表示リストの最後にあるその変換された幅及び高さを有する、図108に図示された種類の画像位置コマンドを保存する。
本発明の幾つかの実施形態に於いて、全てのビットマップ画像は、多色サブピクセル最適化ルーチンを使用して、サブピクセル最適化されている。他の実施形態に於いては、グレースケールビットマップのみが任意の2色サブピクセル最適化処理を受ける。
本発明の幾つかの実施形態に於いて、ベクトル記述によって定義された形状に対してサブピクセル最適化を実行することによって、ベクトル画像を処理することが出来る。そうした幾つかの実施形態に於いて、サブピクセル最適化がプロキシ上で実行されるが、他の実施形態に於いては、薄型クライアント上で実行される。ベクトル、又は幾何学的に定義された描画の利点の1つは、それらの記述によって画像を表現することが可能であるという簡潔さにある。このように、薄型クライアントに対する回線容量が第一の制限である場合、画像に関するベクトル記述をダウンロードし、その後、薄型クライアントにサブピクセル最適化を使用してそれらをレンダリングさせることはあり得ることである。
幾つかの実施形態に於いて、画像に対して画像認識を実行し、その後、認識された画像を記号表記で薄型クライアントにダウンロードすることが可能である。例えば、多くのウェブページに於いて大きなテキストをビットマップで表示することが一般的である。そうしたビットマップ上で光学的文字認識を実行することができ、該当する文字及びそれらのフォント、又は、それらのフォントの近似が、そのページを記述するために必要な回線容量を低減するために、薄型クライアントに記号的にダウンロードされる。
スクリーンキャプチャ及びダウンロードルーチンが、例えば、ラジオボタン、チェックボックス、テキストフィールド、又は、ブラウザからのボタンなど、制御オブジェクトを生成するルーチンに対する呼び出しを受信する場合、図106Cに図示された制御生成ルーチン10666によって、関数10667乃至10670が実行される。関数10667は、ブラウザが描画される制御を要求したスクリーン位置を、それが薄型クライアントのスクリーンに描画される位置に変換する。図108に図示されているように、関数10668は、対応するテキストラベルを含むダウンロード表示リストに対応する制御生成コマンドをセットし、関数10670は制御オブジェクトの対応するブラウザ側の部分を生成する。
本発明の本実施形態に於いて、薄型クライアントのスクリーンに表示された制御オブジェクトの機能性は、プロキシと薄型クライアントとの間で共有されている。例えば、チェックボックスがチェックされたかどうか、どのラジオボタン一式が押下されたかどうか等の状態情報は、薄型クライアントに保存されている。これにより、ユーザが制御オブジェクトに情報を入力する度に、薄型クライアントからプロキシに通信する必要性が回避される。一般に、クライアントがそうしたサーバへの中継のために、そうした情報をプロキシに送信する必要があるのは、そうした制御に対して保存された情報が、元々ウェブページを生成したリモートサーバコンピュータに送信されることを示す、何らかのボタンをユーザがクリックする場合に限られる。
薄型クライアントにリンクする、より高い回線容量を有する本発明の他の実施形態に於いて、プロキシ上で実行される個々の制御オブジェクトに関連付けられた機能性をより多く、又は、実質的に全て有することによって、薄型クライアントのコードを簡略化することが望ましい。
スクリーンキャプチャ、及び、ダウンロードルーチンが、図106Aの関数10602によって要求されたスクリーン再描画の完了を決定する場合、図106Cの関数10672によって、関数10674が図107に図示されたダウンロード表示リストルーチン10700を呼び出す。
図107に示すように、ダウンロード表示リストルーチンは、ダウンロードストリームで新たな薄型クライアントのスクリーン上に新たに全部又は一部が表示される、ダウンロード表示リストに全ての要素をセットする関数10702を含んでいる。通常、これは、現在のビューウインドウ内で発生するブラウザの仮想スクリーンに於ける任意の要素を含んでいる。しかしながら、以下で説明するように、薄型クライアントのスクリーン上で先のビットマップのかなりの部分を再利用可能なスクロールの場合に於いては、薄型クライアントスクリーンの現在のビットマップの再利用可能な部分に存在しないビューウインドウの部分に於いて、少なくとも部分的に発生する要素のみがダウンロードストリームにセットされる。
本発明の多くの実施形態に於いて、ダウンロード表示リストを生成する図106A乃至106Cの関数は、それがビューウインドウ内に適合しない場合、ダウンロード表示リスト上の要素を入力しない。他の実施形態に於いて、このフィルタリングは関数10702に於いて行われる。
本発明の多くの実施形態に於いて、薄型クライアントスクリーン内に実際に適合するそうした要素の部分のみをダウンロードするために、ダウンロードされる要素が切り取られる。これは、ダウンロードに必要なビット数を低減するという利点を有するが、演算の複雑化を招く。
薄型クライアントスクリーン上に表示されるダウンロード表示リスト上の全ての要素がダウンロードストリームにセットされた時点で、図108に於ける数字項目10818によって示されているように、関数10704は、ダウンロードストリームに於ける対応する画像位置コマンドを有する全ての画像のビットマップを、ダウンロードストリームの最後に設置する。そうしたビットマップをダウンロードストリームの最後にセットする前に、本発明の幾つかの実施形態はそれらに非可逆圧縮を実行する。幾つかの実施形態に於いて、使用されるアルゴリズムは、緑の色値の差異が赤の色値の差異に比してより知覚可能であり、赤の色値の差異が青の色値の差異に比してより知覚可能である事実を考慮したメトリックを使用し、画像中の色値を、RGB色値に於ける視覚的に知覚不能な差異を有する色のクラスタに集合させるアルゴリズムである。
次に関数10705は、可逆圧縮アルゴリズムを使用して、非可逆アルゴリズムによって以前圧縮された画像を含むダウンロードストリームを圧縮する。この目的のために、標準的な従来技術の可逆圧縮アルゴリズムを使用することが出来る。
図108は、そうしたダウンロード表示ストリームに関する概略図である。幾つかの実施形態に於いて、そうしたストリームは実際にはマークアップ言語を使用して表現される。
図108に図示されたフォントコマンド10812は、図106Aの関数10623による表示リストに記録されたフォントコマンドを表している。
図108の文字列コマンド10814は、図106Aのステップ10624によるダウンロード表示リストに記録されたコマンドを表している。
図108の背景色コマンド10806は、図106Aに図示された関数10632によって入力された背景色コマンドを表している。
図108の矩形コマンド10808は、図106Aの関数10634によって保存された矩形情報を表している。
図108に図示された画像位置コマンド10810は、図106Bの関数10664によって記録された画像位置コマンドを表している。
図108の制御コマンド10816は、図106Cの関数10668によってダウンロード表示リストにセットされた制御コマンドを表している。
ここで図107を再び参照すると、ダウンロードストリームに対する全ての要素が選択され、送信する準備が完了する時点で、関数10706は、ブラウザコンピュータと薄型クライアントとの間のソケット接続を開き、次に、関数10708は、薄型クライアントに、ダウンロードストリームの表示リスト情報を送信する。次に、薄型クライアントは、図109A乃至109Cに関して以下で詳細に記載するように、情報を表示する。
ここで図106Cを再び参照すると、関数10674に於けるダウンロード表示リストルーチンへの呼び出しが完了する時点で、関数10676は表示リストをクリアし、薄型クライアントにダウンロードされる次のスクリーンに対して、新たな表示リストを生成することが可能である。
ここで図105Aを再び参照すると、同図に図示された関数10510によって呼び出されたスクリーンキャプチャ及びダウンロードルーチンの完了については今説明した通りである。
図105Aに図示されているように、ブラウザのプロキシコードが、薄型クライアントのスクリーン上に表示された1つ又は複数の制御オブジェクトの状態に関してブラウザコードの他の部分からクエリを受信する場合、関数10514によって、関数10516及び10518が実行される。関数10516は、その一つ又は複数の制御オブジェクトの状態に関して、薄型クライアントにクエリを送信する。そうした状態情報を薄型クライアントから受信する場合、関数10518は、そうした状態情報に対する要求を行ったプログラムにそれを戻す。
図106Cの関数10666乃至10670に関して上述したように、本発明のこの実施形態は、そうした制御が表示されるウェブページのウェブサイトに送信されたそうした状態情報を有する選択を行う前に、ユーザが情報を変更するので、通信回線容量を低減するために、例えばラジオボタン、チェックボックス、及びテキスト入力フィールドなど、個々の制御オブジェクトに関する状態情報について実際にクライアントに描画及び保存をさせる。一般に、ユーザが送信ボタンをクリックする場合、関連するクリックイベントがプロキシコンピュータまで送信され、それによりスクリーン座標が仮想レイアウトスクリーン上に於ける対応する座標に変換され、次に、仮想スクリーン解像度を有し、ブラウザが表示していると見なすスクリーン上であたかもクリックイベントが生成されているかのように、そのクリックイベントに対応するためのブラウザコードに対して、ブラウザのイベント待ち行列にそれがセットされる。これが実行される時点で、ブラウザコードは従来、現在のウェブページの全ての制御オブジェクトに関する状態を要求し、これにより、現在のウェブページが由来するウェブサーバに情報が戻ることを知らせることが出来る。関数10514乃至10518の操作を引き起こすのは、そうした要求である。
ブラウザのプロキシコードがスクロール又は移動コマンドを薄型クライアントから受信する場合、関数10520によって、図105Aの関数10522乃至10534が実行される。
関数10522は、スクロール又は移動に対応して、図102に図示されたビューウインドウ10210をブラウザのレイアウト10206に関連して移動させる。次に、関数10526は、移動前にビューウインドウに存在したビューウインドウの任意のかなりの部分が、移動後に未だビューウインドウに存在するかどうかを確認するためにテストを行う。かなりの部分がビューウインドウに存在する場合、このことは、薄型ブラウザスクリーン上に現在表示されているビットマップの実質的な部分が、要求されたスクロール又は移動の実行後に、表示に於いて再利用可能であることを意味する。この場合、関数10528は、図108に於けるダウンロードストリームの最上部付近に図示されたスクロールコマンド10804を、スクロールされたスクリーンに対して生成される新しい表示リストの開始位置にセットする。そうしたスクロールコマンドは、薄型クライアントの画面の以前のスクリーンビットマップのどの部分を再利用するかを示すXYシフト値を含んでいる。
図108に於いて、クリアコマンド10802及びスクロールコマンド10804は、ダウンロードストリームの開始位置に図示されており、これにより、両コマンドを説明することが出来る。本実施形態に於いて、2つのコマンドの内、クリアコマンド又はスクロールコマンドの一つだけが所定のダウンロードストリームを開始し、クリアコマンドは、薄型クライアントのスクリーンが全体的に再描画される場合に使用され、スクロールコマンドは、薄型クライアントの先のビットマップの部分が新しいスクリーンで再利用するためにシフトされる場合に使用される。
以前ダウンロード及び描画が実行され、スクロールコマンドを使用可能となる、スクリーン表示の実質的な部分を再利用することによって位置を比較的小さく変更することを含むスクロールに於いて、薄型クライアントにダウンロードされるデータ量を実質的に低減することが出来る。例えば、本出願の出願時点に於いて一般的な、比較的低速度のデジタル携帯電話リンクを介してブラウザと薄型クライアントが通信する状況など、特に、ブラウザと薄型クライアント間の回線容量が制限されている状況に於いて、これは、スクロールされたスクリーンが薄型クライアント上に表示可能な割合を実質的に向上させることが出来る。
スクロールコマンド又は移動コマンドの結果生じる移動されたビューウインドウが、図102に概略的に図示された、仮想スクリーン10206に現在存在しないウェブページのレイアウトの部分を含む場合、図105Aの関数10530によって、関数10532及び10534が実行される。関数10532は、ビューウインドウの全てがブラウザの仮想スクリーン内に含まれるように、ブラウザの仮想スクリーンをスクロールさせ、次に、関数10534が新たに移動された仮想スクリーンに対して、ブラウザからの再描画を要求する。この描画が完了する時点で、関数10506及び10510は、図106A乃至106Cに関して上述されているように、新たに描画された要素を取り込み、描画する。
ブラウザのプロキシが薄型クライアントからズームコマンドを受信する場合、図105Aの関数10536によって、関数10538乃至10552が実行される。
関数10538は、ズーム変更に従って表示倍率を変更する。
関数10540は、選択されたズームに従って、ビューウインドウをブラウザの仮想ウインドウに関連して拡大/縮小する。
関数10542は、拡大/縮小されたビューウインドウが仮想スクリーン内に現在含まれていないウェブページのレイアウトの部分を含むかどうかを確かめるためにチェックを行う。ウェブページのレイアウト部分を含む場合、関数10542によって、関数10544が仮想スクリーンをスクロールする、又は、縮尺ビューウインドウを仮想スクリーン内に適合させるために解像度を変更する。
仮想スクリーンをスクロールすることによって、新しいビューウインドウが仮想スクリーンに適合することが出来る場合、ウェブページを再びレイアウトする必要がなく、仮想スクリーン内にある異なる場所を表示すること、及び/又は、異なる倍率で仮想スクリーン表示することによって、ズーム前に存在した同一レイアウトを表示するために、ズームを使用することが出来る。しかし、ズームが、図105Aに図示された実施形態に於いて、ビューウインドウを仮想スクリーンサイズに比して大きくするズームアウトである場合、プロキシブラウザはクライアント上に表示されたビューウインドウの任意の部分に供給された任意の入力を、それがあたかもプロキシブラウザの仮想スクリーン上の対応する位置で発生したかのように処理することが出来るように、ビューウインドウが仮想スクリーン内に完全に適合可能な新たな仮想スクリーンサイズで、ウェブページを表示することが必要となる。記載されている実施形態に於いて、新しい仮想スクリーン解像度が先のレイアウトに於いて使用されたレイアウト解像度に比して大きい場合、これによりウェブページは新しいレイアウトで表示され、異なる位置で改行させることが出来る
例えば、プロキシブラウザがパッチを適用されるというよりは、ズームされた表示をサポートするために設計された実施形態、レイアウト全体のダウンロードに関連してクライアントが直接ズームを行う図115に関して上述された実施形態など、本発明に関する他の実施形態に於いて、極端なズームアウトはウェブページの再レイアウトを必要としない。
最後に、関数10552は、スクリーン再描画を呼び出す。これにより、スクリーンキャプチャ及びダウンロードルーチンが、新しいズーム倍率で現在のビューウインドウの再描画を取得し、対応する表示情報を薄型クライアントにダウンロードするので、新しいズーム設定でウェブページを表示することが出来る。
図105Bに示されているように、ブラウザのプロキシが薄型クライアントから仮想解像度変更コマンドを受信する場合、関数10554によって、関数10556乃至10560が実行される。関数10556は、図102に図示された仮想解像度制御10214に保存されたブラウザの仮想スクリーン解像度を要求された解像度に変更する。次に、ステップ10560は、スクリーン再描画を要求する。これは、ブラウザが新しい仮想スクリーン解像度で現在のウェブページを再びレイアウトし、ビューウインドウが薄型クライアントスクリーン上に有するピクセル数に対する、ビューウインドウが仮想スクリーンに有するピクセル数の比率に対応する表示の倍率で、仮想スクリーンの全てを再描画するからである。
仮想解像度に於けるそうした変更によって、そうしたレイアウト内の画像及びテキストのサイズに関連してレイアウトが実行されるサイズを変更する。ユーザが、サイズに於けるそうした変更をキャンセルする仮想スクリーンに関連して、ビューウインドウの相対的なサイズに於ける変更をユーザが行わない限り、相対的なレイアウトサイズに於けるそうした変更によって、スクリーン上に表示される画像及びテキストのサイズを変更する。相対的なビューウインドウサイズに於けるそうした補償的な変更がない場合、仮想解像度を低減することによって、画像及びテキストがスクリーン上に表示されるサイズを大きくし、テキストラインのより多くをより大きなテキストサイズで一度にスクリーン上に適合させるように、それらに表示されたフォントのサイズに関連して、テキストラインをより短くする傾向がある。それ故、ある特定の種類のズーム機能をウェブページの表示に供給するために、仮想レイアウトサイズに於ける変更を使用することが出来る。
発明者は、倍率2でレイアウトを縮小することを含む、典型的なPDAのサイズである320×240スクリーン上にウェブページを表示する際に、640×480の仮想スクリーンを使用して、極めて良好な可読性を供給することが出来るということを発見した。しかしながら、より大きな解像度表示に対して表示された場合に、ウェブページがどのように見えるかをユーザが見ることが出来るようにするためには、可読性が犠牲になるとしても、例えば、PDAサイズの320×240画面上に800×600の仮想スクリーン解像度を表示する場合など、ウェブページをさらに低減された縮尺で表示することに本発明を利用することが出来る。言うまでもなく、ページのレイアウトは、結果的に生じるフォントサイズに於ける相対的な増大のために、そうした解像度で表示するために元々意図したレイアウトとは全く異なるが、最小フォントサイズが制限されることをユーザが選択する場合、図106Aの関数10614に関して上述されたように、より大きな仮想解像度を有するテキストでさえ、読み取り可能なフォントで表示される。
図105Bの関数10562によって示されているように、ブラウザのプロキシコードが、薄型クライアントのスクリーン上でのクリックに関連して薄型クライアントから他のユーザ入力を受信する場合、関数10564は、仮想スクリーン上の対応する位置に対するクリックに関連して、薄型クライアントスクリーンの位置を変換し、殆どのブラウザのコードが、それがレイアウトしていると見なす仮想スクリーン上でユーザが実際にクリックしたかのように、ブラウザがイベントに対応することが出来るように、関数10566はこのイベントをブラウザのイベント待ち行列に中継する。
これが、ウェブリンクがテキストリンクであろうと画像リンクであろうと、薄型クライアント上に表示されたウェブページ上のウェブリンクを選択するために、プロキシ上のブラウザが薄型クライアントのユーザからの入力に対応する方法である。例えば、ユーザが薄型クライアントスクリーン上に表示されたリンクをクリックする場合、それが表示していると見なす仮想スクリーンに於ける同一リンクをユーザがクリックしたかのように動作するプロキシ上のブラウザに対応するクリックが中継される。次に、プロキシのブラウザは、リンクに対応してインターネットを介してHTTP要求を発することによって対応する。そのリンクに対応するウェブページが受信される場合、ブラウザはそれを仮想画面上にレイアウトし、表示しようとし、これによって、図105Aの関数10506及び10510が、ビューウインドウに対応するレイアウトのその部分に含まれた情報を取り込み、そのスクリーン上に表示するために薄型クライアントにそれをダウンロードさせる。その結果、薄型クライアントのユーザは、通常のブラウズコンピュータのユーザと略同一の方法で、ウェブをブラウズすることができる。
図109A乃至109Cは、薄型クライアントコンピュータのユーザがそのスクリーンを使用して、ワールドワイドウェブ(WWW)をブラウズ出来るように、プロキシブラウザに関連して動作するのに役立つように設計された、薄型クライアントコンピュータ上に於けるコード10900に関する高度に簡略化された擬似コード表記である。
図109Aの関数10902は、図107の関数10708によって薄型クライアントに送信されたダウンロードストリームの全て又は最初の部分の受信に対応する。関数10902は、受信される順番でそのストリームに含まれた、図108に図示された種類の個々のコマンドへの対応を開始することにより、このような対応を行う。ダウンロードストリームが完全に受信されるまで、新しいスクリーンの描画作業を遅延する必要がないように、関数10902は、1つ又は複数のコマンドが受信され次第、これを開始する。ダウンロードストリームに含まれた各種異なるコマンドへの対応については、図109A乃至109Bに於いて数字10904乃至10956が付与された関数によって示されている。
関数10904及び10906によって示されているように、薄型クライアントがダウンロードストリームに於けるクリアコマンドを読み取る場合、例えば、全体的に白の値に設定されることによって、スクリーン上に表示されたビットマップがクリアされる。
薄型クライアントが、ダウンロードストリームに於けるスクロールコマンドを読み取る場合、関数10908によって、関数10910及び10912が実行される。関数10910は、コマンドに含まれたXYシフト値によって示されたスクリーン上の新しい位置へのスクロールコマンドに於いて指定されたスクロールの後で再利用される薄型クライアントスクリーンのビットマップの一部をコピーする。そして、関数10912は、スクリーンの残りの部分をクリアする。
薄型クライアントが、ダウンロードストリームに於ける背景色コマンドを読み取る場合、関数10914及び10916は、現在の矩形背景色変数を、コマンドで指定された色に設定する。これにより、背景色の値が変更されるまで、矩形コマンドに対応して薄型クライアントによって描画された全ての矩形は、その特定の色値を有する。
薄型クライアントがダウンロードストリームに於ける矩形コマンドを読み取る場合、関数10918及び10920は、現在の背景色を使用し、コマンドに於いて指定されたスクリーン位置、幅、及び、高さを有する矩形を描画する。
薄型クライアントが画像位置コマンドを読み取る場合、関数10922及び10923はこの時点で何も実行しない。これは、通常、そうした画像位置コマンドに於いて参照された画像を描画するために必要なビットマップが、そうした場合に受信されていないからである。他の実施形態に於いて、ブラウザは矩形描画コマンドを画像に関連付け、これにより、画像に関連付けられたブラウザスクリーンの一部が、ビットマップ画像の表示位置を示す画像上に描画された矩形を有することになる。
薄型クライアントがフォントコマンドを読み取る場合、関数10924及び10926は、フォントコマンドに記載された全てのフォント属性を、そのコマンドに於けるそれらの属性に対して記載された値に設定する。
本発明の異なる実施形態に於いて、異なるフォント属性を使用することが出来る。少なくとも、フォントファミリー、フォントサイズ、及び、フォントの前景色が、フォント属性でサポートされることが好ましい。
薄型クライアントがダウンロードストリームに於ける文字列コマンドを読み取る場合、関数10928によって、関数10930乃至10940が実行される。
関数10930は、薄型クライアントがフォントビットマップキャッシュに於いて、現在のフォント属性値によって指定された現在のサイズ及びフォントファミリーに於ける現在の文字列の各文字に対するビットマップを有するかどうかを確認するためにテストを行う。このビットマップを有していない場合、関数10932乃至10936が実行される。
関数10932は、図2に関して上述したフォントサーバ134に、クライアントのインターネット接続を介してHTTP要求を送信する。要求されたフォントがフォントサーバから受信される場合、関数10934及び10936は、それを薄型クライアントのフォントビットマップキャッシュにセットする。
注目すべきは、本発明の幾つかの実施形態では、関数10930及び10936を使用する必要がないように、薄型クライアントブラウザソフトウェアの一部として、永続的にフォントビットマップを十分に保存することである。他の実施形態に於いては、図109Aに図示された例に於けるフォントビットマップに図示されているように、サブピクセル最適化フォントアウトラインは、薄型クライアントによって永続的に保存されるか、必要に応じて要求される。
薄型クライアントが現在の文字列をレンダリングするために必要なフォントビットマップの全てを有する場合、関数10938及び10940は、前景色を含む現在のフォント属性値を使用して、文字列を指定されたスクリーン位置でスクリーン上に描画する。現在の実施形態に於いて、フォントビットマップは、図60、96、97に関して上述された種類のアルファ値ビットマップとして表される。そのように実行する場合、文字列が描画されるスクリーンビットマップの一部から、背景色が抽出される。
幾つかの実施形態に於いて、演算を低減するために、文字列が描画されるスクリーンの部分の色値は、比較的少ない数のポイントでサンプリングされ、これらのサンプリングされた色値の平均値は、図97に関して上述しているように、文字列表示全体に対する背景色として使用される。
記載されている実施形態に於いて、ダウンロードストリームに含まれる文字列の全ては、単一のラインテキスト文字列であり、これらの多くがプロキシブラウザのレイアウトエンジンによるライン境界を越えた連続テキストのラッピングから生じている。結果として、この実施形態では、薄型クライアントがそうしたテキストの任意のラッピングを実行する必要はない。
関数10940は、文字列のビットマップ画像を、文字列の文字に対応する別々の複数のフォントビットマップで構成することによって描画する。通常、そうした構成では、各種別々の文字は、異なる別々のフォントビットマップによって表される。
異なるフォントサイズ(例えば表示倍率に於ける変化によって生じた異なるフォントサイズ)でのそうした構成に於いて使用されたフォントは、そうした各フォントサイズで可読性を向上させるために選択された各文字の形状及びピクセル配列を有している。殆どの実施形態に於いて、ビットマップのピクシレーションを用いて文字形状の配列を改善するために、フォントビットマップに関連して、文字の形状及び位置を選択することによって、こうした改善された可読性を実現する。そのような形状及びピクセル配列は、10ピクセル/em又はそれ未満のフォントビットマップを扱う場合に特に重要であるが、8ピクセル/em又はそれ未満では、さらに重要である。これは、フォントビットマップのより粗いピクシレーションのために、フォントビットマップが小さくなるにつれて読み難くなるからであり、それ故、フォントビットマップがそうしたピクシレーションに適合するために選択された文字の形状及び配置を有することがより一層重要になる。
本発明の多くの実施形態に於いて、より小さな縮尺のステップ10940によって使用されたフォントビットマップは、ピクセル内で発生するカラーアンバランスのみが分配される、上述の種類の非線形カラーバランスによって生成されたサブピクセル最適化されたビットマップである。そうしたサブピクセル最適化が、それらの粗いビットマップピクシレーションにうまく適合するように、適切に形成され、配置されたアウトラインに組み合わされる場合、描画された結果として生じるビットマップは、それらの小さなピクセルサイズを考慮すると、極めて読み易い。本発明の他の実施形態に於いて、そうした小さなピクセルサイズでの可読性を改善するために形成され、位置されたアウトラインを同様に有する非サブピクセル最適化されたアンチエイリアスフォントが使用される。
ここで図109Bを参照すると、薄型クライアントがダウンロードストリームからの制御コマンドを読み取る場合、関数10942によって関数10944乃至10948が実行される。関数10944は、現在の制御コマンドに於いて指定された制御IDに対応するデータ、又は、プログラムオブジェクトを既に生成しているかどうかを確認するためにテストを行う。生成していない場合、関数10946は、制御コマンドに於いて指定された種類のデータ又はプログラムオブジェクトを生成し、それをそのコマンドで指定された制御IDに関連付ける。
次に、ステップ10948は、指定された種類の制御オブジェクトのサブピクセル最適化されたビットマップを、制御コマンドに於いて指定された位置に於いて、薄型クライアントのスクリーン上に描画する。次に、ステップ10948は、サブピクセル最適化されたフォントを使用して、制御オブジェクトのビットマップ上に、制御に関連付けられたテキストを描画する。次に、ステップ10948は、制御のビットマップに対応する表示スクリーン位置を有するホットゾーンを、薄型クライアント上で制御を表すデータオブジェクト又はプログラムオブジェクトと関連付ける。
薄型クライアントがダウンロードストリームからの画像コマンドを読み取る場合、関数10950によって、関数10952乃至10956が実行される。
関数10952は、現在の画像コマンドと同一の画像IDを有する画像位置コマンドが発生する毎に、現在の表示ストリームをスキャンする。そうした各画像位置コマンドに対して、関数10952によって、関数10954は薄型クライアントのスクリーン上の画像位置コマンドで指定された位置にビットマップを描画する。全ての薄型クライアントの描画関数と同様に、薄型クライアントスクリーン上に適合しない画像の任意の部分は、そうした描画操作に於いて切り取られる。
次に、関数10956は、これらの描画された任意のビットマップと同一位置で発生する表示リストに於ける、他の全てのアイテムを再描画する。これが必要なのは、ウェブページがテキストを画像の最上部にセットすることが一般的であり、それ故、ビットマップ画像と同一位置に表示されるはずの任意の文字列は、これらの画像が描画された後で再描画されることが望ましい。本発明の一実施形態に於いて、薄型クライアントは、そのリストに於ける最初の画像位置コマンドの後に発生する、ダウンロードストリームの表示リストの全ての非画像要素を単に再描画する。
図110に図示されているように、テキスト入力フィールドに関連付けられたホットゾーン上でユーザがクリックする場合、図109Bの関数10958及び10960によって、関数10962乃至10978で構成されるキーボードルーチンが実行される。
関数10962は、図111に図示されているように、薄型クライアントのスクリーン上に、ポップアップユーザキーボード11102、及び、テキスト編集フィールド11104を表示する。次に、ユーザがポップアップキーボードの「Enter(入力)」キーを押下するまで、ループ10964が実行される。このループ中に、ユーザがテキスト文字を打ち込む度に、関数10966によって、関数10968は文字に関するサブピクセル最適化テキストビットマップをポップアップキーボードのテキスト編集ライン上の現在のカーソル位置にセットし、カーソルのビットマップを新たに描画された文字の後ろの位置に移動させる。そして、関数10970は、ポップアップキーボードのプログラムに関連付けられた一時的なテキスト編集文字列に打ち込まれた文字を追加する。
ユーザがポップアップキーボードの「Enter(入力)」キーを押下する場合、関数10972によって、関数10974乃至10978が実行される。関数10974は、ポップアップキーボードが引き起こされるテキスト編集制御に於けるポップアップキーボードに関連付けられた、一時的なテキスト編集文字列の値を保存する。関数10976は、サブピクセル最適化ビットマップを使用して、図112に示されるように、薄型クライアントのスクリーン上の制御オブジェクトのテキスト入力フィールド11000のビットマップに、テキスト編集文字列の文字を描画する。
次に、関数10978は、ポップアップキーボードの上に、ポップアップキーボードが描画される前にスクリーン上に表示されたビットマップを描画することによって、薄型クライアントのスクリーンからポップアップキーボードを取り除く。
図113は、ポップアップキーボードルーチンをテキスト入力フィールドにテキストを入力する以外の目的で使用することが出来ることを図示している。図109A乃至109Cの擬似コードに表示されていないが、ポップアップキーボードは、薄型クライアントに表示されたユーザが見たいと考えているウェブページのURLを入力するために使用することも出来る。
ボタンバー又はツールバーをグラフィカルユーザインターフェース(GUI)の最上部に有する本発明の一実施形態を図示しているという点を除いて、図114は実質的に図113と同一である。このボタンバーは、その左端に、一般的にウェブブラウザで見られる種類の「Back(戻る)」ボタン及び「Foward(進む)」ボタンを有している。またそれは、こちらも一般的にウェブブラウザで見られるボタンであるが、リフレッシュボタン、ブックマークボタン、及び、ヒストリーボタンにそれぞれ対応する「R」、「B」、「H」でラベル付けされたボタンを有している。また、ボタンバーは、クリックされた場合に図114に図示されたポップアップキーボードが現れるURLテキスト入力フィールドを有する。ポップアップキーボードが表示されていない場合、このテキスト入力フィールドは、薄型クライアントのスクリーン上に表示された現在のウェブページのURLを表示する。本発明の一実施形態に於いて、ユーザは、ハードウェアのボタンを押下することによって、そうしたツールバーの表示、非表示を選択することが出来る。この実施形態に於いて、そのようなツールバーが表示されていないとしても、ユーザは、例えばバックコマンドやフォーワードコマンドなど、より一般的なウェブブラウズ機能の幾つかを呼び出すために、ハードウェアボタンを使用することが出来る。
本発明の他の実施形態に於いて、そうしたグラフィカルユーザインターフェース(GUI)のツールバーもまた、ウェブページの表示のズーム、及び/又は、相対的なレイアウトサイズ(即ち、仮想レイアウト解像度)を含む、ブラウザの他の機能にユーザがアクセスすることが可能なボタン又はメニューを有することが好ましい。
ここで図109Bを再び参照すると、ユーザが、ボタン又はメニューアイテム制御のホットゾーン上でクリックする場合、関数10980によって関数10981及び10982が実行される。
関数10981は、ボタン又はメニューアイテムの外見を適切に変更する。ボタンの場合であれば、ボタンに関連付けられたビットマップがボタンが、押下されていることを示すために再描画される。メニューアイテムの場合であれば、最終的な選択がなされたか否かに応じて、サブメニューが表示されるか、又は、メニューアイテムの表示が取り除かれる。
メニューアイテムの場合に於いて、最終的な選択が成された場合、又は、ボタンが押下され、解除された場合、関数10982は、ボタンの制御ID又はメニューアイテムの制御ID、及び、それが選択されたという指示をブラウザに送信し、ブラウザはブラウザ上の対応するボタン又はメニューアイテムの制御オブジェクトをあたかも押下されたように動作させることによって対応する。
ユーザが、他の種類の薄型クライアント制御に関連付けられたホットゾーン上でクリックする場合、関数10983は、これに応じて、薄型クライアントの表示上の制御のビットマップの外見を変更する。例えば、チェックボックスの場合であれば、スクリーン上の制御の表示にチェックが表示されるか、又は、表示から取り除かれる。次に、ステップ10985は、制御オブジェクトに対応して、対応する状態変更を保存する。上述したように、記載の実施形態に於いて、通信の要求を低減するために、ブラウザがそうした情報を要求するまでは、そうした制御オブジェクトの状態は、ブラウザに伝達されない。
クライアントプログラム、又は、コンピュータの制御インターフェースに関連付けられていない薄型クライアントのスクリーンの他の部分上でユーザがクリックする場合、関数10986及び10987は、クリックが発生したスクリーン位置に加えて、そのクリックに関連するイベントを、プロキシブラウザに送信する。図105Bの関数10562乃至10556に関して上述されたように、ブラウザは、そうしたクリックの位置を仮想スクリーン上の対応する位置に変換し、仮想スクリーンの解像度で、それが描画しているとブラウザが見なすスクリーン上で、クリックがあたかも発生したかのように、そうしたクリックに対応する。幾つかの実施形態に於いて、通信の要求をさらに低減するために、他のクリックが、プロキシのブラウザが対応することになっているユーザ入力に一致すると考える根拠を薄型クライアントが有する場合に限り、薄型クライアントはそうした他のクリックをブラウザに報告する。
ここで図109Cを再び参照すると、薄型クライアントが、一つ又は複数の制御オブジェクトの状態を要求するプロキシブラウザからのクエリを受信する場合、関数10988によって、関数10989は薄型クライアント上の対応する制御の状態を問い合わせ、関数10909は、そうした状態情報をプロキシブラウザに送信する。図105Aの関数10518に関して上記されたように、次にプロキシブラウザは、あたかもその情報が、仮想スクリーンに関連した対応する制御オブジェクトの現在の状態の一部であるかのように、それを要求したブラウザの部分に、そうした要求された情報を返す。
薄型クライアントのユーザが、そのスクリーンをスクロールするためにコマンドを入力する場合、関数10991及び10992は、そのスクロールコマンドをプロキシにアップロードする。これによって、図105Aに関して上記された関数10520乃至10534は、新たにスクロールされた位置に、現在のウェブページを表示するために、新しいダウンロードストリームを生成し、ダウンロードする。
ユーザが、薄型クライアント上に表示された画像のズーム(即ち、縮尺)を変更するためにコマンドを入力する場合、関数10993及び10994は、対応するズームコマンドをプロキシにアップロードする。これによって、図105Aに関して上述された関数10536及び10552は、新しいズーム設定で現在のウェブページを表示するために、薄型クライアントにダウンロードされた新しいダウンロードストリームをもたらす。
ユーザが薄型クライアントの表示に関する仮想解像度を変更するためにコマンドを入力する場合、即ち、プロキシブラウザ上の仮想スクリーンがレイアウトされる解像度を変更する場合、関数10995及び10996は、選択された仮想解像度をプロキシにアップロードする。これにより、図105Bに関して上述された関数10554乃至10560は、プロキシブラウザの仮想スクリーン解像度を変更し、新しい解像度で仮想スクリーンを再びレイアウトし、対応するダウンロードストリームを薄型クラインアントに送信するので、それは、ウインドウに対応する仮想スクリーンの一部を現在のズーム設定で薄型クライアントスクリーン上に表示することが出来る。仮想解像度に於ける変更は、仮想レイアウトの幅に関連して、例えばテキスト及びイメージ等のレイアウト要素の相対的なサイズを変更する傾向があるので、本明細書中では、仮想解像度は相対的なレイアウトサイズとして言及される場合がある。
図109Cの最下部に図示されているように、ユーザが薄型クライアントの制御グラフィカルユーザインターフェース(GUI)に関連付けられた他のコマンドを入力する場合、関数10997によって、省略記号10999によって示された、これに対する適切な応答が実行される。そのような他の関数は、ブックマークの選択、ブックマークされたウェブページへのアクセス、Back(戻る)及びFoward(進む)機能、ブラウザのユーザインターフェースの一部となり得る任意の他の関数を含む。物理的なボタンの使用、又は、薄型クライアントコンピュータへの他の物理的入力、例えばボタン、メニューアイテム、又は、ダイアログボックス制御などのグラフィックオブジェクトの選択、又は、仮想のその他任意の周知のグラフィカルユーザインターフェース(GUI)技術によって、そうした要求を選択することが出来る。
図115乃至117は、薄型クライアントがプロキシサーバを介してウェブをブラウズ可能にする代替方法に関する。この実施形態に於いて、図117に図示されているように、プロキシコンピュータによって生成されたウェブページの全体的なレイアウト10206は、薄型クライアントによってダウンロードされキャッシュされる。後述するように、これにより薄型クライアントは実質的により速くレイアウト内をスクロールすることが出来るのであるが、これにより、薄型クライアントが視認される各ウェブページに対してレイアウト全体及び全画像をダウンロードしようとするので、ダウンロードされる総ビット数を増加させる可能性がある。
図115は、そうしたページレイアウトキャッシュスキームで使用可能なプロキシブラウザコード11500の一部を図示している。
本発明のこの実施形態に於いて、プロキシブラウザは薄型クライアントからウェブページに対する要求を受信する場合、関数11502によって関数11504乃至11524が実行される。
図115の関数11502に関連付けられた擬似コードによって図示されているように、この特別なウェブキャッシングに関する実施形態に於いては、薄型クライアントは、所望の仮想解像度、ズーム設定、及び、ビューウインドウ位置を含む、ページに対する所望のビュー設定でウェブページを要求することが出来る。これを実行するのは、ページが要求される度に、そうした設定値を別々に入力する必要なく、所望の仮想解像度、ズーム設定、及び、ビューウインドウ位置で、ユーザがそうしたウェブページを自動的に視認出来るように、ユーザがそうしたビュー設定を、特定のURL又はURLパス名の部分を含むブックマークに関連付けることを可能にするためである。例えば、これにより、ユーザはそのページの所望箇所に於いて自動的にズームされた表示で、通常アクセスされたウェブページを視認することが出来る。
ウェブページに対する要求が薄型クライアントから受信された時点で、プロキシブラウザ上の関数11504は、薄型クライアントから要求されたURLに於いて識別されたサーバからそのウェブページを要求する。ウェブページがサーバから受信される場合、関数11506によって、関数11507乃至11516が実行される。
関数11507によって、プロキシ上のブラウザのレイアウトエンジンは、ウェブページに対する薄型クライアントからの要求に於いて指定されたビュー設定に関連付けられた仮想スクリーン解像度で、受信されたウェブページをレイアウトする。図106Aの関数10606乃至10618に関して上記されたものと同様の方法で、置換されたフォントに対して拡大/縮小された文字列測定を使用して、このレイアウトを実行する。使用される倍率は、現在のページに対する要求において指定されたビュー設定によって決定される。
関数11508は、現在の要求に関するビュー設定に於いて潜在的なビューウインドウを含む、結果として生じたレイアウトに関連して、仮想スクリーン位置を特定する。それ故、例えばビュー設定がレイアウトの一番右の640×480部分を見ることを要求し、レイアウトが800ピクセル幅を有するように強制される場合、仮想スクリーン位置は、レイアウトに於いて、約ピクセルコラム160からピクセルコラム800に拡張する。
図117に於いて概略的に図示されているように、関数11518によって、関数11520はレイアウトされているウェブページに関連して受信されたそれぞれの画像11702を拡大/縮小、及び、サブピクセル最適化する。
ウェブページに於いて参照された全画像が受信され、拡大/縮小され、サブピクセル最適化された時点で、関数11522によって、関数11523はそのレイアウトに対して表示リストを作成し、その表示リスト、及び、全ての関連するサブピクセル最適化、拡大/縮小された画像を圧縮する。次に、関数11524は、後に縮小されたサブピクセル最適化された画像が続く、ウェブページレイアウトを含むダウンロードストリームで、その圧縮されたデータを薄型クライアントに送信する。
本発明の該特徴に関する他の実施形態に於いて、画像の全て又はその一部でさえもプロキシサーバにダウンロードされる前に、レイアウトの部分を薄型クライアントにダウンロードすることが出来る。これにより、薄型クライアントはウェブページのテキストの表示をより迅速に開始することが出来る。多くのウェブページは、それらの画像全てのサイズに関する記述を含んでいるので、多くの場合、そうしたレイアウトを実行するソフトウェアによって画像が受信される前に、ウェブページの適切なレイアウトを実行することが出来る。そうではない場合、そのページは全画像のサイズを確認する際に、再びレイアウトされなければならず、その後で、こうした新たなレイアウトをクライアントまで送信することが出来る。
異なる縮尺で以前ダウンロードされた一つ又は複数の画像を再び拡大/縮小し、サブピクセル最適化するために、ユーザが薄型クライアントから要求を受信する場合、関数11526乃至11532は、そうした画像を再び拡大/縮小及びサブピクセル最適化し、圧縮し、そして薄型クライアントにダウンロードする。これにより、ユーザが異なるズーム設定でダウンロードされたウェブページレイアウトを見ようとする場合、ユーザは異なるサブピクセル最適化されたサイズでウェブページを見ることが出来る。
スクリーン入力のイベントが薄型クライアントから受信されると、関数11534によって、関数11536乃至11542が実行される。
関数11536は、コマンドに関連付けられたページレイアウト座標が、図117に示された、現在プロキシブラウザの仮想スクリーン10208にマッピングされているウェブページレイアウト10206の部分10206Aに一致するかどうかを確かめるためにテストを行う。一致しない場合、関数11538は、そのコマンドに関連付けられたレイアウト座標を含むレイアウトの新しい部分10206Bまで仮想スクリーンをスクロールする。
関数11540は、受信されたスクリーンイベントのページレイアウト座標に対応する仮想スクリーン座標を計算する。そして、あたかもユーザが仮想スクリーン自体に於ける対応する仮想スクリーン座標でクリックしたかのように、例えばリンクのクリック等のイベントにそれが対応出来るように、関数11542は仮想スクリーン座標と共に入力スクリーンイベントをブラウザのイベント待ち行列にセットする。
図116は、図115及び117に図示されたページレイアウトキャッシュスキームをサポートするために使用可能な薄型クライアントコードの一部に関する高度に簡略化された擬似コード記述である。
薄型クライアントがページレイアウトの表示リストを含むダウンロードストリームを受信開始する場合、関数11602によって、関数11604及び11606が実行される。
関数11604は、ビューウインドウ(例えば、図117に図示されたビューウインドウ10210A)のマッピングをページレイアウトに関連して設定し、次に、そのマッピングに基づいて現在のクライアント側の表示倍率を計算する。
関数11620は、現在のクライアント側の倍率を使用して、現在のビューウインドウ内に適合するダウンロードされたページレイアウトの任意の部分を表示する。このプロセスは、関数11622乃至11630を含む。
関数11622は、現在のクライアント側の倍率に関する関数であるフォントサイズを用いて、現在のビューウインドウ内に発生する各文字列要素を表示する。それが実行され場合、そうした文字が表示されるピクセルサイズが変化する際に、必要に応じて、それがフォントのヒンティングによる不均一な影響から生じる可能性のある、文字の相対的なサイズに於ける任意の不均一な変更に対して調整を行う。コンピュータスクリーン上でのテキスト表示と、さらに高解像度で印刷される際の該テキストの外観との間のWYSIWYG通信を提供するために、従来から使用されている技術に類似した、例えば文字間の間隔の変更など、不連続及び不均衡を補う技術を使用することによって、関数11622はこれを実行する。以前表示されたサイズとは異なるサイズを有するフォントビットマップが要求される場合、そうした異なるサイズの文字に対するフォントビットマップに対して、薄型クライアント上の記憶装置からアクセスすることと、ネットワークフォントサーバからアクセスすることと、フォントアウトラインから必要なサイズでラスタ化することの何れかを行うことが出来る。
関数11620によって生成された表示が、ビットマップ画像10818が縮小された倍率とは異なる倍率の場合、関数11624によって、関数11626乃至11630が実行される。これらはプロキシサーバに対して、ビューウインドウ内に全体的又は部分的に存在する全画像を新しい倍率で再び拡大/縮小し、サブピクセル最適化するように要求する。その後、同一画像のビットマップは、そうした画像に対する一時的な表示を提供するために、薄型クライアント上に保存、表示された、以前縮小されたサブピクセル最適化画像10818からローカルに再び拡大/縮小される。そして、元のサイズから再び拡大/縮小され、要求された画像、及び、ウェブページに関連付けられたより高い解像度のビットマップが、プロキシサーバから薄型クライアントにより受信された場合、それらは表示スクリーン上の適切な位置に描画される。
幾つかの実施形態に於いて、ユーザが表示のズームを変更する場合、新しい倍率でスクリーン上のページの部分に対応する任意の画像のビットマップは、適切にサブピクセル最適化された画像がダウンロードされるまで、ユーザにそうした画像の一時的な表示を提供するために、薄型クライアント上に生成された画像に関する迅速であるが粗い表現で表示される。新しい倍率が以前ダウンロードされたビットマップの倍率の整数倍である場合、そうした迅速な表示を比較的生成し易い。ビットマップ倍率の整数倍ではない場合、多くの方法の内、任意の方法で一時的な表示を生成することが出来る。例えば、それらは図12乃至53に関して上述された方法の内一つの方法で生成されたサブピクセル最適化された画像になり得る。ソース画像が出力画像に比して低解像度である場合でさえも、これらの方法に記載された基本的な手順を適用することが出来る。さらにコンピュータ処理的に単純な方法は、整数の換算比を有する画像として、及び、以前の画像に対して描画されることを目的とする適切に拡大/縮小された画像よりも多くの空間を占めないように、適切な縮尺と同一、又は、それより小さなサイズで切り取られた画像、又は、拡大/縮小された画像として、以前の画像を表示することである。
ユーザがプロキシブラウザに送信されるスクリーン入力を生成する場合、関数11632乃至11636は、その入力の薄型クライアントスクリーン座標を、対応するページレイアウト座標に変換する。そして、スクリーン入力及び対応するページレイアウト座標がプロキシブラウザにアップロードされる。次に、プロキシブラウザは図115に関して上述された関数11534乃至11542を使用して、そうした入力に対応する。これにより、あたかもユーザがプロキシブラウザの仮想スクリーン上のウェブページの対応する部分でクリックしたかのように、プロキシブラウザがそうしたスクリーン入力に対応する。
ユーザがウェブページのコンテンツに関連してより迅速にスクロール、及び/又は、ズームを行うことが出来るように、例えば図115乃至117に関して上述したような、薄型クライアントが現在スクリーン上に表示されているウェブページの部分よりも多くの部分を保存可能なキャッシングスキームを使用することが出来る。このことが特に当てはまるのは、薄型クライアントがプロキシサーバに対して比較的低い回線容量を有する場合である。
この出願の時点で一般的に利用可能な現在のデジタル携帯電話通信速度に関連した回線容量と同程度に低い回線容量を使用した場合でさえ、ウェブの比較的迅速なブラウズを可能にするために、ここで記載したそうしたキャッシングスキームに関する実施形態を実行することが出来る。これは、通常、殆どのウェブページに含まれる画像を除く全コンテンツを、3000バイト、又は、それ未満に適合するように圧縮することが出来るからである。それ故、現在のデジタル携帯電話の通信速度で、殆どのウェブページのテキスト部分全体を数秒でダウンロードすることができ、テキストの最初の部分をさらに短い時間で描画することが出来る。言うまでもなく、画像のダウンロードにはより多くの時間を要する可能性はあるが、ウェブページの最初の画像の内、大型画像以外は、一般的に数秒以内で表示することが出来る。そして、より高速の通信回線でこの遅延を大幅に低減することが出来る。
図118乃至120は、仮想的なウェブブラウズ環境に於いて使用可能であるが、小型スクリーン上でウェブをブラウズする際に特に有用である、本発明に関する特徴を図示したものである。これは、例えば、上記に於いて議論した薄型クライアントコンピュータなどの小型スクリーン装置上での使用を含む。本発明のこれらの特徴は、ウェブページの選択された部分へのズームイン又はズームアウトを含んでいるので、ここで説明したレイアウトキャッシングスキームを使用することによって、薄型クライアントコンピュータ上で迅速に動作させるために実行することが出来る。
図118は、640×480の仮想解像度でレイアウトされ、その後、320×240スクリーン上で表示するために縮小され、サブピクセル最適化された、標準的なウェブページの図を示している。視力の良い人であれば、殆どの人が通常ハンドヘルドコンピュータを使用する距離でそうしたコンテンツを読み取ることが出来る。しかし、より大きなサイズで表示される場合には、殆どのウェブページのコンテンツをさらに容易に読み取り可能にすることが出来る。殆どのウェブページがマルチコラムでレイアウトされているので、多くの場合、ユーザが読み始めたいと考えるコラム部分の最上部に表示を迅速にズーム可能であることが好ましい。ユーザがズームされたビューで表示スクリーンの最上部付近に表示したいと考える垂直方向の位置に、所望のテキストコラムを越えて、ポインティングデバイス11902をドラッグすることによって、ユーザはこれを実行することができる。表示がこの種類のズームを実行するモードの状態である場合、図119に図示された種類の水平線形ドラッグによって、その表示がスクリーンの幅に適合するように、ドラッグによって示されたウェブページレイアウトの幅を拡大/縮小する。図119に図示された例に於いて、このユーザ入力によって、図120に図示されたように、その表示がズームされる。
また、ユーザインターフェースによって、ユーザはスクリーン上に図示されたウェブページレイアウトに於ける領域の周囲の選択ボックスをドラッグすることが可能となり、ウェブページに於いて選択された領域がスクリーンに適応するように、システムがウェブページの表示をズームすることが好ましい。
また、そうしたドラッグに於いて、ユーザがスクリーンの所定の端部に関連付けられた境界を越えて、ポインティングデバイスをドラッグ可能であることが望ましく、これが実行される場合、これに対応して、そうしたドラッグの開始として、スクリーン内に全体的に適合するには大き過ぎる、又は、不適切に位置づけられているウェブページレイアウト内で、幅、高さ、又は、領域に適合させるためのズームをユーザが実行することを選択可能にするために、スクリーン上に表示されたウェブページの部分がスクロールするそうしたドラッグによって、大き過ぎてドラッグ中に表示される倍率でスクリーン上に適合出来ないレイアウトの部分が選択される場合、テキスト及び画像が表示されるサイズを低減するために倍率を変更する。
レイアウトに於ける選択された幅、高さ、領域がスクリーンに適合するように拡大/縮小されるということは、その最大次元が、スクリーンの3分の2、及び、完全に対応する次元との間の範囲に分布するように拡大/縮小されるということを意味する。一般的には、そうした拡大/縮小によって、選択された長さ及び領域が、スクリーンの80乃至90%から完全に対応する次元の範囲まで分布する最大次元を有することが望ましい。
図121乃至図128は、ズームクリックと呼ばれる本発明の特徴を図示している。この特徴によって、低解像度で見られるスクリーン、極めて小さなスクリーン、又は所望のスクリーン位置に関連して正確に容易に配置出来ないポインティングデバイスと共に使用されるスクリーン内で、ユーザがより簡単に、且つ、正確にアイテムを選択することが出来る。これが特に有用であるのは、携帯電話サイズのスクリーン、ポインティングデバイスとして指を使用するタッチスクリーンデバイス、及び/又は、ポインティングデバイスを正確にセットすることが困難な走行中の車などの環境で使用されるタッチスクリーンデバイスを取り扱う場合である。
ズームクリックに於いて、ユーザがスクリーンに於ける所定の位置でクリックダウンする場合、ユーザがクリックしたスクリーンの部分が拡大された縮尺で表示される。その後、ユーザは、所望の位置にポインティングデバイスが位置するまで、この拡大された表示に於いて、押下されたポインティングデバイスで自由にナビゲートする。この時点で、ユーザはポインティングデバイスの押下を終了し、解除することができ、これにより、押下の解除に於ける現在の位置が、従来のグラフィカルユーザインターフェース(GUI)のクリックに対応する目的の為に選択された位置として取り扱われる。
ズームクリックを使用して、ダブルクリックを異なる方法で表現することが出来る。最も簡単な方法の一つは、単にズームクリック直後の素早い第2のクリック及び解除を記録し、ズームクリックをダブルクリックに変換するように、ズームクリックと同一位置に接近することということである。
ズームクリックに関する他の実施形態では、異なって動作するが、好ましい実施形態によって、ズームクリックに於けるダウンクリック中の拡大図に於けるポインタの動きは、そうした拡大/縮小図に於ける通常のポインタナビゲーションと同一の割合で発生する。これは、例えば、表示解像度を2倍にするズームクリックに於いて、ユーザが他の場合に比して2倍のポインティング解像度を有することを意味する。また、ズームクリックモードでダウンクリックを維持する間にユーザがポインタを移動させると同時に、スクリーンの端部、又は端部付近に到達する場合、このモードでユーザがページ全体をナビデートすることが出来るように、画像がスクロールすることが望ましい。
図121乃至128の例に於いて、2つ折りの携帯電話機/コンピュータ120Cが図示されている。この例では、携帯電話機が320×240全ピクセル解像度、及び、カラーサブピクセルアドレス指定能力を有することが想定されている。言うまでもなく、本発明の他の実施形態に於いては、他の解像度を使用することが出来る。使い易くするために、携帯電話機は、ユーザの指で操作可能なタッチセンシティブスクリーンを有すると仮定されている。他の実施形態に於いては、タッチパッド、消しゴム付きポインタ、マウス、ナビゲーションボタン、超音波ビジュアルタッチスクリーンポインタ位置検出装置など、他の種類のポインティングデバイスをズームクリックと共に使用することが出来る。
図121は、図11及び図110に示す「priceline.com」のウェブページと同一の画像を有する携帯電話機を図示している。
図122は、ズームクリックモードで、ユーザが図110に関して議論したものと同一のテキスト入力フィールド11000を選択するために、スクリーン上にユーザの指12102を押下しようとする場合に、何が起こるかを図示している。ユーザが自分の指をタッチスクリーンに接触させる際に、カーソルが置かれる正確な位置を前もって推定することは困難な場合が多い。ズームクリックがこれに対して役立つのは、任意の選択がなされる前に、タッチスクリーンを接触している指から生じるカーソル170の位置をユーザが確認することが出来るからである。また、それは、例えば図123に図示された所望のテキスト入力フィールド1100など、ユーザが所望のリンクや制御の上にカーソル12204を位置付けすることを容易にする、より大きな表示尺度のスクリーンを図示している。
ユーザが図123に図示された位置に於けるカーソルを備えたタッチスクリーンから、指を離す時点で、図124に図示されているように、上述の図111に於いてポップアップキーボードが現れる場合と同様に、ポップアップキーボード11102が現れる。
図125に図示されているように、ズームクリックモードで、ユーザが、ポップアップキーボード11102に於いて所望の文字(この例では「b」)に接触しようとする場合、接触されたキーボードの部分の画像が大きく拡大される。図125に図示された例に於いて、ユーザは最初にタッチスクリーンを押下した時点では、カーソル12204を正確に所望の位置に位置付けていない。ユーザは、図126に図示された位置にカーソル11102を位置付けるために、指12202をドラッグすることによって、ズームクリックモードに於けるこの問題を容易に修正することが出来る。その後、ユーザがスクリーンから指を離す場合、スクリーン画像は通常の縮尺に戻るが、これにより、次の文字がキーボード内の何処に位置しようが、ポップアップキーボード11102の全体が表示されて、次の文字を迅速に選択することが可能となる。
図127に図示されているように、図126に於ける選択された文字「b」は、ポップアップキーボードのテキスト入力フィールド11104に入力されたように表示される。
ユーザが、図125乃至127に図示された処理によって文字の選択を継続する場合、ユーザは、「Enter(入力)」キーの選択を受けて、テキストの全文字列を入力することが出来るようになり、これにより、図128に示されたように、ウェブページの所望の位置に所望のテキストが入力される。
本発明の多くの実施形態に於いて、ズームクリックで使用されるズームは、スクリーン上の全部又は一部に以前表示されたビットマップを、例えば2倍、3倍などの整数倍で拡大することを含む。これにより、比較的処理能力の低いプロセッサを使用した場合でも、そうしたズーミングを実質的に瞬間に実行することが出来るので、ズームクリックは極めて速いユーザインターフェースとなる。
図129乃至137は、ウェブブラウザのユーザが、実質的により大きな倍率でライン境界を越えて、リフロー、又は、再レイアウトされるウェブページからテキストの部分を選択することが出来る発明の特徴を図示している。そうしたテキストのリフローは、小型スクリーンを有する表示上で特に有用であるが、これは、テキストのリフローによって、選択されたウェブテキストが、さらに大きなフォントで表示され、同時に、そうしたテキストの全ラインがそうしたスクリーン内に適合することが出来るからである。これにより、そうしたテキストの連続するラインを読むために、繰り返し水平方向にスクロールを進めたり戻したりする必要がなく、そうしたラインを素早く読むことが出来る。
小型スクリーン表示の解像度がどの程度高解像度であるかに関わらず、表示が比較的接近して保持されていない限り、人間の目では比較的大きな解像度でそれが表示するもののみを視認することが出来る。本発明のこの特徴によって、ウェブテキストを、比較的大きな倍率で表示の幅内に適合するラインを越えて一塊として表示することが出来る。例えば、それにより、対角4インチスクリーンを有するハンドヘルドコンピュータのユーザは、5、6フィート離れて立っている人のグループが見るのに充分な大きさの縮尺でテキストを表示することが出来る。同様に、それにより、ユーザは携帯電話や腕時計サイズの表示を顔の近くまで保持することなく、これらの表示上でテキストを視認することが出来る。また、スクリーンから比較的遠くに離れた人や、視力が正常ではない人に対して、ウェブテキストを表示するために、通常のサイズのコンピュータ表示スクリーンと共にそれを使用することが出来る。
図129は、本発明の該特徴に従って、ウェブテキストを再表示するためにクライアントコンピュータで使用可能なプログラム12900に関する、高度に簡略化された擬似コード記述を示している。
当然のことながら、本発明の該特徴はクライアントコンピュータでの使用に制限されない。事実、図140乃至141に関して後述する種類のシステムに於いて見られるように、ウェブブラウザ以外のアプリケーションによって生成されたビジュアル出力を見る際に、変更を加えて、本発明の該特徴を使用することが出来る。
多くのウェブページは、異なるコラムにテキストをレイアウトするように、即ち、そうしたレイアウトに関連して異なる水平方向の位置にテキストをレイアウトするように設計されている。ウェブページは、テーブルやフレームの使用を含む複数の異なる方法で、そうした異なる所望の水平置換を示すことが出来る。好ましい実施形態に於いて、異なる所望の水平置換に関するそうした指示を反映するために、そうした複数コラムレイアウトで、ウェブページのテキストを表示するオプションを有するウェブブラウザを用いて、そうしたテキストのリフローが使用される。ユーザが、新しい倍率で1つのコラムに於けるテキストのリフローに対して、そうしたマルチコラムウェブページレイアウトの領域を選択する場合、関数12902によって、関数12904乃至12908が実行される。
本発明の幾つかの実施形態に於いて、ユーザがより大きな縮尺でリフローしたいと考えているウェブページの幅の部分を越えて、例えば図130に図示されたスタイラス11902等のポインティングデバイスをドラッグすることによって、そうした選択を実行する。現在議論している方法によって、テキストをライン境界を越えてリフローすることができ、テキストの選択されたコラムをさらに大きなフォントで表示し、同時にそうしたテキストのライン全体をスクリーン内に適合させるという点を除いて、これは、図119に関して既に議論した内容と同様である。
図129の関数12904は、選択されたレイアウト領域内に実質的に存在する、現在のウェブページのレイアウトに於ける全ての文字列と対応する下線部(即ち、リンクとしてのテキストのラベリング)を選択する。
図131は、図117の下半分に示された図に類似した、図130に図示されたウェブページのレイアウト10206Aの最上部を図示している。図131に於いて、破線の矩形13102は、図130に於いてユーザによって選択されたコラムに対応するウェブページのレイアウトの部分を表している。
本発明の幾つかの実施形態に於いて、かなりの部分、例えば、その長さの3分の2、又は、4分の3が、ユーザによって選択された領域内に適合する場合、文字列は選択された領域内に存在すると見なされる。例えば、図130に於いて、ユーザは同図に表示されたスクリーンの右側部分でテキストを選択しようとしていた。しかし、図130の例では、ユーザは、スタイラスのドラッグで、意図したコラムの幅を正確に選択することが出来なかった。それにも関わらず、関数12904は、選択された領域内に実質的に存在する全文字列を選択するので、あたかもユーザが意図したコラムを正確に選択したかのように、テキストリフローが実行される。
図132は、選択された領域内に含まれる、図131に図示されたウェブページのレイアウトに於ける文字列の最初の部分を図示している。この図に於いて、下線部はリンクに対応するテキストの部分を示している。
選択された領域の文字列の全てが選択された時点で、関数12906は、レイアウトに於ける接近性又は他の特質によって、それらが同一パラグラフの一部であることを示す、1つ又は複数の連続する文字列の内、任意のグループをラベル付けする。これは、パラグラフブラケット(Pが付された括弧)13202によって、図132に図示されている。
図132に図示されたように、この方法は、パラグラフである文字の全グループ分けを検出しない可能性があるが、そのテキストに対応するHTMLを参照する必要なく、それらの多くを検出するのである。記載されている本発明の実施形態に於いて、そうしたHTMLがプロキシサーバに保存されるが、これは、そのようなアクセスがクライアントコンピュータ及びプロキシサーバ間の通信に関連付けられた遅延が必要となることを意味している。他の実施形態に於いて、特に、クライアントコンピュータが常駐するフルブラウザを有する実施形態、又は、プロキシコンピュータへの高いアクセス回線容量接続を有する実施形態に於いて、選択された文字列が如何にしてパラグラフに於いてグループ化されるべきかを、より正確に決定するために、HTMLコードへのアクセスを使用することが出来る。他の実施形態に於いて、プロキシサーバにダウンロードされたレイアウト情報は、ウェブページのHTML内に含まれるパラグラフ境界に関する任意の情報を有することが出来る。幾つかの実施形態に於いて、そうしたリフローされたテキストを表示する薄型クライアント上ではなく、プロキシサーバ上で、そうしたテキストのリフローを実行することができ、これにより、プロキシサーバは、ウェブページの表示に含まれたパラグラフのグループ分けに関する任意の情報に直接アクセスすることが出来る。
選択された文字列がパラグラフにグループ化された時点で、関数12908は、表示スクリーン(又は、画像が表示スクリーン全体よりも小さい領域に表示されている場合には、表示ウインドウ)の幅を越えて、選択された拡大倍率を使用して、各パラグラムのテキストをリフローする。
このテキストリフロー処理は、図132の最上部に於ける文字列が新しい倍率でレイアウトされている図133に図示されている。図示されている例に於いて、図130のテキストは、同一スクリーン内に於いて元のサイズの2倍でリフローするために選択されている。薄型クライアントのユーザインターフェースによって、ユーザが適度なフォントサイズから極端に大きなフォントサイズに及ぶ、選択されたテキストリフロー関数を用いて使用される、複数の異なる倍率を選択可能であることが好ましい。
図133に於いて、下線部は図132の下線部とは異なるものを表示するために使用されている。図133に於いて、図132に於ける通常のレイアウト文字列から生じた各ライン上のテキストは、連続するアンダーラインで図示されている。図132に於ける異なる文字列から生じる、図133に於ける同一ライン上のテキスト部分の間に於ける下線部の間隔は、それらの違いをより簡単に見ることが出来るように誇張されている。
図133に於いて、ラインの境界を越えて一塊になっている図132に図示された元のレイアウトから生じる個々の文字列の全てが、1つのライン上の部分から、次のライン上の継続する部分まで、矢印によって示されている。
図134は、図130及び131に図示された元のレイアウトの選択された文字列が、薄型クライアントのスクリーン上に約2倍のサイズでリフローされた時点で、どのように見えるかを示す概略図である。図134を参照して分かる通り、ウェブテキストはそうしたテキストリフローによって、遠くから格段に見易くなる。2倍の代わりに、4倍又は6倍で同一テキストをリフローすることによって、表示スクリーンから相当離れた場所にいるユーザに対して、同一ウェブコンテンツを表示することが可能になる。
図135乃至137は、リフローされるテキストの部分をユーザが選択可能な他の方法を図示している。
図135は、他のテキストの一部分、又は、複数部分が侵入するテキストの中央コラムを有するウェブページの部分を図示している。
図136は、ウェブページ全体のレイアウトの縮小ビューをユーザがどのように取得したかを図示している。多くの実際の実施形態に於いては、小さ過ぎるので個々の文字としてそうした縮小ビューで表示することが出来ないテキストの部分を示すために、テキストグリーキングが使用される。ウェブページ全体のレイアウトが薄型クライアント自体に保存された、図115乃至117に関して上述されたような、薄型クライアントコンピュータ上で、そうした縮小ビューを迅速に生成することが出来る。
図136に於いて、多角形領域に於ける角部でウェブページの表示をクリックすることによって、ユーザが拡大ウェブページビュー上のそうした領域を定義可能なモードを、ユーザが選択している。これが実行される時点で、何れのテキストがリフローされるかを選択するために、選択された領域が図129に図示された関数12904によって使用される。
図137は、選択されたテキストがリフローされ、表示された時点で、選択されたテキストがどのように見えるかを図示している。
図138乃至139は、図2に関して上述されたフォントサーバ230をより詳細に説明している。
図138に於いては、複数のクライアントブラウザ200が存在し、各クライアントブラウザが、同一のプロキシサーバ210を介して1つ又は複数のサーバ220からのコンテンツにアクセスし、同一フォントサーバ230からのフォントにアクセスするという点を除いて、図138は図2に対応している。
これは、各薄型クライアントブラウザで使用するために販売され、ライセンスを受け、又は、頒布されたソフトウェアが、クライアントが有していないフォントを同一フォントサーバ230から検索するようにプログラムされ、同一プロキシサーバ210を介してウェブ要求を実行するようにプログラムされているからである。言うまでもなく、本発明の該特徴に関する他の実施形態に於いて、薄型クライアントは、それらの地理的位置、又は、インターネットサービスプロバイダなどの要因に基づいて、一般的な複数のプロキシサーバの内、何れのプロキシサーバを使用すべきかを選択するようにプログラムされている。フォントを要求、受信する一般的な複数のフォントサーバの内、何れかのフォントサーバを選択するために、薄型クライアントは同様の内容を検討することが出来る。
図139は、図138に図示された種類のフォントサーバ上で使用可能なプログラム13900の高度に簡略化された擬似コード記述である。また、通常のブラウザコンピュータに加えて、ウェブブラウザ以外のアプリケーションを実行するコンピュータに対してフォントを供給するために、このフォントサーバを使用することが出来る。
フォントサーバが、コンピュータから指定されたフォントの文字に対するHTTP要求を受信する場合、関数13902によって、ステップ13904乃至13922が実行される。
図139に図示されたフォントサーバコードの特定の実施形態は、指定されたサイズで指定されたフォントに対して設計された各文字を別個のHTTP要求で特定するプロトコルと共に使用するために設計されている。それは、所望のフォント、フォントサイズ、及び、文字を、URLパス名の一部として指定する。言うまでもなく、他の実施形態に於いては、フォントサーバによって、HTTP要求が複数の文字、複数のフォントを指定可能であり、そして/又は、URLパス名以外でフォントを指定することが可能である。
各文字フォント形状を別々に要求するシステムに於いて、HTTPプロトコル1.1又はそれ以降のプロトコルが使用されることが好ましいが、これは、そうした各要求を処理するために別個の接続をオープン、又は、クローズする必要なく、そうしたプロトコルによって、複数のHTTP要求を所定のクライアントコンピュータからサーバによって処理することが出来るからである。
図139に図示された本発明の実施形態に於いて、フォントサーバが、要求に於いて指定されたURLパス名に一致するフォントビットマップを現在保存していると判断する場合、関数13904によって、関数13906が、URL要求がなされたネットワークアドレスに対するHTTPの応答に於いて、そのフォントを送信し、その後、関数13908が関連するアカウントに処理を命令する。そのようにダウンロードされたフォントは、フォントビットマップ、又は、フォントアウトライン記述の何れかであっても良い。
そうしたアカウントの命令は、本発明のすべての実施形態に於いて使用される訳ではない。それが使用される実施形態の幾つかに於いて、命令されたアカウントは、フォントが送信されるコンピュータに関連するアカウントである。他の実施形態に於いては、命令は、そうしたフォントの仕様を含んだウェブページに関連付けられたグループのアカウントに対して行われる。さらに他の実施形態に於いては、命令は、上述した種類のプロキシサーバに関連付けられたアカウント、又は、そうしたプロキシサーバのサービスのユーザに対して行われる。
要求されたフォントがフォントサーバの記憶装置に存在せず、要求されたフォントがフォントサーバの対応するアウトラインフォントを有するビットマップである場合、関数13910によって、関数13912乃至13922が実行される。
関数13912は、HTTP要求のフォントパス名によって示されたサイズ及び実行可能な変換などの属性を有するビットマップを生成する。この関数は、要求されたフォントのパス名によって、サブピクセル最適化バージョンのフォントが望まれていることが示されたかどうかを決定することを含む。それが示された場合、関数13914及び13916は、好ましくは、図55乃至96に関して上述された非線形カラーバランス法を使用して、サブピクセル最適化バージョンのフォントを生成する。
フォントビットマップが生成された時点で、関数13918は、ネットワークを介して、要求中のアドレスに対するHTTPの応答に於いてビットマップを送信する。関数13920は、要求に於いて指定されたパス名に対応するアドレスで、フォントビットマップをキャッシュする。関数13922は、関数13910に関して既に議論したように、命令が実行される実施形態に於いて、処理に関連するアカウントに命令する。
図140は、リモートコンピュータ1400上で起動する1つ又は複数のアプリケーションによって、薄型クライアントコンピュータ200が、スクリーン出力として生成されたテキスト及び画像に対応するデジタルコンテンツを表示することが出来るように、本発明の特定の特徴を使用することが出来ることを図示している。そうしたアプリケーションは、ウェブブラウザ、表計算、ワードプロセッサ、データベースプログラム、又は、仮想スクリーン表示を生成可能な以如何なる種類のソフトウェアであっても良い。
リモートコンピュータは、リモートコンピュータのオペレーティングシステム14004のディスパッチテーブル14008に於けるフックを含む、リモートスクリーン生成プログラム14006を含む。これらのフックは、所定の表示解像度でスクリーンに対して、テキスト、形状、ライン、制御オブジェクト、ビットマップを描画するために、一つ又は複数のアプリケーション14002によって実行されたオペレーティングシステムに対する呼び出しを遮る。幾つかの実施形態に於いて、そうした描画コマンドによって、コンテンツがリモートコンピュータに関連付けられたスクリーン上に実際に表示され、その他の実施形態に於いては、リモートコンピュータにはスクリーンが存在しないので、そうした描画コマンドが仮想スクリーンに対して実行される。以下のテキストに於いて、簡略化するために、仮想スクリーンとして、所定のクライアントコンピュータ上でグラフィック出力を表示し、ユーザ入力を受信しているとこれらのアプリケーションが判断する映像空間について言及する。
アプリケーション14002の1つがオペレーティングシステムに対して表示要素を描画するように要求する場合、リモートスクリーンジェネレータの対応するルーチン14010への対応する呼び出しを行うために、オペレーティングシステムのディスパッチテーブルに於けるフックの一つによって、その呼び出しが遮られる。図102、及び、106A乃至106Cに関して上述した方法と同様の方法に於いて、これにより、図102及びそれに続く図に関して上述された表示リスト10212と実質的に類似した、ダウンロード表示リスト10212Aが生成される。そうしたシステムに関する多くの実施形態に於いて、ビットマップ描画ルーチンの呼び出しによって、上述の種類の縮小及びサブピクセル最適化された画像がダウンロード用に生成され、測定文字列ルーチン及び文字列描画ルーチンへの呼び出しは、8ピクセル/em又はそれ未満と同様に小さなサイズのフォントを含む、サブピクセル最適化されたフォント又は他のアンチエイリアス処理されたフォントの置換及びフォントマトリクスを含む。
図102に図示された制御10214乃至10218に対応する、ズーム、スクロール、及び、仮想レイアウト制御1412は、仮想スクリーンへの薄型クライアントのビューウインドウのマッピングを制御し、したがって、アプリケーションによって仮想スクリーンに描画された要素が、ダウンロード表示リスト10212Aに描画され配置される表示倍率を制御する。これが画像ビットマップのサブピクセル最適化と、図106A乃至106Cに関して上述された種類のフォント置換とを含むことが好ましい。
ダウンロード表示リストが所定の仮想スクリーンに対して生成された時点で、図109A乃至109Cに関して上述された方法と同様の方法で、後にそのスクリーン上にダウンロード表示リストを描画する、対応するクライアントコンピュータにダウンロード表示リストが圧縮され、ダウンロードされる。
本発明の幾つかの実施形態に於いて、仮想スクリーンに対する個々の描画は、薄型クライアントにダウンロードされた対応する描画コマンドを有する。仮想スクリーンへの対応する変更に応答して、薄型クライアントスクリーンに対する僅かな変更を実行可能な速度を速めるために、これを利用することが出来る。
図140に図示された実施形態に於いて、スクリーン位置に関連付けられたユーザ入力が、薄型クライアントからリモートコンピュータにアップロードされ、スクリーン位置は、薄型クライアントのビューウインドウと仮想スクリーン間のマッピングを反映するために、スクリーン座標を変換させる。これが実行される時点で、そうしたイベントは。それらの変換されたスクリーン座標を用いてリモートコンピュータオペレーティングシステムのイベント待ち行列にセットされ、これにより、関連するアプリケーション14002は、あたかもそれがリモートコンピュータの対応する仮想スクリーン上に入力されたかの様に、そのイベントに対応する。
例えば、ラップリンク社(所在地:ZIPコード98011、アメリカ合衆国 ワシントン州 ボセル ノースクリークパークウェイ 18912 スイート100)のLapLink、又は、シマンテック社(所在地:ZIPコード95014 アメリカ合衆国 カリフォルニア州 クパティーノ スティーヴンスクリークブルバード 20330)のpcAnyware等の、スクリーン共有アプリケーションによって使用される技術の多くを、図140に図示された種類の本発明の実施形態と共に使用することが出来る。実際、同図に於けるリモートコンピュータが自身のスクリーンを有する場合、図140に図示された実施形態を、クライアントコンピュータとリモートコンピュータ間でのスクリーン共有を実行するために使用することが出来る。
当然のことながら、クライアントコンピュータが十分な演算能力を有する実施形態に於いては、クライアント及びリモートコンピュータは、ピアツーピアの方法で動作可能である。リモートコンピュータは、専用のアプリケーションサーバコンピュータであっても良いし、例えば、デスクトップコンピュータ、ラップトップコンピュータ、又は、タブレットコンピュータを含むパーソナルコンピュータ等の如何なる種類のコンピュータであっても良い。
図141は、上述した本発明の特徴に従って、そうしたアプリケーションによって生成されたスクリーン表示が、縮小、及び/又は、サブピクセル最適化されるように、1つ又は複数のアプリケーション14002によって生成されたオペレーティングシステムの呼び出しを遮るために、コンピュータのオペレーティングシステム14004のディスパッチテーブル14008に於いてフックを用いている点で、図140に図示された実施形態に幾分類似している本発明の実施形態を図示している。図141の実施形態が図140に図示されたクライアントサーバの実施形態と異なるのは、図141に図示されているように、それが1つのコンピュータシステム14100上で動作するように設計されている点である。それらの出力があたかも高解像度を有する仮想スクリーンに表示されているかのように、修正することなく、そうしたプログラムを実行するために、低解像度スクリーンであるが、デスクトップアプリケーションの起動に十分なパワーを備えるコンピュータ上で、このシステムのプログラミングを使用することが出来る。また、より大型のスクリーンの一部に、アプリケーションの出力スクリーンに関する縮小版を描画するために、それを使用することが出来る。
この実施形態に於いては、それらの出力がスクリーン10220A上に表示される解像度に比して、より大きな仮想解像度で、スクリーン上で動作していることがアプリケーション14002に報告される。そうしたアプリケーションが、スクリーンに対して要素を描画するために、オペレーティングシステムに対する呼び出しを行う場合、OSディスパッチテーブル14008にセットされたフックによって、拡大/縮小されたサブピクセル最適化スクリーンジェネレータプログラム14006Aの一部分14010A内の対応する描画ルーチンが起動される。この置換描画ルーチンは、上述されたように、縮小、及び/又は、サブピクセル最適化されたビットマップの作成を含む、仮想スクリーン表示リスト10206Bに対応する要素を描画する。また、それによって、現在のビューウインドウ10210C内に適合する仮想スクリーンの部分に描画されたそうしたスクリーン要素の任意の部分が、オペレーティングシステムで描画コマンドを呼び出すこと、又は、それら自身をそのスクリーン上に直接描画することによって、コンピュータ14100の表示スクリーン10220A上に、縮小、及び/又は、サブピクセル最適化された方法で即座に表示される。
アプリケーションプログラムが測定文字列コマンドに対してオペレーティングシステムを呼び出す際に、そのコマンドも同様に遮られ、これにより、その呼び出しは、図106Aの関数10608乃至10618に関して上述された方法で、置換されたフォントサイズに対するフォントマトリクスを返す。
コンピュータのスクリーンへのスクリーンイベント入力は、オペレーティングシステムのイベント待ち行列から抽出され、そうしたイベントがスクリーン上で生成されたスクリーン座標を、そうした変換を制御するために、その仮想スクリーンへのビューウインドウのマッピングを使用して、表示リストによって表現された仮想スクリーンのレイアウトに於ける対応する位置に変換するイベント位置スケーラに送られる。イベントの座標が適切に変換された時点で、イベントはオペレーティングシステムのイベント待ち行列に戻され、オペレーティングシステムによって、あたかもイベントが仮想スクリーン上に入力されたかのように、アプリケーションがイベントに対応する。
図141に図示された種類の本発明に関する実施形態によって、コンピュータのユーザは、標準的なコンピュータアプリケーション14002によって生成されたスクリーン上で、それらのアプリケーションが、選択されたテキストリフローをサブピクセル最適化、縮小、ズーム、及び、実行する機能をサポートするべく設計されていない場合であっても、これらの機能を行うことが出来る。
図示しない本発明の他の実施形態に於いて、コンピュータのオペレーティングシステムは、図141に図示された拡大/縮小されたサブピクセル最適化スクリーンジェネレータ14006Aに図示された種類の機能性を含むように変更することが出来る。さらに本発明の他の実施形態に於いて、ブラウザプログラムを含むアプリケーションプログラム14002を、そうした機能性の全部又は一部を直接的にサポートするために変更することが出来る。
図142は、例えば、同図に図示された薄型クライアントコンピュータ200A乃至200Dなどの薄型クライアントコンピュータを、ワイヤレスネットワークを介して、インターネットコンテンツ、又は、アプリケーションプログラムにアクセスするために使用することが出来るように、図102及び140に図示された本発明の実施形態を如何にして使用することが出来るかを図示している。
この図に於いて、コンピュータ200A乃至200Dは、図102及び140に図示された薄型ライアントコンピュータ200に対応する。コンピュータ200Aはハンドヘルドコンピュータである。薄型クライアントコンピュータ200Bは、携帯電話機である。薄型クライアントコンピュータ200Cは、腕時計型コンピュータである。薄型クライアントコンピュータ200Dは、頭部装着型コンピュータ、又は、ポータブルコンピュータ用の頭部装着型ディスプレイである。これらの薄型クライアントコンピュータのそれぞれは、サブピクセルアドレス可能な表示を有することが出来る。
本出願の出願時に於いて、本発明の殆どの特徴で使用するのに充分高い解像度を有するうした種類の各装置に対して、現在スクリーンを製造することは可能である。例えば、現時点で、2インチ又はそれ未満の対角長を有する320×240カラーLCD表示を製造することは可能である。現在、さらに高解像度を有する有機LED装置を製造することが出来る。近い将来、そうした小型スクリーンのコストは低下するはずであり、それらの利用可能性及び解像度は増大するはずである。
図142に図示された薄型クライアントコンピュータの全ては、図102に図示された種類のリモートプロキシサーバコンピュータ210、又は、図140に関して図示された種類のリモートアプリケーションサーバ14000に関して上述された種類の情報を、送受信可能にするワイヤレストランシーバを有している。そうしたトランシーバは、ワイヤレスLANトランシーバ14204と通信するためのワイヤレスLANトランシーバであってもよく、ワイヤレスインターネットトランシーバ14202と通信するためのデジタル携帯電話ワイヤレストランシーバであってもよく、また、両方の種類のワイヤレストランシーバと通信するように設計されたトランシーバであることが望ましい。他の実施形態に於いて、例えば、Bluetooth又は赤外線通信など、他の種類の無線通信を使用することが出来る。
図142に図示されたリモートコンピュータ14000AA乃至14000ACは、図140に図示されたリモートサーバコンピュータ14000に対応する。
図142に図示されたリモートアプリケーションサーバコンピュータ14000AAは、ラップトップコンピュータ、デスクトップコンピュータ、サーバコンピュータ、又は、リモートアプリケーションサーバコンピュータ14000として動作するようにプログラム可能な他の種類のコンピュータを表現している。サブピクセル最適化されたアプリケーションサーバ14000ABは、そうしたクライアントに関連したLAN又はWANに接続された複数の薄型クライアントコンピュータ用のアプリケーションを実行するために設計されている、図140に図示された一般的な種類のリモートコンピュータである。リモートコンピュータ14000AA及び14000ABは、プライベートローカルエリアワイヤレストランスミッタ14204を介して、薄型クライアントと通信可能であるか、又は、数字10222及び14202によって示されているように、ワイヤレスインターネットを介して薄型クライアントと通信可能である。
サブピクセル最適化されたアプリケーションサーバ14000ACは、複数の薄型クライアントコンピュータ200がインターネットを介して、数字14202によって示されたワイヤレストランスミッションネットワークによって、アプリケーションを使用することが出来るように、直接的にインターネットに接続されている点を除いて、サーバ14000ABに類似したアプリケーションサーバである。
図142に於いて、図102に関して上述された種類のプロキシサーバ210は、LAN又はWAN14204に接続されていることが図示されている。例えば、これは、企業がインターネットに接続しないことを希望するウェブブラウズを処理しようとするプロキシサーバであっても良い。当然のことながら、例えば、商業的なプロキシ提供サービスを供給する企業によって運営されているプロキシサーバなど、他のプロキシサーバは、通常、図142に於いても同様に図示されたインターネット10222に直接的に接続される。
図142に図示されたシステムによって、実質、常に都合良く持ち運び可能な小型コンピュータは、ウェブページ及び殆どのアプリケーションプログラムの出力にアクセスし、表示することが出来る。本出願の出願時に於いて、例えば、図142に図示されたLANトランシーバ14204などの比較的安価なワイヤレスLANトランシーバの回線容量は、ケーブルモデムに接続されたデスクコンピュータ上でそうしたデジタルコンテンツを見ることが出来る速さと略同様の速さで、図142に図示された種類の薄型クライアントが、ウェブコンテンツ又はアプリケーションプログラムの出力を見ることが出来る程、充分に高速である。そして、これは、ポケットの中、手首の上、又は、眼鏡の一部として持ち運び可能な機械であり、スイッチがオンの状態になって数秒以内にそうしたメディアにアクセス可能な機械装置である。
本出願の出願時にアメリカで一般的に利用可能なデジタル携帯電話の回線容量に於いて、通常、殆どのウェブページのテキスト全体をダウンロードするためには数秒かかり、ウェブページの画像をダウンロードするには、さらに時間がかる。言うまでもなく、本発明の多くの実施形態は、テキストの一部が受信され次第、テキストの表示を開始し、ユーザはダウンロードされたページの一部を極めて迅速に見始めることが出来る。
本出願時に於いて、数十万ビット/秒、又は、数百万ビット/秒の範囲で回線容量を提供可能な、新規のより高速なデジタル携帯電話システムが開発されている。そのような、より高速のシステムが一般的に展開されるようになった時点で、本発明のユーザは、DSLやケーブルモデム接続を介して、デスクトップ又はラップトップ上でウェブページにアクセスする場合と殆ど同じスピードと快適さで、ユーザが移動する殆どの場所で数秒以内にスイッチをオンの状態にすることが可能な小型のポータブルデバイス上で、ウェブページ及びアプリケーションスクリーンを読み取ることができ、やり取りすることが出来る。
本発明のユーザは、DSL又はケーブルモデムを介してデスクトップコンピュータ又はラップトップコンピュータ上でアクセスしているかのように、移動先の大抵の場所でスイッチオンから数秒以内に使用され得る小型の携帯装置上で、ウェブページやアプリケーション画面を読んで相互に対話出来る様になる。
図143乃至144は、図102に関して上述された種類のプロキシサーバ、又は、図140に関して上述された種類のリモートアプリケーションサーバコンピュータの何れかに対して、薄型クライアントとして機能することが出来る、ハンドヘルドコンピュータ200Aに関する2つの図を示している。
図143に於いて、コンピュータは、使用するために設計された縦方向で図示されている。コンピュータ上のネイティブオペレーティングシステムは、フォント及びグラフィカルユーザインターフェース(GUI)要素を縦方向で描画するように設計されている。これは、本出願の出願時に販売されたハンドヘルドコンピュータの多くが設計され、構築された方法である。例えば、今日、240×320全ピクセル解像度を有するサブピクセルアドレス可能スクリーンを有する、複数のそうしたハンドヘルドコンピュータが市場に存在する。また、これらのコンピュータの多くは、表示が意図された縦方向に位置する時に、水平方向に走るサブピクセルストライプを有する。
残念ながら、そうした縦方向では、殆どの人がコンピュータの使用時に慣れており、且つ、殆どのウェブページが設計されている横方向の縦横比の種類を提供しない。更に、そうしたコンピュータが水平方向のサブピクセルストライプを有する場合、そうしたストライプは、垂直方向に於いて、サブピクセル解像度の全ての潜在的増加をもたらす。残念ながら、テキストの表示は、そうした垂直方向の解像度に於ける増加に比して、水平方向の解像度に於ける増加から、実質的に恩恵を受ける傾向がある。
これらの全ての理由のために、そうした縦向きの機械を使用する本発明の多くの実施形態は、図144に図示されているように、そうした機械を90度回転させた場合に、それらを使用するように設計されており、それ故、殆どのコンピュータスクリーンのレイアウトに関する縦横比にむしろ近い、横方向の縦横比を有しており、その結果、それらのサブピクセルは、テキストの表示に最も有用な水平方向の解像度に於ける増加を提供する。そうした多くの実施形態に於いて、上述の薄型クライアント200は、横方向の機械装置として見られるために回転され、縮小フォント及び画像ビットマップが横方向で描画される縦方向の携帯情報端末(PDA)である。サブピクセル最適化を使用するそうした実施形態に於いて、そうしたPDAを使用するために設計された縦方向でピクセルが見られる場合に現れるサブピクセルの直交配置というよりは、そうしたピクセルが横方向で見られる場合に現れる各ピクセル内のサブピクセルの空間配置に対してサブピクセル最適化された画像、及び/又は、フォントビットマップを使用して、ウェブページが表示される。
図145は、サブピクセル最適化を使用して、例えば、矩形、楕円、線、及び、曲線などの基本的な形状を描画する要求に対応するために、本実施形態の幾つかの特徴を如何にして使用することが出来るかを示す、高度に簡略化された擬似コード表記である。多くの異なる種類のアプリケーション、オペレーティングシステム、及び、薄型クライアントソフトウェアに於いて、そうした機能を使用することが出来る。
図145の例では、図示された擬似コードは、他の使用方法の中でも、図109Aに関して上述された矩形コマンド10918の代わりに使用可能な矩形描画関数14500に関連している。そうしたルーチンは、その位置、幅、及び/又は高さが、表示されるサブピクセルアドレス可能スクリーンの全ピクセル解像度に比して、より高度な解像度で定義された矩形を描画するための呼び出しによって、呼び出される。これに対応して、関数14502は、そうしたより高度な解像度で定義された矩形の画像をレンダリングするために、サブピクセル解像度でサブピクセル最適化ルーチンを使用する。例えば上述のスキームのように、多くの場合、非線形カラーフィルタリングを有する2色最適化スキームが、最高の視認可能な空間解像度を提供する傾向のあるモノクロ矩形を別にすれば、仮想の任意のサブピクセル最適化スキームを使用して、これを実行することが出来る。
図146は、サーバからダウンロードされたアプレットによって、クライアントのスクリーン上にサブピクセル最適化したスクリーン要素を描画可能とするための、サーバ及び/又はプロキシコンピュータ上で起動可能なコード14602、及び、薄型クライアントコンピュータを含む、クライアントコンピュータ上で起動可能なコード14604に関する高度に簡略化された擬似コード表記14600である。
そうした実施形態に於いて、クライアントの関数14606は、サーバからメディアを要求する。クライアントコンピュータ上で起動可能な1つ又は複数のアプレットプログラムを含む、メディア又はデータをダウンロードすることによって、サーバは関数14608で対応する。関数14610に於いて、クライアントコンピュータは、アプレットを含むメディアを受信し、関数14612はそのアプレットをロード及び実行する。関数14614に於いて、クライアントコンピュータ上のサブピクセルアドレス可能スクリーンにサブピクセル最適化された要素を描画する。
サブピクセル最適化されたビットマップを複製又は生成すること、サブピクセル最適化されたフォントでテキストをレンダリングすること、例えばベクトル定義されたグラフィック、又は、例えばライン、矩形、及び、楕円などの比較的単純な幾何学的形状など、サブピクセル最適化された形状を描画すること、の何れかによって、アプレットはサブピクセル最適化された要素を描画することが出来る。
図147及び148は、ロールオーバ画像、及び、GIFFアニメーションのそれぞれに対して、サブピクセル最適化を如何にして適用することが出来るかを図示している。
図147に図示されたサブピクセル最適化ルーチン14700に於いて、ポインティングデバイスが検知出来るように、画像に関連付けられたスクリーンの部分に存在しない場合に表示される非ロールオーバ画像14702と、ポインティングデバイスが検知出来るように、そのスクリーン部分に存在する場合に表示されるロールオーバ画像14704は、両方とも、関数14706によって縮小され、サブピクセル最適化される。これにより、拡大/縮小され、サブピクセル最適化された非ロールオーバ画像14708、及び、拡大/縮小され、サブピクセル最適化されたロールオーバ画像14710が生成される。次に関数14712は、ポインタがそれらの関連付けられたスクリーン領域上に検出可能に存在するか否かということに基づいて、これらの2つのサブピクセル最適化された画像の内、何れを表示させるのかを選択するために使用される。これにより、2つのサブピクセル最適化された画像は、複合「ロールオーバ」グラフィックとして機能する。
本発明のこの特徴に関する他の実施形態に於いて、同様の技術を、ボタンに関連付けられた2つの画像、即ち、ボタンが押下されてない場合に表示される画像と、ボタンが押下されている場合に表示される画像、に適用することが出来る。
図148に図示された方法14800は、図147に関して上述された方法に類似している。それは、GIFFアニメーションの別個の画像14802乃至148906のそれぞれを取得し、縮小され、サブピクセル最適化された対応するGIFFアニメーション一式を生成するために、関数14808に於いてサブピクセル最適化する。次に、関数14816は、サブピクセル最適化されていないGIFFアニメーションが表示される方法と実質的に同一の方法で、サブピクセル最適化された画像を表示する。
薄型クライアントコンピュータ上のスクリーンを含む、サブピクセルアドレス可能スクリーン上のウェブページへのアクセスを含む上述の発明に関する他の特徴を用いて、図147及び148に関して上述されたサブピクセル最適化を使用することが出来る。
図149は、3Dアニメーションをサブピクセル最適化する方法14900を図示している。この方法は、アニメーションの連続フレームのそれぞれに対して、関数14904乃至14908一式を実行することを含んでいる。
関数14904は、現在のフレームのビットマップ、又は、最後のフレームから変更された画像の少なくともそれらの部分のビットマップを作成するために、3Dアニメーションエンジンを実行する。この関数は、そうしたビットマップのサブピクセル最適化されたバージョンが表示される全ピクセル解像度よりも高解像度で、そうしたビットマップを生成する。
次に関数14906は、フレームビットマップ、又は、少なくとも最終フレームからのフレームビットマップに於いて実行された変更を、縮小及びサブピクセル最適化するために、例えば上述された技術などの技術を使用する。
次に、関数14908は、フレームビットマップの、縮小され、サブピクセル最適化された画像、又は、少なくともフレームの変更された部分の、縮小され、サブピクセル最適化された画像を、サブピクセルアドレス可能スクリーン上に表示する。
ユーザがゲームを実行することができ、サブピクセル最適化によって可能となるより高度な解像度で、そうしたゲームで生成される画像を視認することが出来るようにするためには、図149に図示された方法が特に有用である。小型スクリーンを有するハンドヘルドデバイスに於いて、そうした目的をその方法に使用することが出来る。リモートコンピュータ上で生成されたアニメーション画像を表示するクライアントコンピュータ、及び、そうした動画をローカルに生成するコンピュータの両方にその方法を使用することが出来る。
図150及び151は、図149の方法がクライアントサーバのゲームアプリケーションで使用可能な一つの方法を図示している。
図150は、そうした実施形態に於いて使用されるゲームサーバコンピュータ上でのプログラム15000を図示している。数字15002及び15004で示されているように、ゲームサーバが、1つ又は複数のゲームクライアントコンピュータからユーザ入力を受信する場合、入力をゲームエンジンに送信する。そうした入力がスクリーン入力の場合、ユーザのスクリーン解像度と、ゲームエンジンがスクリーン入力と関連付ける空間との差を補正するために、入力が適切に拡大/縮小される。
関数15006に於いて、ゲームエンジンのコンピュータは、現在のフレーム、又は、以前の表示リストに対する現在のフレームに関連付けられた任意の変更に対する表示リストを算出する。次に、関数15008は、3Dレンダリングプログラムに、現在のフレームに対して生成された表示リストに対応するフレームビットマップをレンダリングさせ、現在のフレームのビットマップに必要な変更をレンダリングさせる。そうしたビットマップは、関数15010によって生成されるサブピクセル最適化画像の解像度よりもより高度な解像度で生成される。
クライアントが異なるクライアントに対して異なるスクリーン画像を生成する場合、これらの別個のビューのそれぞれに対して、関数15008が別個に実行される。
次に、関数15010は、現在のフレームのビットマップ、又は、フレームに対する現在の変更のビットマップを、縮小し、サブピクセル最適化する。また、この関数がそうした変更のビットマップのみを縮小している場合、これに対して、それはそれらの変更に関連付けられたスクリーン位置を縮小する。
次に、関数15012は、サブピクセル最適化されたビットマップを圧縮し、そして適切な場合には、それらの位置を圧縮し、関数15014は、圧縮され、拡大/縮小され、サブピクセル最適化された画像と、クライアントに表示するための任意のそうした位置をダウンロードする。
図151は、図150のプログラムに使用するために設計されたゲームクライアント上のプログラム15100を図示している。
関数15101は、ダウンロードされた画像を受信し、関数15102はそれらを解凍する。次に、関数15104は、拡大/縮小された、サブピクセル最適化されたアニメーションフレームビットマップを表示、又は、以前のアニメーションスクリーンの画像に対する変更のビットマップを、そうした変更に適用された位置に表示する。これはサブピクセルアドレス可能表示に於いて実行される。
数字15106及び15108によって示されているように、クライアントがユーザ入力を受信する場合、そうした入力に関連付けられた任意のスクリーン座標が適切に変換されるように、その入力をゲームサーバにアップロードする。
本発明の該特徴に関する他の実施形態に於いて、ゲームサーバとゲームクライアント間の機能性の配分は異なる可能性がある。幾つかの実施形態に於いて、プロキシサーバとは異なるゲームサーバ上で元々生成されたゲームコンテンツを薄型クライアント上に表示するために、一般的に上述のプロキシサーバに類似したプロキシサーバをサブピクセル最適化の実行に使用することが出来る。さらに他の実施形態に於いて、ゲームクライアント自身がサブピクセル最適化を実行することが出来る。
図152は、関連付けられた透明マップを有する画像が、そうした画像、及び、関連付けられた透明マップの両方のサブピクセル最適化で表示することが可能な、本発明の特徴に関する高度に簡略化された擬似コード記述である。
図152に図示されたプログラム15200は、前景画像、即ち、背景又は他の以前のビットマップの最上部の表示が関連付けられた透明ビットマップによって制御される画像、に関する拡大/縮小されサブピクセル最適化されたビットマップを生成する関数15202を含む。使用されるサブピクセル最適化は、2色サブピクセル最適化、又は、多色カラーサブピクセル最適化の何れか、或いは、これら2つの組み合わせであっても良い。上述の方法を含めて、画像のサブピクセル最適化された表現を生成する方法として周知の任意の方法を使用することが出来る。
関数15204は、画像の関連付けられた透明マップのサブピクセル最適化を実行する。2色サブピクセル最適化を使用することが望ましいが、これは、アルファ値が0から1の範囲に及び、3コンポーネント色空間における直線に沿って変化する透明値を、透明マップの高解像度ソース画像が有するからである。そうしたソース画像アルファ値はグレースケールカラーに対応するが、これは、そのマップのサブピクセル最適化された出力画像に於ける任意のピクセルに対応する透明マップソース画像の領域が、一定の透明値で覆われる場合、その出力ピクセルのサブピクセルのすべてが同一のアルファ値を有する傾向があるからである。上述の非線形カラーバランスを使用して、透明マップの2色サブピクセル最適化を実行することが望ましい。
前景画像、及び、それに関連付けられた透明マップに関するそうしたサブピクセル最適化が実行された時点で、関数15206は、サブピクセル最適化表示にこの組み合わせを表示する。この処理は、表示された画像の各ピクセル列の各サブピクセルに対するループ15210を含む、各ピクセル列に対するループ15208を実行することを含む。関数15210によって、関数15212及び15214が各サブピクセルに対して実行される。関数15212は、現在のアルファ値をサブピクセル最適化透明マップの対応するサブピクセルのアルファ値に設定する。次に、関数15214は、現在のサブピクセルの輝度を、「現在のアルファ値」に「サブピクセル最適化された前景画像の対応するサブピクセルの輝度値」を乗算した値に、「1から現在のアルファ値を減算した値」に「透明画像が描画されている背景ビットマップに於ける現在のサブピクセルの以前の輝度値」を乗算した値を加算した値に設定する。
これは、前景画像が以前のビットマップ上に描画される場合に、個々のサブピクセルのそれぞれの輝度値が前景画像の対応するサブピクセル値、又は、以前のビットマップの対応するサブピクセル値から算出される程度が、サブピクセル最適化された透明マップの対応するサブピクセルアルファ値の関数として規定されることを意味する。
本発明の幾つかの実施形態に於いて、透明マップに関連付けられた画像は、サーバ又はブラウザコンピュータ上で拡大/縮小及びサブピクセル最適化され、ダウンロードされ、そして、クライアントコンピュータ上に関数15206によって表示される。本発明の他の実施形態に於いて、そうしたサブピクセル最適化透明画像は、記録されたデジタルメディア上で利用可能になる。さらに本発明の他の実施形態に於いて、上記画像は、それらを表示する同一のコンピュータによって生成される。
本発明の他の実施形態に於いて、サブピクセル最適化されていない透明マップに含まれるアルファ値を使用して、サブピクセル最適化された前景画像を表示することが出来る。
本発明の幾つかの実施形態に於いて、1つの色に知覚的に近い色のグループを表すために、非可逆カラー圧縮を使用する。1次元透明値、図70、96、及び、97に関して上述された種類の3次元透明(即ち、不透明度又はアルファ)値、又は、RGBコンポーネント値と同様に、特別色次元として透明コンポーネント値を有する色値で、そうした圧縮を実行することが出来る。そうした圧縮に於いて、1又は0のアルファ値、或いは1又は0に極めて近い値を示す透明値又はコンポーネント色値が、それぞれ1又は0から懸け離れた透明値で表現されることを回避することが一般的には望ましい。これは、透明度の範囲の両極での不透明性に於ける僅かな変化に対して、透明度の範囲の他の部分に於けるそうした変化に比して、目はより敏感であるからである。
サブピクセル最適化されていない画像が透明マップに使用される全ての目的のために、サブピクセル最適化された表示上で、透明マップを有するサブピクセル最適化画像を使用することが出来る。これは、アニメーション及びウェブページのレイアウトに於ける使用を含む。
図153乃至162は、映像、及び/又は、アニメーションのサブピクセル最適化に関する本発明の特徴に関する、高度に簡略化された擬似コード記述である。映像及びアニメーションが使用される仮想の他のコンテンツだけでなく、ウェブブラウズのコンテンツに於いて、そうしたサブピクセル最適化を使用することが出来る。
図153は、映像キーフレーム間の補間を使用して表示された映像をサブピクセル最適化するために使用されるプログラム15300を示している。このプログラムは、サブピクセル最適化される映像が圧縮フォーマットで受信される場合に使用される関数15302を含む。それはそうした映像を解凍し、サブピクセル最適化することが出来る。
関数15304は、映像のキーフレームを縮小し、サブピクセル最適化する。関数15306はキーフレーム間の補間された変更を縮小するが、サブピクセル最適化を行わない。図153に図示された本発明のこの特徴に関する幾つかの実施形態に於いて、そうした補間された変更をサブピクセル最適化することが出来るが、これを実行することによる利益は殆んどない。これは、そうした変更がスクリーン上にあまりにも速くあらわれるので、それらのサブピクセル最適化が認識されず、それらのサブピクセル最適化を回避することによって、コンピュータ上の負荷を低減するからである。
関数15308は、サブピクセル最適化されたキーフレーム、及び、サブピクセル最適化されていないフレーム間の補間を用いて、縮小された映像をサブピクセルアドレス可能表示上に表示する。
本発明の他の実施形態に於いて、明確に認識するのに充分長い一つの位置で、スクリーン上に存在する映像の部分を単にサブピクセル最適化するというこの概念を、他の方法で使用することが出来る。
図154は、表示フレームに対して描画される、部分−全体−フレーム画像要素の連続によって、全体的又は部分的に表現された映像をサブピクセル最適化するために使用することが出来るプログラムを図示している。一般的に、そうした映像もまた、全体フレーム画像を含み、必要に応じて、その中に存在する1つ又は複数のオブジェクトの動きを表すためにスクリーンを徐々に変更するために、一部−全体−フレーム描画の連続を使用する。これは、図149に関して上述した種類のアニメーションを含む。またそれは、図153に関して上述した一般的な種類のキーフレーム及びフレーム間の補間を有する映像を含む、映像圧縮の様々な方法を含むことが出来る。
図154のプログラムは、サブピクセル最適化される映像が圧縮形式で受信される場合に使用される関数15402を含んでおり、この場合、その関数がその映像を解凍する。次に、関数15404は、映像に含まれる任意のフレーム画像を拡大/縮小し、サブピクセル最適化し、表示倍率でそれらを縮小する。次に、関数15406は、任意の変更ビットマップを拡大/縮小し、サブピクセル最適化し、そうした画像のサイズとそれらの位置を、その倍率で拡大/縮小する。
関数15407及び15408は、映像シーケンスに於ける拡大/縮小及びサブピクセル最適化された任意の映像フレームを、サブピクセルアドレス可能スクリーン上に繰り返し表示する。そうした映像フレームの表示後、関数15406によって、その変更ビットマップに関連付けられた拡大/縮小位置で、そのフレームのビットマップに対して、任意の一つ又は複数の拡大/縮小され、サブピクセル最適化された変更ビットマップを表示する。
図154の方法によって、サブピクセル最適化された映像及びアニメーションが、サブピクセル最適化に必要な演算量を低減する方法で描画可能になるということが分かるが、これは、図154の方法では、その映像画像に対して変更が加えられる度に、フレーム全体のサブピクセル最適化を必要とする訳ではないからである。
図155及び156は、フレームに関連して移動するサブピクセル最適化された画像を表示可能な2つの異なる方法を図示している。
より大きな画像に関連して、サブピクセルアドレス可能表示上で、画像が全ピクセルの値を増加させて移動するように、図155は固定のサブピクシレーションで画像を表示するプログラム15500を含む。それは、上述した方法を含む任意の方法で生成可能なサブピクセル最適化画像を保存する関数15502を含む。それは、各連続フレーム時間に対して実行されるループ15503を含む。このループは、関数15504及び15506で構成されている。関数15504は、より大きな画像に関連して、画像に対する動きを算出する。この移動計算に於いて、各表示フレームでオブジェクトに対して計算された位置は、最も近い水平及び垂直方向の全ピクセル位置に近似され、画像のサイズと方向は変更されない。関数15506は、それに対して計算された全ピクセル解像度位置で、関数15504によって画像を表示する。画像のサブピクセル最適化されたビットマップを1つだけ計算しなければならず、その単一の画像がスクリーン上を横切るように繰り返し使用されるので、この方法はコンピュータ処理的に極めて効率的である。
図156は、サブピクシレーションの変更によって動画を表示するプログラム15600を図示している。それは、移動される画像の高解像度ソース画像を保存する関数15602を含んでいる。またそれは、各連続フレーム時間に対して実行されるループ15603を含んでいる。このループは、あるとすれば、現在のフレームに対して、現在の変換、回転、及び/又は、高解像度ソース画像の転換を計算する関数15604を含む。次に、そのループの関数15606は、そのように生じた、変換、回転、及び/又は、転換されたビットマップの、縮小及びサブピクセル最適化されたビットマップを生成する。このサブピクセル最適化では、それが全ピクセル解像度よりも高度な解像度で表示されるサブピクセル配列に関連して、この変換されたビットマップの位置が考慮される。次に、フレームループの関数15608は、サブピクセルアドレス可能表示上に、結果として生じるサブピクセル最適化されたビットマップを表示する。
ゲームアニメーションに於ける妖精に加えて、動画文字、又は、より大きなフレームに関連して移動されるその他の視覚表現を表示するために、図155又は156に関して上述された方法の何れかを使用することが出来る。
図155の方法は、ビジュアルオブジェクトの動きに関するより精度の低い表現を提供する傾向にあるが、コンピュータ処理的にはより効率的である。図156の方法は、より精度の高い視覚表現を提供するが、コンピュータ処理的には費用がかかる。
本発明の幾つかの実施形態に於いて、これら2つの方法の組み合わせを使用することが出来る。例えば、オブジェクトとサブピクセル配列間に於ける可能なマッピングの小さなサブセットを保存することができ、オブジェクトが移動すると、それが表示されるサブピクセル配列に関連して、その現在位置に関するより高度な解像度の表現を最も詳細に表現する、そうした保存されたマッピングの方法で表示される。
図157及び/又は158は、サブピクセルアドレス可能スクリーン上に表示するために、DVD又はHDTV映像を縮小し、サブピクセル最適化することによって、DVD又はHDTV映像の表示を最適化するために使用される、本発明の特徴を図示している。これが特に有用であるのは、垂直方向よりも水平方向に於いて、より高度なサブピクセル解像度を有するサブピクセルアドレス可能スクリーンと共に使用される場合であり、これは、一般にDVD及びHDTV映像が、高さが高いと言うよりは実質的に幅が広い縦横比を有しているからである。
図159は、異なる属性を有する別個のオブジェクトとして、映像画像のサブコンポーネントを表す映像フォーマットに適用可能な本発明の特徴を図示している。図159に於ける特別な例は、MPEG4映像の表示をサブピクセル最適化するプログラム15900を含んでいる。
図159に図示されたプログラムは、MPEG4映像を受信し、解凍する関数15902を含んでいる。それは、MPEG4映像に於いて異なる種類のオブジェクトを縮小する際に、異なるサブピクセル最適化方法を使用する関数15904及び15906を含んでいる。この関数は、好ましくは非線形カラーバランスを用いて、2色オブジェクトに2色サブピクセル最適化を使用し、多色オブジェクトに多色サブピクセル最適化を使用する。関数15908は、サブピクセル最適化スクリーン上に、2色オブジェクト及び多色オブジェクトの組み合わせを表示し、MPEG4の記述によって指示されているように、スクリーンに関連して、そうしたサブピクセル最適化オブジェクトを移動させ、図155及び/又は156に関して既に議論した種類の方法を使用する。
本発明の幾つかの特徴は、MPEG4データストリームに於ける異なるオブジェクトタイプに対して、異なるサブピクセル最適化アルゴリズムを使用することに限定されない。しかし、そうした異なるサブピクセル最適化アルゴリズムを使用することによって、例えばテキストなど、2色オブジェクトに対してより高度な知覚解像度を提供することができ、これにより、幾分改善された画像を提供するという利点を有するのである。
図160及び161は、ユーザがコンピュータネットワーク上のサブピクセル最適化映像にアクセスするシステムに関する。
図160は、サブピクセル最適化され、縮小された映像を提供するサーバコンピュータによって使用されるプログラム16000を図示している。そうしたサーバは、さらに他のサーバコンピュータから、クライアントによって要求された映像にアクセスし、その後、クライアントにダウンロードする前に、それを縮小し、サブピクセル最適化するプロキシサーバであっても良い。他の実施形態に於いて、サブピクセル最適化された映像の提供は、そうした仲介プロキシサーバを介さずに実行される。
図160のプログラムは、クライアントコンピュータから特定の映像に対する要求を受信する関数16002を含む。例えば、図160に図示された実施形態など、多くの実施形態に於いて、この要求は、映像がサブピクセル最適化される水平及び垂直方向のサブピクセル解像度も記述する。1つの固定サブピクセル解像度を有するクライアント一式を提供するだけの実施形態に於いては、要求の一部として、そうした情報を必要としない。
関数16004は、要求された映像コンテンツを受信する。上述したように、リモートサーバから映像コンテンツにアクセスすること、実行中のコンピュータに関連付けられたRAM又は大容量記憶装置から映像コンテンツにアクセスすること、そうしたコンテンツを動的に生成させること、又は、幾つかのソースから入力された映像を選択すること、によって、これを実行することが出来る。
関数16006は、関数16002の要求に関連付けられたサブピクセル解像度に受信された映像を縮小し、サブピクセル最適化する。次に、関数16008は、サブピクセル最適化映像を圧縮し、関数16010は、要求している装置に、その圧縮された映像をダウンロードする。
そうしたサブピクセル最適化画像に使用される圧縮アルゴリズムは、そうしたサブピクセル最適化された画像に於ける任意のピクセルに関連付けられた色値の位置が、比較的限られた色の距離以上の距離でRGB色空間に於いて移動されない限り、サブピクセル最適化によって可能となる増大された空間解像度を実質的に減少させることなく、ある程度の損失を有した圧縮アルゴリズムを有することが出来る。
図161は、図160に記載された本発明の特徴に使用可能なシステム16100を表している。このシステムは、プロキシコンピュータコード16100、及び、薄型クライアントコンピュータコード16112を有しており、これらの両方が高度に簡略化された擬似コードによって図161に図示されている。
薄型クライアントが所定の映像に対するユーザ要求を受信する場合、関数16113は、映像がプロキシに表示されるサブピクセル解像度を含む、映像に対する要求を送信することによって対応する。プロキシがそうした映像に対する要求を受信する場合、その関数16100によって、関数16103は、映像を取得可能なサーバに、映像への対応する要求を送信する。多くの実施形態に於いて、これは、そうした要求のURLに於いて識別されたサーバである。
要求された映像がプロキシサーバによって受信される場合、関数16104によって、関数16106乃至16110が実行される。関数16106は、映像を、クライアントからの要求に関連図けられたサブピクセル解像度まで縮小し、サブピクセル最適化し、関数16108は、そのサブピクセル最適化された映像を圧縮し、関数16110は、それを要求したクライアントに、それをダウンロードする。
クライアントがプロキシから要求された映像を受信する場合、関数16114によって、関数16115は映像を解凍し、関数16116はサブピクセルアドレス可能表示上に、その縮小され、解凍された映像を表示する。
図162乃至166は、デジタルインクの見た目を向上させるために、本発明の特徴をどのように使用することが出来るかを図示している。デジタルインクは、通常、ユーザがポインティングデバイスによって文字を書く、又は、図形を描画しようとすることに対応して、スクリーン上に描画される白黒のビットマップである。従来、デジタルインクビットマップは、各ピクセルが黒、白、又は、デバイスによってはグレースケール値として表示される全ピクセル解像度で通常表現されている。
本発明の1つの特徴は、より高解像度でデジタルインクを表現するためのサブピクセル最適化を使用することにある。デジタルインクがコンピュータメモリ内に於いて、点及び線、又は、そうした複数点間の曲線で表現される場合、そうした複数点間の線に関する結果的として生じる数学的記述は、スクリーンの全ピクセル解像度に比して、遙かに高い解像度を有することが出来る。
図162は、デジタルインクを視認可能な透明度を最適化するために使用することが出来るプログラムに関する高度に簡略化された擬似コード記述である。
図162に図示されたデジタルインクコード16200は、点の集合、及び、そうした複数点間の曲線又は直線として、ポインティングデバイスのストロークを記録することによって、デジタルインク描画モードの状態で、ポインティングデバイスを用いてユーザ入力に応答する関数16202を含む。関数16206は、直線及び曲線のサブピクセル最適化を使用して、スクリーン上にインクを描画する。実質的に任意のサブピクセル最適化スキームを用いてこれを実行することが出来るが、例えば、上述の非線形カラーバランスを使用する2色サブピクセル最適化スキームなど、2色サブピクセル最適化スキームを用いて実行することが望ましい。
図163は、ハンドヘルドコンピュータ16300のスクリーン上に描画された、幾つかのデジタルインク16302を図示している。この図示は、全ピクセル輝度値のみを表現可能なプリンタで印刷されるので、図163に図示されたデジタルインクは、グレースケールアンチエイリアスとしてサブピクセル最適化を表示する。当然のことながら、サブピクセルアドレス可能表示上で画像を見る場合、図163に図示されている画像も、さらに明瞭に見える。
デジタルインクプログラムのユーザが、デジタルインクの部分の表現を拡大することを選択する場合、関数16208によって、関数16212は、非線形カラーバランスと共に2色サブピクセル最適化を使用して、ユーザが選択した拡大サイズで、デジタルインクの直線及び曲線のサブピクセル最適化されたビットマップを生成する。次に、関数16212は、ユーザのスクリーン上に、その拡大された画像を表示する。
図164は、図163に図示されたデジタルインク16302の一部分に関する拡大された表現16302Aを図示している。これにより、図165に図示されたビットマップ16302Bによって図示されているように、図163に図示されたデジタルインクの表現16302のピクシレーションを単に拡大することによって生成される表現に比して、実質的により明瞭なデジタルインクの表現が提供される。
注目すべきは、図165に図示されたビットマップの表現は、実際には、デジタルインクの幾つかの拡大された表現に比して、より見易いということである。これは、幾つかのデジタルインクの表現で使用されていないアンチエイリアスを用いて、図163に図示されたビットマップが全ピクセルグレースケール値で印刷されているからである。
関数16214によって、関数16216は、非線形カラーバランスと共に2色サブピクセル最適化を使用して、選択された縮小されたサイズで、インクの直線及び曲線のサブピクセル最適化されたビットマップを生成し、関数16218は、サブピクセルアドレス可能表示上にその縮小されたビットマップを表示する。そうした処理の結果は、図166に図示されたビットマップ16302Cによって図示されている。
オン又はオフの全ピクセルとして記録されたデジタルインクに対応するために、本発明のこれらの特徴を修正することが出来る。そうした「オン」のピクセルで表現された各ストロークの中心線をルーチンに評価させ、その後、上述されているように、様々なスケールでデジタルインクの中心線のサブピクセル最適画像を生成することによって、これを実行することが出来る。さらに正確ではあるが、コンピュータ処理的に費用のかかるアプローチは、そうしたデジタルインクの連続部分と、例えばベジエ曲線などの対応する直線及び曲線の連続との間の最適な適合を求める。
他の実施形態に於いて、そうしたビットマップ上でサブピクセル最適化された拡大/縮小を単に実行することによって、デジタルインク描画によって生成されたビットマップ上で、サブピクセル最適化を実行することが出来る。
サブピクセル最適化をグレースケールアンチエイリアスで置換することによって、デジタルインクに関する本発明の幾つかの実施形態を、サブピクセル最適化されていない表示と共に使用することが出来る。
図167は、サーバ、クライアント、プロキシサーバ、薄型クライアント、リモート、デスクトップ、又は、上述された他のコンピュータの多くが有することが出来るコンポーネントを図示している。当然のことながら、図167に図示されたコンポーネントの全てが、そうした全てのコンピュータに存在する訳ではなく、殆どのそうしたコンピュータは、図167に図示されたコンポーネント以外に他のコンポーネントを有する。
本発明の様々な特徴を用いて使用される殆どのコンピュータが、本発明のそうした特徴に関する関数を実行し、そうした特徴の方法に従ってデータ16704を読み出し及び書き出しをするために、プログラム16702を実行可能な何らかの種類のプロセッサ16716を有している、ということを明確にするために同図が示されている。本発明は、方法だけでなく、そうしたコンピュータプログラム及びデータに関し、さらには、そうした方法を実行、又は、そうしたデータを使用するために、プログラムされた、及び/又は、ハードウェアに組み込まれたコンピュータシステムに関する。
殆どのそうしたコンピュータに於いて、本発明のプログラムは、機械可読形式で、RAM16706、ROM16707、又は、例えば、ハードドライブ16708、フロッピドライブ16709、CD−ROMドライブ16711、及び/又は、DVDドライブ16713など、大容量記憶装置に保存される。また、例えば、フロッピディスク16710、CD−ROM16712、DVD−ROM16714、又は、仮想の任意の他の機械可読記憶媒体に、本発明のプログラムを保存することが出来る。また、例えばネットワークインターフェース16720など、ある種の通信ポートを介してコンピュータが受信可能な数字16719で示された伝搬信号として、本発明のプログラム及び/又はデータを表現することが出来る。
図168は、図60乃至97に関して上述された非線形カラーバランス法を使用して、生成された小型のサブピクセル最適化されたフォントを示す320×240スクリーンの全ピクセルグレースケール表現を提供している。同図は、そのテキストの部分が破線部16800で囲まれている点を除いて、図56と同じである。
図169は、破線部16800内の図168に図示したビットマップの部分に関する8倍の拡大図である。図169は、図168に図示されたフォントに於ける垂直ストロークの殆どが、その左側に、そうしたフォントの明瞭さをぼかすカラーバランス分配を含んでいることを図示している。この同一の僅かなぼかしが、図1、10、11、99、101、104、110乃至114、121乃至128、130、及び、144に図示された小型フォントに於いて生じている。
サブピクセル最適化フォントビットマップを生成する非線形カラーバランス法の主な利点の一つが、そうした分配がカラーバランスに必要ない場合、輝度値の分配を防止しようとする非線形法によって、文字フォント形状のぼかしを低減するための能力である。
図169に図示された種類のフォントの主なストロークの左に、色値の望ましくない拡散を観測した場合、本発明のこの特徴の発明者は、そうした拡散を低減することが出来るかどうかを確かめようとした。この発明者は、そうした拡散のソースが何かを割り出そうとした。
ここで再び図170を参照すると、この発明者は、非線形カラーバランス処理が行われたビットマップの生成に使用されるアルゴリズムが、サブピクセル17000の2つのパディングコラムを、実際の非ゼロカバレッジ値17004を含む(即ち、ラスタ化で表現されている文字フォント形状の一部分によって実際に覆われた)文字フォント形状のラスタ化に於ける左端のサブピクセルコラム17002の左側に自動的に設定するよう設計されていたことを発見した。そうした非ゼロカバレッジ値を含む左端のサブピクセルコラムの左側にある、2つのサブピクセルコラムにカラーバランス色値を拡散可能にする余地を与えるために、これを実行する。これが望ましいのは、部分的に覆われたサブピクセルの左側2ピクセルにカラーバランス分配を可能にする、上述された非線形カラーバランスアルゴリズによって、そうした左側の分散が必要とされる場合である。
残念ながら、2つのそうしたサブピクセルコラム17000のみを用いて、ラスタ化サブピクセル配列をパディングすることは、そうしたカバレッジ値を含む左端のサブピクセルコラム17002を、2つのパディングサブピクセルコラムを含むピクセルコラムの右端サブピクセルコラムにするという、好ましくない影響を有する傾向がある。RGB表示では、これにより、実際のカバレッジ値を有する左端のサブピクセルコラムが青色サブピクセルに対応する。
これが望ましくないのは、それによって、フォントビットマップに於ける一番左のピクセルコラムのピクセルが、実際のカバレッジ値を有していない2つの一番左のサブピクセルと、非ゼロカバレッジ値を有する一番右のサブピクセルを有し、カラーバランスを達成するために、その非ゼロカバレッジ値が分配されることが要求されるからである。これが、図169に図示された主要な垂直ストロークの殆どの左方向の不鮮明な状態に関する理由である。
発明者は、サブピクセルコラムの幅に比して垂直ストロークの境界を適切に段階的に位置づけ可能なシステムでヒンティングされた文字フォント形状が、例えば図171に図示された端部17100など、一番左の垂直ストロークの一番左の端部を、非ゼロカバレッジ値17002を含む一番左のサブピクセルコラムへの極僅かな距離で開始するために、これらの文字フォント形状をヒンティングした者によって、多くの場合設計されていることを言及した。これは、非線形カラーバランスが分配しなければならなかったサブピクセルコラム17002内に含まれた非ゼロカバレッジ値の量を実質的に低減し、これにより、文字のサブピクセル最適化された表現に於ける好ましくない不鮮明な状態を大幅に低減する。
例えば、発明者は、最良のヒンティングの組み合わせの多くがそうしたアルゴリズムに使用された場合、結果として生じるビットマップに於ける第2の一番左のピクセルコラム17103に、如何なるカラーバランス拡散をも要求しないために、全体的に覆われた1つ又は複数のピクセルを有するように、例えば図171に図示された垂直ストローク17102などの文字の第1垂直ストロークが、右側に3つの連続するサブピクセルコラムにおける合計カバレッジを用いて、1つのサブピクセルコラムに僅かに入る一番左の端部を有することを発見した。
そうした最適化されたヒンティング処理に於いて、第1垂直ストロークの一番右の端部から3、6、又は、9サブピクセルコラムの距離で始まる3つの隣接するサブピクセルコラムを覆うように、次の垂直ストロークが配置される。これにより、例えば図171に図示された垂直ストローク17104及び17106など、次の垂直ストロークが、如何なるカラーバランスも必要としないように、全体的に覆われた複数のピクセルを有する。
図168乃至171に図示された種類のフォントは、従来技術の方法によって生成された殆どのサブピクセル最適化フォントビットマップに比して読みやすいが、これらの調査の結果、本発明者は、図172乃至174に図示されているように、より明瞭なサブピクセル最適化フォントの生成方法を発見した。
フォントビットマップを生成及び表示するための新たなより明瞭な方法を使用していることを除いて、図172は、図168に図示された種類のウェブページのサブピクセル最適化された320×240ピクセル表示を表現する、全ピクセルグレースケールビットマップを図示している。
図173は、17200の数字が割り当てられた破線ボックスに図示された図172の部分の4倍拡大図を示している。
図174は、図173の破線部17300に図示されたテキストの部分をさらに4倍拡大した図を示している。
図172乃至174を見ると分かるように、これらの図に図示されたフォントビットマップに含まれる垂直ストロークの多くから発生する色値の水平方向の拡散は比較的少ない。注目すべきは、カラーバランスに起因する任意の拡散のためではなく、これらの図中のテキストが、背景色を有する図172のウェブページの部分から選択されたために、図173及び174における規則的な薄い灰色の背景が生じるということである。これらの図に図示されたフォントは、図168及び169に図示されたフォントに比して実質的に明瞭である。
本発明者は、文字の一番左側の垂直ストロークの一番左の端部を、ピクセル境界の左端に揃えることによって、こうした改善を行った。多くの実施形態に於いて、図175に図示された3つのパディングサブピクセルコラム17500を、非ゼロカバレッジ値を有する一番左のサブピクセルコラムの前に挿入することによって、これを実行する。これは、文字のアウトラインによって全体的又は部分的に覆われた一番左のラスタ化ユニット(即ち、サブピクセル)を、ピクセルコラムの一番左の端部に自動的に揃える。一番左のアウトライン端部がラスタ化ユニットの一番左の端部に揃えられるように、文字がヒンティングされる場合、これにより、一番左のアウトライン端部が、結果として生じるフォントビットマップに於けるピクセルの一番左の端部に自動的に揃えられる。フォントアウトラインの一番左の端部が垂直ストロークである場合、これにより、非線形カラーバランスの後でさえ、明瞭な一番左の垂直ストロークを有するフォントビットマップを非常に簡単に生成することができる。
図176は、本発明に使用可能な多くの可能なヒンティングインターフェースの1つを図示している。このヒンティングインターフェースに於いて、破線17602は、所望の文字の左側ベアリングを対話形式で定義するために、ユーザによって移動可能なラインである。破線17604は、右側ベアリングを定義する移動可能なラインである。左側ベアリングは、ペン位置と呼ばれることもある、文字が描画される位置に対する第1参照ポイントと、描画される文字のビットマップの一番左の端部との間の距離である。ライン17604は、テキストのラインに沿って、ペン位置が次の連続する文字の描画開始点に通常配置されるビットマップに対する位置に対応する。右側ベアリングは、ライン17604と描画される文字のビットマップの一番右の端部との間の距離である。アドバンス幅は、ライン17604とライン17602との間の距離として定義される。これは、文字のビットマップの描画前のペン位置と描画後のペン位置との間の通常の全幅を表している。他の実施形態に於いて該当する必要はないが、幾つかの実施形態に於いては、左側ベアリングとアドバンス幅は、複数のピクセル幅に近似される。場合によっては、左側ベアリング値、及び/又は、右側ベアリング値は負の値になり得る。例えば、連続する文字に関連付けられたビットマップは、多くの場合、互いのアドバンス幅の部分に重なるようなイタリック体のフォントでは、しばしばこのような事態が発生する。
図176に図示された小型の矩形ドット17606のそれぞれは、サブピクセル最適化フォントビットマップにおいて、個々のサブピクセルに対応するラスタ化ユニットの中心に対応する。この特別なヒンティングインターフェースに於いて、文字フォント形状のアウトラインに半分以上覆われたラスタ化ユニットが黒色で示される。但し、さらに進んだインターフェースでは、そうしたラスタ化ユニットをグレースケールカバレッジ値で表示することが出来る。文字フォント形状のアウトラインは同図に図示されており、アウトラインに於いてセグメントを定義する各ポイントは、制御ポイントであろうがセグメントエンドポイントであろうが、数字が割り当てられている。
図177乃至181は、図182に含まれた高度に簡略化された擬似コードに記載されたステップの幾つかを説明する一助となるように使用される。
図182に図示された擬似コードが、図172乃至175に関して上述された、より明瞭な非線形のカラーバランスサブピクセル最適化ビットマップを生成するための改良された方法に関連する計算上の特徴に焦点を当てていることを除けば、図182は、図60に図示された疑似コードに一般的に対応するプログラム6000Aに関する高度に簡略化された擬似コード記述である。
この擬似コードが、文字フォント形状を配置可能なラスタ化ユニットの最もタイトな矩形配列を決定する関数18202を有しており、ヒンティングによって定義されたそうしたラスタ化ユニットに対する文字フォント形状の配列を考慮に入れている。
それが発生する個々のラスタ化ユニットに対するフォントアウトラインの位置は、この関数によって変更されない。したがって、そうしたアウトラインの一番左側のポイントが、それが位置するラスタ化ユニットの左側端部以外で発生する場合、そのラスタ化ユニットは、関数18202によって生成される最もタイトな矩形配列の一番左側の端部で発生し、アウトラインの一番左側のポイントは、その矩形の一番左側のラスタ化ユニットコラム内で発生するが、その一番左側のコラムの一番左側の端部では発生しない。
図177及び178は、この関数を説明する一助となるべく使用される。図177は、ヒンティングされた文字フォント形状のアウトラインに対応する。図178は、図177に図示された文字アウトラインに対して、関数18202によって返される、(それぞれのサイズがサブピクセルに対応する)ラスタ化ユニットの矩形を図示している。このグリッドは、文字フォント形状を含むラスタ化ユニットが適合する、最も緊密で、最小の矩形に対応する。
関数18202が完了した時点で、関数6002A乃至6006が実行される。これらは、図60のステップ6002乃至6006に対応する。それらは、関数18202によって返された矩形に含まれる各ラスタ化ユニットに対するカバレッジ値を決定するために使用される。そうした各カバレッジ値は、ラスタ化されている高解像度文字フォント形状アウトラインによって覆われたサブピクセルの割合を表している。
図179は、図178に図示された配列に於ける各ラスタ化ユニットに対して計算されたカバレッジ値を図示している。そこでは、カバレッジが黒に色付けされたラスタ化ユニットの割合で表現される。図179に於いて、文字フォント形状アウトラインによって覆われたユニットの対応する部分がラスタ化ユニットの最上部で発生する場合、カバレッジを表す各ラスタ化ユニットに於ける結果として生じる棒グラフの部分は、ラスタ化ユニットの最上部に設置される。
図180に於いて、個々のラスタ化ユニットの全てに対する棒グラフは、上述した図46乃至52、及び、図92乃至93に図示されたカバレッジ値の表現により厳密に対応させるために、対応するサブピクセルユニットの最下部から設置される。
文字フォント形状がラスタ化された時点で、ステップ18204は、サブピクセルカバレッジ値の結果として生じる配列を、サブピクセルアドレス可能ピクセルの配列にマッピングする。上述のタイトな矩形に於けるラスタ化ユニットの第1コラムをピクセル行の一番左のサブピクセルに揃えることによって、ステップ18204はこれを実行する。これによって、非ゼロカバレッジ値を有するラスタ化ユニットの一番左側のコラムが、図175に関して上述された全ピクセルに一番左のサブピクセルコラムとして配置される。図177乃至181で図示された例では、これによって、結果として生じるサブピクセル配列が、図181に於いて18102とラベル付けされた中央の5つのピクセルコラムに図示されているように見える。
次に、ステップ18206は、現在の文字に対して生成されているビットマップ配列を、3つのサブピクセルで構成されるピクセルコラム1804に当てる。実際の非ゼロカバレッジ値を含む一番左側のサブピクセルコラムを有するピクセルの左側にこのパディングコラムを設置する。これにより、この例のサブピクセル配列が、図181のピクセルコラム18104及び18102の組み合わせによって示されるように見える。
次に、ステップ18208は、ビットマップのサブピクセルコラムの合計が3の偶数倍、即ち、全ピクセルコラムの偶数倍になるように、ビットマップ配列に右側の2つ又はそれを超えるサブピクセルコラムを当てる。これにより、この例のサブピクセル配列が、図181のピクセルコラム18104,18102,及び、18106の組み合わせによって示されるように見える。
ステップ18210は、パディングピクセルコラムの追加を相殺するために、左側ベアリング値、及び/又は、右側ベアリング値を調整する。したがって、例えば、さもなければ1ピクセル幅の左側ベアリングを有するビットマップは、左側パディングコラムの追加を相殺するために、ゼロの左側ベアリングを有するように変更される。同様に、右側に追加された余分のピクセルコラムを有するビットマップは、1ピクセル幅だけ右側ベアリングを減少させる。
次に、関数18212は、多くの実施形態において、上記図60に図示されたループ6008によって記載されたステップに対応する非線形カラーバランスを実行する。
これが実行された時点で、上述の図96に記載された種類のパックト色値表現を使用する実施形態に於いて、ステップ18214は、カラーバランス処理後に生じるピクセル色値を、より制限されたカラーパレットからの対応値に変換する。
ここで留意すべきは、図182の方法によって、図168及び169に関して上述された不要な色拡散を引き起こしがちになることなく、必要となる可能性のある任意のカラーバランスのための余地が与えられるということである。図182の方法は、ラスタ化されているフォント形状によって覆われた領域に対応する任意のサブピクセルの左側及び右側に少なくとも2つのサブピクセルが存在することを確実にすることによって、これを実行する。
本発明のこの特徴に関する他の実施形態に於いて、不鮮明さを低減する非線形カラーバランスの能力を最大限に利用するために、フォント形状及び垂直ストロークの一番左の端部及び一番右の端部を全ピクセル境界に揃えるための他の方法が使用される。幾つかのそうした実施形態に於いて、パッディングピクセルコラムがフォントビットマップの左側又は右側に追加されたかどうかは、カラーバランス分配がそうした位置で必要とされたかどうかという関数となり得る。
図183は、図182に記載された方法によって生成されたビットマップを使用して、文字の文字列を描画するための関数を記載している。この擬似コードは、図182の方法で生成されたビットマップに使用された本発明の特徴に焦点を当てているという点を除いて、図97に関して上述された擬似コードに類似している。
図183に図示された描画文字列関数18300が呼び出される場合、ステップ18302は、ペン位置を文字列の表示が先頭になっている場所を示す描画文字列呼び出しによって特定された開始位置に設定する。
次に、図97に記述されたループ9714に類似するループ9714Aが、表示に対する文字列の各文字に対して実行される。
このループに於いて、ステップ9716は、現在の文字のフォントビットマップにアクセスする。次に、ステップ18304は、文字の開始点を現在のペン位置に設定する。次に、ステップ18306は、左側ベアリングによって現在のペン位置を調整する。上記に於いて既に述べたように、左側ベアリングは、文字ビットマップに余分な1ピクセルコラムがその左側に当てられているという事実を考慮するために、通常の状態から変更されているので、左側ベアリングが1ピクセルコラムの幅だけ減少されている。
次に、ステップ9718Aがフォントビットマップに於ける各ピクセルに対して実行される。これは、現在のピクセルの値が非ゼロであるかどうかを確認するためにテストを行うサブステップ18308を有する。現在のピクセルの値が非ゼロであれば、画面上に於いて、現在のペン位置の関数として定義された位置にピクセルを描画する。
現在のピクセルの値がゼロの場合、それは全体的に透明なピクセルを表現し、これは、以前、現在のピクセルの位置に存在した背景色が変更されずに残されていることを意味する。本発明のこの実施形態に於いて、図96に記載された関数は、そうした全体的に透明なピクセルを表現するために、ゼロの値を保持している。
透明なピクセルを書き込まないようにすることは、図183に記載された実施形態に於いて、ビットマップの全てのピクセルに適用される。透明なピクセルを書き込まないようにすることは、図182に関して上記したステップ18206によって、文字フォントビットマップの一番左側の端部に設置されたパディングコラムに於けるピクセルに関しては特に重要である。これは、そうしたパディングコラムに於けるピクセルが、垂直ストローク境界が垂直ピクセル境界に揃えられている場合に非線形カラーバランスの結果として、パディングコラムに拡散された色値を有さないからである。その結果、そのようなピクセルは透明になり、左側の文字によってピクセル位置に設置されている可能性のある色値は、変化のない状態を保持することが可能でり、これにより、カバレッジ又はカラーバランス情報を有する隣接文字のピクセルコラムを互いに近接して設置することが出来る。
透明で、記載のない、「e」に関連付けられた左側のパディングコラムを通じて表示可能となっている「w」からの色値を有する場合、例えば、図173の数字17302によって示された位置においてこれを確認することが出来る。また、「r」と「e」の間のピクセルコラムが、「e」の透明なパディングピクセルコラムに重ねられていない「r」からの色値を有する図174の数字17402によって示された位置でこれを確認することが出来る。
当業者には理解可能であるが、関数9718Aは、ビットマップのそれぞれを適切な位置に描画するために、ピクセルが描画される位置を制御するある種の繰り返しが、フォントビットマップの各行に対して繰り返されることを要求する。
当然のことながら、本発明の他の実施形態に於いて、次の文字の対応するピクセルが透明な場合に、一つの文字からの非透明色値を単に透けて見えるようにする関数というよりは、むしろ、隣接文字からの非透明ピクセル値との重なりを結合可能な関数を提供することが出来る。
そうした処理がサブピクセル対サブピクセルに基づいて、そうした透明値の結合を可能にすることが望ましい。そうした処理は、さらに演算処理が必要ではあるが、間隔の近い文字のさらに正確な表現を提供することが出来る。
この結果を達成する一つの方法は以下の通りである。即ち、文字間の任意の重複するピクセルに関連付けられた3つの対応するアルファコンポーネント値のそれぞれを追加し、任意のコンポーネント値を最大可能値で切り取る。そして、結果として生じるピクセルのそれぞれを描画し、前景色及び背景色がその位置でどの程度描画されるべきかを決定するために、結合されたコンポーネントアルファ値を使用する。
ユーザによって移動可能なライン又は制御で構成されたインターフェース特性18402を有するという点を除いて、図184は図176に関して上述されたインターフェースに類似したヒンティングインターフェースを図示している。この制御によって、ユーザは、自身の文字フォント形状アウトラインに対して、一番左側のパディングピクセルコラムに付随するピクセルコラムの一番左の端部に位置を揃えるように選択的に位置付けることが出来る。
そうしたインターフェース特性が望ましいのは、単一の垂直ストローク以外の一番左の端部を有するフォントをヒンティングする場合である。例えば、最大ピクセル幅未満で、その左端部に突き出ている小型のセリフ活字を備えた一番左の主要な垂直ストロークを有する文字フォント形状を処理する場合、ヒンティング実行者が、より左側のセリフ活字ではなく、むしろ、全ピクセル境界に揃えられた主要な一番左の端部を有することを望んでいる可能性がある。図184に図示されたインターフェース特性は、ヒンティング実行者がそうした配列を選択し易いものにする。
ヒンティング実行者に同等の能力を与える他の方法によって、図170又は171に関して上述されているように、2つのサブピクセルパディングコラムのみを追加するかどうか、または、図175、181、及び、182に関して上述されているように、3つ又はそれを超えるそうしたサブピクセルパディングコラムを追加するかどうかをユーザが選択することが出来る。
今述べた非線形カラーバランスサブピクセル最適化画像をより明瞭にするための方法は、図172乃至174に図示された種類の小型フォントだけでなく、例えば図55に図示された比較的大型のフォントなど、より大きなフォントにも適用することが出来る。
当然のことながら、サブピクセル最適化は、通常、3つの異なる種類のピクセル、即ち、前景ピクセル、背景ピクセル、及び、中間的にカラーバランスされたピクセルで、フォントビットマップを表現することが出来る。前景ピクセルは、表現されているフォント形状によって全体的に覆われたフォント画像の部分を表現しており、文字が表現される前景色で描画される。背景画素は、フォント形状によって全体的に覆われていないフォント画像の部分を表現しており、背景色でフォントが表示される最上部に描画される。中間ピクセルは、フォント形状で部分的に覆われたピクセル、及び/又は、部分的に覆われた近傍ピクセルに対してカラーバランス分配を受け付けるピクセルを表現している。サブピクセルのそれぞれの色は、カラーバランスによって別々に決定される。
図46、47、52、及び、93に関して上述された種類の従来技術の非線形カラーバランスがフォントに適用された場合、文字形状の端部が完全にピクセル境界に揃えられたとしても、文字形状の各端部を越えて、サブピクセルの色の変化の方向に、カラーバランスが実行される。ヒンティングがどんなに上手くいっても、これが全ての文字の形状の空間的な不鮮明さをもたらす。
図48、49、51、及び、91に関して上述した種類の非線形カラーバランスがフォントに適用される場合、カラーバランスによって生じる空間的な不鮮明さを大いに低減するために、ヒンティングを使用することが出来る。端部がピクセル境界に揃えられている文字の形状の部分に於いて、カラーバランス分配がピクセル境界を越えて必要にならない場合が多い。これは、そうした非線形カラーバランスのみが所定のピクセル内で生じるカラーアンバランスを分配するからである。これは、前景ピクセルをそうした位置に於いて、サブピクセルの色の変化の方向に沿って背景ピクセルの次に配置させ、フォント形状の知覚される明瞭さを大幅に向上させる。このことは、図173及び174に図示されており、これらの図中で、垂直ストロークの端部がピクセル境界と一直線になるように、垂直ストロークの実質的な部分が図示された8ピクセル/emでヒンティングされている。その結果、前景ピクセルは、多くのそうした垂直ストロークの端部の実質的な部分に沿って、背景ピクセルの次に水平方向に配置される。図168及び169に図示された一番左側の垂直ストローク端部のそれ程最適ではないヒンティングを使用する場合でさえ、カラーバランスの不明瞭さの合計は、従来技術の線形カラーバランスから生じる不明瞭さの合計に比して実質的に小さい。
図185乃至190は、特に、比較的小さい又は比較的低解像度のスクリーン上でブラウズが実行される場合に、ウェブページのブラウズを向上させるために使用可能なユーザインターフェースの技術革新に関する高度に簡略化された擬似コード記述である。
図185は、図129乃至134に関して上述された選択テキストリフロー法に関するより高度なレベルの記述である。この方法18500は、ウェブページのコンテンツにアクセスする関数18502と、ウェブページのコンテンツの最初のレイアウトを実行する関数18504とを含み、ウェブページ内のテキストについて示された異なる水平方向の位置にテキストをセットする。
ウェブページの記述に使用されるマークアップ言語は、テキストの異なる部分が異なる水平方向の位置、又は、ウェブページの異なる水平方向の範囲に描画されることを指示する複数の方法(2つだけ例を挙げると、テーブルとフレームの使用)を有している。
そうしたレイアウトが実行された段階で、関数18506は、レイアウトの要素を所定の縮尺、及び、最初のレイアウトで決定された相対的な位置に表示する。この表示が実行された後、ステップ18508は、最初のレイアウトの表示に於ける所定の水平方向位置でテキストの一部を、ユーザが選択出来るようにする。これを可能にする1つの方法は、図130に関して上述されている。
そうした選択が実行される場合、関数18510によって、関数18512及び18514が実行される。関数18512は、ユーザが選択したテキストの第2レイアウトを実行する。コラムのライン幅に比して、異なった、通常より大きなフォントサイズをテキストが有する新しいコラムのラインを越えて、この2番目のレイアウトが選択されたテキストをリフローする。この第2レイアウトが実行される場合、関数18514は、ウェブページが表示されているスクリーン、又は、スクリーンウインドウ幅の少なくとも3分の2を満たす縮尺で、新しいコラムのレイアウトを表示する。
図135乃至137に関して上述したように、そのように選択されたテキストリフロー法に於ける第2レイアウトによって、ユーザはウェブページのレイアウトの選択部分を、全体的に読み易いフォントサイズで見ることが出来る。小型スクリーン、及び/又は、視聴者から比較的離れたスクリーンの両方の低解像度スクリーンに関して、非常に大きな利点である。そうした方法に於ける第1レイアウトによって、ユーザはウェブページがより通常に近い表示でどのように見えるよう計画されているかを視認することができ、見たいと考えるテキストのどの部分をより大きなフォントサイズで再表示するかを、より迅速に選択することが出来る。
図186は、図118乃至120に関して上述した一般的な種類のズーム・トゥ・フィット法18600に関する高水準の擬似コード記述である。
この方法は、ウェブページのコンテンツにアクセスする関数18602と、ウェブページのコンテンツをレイアウトする関数18604を含んでいる。
そうしたレイアウトの表示がスクリーン上に表示される時点で、関数18608によって、ユーザはこの表示を越えてポインティングデバイスをドラッグすることが出来る。そうしたドラッグ中、スクリーンの端部に関連付けられた境界を越えてドラッグが継続する場合、関数18610によって、関数18612がスクリーン端部の反対側で以前にはスクリーン上に存在しなかったレイアウトの部分を、スクリーン上でスクロールさせる。これを実行するのは、大き過ぎて現在の表示縮尺でスクリーン上に全体的に適合することが出来ないレイアウトの部分、又は、一部だけがスクリーン上に存在するように、ドラッグの開始時点で位置したレイアウトの部分を、ユーザがドラッグで選択できるようにするためである。
ユーザがドラッグを解除する場合、関数18614によって、関数18616及び18618が実行される。関数18618によって、レイアウトの一部がドラッグの最初と最後に一致するレイアウト上の位置に基づいて選択されたものとして定義される。そのように選択された部分は、ドラッグの水平又は垂直方向の範囲を有するレイアウトの部分、又は、そうしたドラッグの最初と最後に対応する対角部を有する領域を備えたレイアウトの部分に対応することが可能である。そして、関数18618は、レイアウトの選択された部分を実質的にスクリーンに適合する縮尺で表示する。実質的にスクリーンに適合するということは、選択された幅、高さ、又は、領域が、対応する寸法又はスクリーンの寸法、或いは、表示が実行されているスクリーンの部分の、少なくとも3分の2を占めることを意味する。
図187は、ユーザがウェブページのレイアウトの表示内で、容易にナビゲート可能なドラッグスクロール法18700に関する高水準の擬似コード記述である。
この方法は、ウェブページのコンテンツにアクセスする関数18702、ウェブページのコンテンツのレイアウトを実行する関数18704、及び、所定の倍率でレイアウトの全部又は一部を表示する関数18706を含む。その後、関数18708によって、ユーザはレイアウトの表示を越えてポインティングデバイスをドラッグすることが出来る。関数18710は、以前スクリーン上に存在しなかったレイアウトの部分を、スクリーン端部を越えてスクリーン上でスクロールすることにより、スクリーン端部に関連付けられた境界を越えて、そうした任意のドラッグに対応する。
ズーム選択関数の一部、又は、ズーム選択関数から独立したものとして、この方法を使用することが出来る。この方法には、表示スクリーンの端部、又は、表示スクリーンの端部近傍で、境界を越えてポインティングデバイスを単にドラッグさせることにより、ユーザがウェブページのレイアウトの表示をスクロール出来るという利点を有する。この方法は、スクロールバーを利用したスクロールに比して、かなり自然で速い。
図188は、ウェブページのレイアウトの所望の部分に於いて、ユーザが即座にズームインすることを選択可能なクリックズーム法18800に関する高水準の擬似コード記述である。この方法は、ウェブページのコンテンツにアクセスする関数18802、ウェブページのコンテンツのレイアウトを実行する関数18804、及び、ウェブページのレイアウトの全部又は一部を第1縮尺で表示する関数18806を含む。関数18808によって、ユーザは第1縮尺で表示されたレイアウトの表示に於いて、選択された位置でポインティングデバイスをクリックすることができ、関数18810は、クリックが実行されたレイアウトに於ける位置の周囲でレイアウトの部分のズームイン表示を実行することによって、そうしたクリックに応答する。一般的に、ズームイン表示は、クリックが実行されたレイアウトに於ける位置を中心とする。
図189は、図121乃至128に関して上述されたズームクリック法18900に関する高度に簡略化された擬似コード記述である。
この方法は、ウェブページのコンテンツにアクセスする関数18902、そのコンテンツのレイアウトを実行する関数18094、及び、関連付けられたポインティングデバイスを有する表示スクリーン上に、ウェブページのレイアウトの前部又は一部を第1縮尺で表示する関数18906を含む。図189に記載されたこの方法に関する特定の実施形態に於いて、スクリーンはタッチスクリーンであり、ポインティングデバイスを人の指にすることが可能であることが意図されている。
第1縮尺でレイアウトの表示が実行された時点で、タッチスクリーン表示に対して押下が実行された際に、関数18908が対応する。そうした押下が発生する場合、この関数によって、関数18910乃至18922が実行される。
関数18910は、スクリーン上で、第1縮尺のウェブページの部分の表示を、より大きな縮尺のウェブページの部分のズームイン表示に置換する。このズームされた部分は、タッチスクリーンの押下に関連付けられたレイアウトに於ける選択された位置を含む。選択レイアウト位置は、選択時の第1縮尺での表示に於いて有していた位置と、実質的に同一の位置をスクリーン上に有することが望ましい。実質的に同一位置ということは、選択された位置が、ズームの直前及び直後のスクリーン上に、スクリーン上に位置する同一の接触に対応するように見える位置を有するはずだということを意味する。これは、選択された位置のスクリーン位置に於ける変化が、そうしたズームの直後に於いて、スクリーンの幅又は高さの20%を超える割合で(そして、望ましくは、その量に比してかなり少ない量で)変更しないことを意味することが望ましい。
ズームイン表示が表示された時点で、関数18912は、接触に関連付けられたウェブページのレイアウトに於ける選択された位置を示すために、スクリーンが接触されている位置の上方にカーソルを表示する。タッチスクリーンデバイスによっては、特に、比較的精密なポイントを有するスタイラスを用いて使用するように設計されたデバイスでは、そうしたカーソルを必要としないが、これは、スクリーンが接触されているポイントをユーザが相当正確に見ることが出来るからである。しかし、ポインティングデバイスとして指を用いて使用するように設計されたタッチスクリーンに於いて、ユーザがそうした接触に関連付けられたスクリーンの表示に於ける位置を正確に確認できるように、多くの場合、スクリーンが接触されている位置の上にカーソルをセットすることが望ましい。これが特に望ましいのは、例えば図121乃至128に図示された、人間の指の大きさに比して比較的小さな表示を用いてこの方法が使用される場合である。
接触が続く間、関数18914は、ズーム表示に於いてカーソルを対応させて移動させることによって、接触の任意の動きに対応する。また、そうした接触が続く間、スクリーンの端部を越えて、以前スクリーン上に表示されていなかったレイアウトの部分を、ズームされた縮尺でスクリーン上でスクロールすることによって、関数18916はスクリーン端部に関連付けられた境界を越えて、接触の任意の動きに対応する。これにより、ユーザは、ズームクリックモードの状態でウェブページのズームされた表示内で迅速に、且つ、便利にスクロールすることが出来る。
関数18918は、ユーザがウェブページのズーム表示に於ける所定の位置で接触を解除する場合に応答する。接触が解除される場合、関数18920は、あたかも解除位置に対応するウェブページに於ける位置でポインティングデバイスのクリックが発生したかのように動作する。例えば、ウェブリンクに対応するレイアウト位置で接触が解除される場合、システムはリンクを選択することによって対応し、ラジオボタンの位置で接触が解除される場合には、システムは、ラジオボタンの状態を切り替えることによって対応する。
これが実行された時点で、関数18922は、スクリーン上でズームインされたレイアウトの表示を、ポインティングデバイスの押下が関数18908によって検知される前にウェブページが表示されていた同一の倍率でレイアウトの表示に置換する。
図121乃至128に関して上述したように、ズームクリックによって、選択された部分のコンテンツを読み易く、且つ、ポインティングデバイスで正確に選択し易くするズームインの縮尺で、ウェブページの所望の部分をユーザが迅速に視認及び選択できるようにするための有益な技術を提供する。
図190は、ユーザがテキストラインを表現するためにグリーキングを使用してウェブページのズームアウトビューを視認することが可能な方法19000に関する高度に簡略化された擬似コード記述である。グリーキングは、読み取り不可能なグラフィック表現でテキストの部分が文書中にレイアウトされるサイズに関する表現である。
この方法は、ウェブページのコンテンツにアクセスする関数19002、ウェブページのコンテンツのレイアウトを実行する関数19004、及び、ウェブページのコンテンツ表示のレイアウトを有するようにユーザが選択した縮尺を検出する関数19006及び19014を含む。
ユーザがウェブページのレイアウトを所定のより大きな縮尺で表示することを選択した場合、関数19006によって、関数19008はウェブページのレイアウトの部分をそのより大きなスケールで表示させる。これは、より大きな縮尺で表示するために拡大/縮小されたビットマップ画像でレイアウトの画像を表現するための関数19010を実行することと、より大きな縮尺での表示に適したサイズを有する別々のビットマップで構成されたビットマップでウェブページの文字列のレイアウトを表現する関数19012を実行することを含む。
一方、小さ過ぎるので、読み取り可能なサイズで、少なくとも幾つかのウェブページのテキストを所定のより小さな表示縮尺で表示することが不可能なそうした表示縮尺をユーザが選択した場合、関数19014によって、関数19016はより小さな縮尺でウェブページのレイアウトの部分を表示させる。これは、より小さな縮尺で表示するために縮小されたビットマップ画像を用いてレイアウト画像を表現する関数19018を実行することと、より小さな縮尺での表示に於いて、個々の文字列のサイズ及び位置を示すグリーキングされたテキスト表現で構成されるビットマップを用いて、少なくとも幾つかの文字列を表現する関数19020を実行することを含む。
多くの場合、そうしたグリーキングに於ける文字列を表現するために使用されるビットマップは、小さな縮尺でウェブページのレイアウトに於ける対応する文字列のサイズに一致する幅、及び/又は、高さを有する直線又は矩形に過ぎない。
テキストが小さすぎて読めないようなサイズでレイアウトを表示する場合、テキストのグリーキングされた表現を使用することによって、そうした表示をより容易、且つ、快適に見ることが出来るようになり、一般に、そうしたグリーキングは、読み取り不可能な小さなフォントビットマップから対応する文字列画像を生成する場合に比して、その生成に必要な演算処理が少ない。
図190に図示された方法に関する主要な使用方法の1つは、ユーザに対してウェブページのレイアウトのオーバービューを即座に視認可能とさせ、例えば、図136及び137に関して上述されたウェブページなど、そうしたウェブページの異なる部分を即座に選択可能にさせることである。
コンピュータユーザインターフェースの当業者は、図185乃至190に記載された方法の幾つかを、互いの組み合わせ、及び、単一ユーザインターフェースモードの一部として上述された本発明の他の特徴との組み合わせで使用することが出来るが、その他の方法を、一般的に異なるユーザインターフェース、又は、異なるユーザインターフェースモーで使用するということを評価するだろう。
図191乃至229は、例えば携帯電話など、非常に小型のスクリーン表示に於いて特に有用であるが、他の種類のコンピュータに於いても使用可能な発明の特徴を説明している。この明細書では、本発明のこれらの特徴をまとめて本発明の新規特徴と呼び、本出願が優先権を主張する本出願の開始時点でリストに上げられた関連出願の何れにも特許請求されていないと信ずる。
図217は、図217乃至225に関して記述されている本発明の新規特徴に関する実施形態に於いて、プロキシサーバ上で実行されたメインループ21700の高度に簡略化された表現である。この実施形態は、図115及び116に関して上述した種類のクライアントプロキシシステムを使用している。図217のテキスト21702によって図示されているように、このメインループのステップは、テキスト21704乃至21706によって示された相違点を除いて、図115に関して上述したステップに類似している。
テキスト21704で図示されているように、図217乃至225に図示された特定の実施形態は、図115の関数11526乃至11532に記述された再スケール(拡大/縮小)をサポートしない。本発明の新規特徴に関する他の実施形態は、オーバービューウインドウ、及び/又は、拡大ビューウインドウに於けるそうした拡大/縮小をサポートすることが出来る。
テキスト21706で示されているように、図217乃至225に記載された本発明の新規特徴に関する特定の実施形態に於いて、プロキシは、所望の仮想スクリーン幅を要求するという事実以外に、レイアウト幅の決定に役立てるために、レイアウトのサブセットとして、仮想スクリーンに関するコンセプトを有していない。 レイアウトエンジンは、レイアウト要素のサイズがより大きな仮想レイアウト幅を要求しない限り、仮想レイアウトをこの要求された幅に限定しようとする。図115に記載された実施形態に於いては、仮想スクリーンを最初に移動させる必要があるが、この実施形態に於いて、プロキシは仮想スクリーンとしてレイアウト全体を処理し、最初に仮想スクリーンを移動させる必要なく、仮想レイアウトに於ける任意の倍所で発生するクリックに対応することが出来る。
図217乃至225に図示された実施形態は、図115に関して記載された実施形態のように、所定のウェブページのレイアウト全体の表示リストを薄型クライアントにダウンロードする。これにより、クライアントコンピュータは、ウェブページの連続部分をプロキシにダウンロードさせるために必要な遅延を被ることなく、ウェブページの新たな部分に移動されたクライアントの表示として、ダウンロードされたウェブページに於ける任意の位置にその表示を即座に移動させることが出来る。
本発明の他の実施形態に於いては、ウェブページ全体を一度にダウンロードしなくても良い。例えば、本発明のこうした新規特徴の一つの代表例では、プロキシサーバの仮想レイアウトの800×945部分に対応する、400×473ピクセルの表示リストをダウンロードした。そうした実施形態に於いて、ユーザがウェブページの以前ダウンロードされた部分から移動した場合、クライアントは、その後でウェブページのレイアウトの新規部分をダウンロードしたプロキシに通知する。
図218は、本発明の新規特徴に関連するクライアントコンピュータのブラウザプログラムのメインループ21800の一部を説明している。同図には図示されていないが、当然のことながら、クライアントのメインループは図116に関して上述されたそうしたステップに類似のステップを含む。さらに、それは数字21802乃至21878で示された関数を含む。
関数21802は、関数21804乃至21806を実行させることによって、プロキシサーバからの要求されたウェブページに関する表示リストの受信に対応する。関数21804は、表示の最初に選択された部分、即ち、任意のスクリーンウインドウに最初に示される部分を、ダウンロードされた表示リストで示されているように、ウェブページのレイアウトの上部左隅にセットする。これは、ユーザがウェブページの他の部分を表示目的で選択するために何らかの対処をする前に、任意の表示スクリーンに表示されるウェブページレイアウトの部分である。
代替実施形態に於いて、表示目的で最初に選択されたウェブページの部分は、例えば、図115のステップ11502に関して上述した種類のビュー設定の使用等、他の手段で設定可能である。
関数21806は、ダウンロードされた表示リストの連続する要素をクライアントコンピュータ上に保存される表示リストデータ構造に変換することによって、それらの要素のクライアントによる受信に対応する。現在の実施形態に於いて、ダウンロードされた表示リストは、クライアント上のウェブページを示す表示リストにセットされることになる対応するデータ構造を決定するために、ステップ21806に於けるクライアントブラウザで後に解析されるページ記述言語で実際に伝達される。
幾つかの実施形態に於いて、オーバービュー及び拡大ビューウインドウに対するビットマップは、ダウンロードされたウェブページレイアウトに対応する表示リストから動的に生成される。他の実施形態に於いて、レイアウトビットマップは、ダウンロードされた表示リストから該表示リストで指定された縮小された解像度で作成され、拡大表示は単に最大解像度で該ビットマップの一部を表示し、オーバービューは該ビットマップのさらに縮小されたバージョンを表示する。
関数21808は、図218の受信された種類の入力の下で意図された一つ又は複数の関数にプログラムフローを向かわせることによって、所定種類の入力の受信に対応する、分岐関数を示している。
仮想的な任意の適切なユーザインターフェースハードウェア、及び/又は、ソフトウェアルーチンによって、分岐関数21808が対応する入力を生成することが出来る。図191に図示された種類の携帯電話を使用する場合、図191及び192に図示された携帯電話に類似の種類のメニュー19104を使用することによって、及び、そうした携帯電話のフォンパッド19105に於ける所望のメニューアイテムに対応する数字を有するキーの押下によって、そうした選択を実行することが可能である。また、ボタン19108及び19112の一つを押下することによって、そうした入力の一つ又は複数を選択することが可能であり、ボタン(19108)及び19112のそれぞれは、所定時間でキー定義タブ19106及び19110のそれぞれに定義された現在の関数を有する。例えば図229に図示された実施形態など、携帯情報端末(PDA)で実行する実施形態を含む他の実施形態に於いて、ユーザ入力の入力に適切な任意のユーザインターフェースを使用することが出来る。
関数21810及び21812によって図示しているように、ユーザが図195乃至199に図示された種類の分割ビューを見たいという要望を示す入力を生成する場合、プログラムはビューモードを分割ビューモードに設定する。これにより、図219の関数に対応する、図218に図示された数字21856及び21858によって示された関数を実行することによって、クライアントブラウザを分割ビューモードで実行する。
関数21814及び21816は、ビューモードをオーバービューオンリーモードに設定することによって、図191乃至193に図示された種類のオーバービューオンリーモードを見るというユーザ選択に対応する。これにより、クライアントブラウザは、図220の関数に対応する、図218に於ける数字21860及び21862で示された機能を実行することによって、オーバービューオンリーモードで機能する。
関数21818及び21820によって示されているように、図194に図示されたタ種類の拡大オンリービューをユーザが選択する場合、該ビューモードは拡大オンリーモードに設定される。これにより、図221の関数に対応する、数字21860及び21862で示された拡大オンリーモード関数が実行される。
関数21822及び21824は、ビューモードを拡大鏡モードに設定することによって、図208乃至211に図示された種類の拡大鏡ビューを見るためのユーザ選択に対応する。これにより、図224の関数に対応する数字21864及び21866で示された拡大鏡モード機能が実行される。
ユーザが図205乃至207に図示された種類のリフローテキストオンリービューを選択する場合、関数21826及び21830は、ビューモードをリフローテキストロンリービューに設定する。これにより、図222の関数に対応する、数字21868及び21870で示された関数が実行される。
関数21832及び21834は、ビューモードをリフローテキスト分割ビューモードに設定することにより、図201乃至203に図示された種類のリフローテキスト分割ビューを見るためのユーザ選択に対応する。これにより、図223A及び223Bの関数に対応する、数字21872及び21874で示された関数が実行させる。
ユーザがリフローテキストサイズ選択を実行する場合、関数21836及び21838は、現在のリフローテキストサイズを選択されたサイズに設定する。多くの好ましい実施形態に於いて、リフローテキストサイズは、例えば、「小」、「中」、「大」、及び、「特大」としてラベル付け可能な複数の一連のサイズの内、選択されたサイズを示す。それぞれのそうしたサイズ選択によって、通常、関連付けられた異なるサイズのフォントを有するウェブページテキストが、例えば、ヘディングテキストをボディテキストに比して大きくすることにより、そうした異なるサイズに幾分比例する方法で拡大/縮小される。
ユーザがコラム幅制限のオン/オフの状態を切り換えることを選択する場合、関数21840及び21842は、コラム幅制限が予めオフの状態であればオンの状態に切り換えて、予めオンの状態であればオフの状態に切り換える。図225乃至228に関して後述するように、コラム幅制限は、拡大ビューウインドウ内で適合する幅にウェブページのレイアウトに於けるテキストコラムの幅を制限する。
ユーザがカーソルナビゲーションを選択する場合、関数21844及び21846はナビゲーションモードをカーソルナビゲーションに設定する。多くの携帯電話に関する実施形態に於いて、これにより、例えば図191に図示されたスイッチ19114で、ナビゲーションロッカースイッチの上下左右の動きが、図191乃至200に図示されたカーソル19116を対応する方向に直接移動させる。
ユーザがビューナビゲーションを選択する場合、関数21848及び21850は、ナビゲーションモードをビューナビゲーションに設定する。これにより、ナビゲーションスイッチの上下左右の動きが、対応する方向に拡大ビュー、テキストリフロービュー、又は、他の種類のビューを直接移動させる。
例えば、カーソルがウェブページに表示されたリンク上に位置する際に選択ボタンを押下することによって、ユーザがリンクを選択する場合、関数21852及び21854は、プロキシサーバに該リンクに関連付けられたウェブページに対する要求を送信し、そのソースからのウェブページに対する要求を含む、図115及び217に関して上述された方法でプロキシサーバに対応させ、ウェブページのレイアウトを実行し、その後、該レイアウトに対応する縮小された表示リストを作成し、クライアントにダウンロードする。
上述の通り、数字21856及び21858、数字21860及び21862、数字21864及び21866、数字21868及び21870、数字21872及び21874、数字21876及び21878に対応する関数については、それぞれ、図219、220、221,222、223A及び223B、及び、224に於いて、さらに詳細に説明されている。
図219は、ビューモードが分割ビューに設定される場合に実行される、一連の関数21900を説明している。これらの関数により作り出されたスクリーンショットは、図195乃至199に図示されている。
関数21902は、表示関数21904乃至21910によって作り出された要素を同時に表示する。
スクリーンユーザインターフェースの当業者が理解しているように、多くの実施形態に於いて、同図、及び、図220乃至224に図示された表示関数は、通常、イベント駆動型であり、これは、それらの表示関数が、関連付けられた表示要素の表示を作成し、変更し、移動させることを示すイベントに対応して、通常、スクリーン上に表示されたビットマップに対して変更を加えるだけだということを意味する。
関数21904は、例えば図195に図示されたオーバービューウインドウ19200A等のオーバーウインドウをスクリーンの第1水平部分に表示する。
図195乃至199に図示された分割スクリーンに関する実施形態は、マイクロソフト社によってサポートされたスマートフォン仕様に於いて使用された176×220ピクセル解像度で表示されている。この実施形態に於いて、オーバービューウインドウは、その中に位置する可能性のある任意のスクロールバーを含め、合計176×132ピクセルのサイズを有しており、殆どのデスクトップコンピュータ及びラップトップコンピュータに対して一般的な、同一の縦横比4対3をそのサイズに割り当てている。
詳細に説明されている実施形態に於いて、プロキシサーバの仮想レイアウトに於ける800ピクセル幅、及び、ダウンロードされた表示リストによって表示された縮小レイアウトに於ける400ピクセル幅に対応するレイアウトの一部に適合するように、オーバービューウインドウ19200Aは、表示リストに記載された解像度から水平方向及び垂直方向に縮小された、ダウンロード済みの表示リストで説明されたレイアウトの一部を示す。オーバービューウインドウが垂直スクロールバーを含む場合、表示されたレイアウトの部分は、スクロールバーに必要とされる幅に減少される。
他の実施形態に於いて、オーバービューウインドウに適合するために拡大/縮小されたウェブページ全体を有する能力をユーザに提供することが出来るが、ウェブページのサイズが大き過ぎて、視聴者にとって、そのように拡大/縮小されたビューが殆ど役に立たなくなるのであれば、多くの場合、これは望ましくない。
関数21906は、図195に図示された拡大された表示ウインドウ19400Aをスクリーンの第2水平部分に表示する。図195乃至199に図示された実施形態に於いて、全体的に拡大されたウインドウは、それが表示されるスクリーンの最大176ピクセル幅、及び、88ピクセル高を有する。これは、プロキシサーバ上に形成されたプロキシサーバの仮想レイアウトに於ける352×176ピクセルのサイズに対応する。
拡大されたビューウインドウは、ダウンロードされた表示リストに記載された最大解像度でオーバービューウインドウに図示されたレイアウトの一部のサブパートを表示している。図示された実施形態に於いて、拡大されたビューウインドウは、オーバービューウインドウに関連して「拡大」される。実際、プロキシサーバ上で形成された仮想レイアウト、及び、その要素の多くが殆どのデスクトップコンピュータ又はラップトップコンピュータ上で見られるサイズに関連して、それは倍率2で縮小される。
拡大されたビューウインドウに於けるテキストはアンチエイリアスフォントビットマップで表示され、該ビットマップは、拡大されたビューウインドウに表示される実際の解像度に対して、可読性を最適化、又は、改善するために選択された文字アウトラインの形状及びピクセル配置を有する。拡大されたウインドウを表示するスクリーンが、垂直方向で実行されるサブピクセル文字列を有する場合、図55乃至97、及び、図168乃至184に関して上述されたフォントと全く同一、又は、類似の垂直方向にサブピクセル最適化されたフォントを使用することが出来る。水平方向でサブピクセルストリッピングが実行される場合、上述の非線形サブピクセル最適化の水平換算を使用するフォントなど、水平方向にサブピクセル最適化されたフォントを使用することが出来る。
関数21908は、図195乃至199のオーバービューウインドウに表示された、拡大されたビューインジケータ19504を表示する。これは、オーバービューウインドウに表示されたウェブページレイアウトに関連して、拡大されたビューウインドウに現在表示されているレイアウトの一部の位置を示す。
関数21910は、オーバービューウインドウ、及び、拡大されたビューウインドウの両方に於いて、図195乃至199に図示されているカーソル19116を表示する。該カーソルは、オーバービュー及び拡大されたビューの両方のそれぞれに於けるレイアウトに関連して、同一位置を有する。
このカーソルは、異なる実施形態、異なるビューウインドウに於いて、又は、選択可能なリンク、テキスト、テキスト領域、他の種類のウェブコンテンツの上に位置するかどうかに関する関数として、異なる形状を有することが出来る。図191乃至211に関する様々な実施形態に於いて、カーソルは、小型の十字形状19116、リンク選択記号19116A、又は、テキストカーソル19116Bとして図示されている。
低解像度表示に於いて、カーソルは比較的大きくなる傾向があり、これにより、高解像度表示に比して、テキスト及び画像の視認をさらに妨害する傾向にあるので、幾つかの実施形態に於いては、ユーザは、カーソルの表示をオフの状態に切り替える為のすべて、又は、幾つかの視認モードに於ける選択肢が与えられる。
分割ビューに於いて、関数21914乃至21948を実行させることによって、関数21912は、例えば図191に図示されたロッカースイッチの押下など、ナビゲーション入力の受信に対応する。
現在のナビゲーションモードがビューナビゲーションモード、即ち、ユーザが拡大されたウインドウに表示されたレイアウトの一部を直接移動させることによってナビゲート可能なモードにある場合、関数21914によって、関数21916乃至21928が実行される。
関数21916によって、関数21918及び21920は、これに対応して、受信されたナビゲーション入力によって示された方向で、(a)拡大されたビューウインドウに表示されたウェブページレイアウトの一部と、(b)オーバービューウインドウに於けるレイアウトに関連した拡大されたビューインジケータ、の両方を移動させる。
関数21916乃至21920によって実行された移動によって、オーバービューウインドウに於けるウェブページレイアウトの一部を越えて、そして、ウェブページレイアウトの以前非表示であった部分の上に、拡大されたビューインジケータの一部を移動させる場合、関数21922によって、関数21924乃至21928もまた、その移動の一環として実行される。
関数21924は、レイアウトの以前非表示であった部分をオーバービューウインドウでスクロールする。関数21926は、ウェブページレイアウトの以前非表示であった部分の上に拡大されたビューインジケータを移動させる。そして、関数21928は、拡大されたビューウインドウに表示されたレイアウトのサブパートをこれに対してスクロールする。異なる実施形態に於いて、そうした関数の命令を変更することが出来る。
図196乃至199は、分割スクリーンモードに於ける関数21914乃至21928によって実行されるビューナビゲーションを図示している。
図196は、ウェブページレイアウトの左端部に、拡大されたビューインジケータ19504を使用した分割ビューを図示している。図197は、関数21916及び21920の動作によって、拡大されたビューインジケータ、及び、拡大されたビューに於けるレイアウトの一部を右に移動した後の分割ビューを図示している。
図198は、図197に於ける拡大されたビューの位置から、オーバービューウインドウに表示されたレイアウトの一部の下端まで、ユーザが拡大されたビューを下方向にナビゲートした後の分割ビューを図示している。
図199は、関数21916乃至21920の動作だけでなく、関数21922乃至21928の動作を介して、図198に於けるオーバービューウインドウに表示されたオーバービューの一部の下方に、ユーザが拡大されたビューを下方向にナビゲートした後の分割ビューを表示している。
関数21922乃至21928の動作、及び、同図の何処かに含まれた類似の関数の動作によって、ユーザは、オーバービューウインドウに図示されたレイアウトの一部の境界を越えて、拡大されたウインドウをスムーズにナビゲートすることが出来る。
図196乃至199に図示された実施形態に於いて、拡大されたビュー内に保持するように、自動的にカーソルを移動させる。他の実施形態に於いて、カーソルの位置を拡大されたビューの位置から独立させることが出来る。通常、そうした他の実施形態がカーソルナビゲーションモードの状態にあった場合、拡大されたビューはそのビューにカーソルを保持するために移動し、これにより、ユーザは拡大されたビューに表示されたより大きな縮尺で、カーソルの位置を継続して視認することが可能となる。
現在のナビゲーションモードが、分割スクリーンの表示時に、カーソルナビゲーションモード、即ち、ユーザが直接カーソルを移動させることが出来るモードの状態にある場合、関数21930によって、関数21932乃至21948が実行される。
関数21932は、入力によって示された方向で、拡大されたビュー、及び、オーバービューの両方に表示されたウェブページレイアウトの一部に関連して、カーソルを直接移動させる。
この関数は、拡大されたビューウインドウに表示されたウェブページレイアウトのサブパートを越えて、拡大されたビューウインドウに於ける以前非表示であったウェブページレイアウトの一部の上に、カーソルを移動させる場合、関数21934によって、関数21936乃至21940がこの移動の一環として実行される。
関数21936は、ウェブページレイアウトの以前非表示であった部分の上にカーソルを移動させる。関数21938は、拡大されたビューウインドウに関連してウェブページレイアウトをスクロールし、これにより、カーソルが移動される以前に非表示であった部分が、拡大されたビューウインドウに於いてスクロールされる。そして、関数21940は、これに対して、オーバービューウインドウに於いて拡大表示インジケータを移動させる。
関数21934乃至21940によって、カーソルモードの状態で、拡大されたビューの境界に対してカーソルを押下することによって、レイアウトに関連して拡大されたビューウインドウをユーザがスクロールすることが出来るということが分かる。本発明に関する代替実施形態に於いて、ユーザは拡大されたビューの外側でカーソルをスクロール可能としても良い。
関数21932によって実行された移動によって、オーバービューウインドウに於けるウェブページレイアウトの部分を越えて、ウェブページレイアウトの以前に非表示であった部分の上に、拡大されたビューインジケータの部分を移動させる場合、関数21942によって、関数21944乃至21948がこの移動の一環として実行される。
関数21944は、レイアウトの以前に非表示であった部分を、オーバービューウインドウに於いてスクロールする。関数21946は、拡大されたビューインジケータをウェブページレイアウトの以前に非表示であった部分の上に移動させる。そして、関数21948は、これに対して、拡大されたビューウインドウに於いて表示されたレイアウトのサブパートをスクロールする。
図220は、ユーザがクライアントブラウザをオーバービューオンリーモードにすることを選択した場合に、クライアントブラウザによって実行される一連の関数22000を図示している。図191乃至193は、このモードで生成された176×220解像度のスクリーンショットである。
関数22002によって、関数22004及び22006は、オーバービューウインドウ19200及びカーソル19116を同時にクライアントブラウザの表示スクリーン上に表示させる。
関数22004によって表示されたオーバービューウインドウは、スクリーンの略全てに表示される。オーバービューウインドウは、ダウンロードされた表示リストによって記載されたレイアウトの一部を表示し、その表示リストに記載された解像度から縮小される。
図示された実施形態に於いて、オーバービューオンリーモードでのオーバービューウインドウは、図219に関して上述された分割モードに於いて図示されたオーバービューウインドウと同一の倍率で、このレイアウトを縮小する。
幾つかの実施形態に於いて、例えば、図193の最下部に図示された「メニュー(Menu」」タブや、「終了(Quit)」タブなど、制御や、その他の目的の余地を残すために、オーバービューウインドウは、スクリーンの全てではなく、略全てを覆っている。
オーバービューオンリーウインドウのサイズを記述する場合に、「略全て」という用語を使用しているが、これは、スクリーンの領域の少なくとも80%を覆っていることを意味する為に使用されることがあるという状況に比べると、それ程極端ではない意味である。幾つかの実施形態に於いて、そうした「略全て」のカバレッジは、ブラウザプログラムによって占められたスクリーンの一部に関連している。
現在のナビゲーションモードがビューナビゲーションモードである場合に、クライアントコンピュータがオーバービューオンリーモードの状態で、ユーザからナビゲーション入力を受信する場合、関数22010及び22012は、入力によって示された方向でオーバービューウインドウに表示されたレイアウトの一部をスクロールする。
一方、クライアントがナビゲーション入力を受信する際に、カーソルナビゲーションの状態にある場合、関数22014によって、関数22016乃至22022が実行される。
関数22016は、入力によって示された方向で、オーバービューウインドウに表示されたウェブページレイアウトの一部に関連してカーソルを直接移動させる。
関数22016によって実行されたこの移動によって、オーバービューウインドウに於けるウェブページレイアウトの一部を越えて、ウェブページレイアウトの以前に非表示であった部分の上にカーソルを移動させる場合、関数22018によって、関数22020及び22022もまた、この移動の一環として実行される。関数22020は、レイアウトの以前に非表示であった部分をオーバービューウインドウにスクロールする。そして、関数22022は、ウェブページレイアウトの以前非表示であった部分の上にカーソルを移動させる。これらの関数によって、ユーザはオーバービューウインドウをスクロールすることが出来る。
図221は、クライアントブラウザが拡大オンリービューモードの状態にある場合、クライアントブラウザプログラムによって実行される一連の関数22100を図示している。このモードで生成された表示に関する176×220解像度のスクリーンショットは、図194に図示されている。
図194に図示されているように、関数22102によって、関数22104及び22106が拡大されたビューウインドウ19400及びカーソル19116を同時に表示させる。拡大オンリービューに於いて、拡大されたビューウインドウは、クライアントのスクリーンの略全て(即ち、少なくともクライアントのスクリーンの80%)を占めている。
図示された本発明の実施形態に於いて、この拡大されたビューウインドウは、(a)ダウンロードされた表示リストに記載された最大解像度でウェブページレイアウトの一部を表示し、(b)拡大されたビューに表示される解像度に対する可読性を改善、又は、最適化するために、ビットマップのピクセルを用いて形成され配置された文字アウトラインを有する、同一のアンチエイリアス処理、又は、サブピクセル最適化処理が行われたフォントビットマップを使用してテキストを表示する、という点で、図219に関して上述された分割ビューに表示されたウインドウに類似している。
ナビゲーション入力が拡大オンリービューに於いて受信される場合、図221に於いて略最大スクリーンオーバービューというよりは、むしろ、略最大スクリーン拡大ビューに関連して、ナビゲーションが実行されるという点を除いて、関数22110乃至22122は、それぞれがオーバービューオンリービューで実行する場合と同一の方法で、ナビゲーションを実行する。
図222は、リフローテキストオンリービューモードの状態にある場合、クライアントコンピュータによって、一連の関数22200が実行されることを図示している。このモードで生成されたスクリーンショットのシミュレーションが、図205乃至207に図示されている。
カーソルが現在位置する、又は、最も近くにあるコラムのテキストが、リフローテキストサイズでリフローされていなかった場合、図222の関数22201及び22202は、現在選択されたリフローテキストサイズで、新たにリフローされたテキストコラムのラインを越えて、そのコラムのテキストをレイアウトする。
図示された実施形態に於いて、ユーザがリフローされるコラムの幅を選択する必要がない点を除いて、図130乃至134に関して上述された方法に類似の方法で、このテキストのリフローを実行することが出来る。その代わりに、このシステムは、リフローされるコラムとして、カーソルが現在位置するコラムを選択するか、又は、任意のテキストを含むコラムにカーソルが現在位置していない場合、現在のカーソル位置に最も近いものとして、そのテキストを含むコラムが選択される。
幾つかの実施形態に於いて、分割スクリーンが表示される場合、及び、ユーザがリフローテキストモードへの変更を選択する際に、システムが拡大ビューナビゲーションモードの状態にある場合、リフローの為に自動的に選択されたテキストコラムは、拡大ビューの中心に最も近いコラムである。
ここで説明された実施形態に於いて、リフローされたテキストのより迅速な表示を可能にするために、テキストコラムのリフローがクライアントブラウザ上で実行される。このレイアウトに関連する演算は、通常、多くのウェブページのレイアウトに関連した演算に比して、それ程複雑ではないので、テキストコラムのリフローを容易に実行することが出来る。他の実施形態に於いて、リフローされたテキストビューに対するテキストコラムのリフローを、プロキシサーバ上で実行することが出来る。
現在選択されたリフローテキストサイズで決定されたサイズを有するフォントを使用して、テキストリフローを実行する。通常、リフローされたコラムの幅に関連してリフローされたテキストのサイズは、ウェブページのレイアウトに於けるコラムの幅に関連して選択されたテキストのフォントに比して大きい。テキストコラムが異なるサイズのフォントを有する場合、概ね比例する方法で、一つ又は複数のそうした個別のフォントサイズを、選択されたリフロー済みのフォントサイズの関数として個別に拡大/縮小することが出来る。
関数22203によって、関数22204及び22206は、図205乃至207に図示されたリフローされたテキストウインドウ20502、及び、カーソル19116A又は19116Bの両方を同時に表示させる。関数22204は、リフローされたテキストウインドウをクライアントコンピュータのスクリーンの略全て(即ち、80%又はそれより大きな割合)に表示する。スクリーンを右、そして、左に交互に移動させる必要なく、テキストのラインを読み取ることが出来るように、この表示はリフローされたテキストコラムの最大幅を表示する。
図205乃至207の疑似スクリーンショットに図示されていないが、文字アウトラインの形状及びピクセル配置がそのウインドウで表示される解像度に対して、可読性を改善、又は、最適化するために選択されているアンチエイリアスフォントビットマップを用いて、このウインドウに於けるテキストを表示することが望ましい。幾つかの実施形態に於いて、これは、例えば、図55乃至97、及び、図168乃至184に関して上述された垂直サブピクセル最適化フォント等、非線形サブピクセル最適化フォントのユーザを含む。
関数22201乃至22206の動作については、図204及び205に於いて説明されている。図204は、図219の関数によって形成された分割ビューに於けるウェブページに関連して、カーソル19116の位置を図示している。図205は、図204に図示された位置にカーソルが位置する際に、ユーザがそのビューモードを選択する場合に生じる、リフローテキストオンリービューを図示している。図204及び205の比較から判る通り、カーソル19116に最も近いテキストコラムが、図205に図示された、結果的に生じるリフローされたテキストウインドウ20502に表示される。
ビューナビゲーションが選択された際に、リフローテキストオンリービューモードでナビゲーション入力を受信する場合、関数22210によって、関数22212乃至22232が実行される。
ナビゲーション入力が水平移動を目的とする場合、関数22212によって、関数22214が実行される。この関数は、この入力の受信以前に表示されたテキストコラムの左側、又は、右側にテキストコラムが存在するか否かを確かめるためにテストを行い、テキストコラムが存在する場合、この関数によって、関数22216乃至22220が実行される。
関数22216は、そのコラムに於ける最も近い位置にカーソルを移動させる。関数22218は、関数22202に関して上述された方法と同一の方法で、そのコラムに存在するテキストを、リフローされたテキストコラムにリフローする。関数22220は、リフローされたテキストウインドウにあるカーソルに最も近い、この新たにリフローされたテキストコラムにテキストを表示する。
図205及び207は、関数22216乃至22220の動作を説明している。図207は、ユーザがそのビューを右側に移動させるナビゲーションコマンドを送信する場合に生じる、図205に図示されたコラムの右にあるコラムに於けるテキストの表示を図示している。図205に於いて、表示されたテキストは、図204に於ける拡大されたビューの殆どを占めるテキストコラムに対応する。図207に於いて、表示されたテキストは、図204に於ける拡大されたビューの右側から始まるコラムに於けるテキストに対応する。
リフローテキストオンリービューに於いて、ビューナビゲーションで垂直移動を受信する場合、関数22222によって、関数22224乃至22232が実行される。
関数22224は、リフローされたテキストウインドウに表示されたリフローされたテキストコラムの一部を、入力によって示された垂直方向にスクロールする。そうしたスクロールは、図205と、図205に図示されたテキストの下位部を表示する図206との間の変化によって示されている。
そうしたスクロールがリフローされたコラムの最上部又は最下部に到達する場合、関数22226によって、関数22228乃至22232が実行される。関数22228は、上方又は下方の最も近くにあるテキスト又はテキストコラムの最下部又は最上部に、それぞれカーソルを設置する。関数22230は、リフローされたテキストウインドウ内に適合するように、新しいコラムのテキストをリフローする。そして、関数22232は、リフローされたテキストウインドウにあるカーソル、及び、その近傍のテキストを表示する。
システムがカーソルナビゲーションモードの状態の場合、ナビゲーション入力の受信時に、関数22234によって関数22236乃至22254が実行される。
関数22236は、リフローされたテキストウインドウに表示されたリフローされたコラムのテキストの一部に関連して、ナビゲーション入力によって示された方向に、カーソルを直接移動させる。
所定のラインの端部を越えて、水平方向の左、又は、右の移動のそれぞれでカーソルを移動させる場合、関数22238及び22240は、上方のラインの最後、又は、下方のラインの最初にカーソルを移動させる。
関数22236又は22240の移動が、現在のリフローされたコラムの最上部又は最下部を越える場合、関数22242によって、関数22244乃至22248が実行される。関数22244は、上方又は下方の最も近いテキストコラムの最下部又は最上部にそれぞれカーソルを設置する。関数22246は、リフローされたテキストウインドウ内に適合させるために、新しいコラムのテキストをリフローする。関数22248は、カーソル及びその近傍のテキストをリフローされたテキストウインドウに表示する。
22236又は22240の移動によって、ナビゲーション入力が生成される前に、リフローされたテキストウインドウに表示されたテキストコラムの一部を越えて、リフローされたテキストウインドウに以前非表示であったテキストコラムの一部の上に、カーソルを移動させる場合、関数22250によって、関数22252乃至22254がそうした移動の一環として実行される。
関数22252は、リフローされたテキストコラムの以前非表示であった部分の上にカーソルを移動させ、関数22252は、リフローされたテキストウインドウに関連して、リフローされたテキストコラムをスクロールさせ、これにより、カーソルが移動される以前非表示であった部分が、リフローされたテキストウインドウにスクロールされる。
図223A及び223Bは、クライアントがリフローテキスト分割ビューにある場合に実行される一連の関数22300を図示している。図201乃至203は、この表示モードで生成されるビューに関する疑似スクリーンショットである。
カーソルが現在位置する、又は、最も近くに位置するコラムのテキストが、現在のリフローされたテキストサイズでリフローされていない場合、図222に於ける類似の数字が割り当てられた関数に一致し得る図223Aの関数22201及び22202は、現在選択されたリフローテキストサイズで、新たにリフローされたテキストコラムのラインを越えて、そのコラムのテキストをレイアウトする。
図223Aの関数22302によって、関数22304乃至22310が、リフローされたテキスト分割ビューの要素を同時に表示する。
関数22304は、表示スクリーンの第1水平部分にオーバービューウインドウ19200Aを表示する。このオーバービューウインドウは、ダウンロードされた表示リストによって表現されたレイアウトの一部を表示し、表示リストに於いて表現された解像度から縮小される。図示された実施形態に於いて、このオーバービューウインドウは、図195乃至199及び図219に関して上述された分割ビューのウインドウに一致する。
関数22306は、図201乃至203に図示された、リフローされたテキストウインドウ20102をスクリーンの第2水平部分に表示する。このウインドウは、リフローされたテキストコラムの最大幅を表示し、これにより、それぞれのラインに対して左右にスクロールする必要なく、そのテキストを読み取ることが出来る。
図205乃至207に図示された、略最大スクリーンでリフローされたテキストウインドウ20502に関して上述されたビットマップと同一のアンチエイリアスフォントビットマップを使用して、部分的なスクリーンでリフローされたテキストウインドウ20102にテキストを表示することが望ましい。
関数22300は、図201乃至203に図示された表示されたテキストインジケータ20104を、リフローされたテキストウインドウに現在表示されているオーバービューウインドウに表示されたテキストの一部を示すオーバービューウインドウに表示する。
関数22310は、それぞれのそうしたウインドウに於けるテキストに対して、同一位置を有するオーバービューウインドウ、及び、リフローされたテキストウインドウの両方にカーソルを表示する。
図223A及び223Bに於ける関数の残りの部分は、リフローされたテキスト分割ビューに於けるナビゲーションを図示している。変更又は追加に対応する図223A及び223Bに於いて下線が付されたテキストを除いて、これらの関数は、図222に図示された関数22210乃至22254に一致する。図223A及び223Bに於いて、図222に図示された関数に対応する関数は、後に文字「A」が続く同一の番号を有する。
図222に図示されたナビゲーションに対する図223A及び223Bのナビゲーション間の相違は、(1)関数22312、22314、22316、22324、22326、及び22328によって示されているように、リフローされたテキストウインドウに表示されたテキストに於ける変化に対応するための、表示されたテキストインジケータの移動と、(2)関数22318乃至22324、及び、関数2230乃至22326で示されているように、リフローされたウインドウに表示されたテキストの一部を、オーバービューウインドウ上の表示されたテキストインジケータに表示可能にする必要がある場合に於ける、オーバービューウインドウに表示されたウェブページレイアウトの一部のスクロールと、(3)関数22236Aで示されているように、リフローされたテキストウインドウ及びオーバービューウインドウの両方に於けるカーソルの移動、を含む。
図224は、ビューモードが拡大鏡ビューに設定される場合に機能する一連の関数22400を図示している。こうした一連の関数は、関数22402乃至22454を含む。このモードのスクリーンショットが、図208乃至211に図示されている。
関数22402によって、関数22404乃至22410が拡大鏡表示の要素を同時に表示させる。
拡大鏡ウインドウによって覆われた部分を除いて、関数22404は、表示スクリーンの略全てに於いて、オーバービューウインドウ19200Bを表示する。このオーバービューウインドウは、ダウンロードされた表示リストによって表現されたレイアウトの一部を表示し、表示リストに表現された解像度から縮小される。図示された実施形態に於いて、オーバービューは、分割ビュー、オーバービューオンリーモード、及び、リフローテキスト分割ビューに於ける、オーバービューウインドウと同一の解像度でウェブページレイアウトを表示する。
オーバービューウインドウが拡大ビューウインドウで「覆われている」と表現する場合、オーバービューウインドウの一部が、ユーザインターフェースの観点から、表示上で拡大されたビューによって覆われているように見えるということを意味する。オーバービューウインドウが拡大されたビューで覆われているように見えるのは、拡大されたビューが、図209と210の間、及び、図210と211との間に位置するように移動される場合に、オーバービューウインドウの以前に「覆われた」部分から拡大されたビューが離れるように、以前に「覆われた」部分が表示されるからである。当然のことながら、殆どの実施形態に於いて、任意の時点で拡大されたビューによって覆われている表示スクリーンの部分に於けるピクセルが、拡大されたウインドウのビットマップのみを表示する。
関数22408は、オーバービューウインドウに図示されたレイアウトの一部を越えて、拡大されたビューウインドウ19400Bを表示する。拡大されたビューは、ダウンロードされた表示リストに表現された最大解像度で、オーバービューウインドウに表示されたレイアウトの覆われたサブポーションの内、拡大されたサブパートを表示する。
関数22408は、オーバービューに表示されたレイアウトに関連して、拡大されたビューに表示されたレイアウトのサブパートの位置を示す、一つ又は複数の拡大されたサブパートマーカを表示する。図示された実施形態に於いて、拡大されたサブパートマーカは、図208乃至211に於いて20804及び20806としてラベル付けされ、拡大されたビューウインドウの端部に設置される。マーカ20804は、拡大されたビューウインドウに表示されたレイアウトの一部のオーバービューウインドウに対して垂直位置を示しており、マーカ20806は、オーバービューウインドウのレイアウトのその部分の水平位置を表示する。
関数22410は、ユーザ可動カーソル19116を拡大されたビューウインドウに表示する。カーソルの位置に対応するオーバービューウインドウの一部が拡大されたビューで覆われているので、カーソルはこのモードでオーバービューウインドウに表示されない。
拡大鏡モードの状態で、クライアントコンピュータがナビゲーション入力を受信する場合、関数22412によって、関数22414乃至22426が実行される。
入力が垂直ナビゲーション入力の場合、関数22414によって、関数22416乃至22420が実行される。関数22416は、余裕が有れば、入力に対応する垂直方向で、オーバービューウインドウに関連して拡大されたビューウインドウを垂直に移動させる。関数22418は、拡大されたビューで表示されたレイアウトの拡大されたサブパートの位置を垂直に移動させる。そして、関数22420は垂直拡大されたサブパートマーカを垂直に移動させ、これにより、それらの位置は、そうした移動後にオーバービューウインドウに於けるレイアウトに関連して、拡大されたサブパートの垂直位置に対応する。
通常、関数22416乃至22420の動作によって、拡大されたビューを移動するので、その垂直中心は、オーバービューウインドウに関連して、ウェブページレイアウトの拡大された部分の位置を覆った状態を維持している。この状態が生じる場合、垂直に拡大されたサブパートマーカの位置は、表示スクリーン全体に関連して移動されるが、拡大されたウインドウに関連して同一位置を維持する。図示された実施形態に於いて、拡大されたビューが、最大オーバービューウインドウに対応する空間の最上部又は最下部に達する場合、さらなる上方向ナビゲーション又は下方向ナビゲーションが、それぞれ、拡大されたビューウインドウを移動させないが、垂直に拡大されたサブパートマーカを上方向又は下方向に移動させる。
図209と211との間の相違は、関数22414乃至22420によって実行される種類の拡大されたビューの垂直ナビゲーションを図示している。
水平ナビゲーション入力を受信する場合、関数22422によって、関数22424及び22426が実行される。
関数22424は、レイアウトの拡大されたサブパートの位置を水平に移動させる。そして、関数22426は、オーバービューウインドウに於けるレイアウトに関連して、拡大されたサブポーションの水平位置に於ける変化に対応するために、垂直に拡大されたサブポーションマーカを水平に移動させる。
図208と209との間の相違は、拡大鏡ビューモードに於ける水平ナビゲーションについて図示している。ここで留意すべきは、拡大ビュー自体は水平方向に移動しないが、拡大ビューに表示されるレイアウト部分と、水平サブポーションマーカ20806のみが移動するという点である。これは、図示された実施形態に於いて、テキストのより長いラインの表示を可能にするために、拡大されたビューがスクリーンの最大幅を拡大し、これにより、水平方向に移動する余地がなくなるからである。
他の実施形態に於いて、オーバービューウインドウは、拡大されたビューの中心の下方に位置する拡大されたビューに表示されたレイアウトの部分を保持するために、拡大されたビューウインドウの下方で、水平にスクロールすることが可能であり、その結果、それはさらに実際の拡大鏡のように動作する。
他の実施形態、そして、特に、より広い、又は、より高解像度のスクリーンを有する実施形態に於いて、実際に拡大鏡の幅はスクリーンの幅よりも狭く、このため、図示された実施形態に於いて拡大鏡が垂直移動することが可能な方法と同様の方法で、水平に移動することが可能である。
カーソルナビゲーションモードの状態で、拡大鏡表示ビューを表示するクライアントのブラウザがナビゲーション入力を受信する場合、関数22428によって、関数22430乃至22438が実行される。
関数22430は、拡大されたビューに表示されたウェブページレイアウトの一部に関連して、入力によって示された方向にカーソルを直接移動させる。関数22432は、関数22430の移動によって、拡大されたビューウインドウに表示されたウェブページレイアウトのサブパートを越えて、拡大されたビューウインドウに於いて以前に非表示であったウェブページレイアウトの一部の上に、カーソルを移動させるか否かを確かめるためにテストを行う。カーソルが上記のように移動する場合、関数22432によって、関数22434乃至22438がその移動の一環として実行される。
関数22434は、ウェブページレイアウトの以前非表示であった部分の上にカーソルを移動させる。関数22434は、拡大されたビューウインドウに関連して、ウェブページレイアウトをスクロールするので、カーソルが移動される以前に非表示であった部分は、拡大された表示ウインドウにスクロールされる。そして、そうしたインジケータを拡大されたビューで表示されたウェブページの一部に対応するオーバービューに関連した位置に対応させることが必要な場合、関数22438は、これに対して拡大されたビューインジケータをスクロールする。
ビューナビゲーションとカーソルナビゲーションモードの何れかで実行される移動によって、拡大されたビューによって覆われた部分を含む、全体的なオーバービューウインドウに対応するレイアウトの一部を越えて、ウェブページレイアウトの以前に非表示であった部分の上に、レイアウトの拡大されたサブパートのサブポーションを移動させる場合、関数22440によって、関数22442乃至22446がそうした移動の一環として実行される。
関数22442は、全体的なオーバービューウインドウに対応する領域に、レイアウトの以前に非表示であった部分をスクロールする。これに対して、関数22444は、拡大されたビューウインドウに表示されたレイアウトのサブパートをスクロールする。そして、必要に応じて、拡大されたビューに表示されたウェブページの一部に対応するオーバービューウインドウに於ける位置に関連した対応を維持するために、関数22448は拡大されたサブポーションマーカを移動させる。
図212乃至216、及び、図225乃至228は、マルチコラムウェブページのレイアウトに於ける、それぞれのコラムの幅を制限する本発明の一つの特徴に関連している。
上述の本発明の多くの特徴、及び、特に図219及び221に関して上述された拡大オンリービュー、及び、分割スクリーンビューと併せて、本発明のこの特徴を使用することが出来る。各ラインを読むために右にスクロールし、その後、左にスクロールする必要なく、そうしたコラムの複数のラインのそれぞれに於けるテキスト全体を読むことが出来るように、個々のテキストコラムをウェブページのズームイン/拡大されたビューの範囲に適合する程度に十分狭くさせるという利点を有している。
ウェブページプログラムの当業者に知られているように、ウェブページは、コラム中に何が存在するかという定義、コラムの幅、及び、コラムの水平置換を含む、コラムの仕様を有している。所定のコラムの幅及び水平置換は、所定のコラムのコンテンツのサイズによって、又は、所定のコラムの右又は左のコラムの幅によって、例えば、使用可能な表示ウインドウサイズの割合として、無制限のピクセルで仕様が指定される等、複数の方法で定義される。そうした仕様が明示的な場合もあるし、黙示的な場合もある。
図226は、HTMLテーブルとして定義された3つのコラムの仕様例を提示している。
同図に於いて22602でラベル付けされたラインは、テーブル定義の第1ラインである。ライン22604は、テーブル行の定義を開始する。この特別のテーブルは、3つのコラムで形成された1行のみを有する。
ライン22606は、第1コラムの幅が200ピクセルとなる仕様を定めている。ライン22608は、第1コラムのコンテンツとなるテキストを示している。
ライン22610は、中央のコラムを定義しており、該コラムに対して明確に指定された幅を与えていないが、そのコラム幅はテーブルが定義される方法で自動的に定義されている。これによって、コラム幅は、他の2つのコラムによって占められていない表示ウインドウに於いて、全ての使用可能な幅を有するように拡大する。ライン22612は、中央のコラムのコンテンツを含んでいる。
ライン22614は、第1コラムと同様に、第3コラムが200ピクセルの幅を有するように仕様を指定している。最後に、ライン22616は、第3コラムのコンテンツの仕様を指定する。
図227は、図228に図示された外部カスケーディングスタイルシート(CSS)への参照を使用して、図226に定義されたコラムに類似した3つのコラム一式を定義する他の方法を図示している。
図212は、図213乃至216に表示されているウェブページのコンテンツの一部を図示している。図212は、例えば、図226又は227に図示された方法等、ウェブページコラムを定義可能な一つ又は複数の異なる方法を使用して、指定されているマルチコラムに配置されたコンテンツを表示している。同図に於いて、コラムの垂直及び水平方向の境界が灰色のラインで示されている。
図213は、コラム幅に制限がない場合に於ける、図212に図示されたウェブページコンテンツのレイアウトに関する図193に図示された種類のオーバービューオンリービュー19200のシミュレーションである。
図214は、図213に図示されたレイアウトの分割ビューのシミュレーションである。同図は、ウェブページの主要なテキストコラムに於けるテキストラインの幅が、あまりにも広いので、図195乃至199に於いて既に図示された種類の拡大されたビューウインドウ19400Aに適合することが出来ないことを図示している。これは、主要なコラムのテキストのそれぞれの最大ラインを読み取るためには、そうしたテキストの読み取りを遅く、且つ、面倒なものにする傾向のある左右のスクロールが必要となることを意味する。
図215は、図225に関して後述するコラム幅制限プロセスを用いてレイアウトされた同一のウェブページのオーバービューオンリービュー19200のシミュレーションである。
図216は、図215に於けるレイアウトと同一のレイアウトの分割ビューに関するシミュレーションである。図216は、図225の幅制限プロセスによって、幅制限を行う前に、ウェブページ上の最も広い幅のテキストコラムであったコラムの幅全体が、分割ビューの拡大されたビューウインドウ19400A内に一度で適合可能となり、そうしたテキストを一層読み易くすることを示している。
本発明のこの特徴に関する多くの好ましい実施形態に於いて、そうした幅制限されたコラムのテキストが、そうしたテキストが表示されるピクセル解像度に対して可読性を改善、又は、最適化する為に選択された、それらの文字アウトラインの形状及びピクセル配置を有するアンチエイリアスフォントビットマップで表示される。そうしたフォントは、図55乃至97、及び、図168乃至184に関して上述された種類のサブピクセル最適化フォントに成り得る。
図214及び216に於いては、拡大されたビューウインドウ19400Aは、そうしたウインドウが実際に有する近似値に過ぎないが、これは、それらのウインドウに於けるフォントが、その図に於いてそれらがレンダリングされた解像度に対して選択されたそれらの文字アウトラインの形状及びピクセル配列を有する、上記段落で議論した種類のフォントではないからである。これが、図214及び216の拡大されたビューウインドウに於けるテキストが、図194、195乃至199、及び、図208乃至211のそれぞれに図示され、且つ、レンダリングされるピクセル解像度に対して選択された、文字アウトラインの形状及びピクセル配置をフォントビットマップが有する拡大されたビューウインドウ19400、19400A、及び、19400Bのテキストに比して読み難い理由なのである。
図225は、マルチコラムウェブページの要素をそれぞれのコラムの幅が制限されるレイアウトにセットするために使用可能な一連の関数22500を図示している。ウェブページのコンテンツをレイアウトする方法は、当該技術分野に於いては周知である。図225に図示された関数は、本発明の幅制限の特徴に関連した動作に焦点を当てている。
図217乃至224で説明されたクライアントプロキシブラウザスキームに於いて、図225のマルチコラムレイアウトは、図115の関数11507で説明されたレイアウトプロセスの一環として、プロキシサーバで実行される。本発明の他の実施形態に於いて、任意の仲介プロキシコンピュータを必要とすることなく、要求されたウェブページを表示しているエンドユーザのコンピュータ上で、そうしたレイアウトをローカルに実行することが出来る。小型コンピュータがさらなるメモリ容量と演算能力を獲得するにつれて、クライアント上でローカルにウェブページレイアウトを実行することはより魅力的になる。
図225の関数22502は、ウェブページに於いて指定されたそれぞれのコラムに対してループを実行する。このループは、関数22504乃至22524を含む。
関数22504は、2つの要因の関数として、定義された水平位置にコラムをレイアウトする。これら2つの要因の内、第1要因は、ライン22506に図示されているように、コラムの指定された水平置換である。コラム幅制限が選択される場合、第2要因は、ライン22508及び22510上に図示されているように、そうしたコラム幅制限によって引き起こされた、現在のコラムの左側にレイアウトされたコラムの指定された幅に於ける任意の減少である。
この明細書及び付随する特許請求の範囲に於いて使用されているように、コラムの指定された水平置換は、例えば、表示スクリーンの幅に関する固定ピクセル位置及び割合などの観点に於ける、その水平置換に関する任意の明確な定義だけでなく、何れのコラムがその左右に位置するかということに関する定義を含んでいる。このように、コラム水平置換が、その左側にあるコラム幅の減少によって変更される場合でさえも、それはやはりその左側に同一コラムを有するので、その位置は依然としてその水平置換に関する関数なのである。
コラム幅制限が選択される場合、関数22512によって、関数22514及び22516がループ22502の現在のコラム内にある任意の画像を、最大の所望コラム幅内に適合するサイズまで縮小させる。
図示された実施形態に於いて、所望の最大コラム幅は、表示時に図216に図示された拡大されたビュー19400A内に適合する幅である。他の実施形態に於いて、所望の最大コラム幅は、そうした実施形態に使用される幅であって、分割スクリーン、又は、スクリーンウインドウ全体としても良い、所定の表示ウインドウ内に適合する幅である。
関数22518は、ライン22520乃至22524で示された2つの要因の関数として決定された幅で、現在のコラムに任意のテキスト及び/又は画像の位置をレイアウトする。テキスト22520に示されているように、これらの要因の内、第1要因は、コラムの指定された幅である。コラム幅制限が選択される場合、これらの要因の内、第2要因は、数字22522及び22524で示されているように、コラム幅が最大の所望コラム幅を越えないようにするために必要な指定された幅の任意の減少である。
図212に図示されたウェブページコンテンツは、その最上部に、2つの幅の狭いテキストコラム21206、及び、そうした幅の狭いテキストコラムのそれぞれに関連した画像コラム21208を有する、メインテキストコラム21204を含む。図225に於ける擬似コードに図示されていないが、そうした幅制限なしで、それらの幅が最大の所望コラム幅に比して狭かったとしても、図215に図示されているように、コラム幅制限は、それらの2つの幅の狭いテキストコラムの幅を減少させる。ウェブページのメインコラム21204の幅を減少させるために、これが実行される。しかし、可読性及びウェブページの全体的な様相を維持するためには、テキストコラムや画像が一部となっている包括的なコラムの幅を減少させる為に、コラム幅制限プロセスが、そうしたテキストコラム及び画像を縮小する幅に関して下限を有していることが好ましい。
この下限のために、これら2つの小型テキストコラム、及び、それらに関連する画像を含むメインコラム21204は、最大の所望コラム幅よりも幅が広い状態にされる。
したがって、メインコラムに於けるテキストのメインボディは、図215に於ける双頭の矢印で示された、そのメインボディが一部となっているメインコラム21204のコラム幅に比して幅が狭い幅21504でレイアウトされている。
本発明の他の実施形態に於いては、コラムに於ける画像又は非テキスト要素の幅を縮小又は制限するために、労力が割かれることはなく、コラムに於けるテキストの幅だけが最大の所望コラム幅に制限される。これにより、テキストラインを所望のビューウインドウ内に適合するサイズまで短くするという価値のある結果を達成することになるが、それにより、多くのコラムの大部分は、テキストで満たされた幅の一部のみを有する傾向となり、図215に図示された空白21506に類似した空白を作り出す。
図217乃至225に於ける擬似コードは、低解像度表示上にウェブページを表示するように設計されており、これにより、所謂「拡大されたビューウインドウ」に於いてさえ、それはウェブページコンテンツを縮小する。この実施形態に於いて、ウェブページは、レイアウト倍率1(即ち、その要素が仮想レイアウトで縮小されていない)を有する仮想解像度で、プロキシサーバによってレイアウトされ、その後、仮想レイアウトのコンテンツは、クライアントによってダウンロードされ表示される表示リストに於いて、表示倍率2で縮小される。
他の低解像度に関する実施形態に於いて、ウェブページのコンテンツを縮小するレイアウト倍率で元のレイアウトを実行することによって、そうした縮小を実行することができ、その後、レイアウトが本来レイアウトされる縮小された縮尺で表示されるように、表示倍率1を使用する。
そうした低解像度表示に関する実施形態に於いて、レイアウト倍率及び/又は表示倍率によって、ウェブページのレイアウトの表示が、コラム幅制限とは独立して、画像及びテキスト文字を含むウェブページの要素の殆ど又は全てを縮小されたピクセル解像度で表示させる。そうした実施形態に於いて、コラム幅制限は、あまりにも広いので、ウェブページの表示に関する他の特徴のすべてを圧縮するために使用される縮小を用いても、所望のウインドウに適合することが出来ないコラムの幅を狭くする。
図191乃至228に関して議論された本発明の特徴に関する幾つかの実施形態に於いて、レイアウト及び倍率は、両方とも1とすることができ、また、組み合わされた場合、ウェブページのコンテンツが全く縮小されず、もしかしたら、拡大さえされる値を有することが出来る。
別の実施形態に於いては、コラム幅制限のプロセスを別の方法で実行することが出来る。例えば、幾つかの実施形態に於いて、幅制限なしに所定のコラムが有する幅と、最大の所望の幅とを比較することと、必要に応じて、コラム幅が過剰な長さになることを防ぐ為に、所定のコラムの幅を狭くすることによって、コラム幅制限のプロセスを達成することが出来る。恐らく多くのウェブページの魅力を低減させてしまうだろうが、幾つかの実施形態に於いて、コラム幅制限のプロセスは、コラムの指定された幅とは関係なく、同一幅を有するように全てのコラム幅を狭くすることを含めることが出来る。したがって、幅制限がない場合には、最大の所望の幅に比して幅の狭いコラムを、そうしたより狭い幅で表示することが望ましい。
そうした実施形態に於いて、コラム幅が低減されないという規則の例外は、図215に関して図示されたような状況に於いて、コラム幅が別の方法で最大の所望コラム幅より狭い幅となる場合である。即ち、発生した多数のコラムが全面的なコラム内の行に水平方向に配列される場合、それ自体がテキストを直接含むという例外、及び、コラム幅制限がない場合に最大の所望コラム幅を越える幅を有するという例外が発生する可能性がある。このような場合、全面的なコラムの幅を減少することが出来るように、図215に図示されているように、水平方向の行にあるコラムが、最大の所望コラム幅に比して実質的に短い長さまで減少された幅を有しても良い。
図229は、図191乃至228に関して上述された本発明の特徴もまた、携帯電話に加えて、他の種類のコンピュータデバイスに適用することが出来ることを図示するために提示されている。図229は、携帯情報端末(PDA)上の分割スクリーンビューのシミュレーションを図示している。この例に於いては、図示されたウェブページの指定されたレイアウトとPDAのより大きなピクセル幅の組み合わせによって、最も幅の広いテキストコラムが幅制限を必要とすることなく表示可能であるので、コラム幅制限を必要としないが、分割ビューが表示され、コラム幅制限が実施されている。分割ビューは、オーバービューウインドウ19200C、拡大されたビューウインドウ19400C、オーバービューウインドウに於ける拡大されたビューインジケータ19504C、及び、オーバービュー及び拡大されたビューの両方に表示されたカーソル19116を含む。
当然のことながら、他の実施形態に於いて、図191乃至228に図示された本発明の幾つかの特徴は、他の種類のコンピュータデバイス、又は、デスクトップコンピュータ、ラップトップコンピュータ、手首装着型コンピュータ、頭部装着型ディスプレイ、さらに大きな表示スクリーンのサブポーション上に形成されたウインドウに於ける表示を含む、他の種類の表示に於いて動作可能である。
また、他の実施形態に於いて、他の解像度を表示スクリーンに対して使用可能であり、様々なウインドウのサイズに対して使用可能である。
当然のことながら、前述の記載及び図面は、説明及び図解を行うためだけに使用されるものであり、本発明は添付の特許請求の解釈がそのように限定されている場合を除いて、それに限定されるものではない。情報開示を有する当業者は、本発明の範囲を逸脱することなく、そこに修正及び変形を加えることが出来る。
広く特許請求されているように、本出願の発明に関する多くの特徴は、任意の1種類のオペレーティングシステム、コンピュータハードウェア、又は、コンピュータネットワークでの使用に限定されず、それ故、本発明の他の実施形態は、異なるソフトウェア及びハードウェアシステムを使用することが出来る。
さらに、当然のことながら、実質的に異なる構成又は手順を用いて、多くの異なるプログラム及びデータ構造によって、以下の特許請求の範囲に記載された関数を実行することが出来る。これは、プログラムというものが、どんな複雑な所定の発想も当業者に理解された時点で、実質的に無制限の方法で表現することが出来る極端に柔軟な技術だからである。このように、特許請求の範囲は図面に記載された正確なステップ、及び/又は、ステップの順番に限定されることを意味していない。このことが特に当てはまるのは、不必要に詳細を提示することでユーザに負担をかけることなく、本発明を実施するために、当業者が知る必要のある事項をより効果的に伝達させるために、上記のテキストに記載された擬似コードが高度に簡略化されたからである。そうした簡略化のために、上述した擬似コードの構造は、多くの場合、本発明を実施する際に当業者のプログラマーが使用する実際のコードの構造とは相当異なる。さらに、明細書中のソフトウェアで実行されることが示されたプログラム化した動作の多くを、他の実施形態に於けるハードウェアで実行することが出来る。
上記で議論した本発明の特徴に関する多くの実施形態に於いて、本発明のそうした特徴に関する他の実施形態に於いて別々に生じる可能性のある本発明の様々な特徴は、同時に発生することが示されている。
本明細書の様々な部分に於いて記載されたサブピクセル最適化及び非線形カラーバランスに関する様々な図面の殆どは、垂直方向のサブピクセルストライピングを有するRGBサブピクセルアドレス可能表示に関する。当然のことながら、非線形カラーバランス及びサブピクセル最適化に関連する本発明の多くの特徴を、水平方向のサブピクセルストライピングを有するサブピクセル表示と同様に、BGR又は他の種類のサブピクセルアドレス可能性を有するサブピクセル表示を用いて使用することが出来る。
上記で示した非線形カラーバランス法に於いて、カラーバランスによって分配されたサブピクセルの輝度の部分のみが、ピクセル内の最小サブピクセル輝度値よりも高い部分である。しかし、他の実施形態に於いては、例えば、ピクセルの平均サブピクセル輝度、又は、最大サブピクセル輝度とは異なる部分など、ピクセル内でカラーアンバランスを引き起こすサブピクセルの輝度の他の部分を分配することが出来る。そうした実施形態に於いて、実際に、平均値又は最大値よりも低いサブピクセル輝度は、そうしたサブピクセルの近傍に於いてサブピクセル輝度の重み付けられた減少で分配可能な負の輝度値となる。
上記に図示した全ての非線形カラーバランス法は、ピクセルに対応するサブピクセル内でカラーアンバランスを引き起こすサブピクセルの輝度の部分を分配するだけである。これが実行されるのは、全ピクセル内で一般的に発見される3つの連続するRGB又はBGRサブピクセルの配列が、知覚的に良好にカラーバランスされているからである。そうした全ピクセルのサブピクセルが等しい輝度である場合、緑色が中央の色ではない順番で、同一強度で表示された同一の3色のサブピクセルの分離したセットに比して、表面上、より色のバランスが取れているように見える傾向がある。これが、全ピクセル境界以外で現れるフォントの端部がカラーアンバランスしているように見える理由の1つなのである。
しかし、他の非線形カラーバランスに関する実施形態を、個々の全ピクセル内でカラーアンバランスを引き起こすサブピクセル輝度を分配することだけに制限する必要はない。他の非線形カラーバランスに関する実施形態は、全ピクセル以外の領域内でのサブピクセルカラーアンバランスの割合を決定し、全体的又は部分的にアンバランスに基づいたサブピクセル輝度値をそうした領域に分配することが出来る。例えば、一般的に生じる複数のアンバランスパターンのそれぞれに対して、カラーバランスの知覚を維持しながら、アンバランスカバレッジ値のどの分配が最小の空間拡散を生成したかを発見するための研究を行うことができ、全ピクセル領域以外の空間領域で発生するカラーアンバランスを分配するために、そうした知覚的に選択された分配を使用することが出来る。
本発明のある特徴は、ラインカバレッジ技術によって、個々のピクセルに対して輝度値を計算するサブピクセル最適化画像の生成及び使用に関する。当然のことながら、下記に特許請求された本発明に関する他の特徴は、そうしたラインカバレッジ関数、又は、エリアカバレッジ関数に関する特定の詳述なしに、サブピクセル輝度を決定するそうした方法に限定されるものではなく、例えば、領域サンプリング技術を含むがこれに限定されないカラービットマップ、グレースケールビットマップ、フォント、及び、他の形状で構成されるソース画像を用いてカバレッジ値を決定するための他の周知の方法を使用することが出来る。
上記議論では、サブピクセル最適化ビットマップに於ける輝度値又はカバレッジ値を割り当てるために使用されるソース画像ウインドウは矩形であり、多色サブピクセル最適化画像に於ける全ピクセルに一致するサイズ、及び、2色サブピクセル最適化画像に於いてサブピクセルに一致するサイズを有する。他の実施形態に於いては、異なる形状及びサイズのウインドウを使用することが出来る。例えば、多色サブピクセル最適化画像に於いて、ソース画像ウインドウは、全出力画像ピクセルに一致するサイズに比して幾分小さなサイズを有しても良い。幾つかの実施形態に於いて、ソース画像ウインドウに於けるカバレッジ値又は輝度値を出力画像に於けるカバレッジ値又は輝度値に変換するために、不規則な重み付け関数を使用することが出来る。例えば、多色サブピクセル最適化画像に於いて、サイズ及び位置が、輝度を決定しているサブピクセルに一致するソース画像ウインドウの部分に於ける輝度に対して、より重み付けをすることが好ましい。事実、図17乃至19に関して議論されたラインカバレッジ配置は、そうした中央重み付けを提供しているが、これは、ラインカバレッジ値を決定しようとしているサブピクセルの位置に一致するソース画像ウインドウの部分を通じてのみ、垂直線が延びているからである。
本発明の幾つかの特徴は、サブピクセル最適化の使用に明確に関連しているが、多くの他の特徴は、サブピクセル最適化に依存していない。本発明の幾つかのそうした特徴に於いては、サブピクセル最適化を含まないアンチエイリアスの形式を使用することが出来る。サブピクセル最適化を含まないアンチエイリアスの形式によって、そうしたアンチエイリアスを使用せずに提供可能な解像度に比して、画像がより高度な解像度を有しているように見せることが出来る。これは、特にフォント画像の場合に当てはまる。例えば、適切なサブピクセル最適化によって、小型フォントはより読み易くなるが、フォントが適切な形状を有し、適切にヒンティングされ、サブピクセル最適化と共に、又は、サブピクセル最適化を用いずにアンチエイリアスを使用した場合、7ピクセル/emと同程度に小さなフォントを比較的容易に読み取ることが可能である。
本明細書、及び、付随する特許請求の範囲に於いて、「スクリーン」、特に、縮小された画像、テキスト、又は、ウェブページレイアウトが表示されるスクリーンについて言及することによって、一般には、例えばスクリーン上のグラフィックウインドウなど、スクリーン全体又はスクリーンの一部の何れかを含むことが出来る。例えば、参照される縮小スクリーン画像を、かなり大きなスクリーン上のウインドウに於いて表示しても良いし、例えば図114に図示されたツールバーのように、特定のグラフィカルユーザインターフェース(GUI)要素にスペースが設けられた後に残される小型スクリーンの一部に表示しても良い。また、当然のことながら、例えば大型スクリーンによって、非サブピクセル最適化技術を用いて可能となる、より高度な空間解像度でコンテンツを見ることが出来るように、大型スクリーンの全て又はかなりの部分を越えて、画像及び/又はテキストを表示するために、本発明の特定のサブピクセル最適化の特徴を使用することが出来る。