(57)【要約】必要以上の複雑な処理を使用せずに、多数の文字を文字コードによって表現できる。例えば、すでにユニコードによって表された文字は、１つの１６ビットのコードの中でユニコードシステムに従って処理することができる。ユニコードにより表現されない文字は、第２の方法で処理される。ユニコードによって表現されない文字は、２つの１６ビットのコードにより表現される。
2005501303.tif 000002
【特許請求の範囲】
【請求項１】
文字を含むファイルを受信するステップと、
該文字が第１のタイプである場合には、前記ファイルを第１のコード形式に変換するステップと、
該文字が第２のタイプである場合には、前記ファイルを第２のコード形式に変換するステップと、
を含んでなる方法。
【請求項２】
プレーンと行と列との形式のウェブページを受信するステップを含む請求項１に記載の方法。
【請求項３】
文字セットのプレーンが変更されたかどうかを決定するためにチェックするステップを含む請求項１に記載の方法。
【請求項４】
前記文字セットのプレーンが変更される場合には、新しい文字セットの指定子が挿入される請求項３に記載の方法。
【請求項５】
前記ファイル内の文字が前記第１のコード形式に基づいて形成されるかどうかを決定するステップを含む請求項３に記載の方法。
【請求項６】
前記文字が前記第１のコード形式に基づいてコード化される場合には、テーブルが前記第１のコード形式にユニコード値をマップする請求項５に記載の方法。
【請求項７】
前記第１のコード形式が使用されない場合には、ユニコードの代理領域を使用する請求項５に記載の方法。
【請求項８】
フォントファイルの位置及びオフセットを見つけるために代理値を使用するステップを含む請求項７に記載の方法。
【請求項９】
フォントファイルをプレーンに分割するステップを含む請求項７に記載の方法。
【請求項１０】
プレーンと行と列との情報から又は代理のユニコード情報から特定の文字に対するフォントを選択的に決定するステップを含む請求項９に記載の方法。
【請求項１１】
文字を含むファイルを受信することと、
前記文字が第１のタイプである場合には、前記ファイルを第１のコード形式に変換することと、
前記文字が第２のタイプである場合には、前記ファイルを第２のコード形式に変換することと
をプロセッサベースのシステムに対して可能にさせる命令を含むプログラム。
【請求項１２】
前記プロセッサベースのシステムに対して、プレーンと行と列との形式のウェブページを受信することを可能にさせる命令をさらに含む請求項１１に記載のプログラム。
【請求項１３】
前記プロセッサベースのシステムに対して、文字セットのプレーンがいつ変更されたかを決定するためにチェックすることを可能にさせる命令をさらに含む請求項１１に記載のプログラム。
【請求項１４】
前記プロセッサベースのシステムに対して、前記文字セットのプレーンが変更される場合には、新しい文字セットの指定子を挿入することを可能にさせる命令をさらに含む請求項１３に記載のプログラム。
【請求項１５】
前記プロセッサベースのシステムに対して、前記ファイル内の文字が前記第１のコード形式に基づいて形成されるかどうかを決定することを可能にさせる命令をさらに含む請求項１３に記載のプログラム。
【請求項１６】
前記プロセッサベースのシステムに対して、前記文字が前記第１のコード形式に基づいてコード化される場合には、ユニコード値を前記第１のコード形式にマップすることを可能にさせる命令をさらに含む請求項１３に記載のプログラム。
【請求項１７】
前記プロセッサベースのシステムに対して、前記第１のコード形式が使用されない場合には、ユニコードの代理領域を使用することを可能にさせる命令をさらに含む請求項１５に記載のプログラム。
【請求項１８】
前記プロセッサベースのシステムに対して、フォントファイルの位置及びオフセットを見つけるために代理値を使用することを可能にさせる命令をさらに含む請求項１７に記載のプログラム。
【請求項１９】
前記プロセッサベースのシステムに対して、フォントファイルをプレーンに分割することを可能にさせる命令をさらに含む請求項１７に記載のプログラム。
【請求項２０】
前記プロセッサベースのシステムに対して、プレーンと行と列との情報から又は代理のユニコード情報から特定の文字に対するフォントを選択的に決定することを可能にさせる命令をさらに含む請求項１７に記載のプログラム。
【請求項２１】
プロセッサと、
文字を含むファイルを受信する手段と、
該文字が第１のタイプである場合には前記ファイルを第１のコード形式に変換し、該文字が第２のタイプである場合には前記ファイルを第２のコード形式に変換することができるブラウザを記憶している、前記プロセッサに接続された記憶装置と
を含んでなるシステム。
【請求項２２】
前記記憶装置が、プレーンと行と列との形式のウェブページを受信することを前記プロセッサに対して可能にさせる命令を記憶している請求項２１に記載のシステム。
【請求項２３】
前記文字が第１のコード形式に基づいてコード化される場合には、前記記憶装置が、前記第１のコード形式にユニコード値をマップすることを前記プロセッサに対して可能にさせる命令を記憶している請求項２１に記載のシステム。
【請求項２４】
前記第１のコード形式が使用されない場合には、前記記憶装置が、ユニコードの代理領域を使用することを前記プロセッサに対して可能にさせる命令を記憶している請求項２３に記載のシステム。
【請求項２５】
前記記憶装置が前記プロセッサに対して、プレーンと行と列との情報から又は代理のユニコード情報から特定の文字に対するフォントを選択的に決定することを可能にさせる命令を記憶している請求項２１に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、インターネットのブラウザに関し、特に、多数の文字に対応するブラウザに関する。
【背景技術】
【０００２】
プリントされる資料として表示されたり、コンピュータのモニタ上に表示されるテキストデータは、２進の数値コードの形式でコード化される。キーボード上の所定のキーをたたくと、そのキーの文字コードが発生する。このとき、コンピュータは、この文字コードを用いて、同じ文字コードがある記憶されたフォントファイルのリストから適当な文字の形状を選択する。
【０００３】
英語のパーソナルコンピュータシステムは、一般に、７ビットの文字コードを使用する。このコードは、約１２８項目の大文字及び小文字のラテン文字と、アラビア数字と、記号及び制御文字の文字セットとを可能にするAmerican Standard Code for Information Interchange (ASCII) (ANSIx3.4-1996)に従って分類される。
【０００４】
中国語と日本語と韓国語（以下、「ＣＪＫ」とよぶ）の文字数は、およそ数十万語のオーダーと比較的に多い。これらの文字は、７ビットのＡＳＣＩＩ文字コード自体の能力をはるかに超えている。
【０００５】
例えば、日本のパーソナルコンピュータは、６，８７９文字のみに適合する日本工業規格（ＪＩＳ）Ｘ０２０８−１９９０を現在では使用している。この規格は多くの基本的な機能に対しては十分であるが、それは、人名と住所名と歴史的なデータ及びその他の情報に対しては十分ではない。
【０００６】
現在のＣＪＫの文字セットは、利用可能な文字セットを考えると各種の重要な情報を提供するには十分でない。例えば、Netscape Communicatorのウェブブラウザが使用するＧＢ−２３１２及びＢｉｇ−５文字セットについては、約１６，０００文字しか利用できない。
【０００７】
その結果、国際標準化機構は、７ビット及び８ビットの文字コードを構造化する方法の概要を説明するＩＳＯ−２０２２と呼ばれる規格を作成している。中国語バージョンは、Request for Comments (RFC) 1922 (Network Working Group, 1996)に記載されているＩＳＯ−２０２２−ＣＮである。
【０００８】
いわゆる統一コード（Unification Code）すなわちユニコードが、全ての世界の文字セットを１つの大きな文字セットの中に統一するために、いくつかの米国のソフトウェア会社によって開発された。国際標準化機構ISO/IEC 10646-1 (1993) Geneva, Switzerlandを参照されたい。ユニコードは、１６ビットすなわち６５，５３６文字に文字セットの空間を限定するよう求めている。この文字空間は、１６ビットすなわち２バイトの固定長コードによって各文字を表す必要があることを意味する。しかしながら、ユニコードでさえも、数十万のＣＪＫ文字を含む全ての世界の文字を、全文字が６５，５３６しか可能でない文字セットを用いて表すことはできない。
【０００９】
例えば、ユニコードでは、ＣＪＫ言語を使用するオンラインのデジタル図書館を作ることができない。そのような図書館は、これまで使用されてきた全ての文字を含む完全な文字セットを必要とする。さらに、ＣＪＫ国内の多くの人や場所の人名及び地名を記載する能力が重要である。その結果、ユニコードは、ＣＪＫの文字セットを文化的に完全なように取り扱うには不十分である。ＣＪＫ言語のユーザがより小さな文字セットで間に合わせることができても、ＣＪＫ言語の表現力及び汎用性は利用可能な文字コードによって大幅に制限される。
【００１０】
このため、特に、ＣＪＫ言語に関連して使用するために多数の文字コードを使用できるようにする文字セットを取り扱う一層優れた方法に対する要求がある。
【発明の開示】
【００１１】
本発明は、文字を含むファイルを受信するステップと、該文字が第１のタイプである場合には、前記ファイルを第１のコード形式に変換するステップと、該文字が第２のタイプである場合には、前記ファイルを第２のコード形式に変換するステップとを含んでなる方法と、それを実行するためのコンピュータプログラムとを提供する。ここで、プレーンと行と列との形式のウェブページを受信するステップを含む態様や、文字セットのプレーンが変更されたかどうかを決定するためにチェックするステップを含む態様であることが好ましい。
また、前記文字セットのプレーンが変更される場合には、新しい文字セットの指定子が挿入される態様や、前記ファイル内の文字が前記第１のコード形式に基づいて形成されるかどうかを決定するステップを含む態様がより好ましい。
さらに、前記文字が前記第１のコード形式に基づいてコード化される場合には、テーブルが前記第１のコード形式にユニコード値をマップする態様や、前記第１のコード形式が使用されない場合には、ユニコードの代理領域を使用する態様であることが好ましい。
加えて、フォントファイルの位置及びオフセットを見つけるために代理値を使用する態様や、フォントファイルをプレーンに分割するステップを含む態様であることが好ましい。ここで、プレーンと行と列との情報から又は代理のユニコード情報から特定の文字に対するフォントを選択的に決定するステップを含むことがより好ましい。
【００１２】
また、本発明は、プロセッサと、文字を含むファイルを受信する手段と、該文字が第１のタイプである場合には前記ファイルを第１のコード形式に変換し、該文字が第２のタイプである場合には前記ファイルを第２のコード形式に変換することができるブラウザを記憶している、前記プロセッサに接続された記憶装置とを含んでなるシステムを提供する。ここで、前記記憶装置が、プレーンと行と列との形式のウェブページを受信することを前記プロセッサに対して可能にさせる命令を記憶している態様や、前記文字が第１のコード形式に基づいてコード化される場合には、前記記憶装置が、前記第１のコード形式にユニコード値をマップすることを前記プロセッサに対して可能にさせる命令を記憶している態様であることが好ましい。
また、前記第１のコード形式が使用されない場合には、前記記憶装置が、ユニコードの代理領域を使用することを前記プロセッサに対して可能にさせる命令を記憶している態様や、前記記憶装置が前記プロセッサに対して、プレーンと行と列との情報から又は代理のユニコード情報から特定の文字に対するフォントを選択的に決定することを可能にさせる命令を記憶している態様であることがより好ましい。
【００１３】
［詳細な説明］
図１に示したウェブブラウザ１２は、より大きな文字セットの必要性に対するプラットフォームレベルの解決策を提供する。このウェブブラウザ１２は、任意のウェブベースの用途に対する汎用のクロスプラットフォームのユーザーインターフェースとして機能する。ブラウザ１２は、全てのウェブベースの用途に対応するために、大きな文字セットを効果的に可能にする。
【００１４】
ハイパーテキストマーク付け言語（hypertext markup language）（ＨＴＭＬ）のソースファイルは、ブロック１０に示すように、ＩＳＯ−２０２２−ＣＮ及びＩＳＯ−２０２２ＣＮ拡張形式に基づいてコード化される。ブラウザ１２では、そのファイルは、ユニコード２．０ （ＩＳＯ／ＩＥＣ１０６４６及びＲＦＣ２１５２（１９９６））の代理機構（surrogate mechanism）のサポートを含むように、拡張されたユニコード形式に変換される。ユニコードの代理機構を使用することにより、百万の固有の文字の文字セットを認識するために十分な能力にまでユニコードは拡張される。現在のユニコード規格は１６ビットの文字長を使用するため、この１６ビット値は６５，５３６文字しか提供できない。
【００１５】
このため、ＩＳＯ−２０２２−ＣＮ及びＣＮ拡張形式は、ブロック１４に示すように、代理サポートを用いてユニコードに変換される。すでにユニコード規格の中で定義されたＣＪＫ文字は、それらの１６ビットのユニコード値に変換される。ユニコード規格によって定義されない残りの文字は、２つの１６ビット値に変換される。本発明の１つの実施形態では、２つの１６ビット値の各々は、0xD800から0xDB00までの範囲と、0xDC00から0xDFFFまでの範囲とにそれぞれある。このことは、代理機構のユニコードの定義に不明確さなしに適合する。
【００１６】
ブラウザ１２は、ブロック１６に示すように、ＨＴＭＬ構文解析などのウェブコンテンツの構文解析を行う。そして、ブロック１８に示すように、残りのレンダリングステップ（rendering step）が完了する。
【００１７】
ブラウザ１２が特定のテキスト文字列を表現する状態にある場合、ブラウザ１２は文字列内の各文字をループする。ＣＪＫ文字に関しては、ブロック２０に示すように、第１の検索により周知のＣＪＫフォントライブラリ内のフォントが捜し出される。このよく知られたＣＪＫフォントライブラリには、Guo-jiu Biao-zhun （「Coding of Chinese Ideogram Set for Information Interchange Basic Set」、GB-2312-80）、Big-5 （Institute for Information Industry、「Chinese Coded Character Set in Computer」、１９８４年３月 ）、GBK （「Information Technology」Universal Multiple-Octet Coded Character Sets, GB 13000）及びGB18030ライブラリが含まれる。よく知られたＣＪＫフォントライブラリの中には含まれないこれらのまれにしか使われない文字については、レンダリングエンジン（rendering engine）は、より大きな文字セットをカバーするフォントライブラリを検索する。ブロック２２及びブロック２４に示すように、適当なフォント表示ドライバが使用される。
【００１８】
ＨＴＭＬのコンテンツをコード化するためにＩＳＯ−２０２２変換器を使用することによって、ユニコードに直接コード化するのではなく、７ビットのコード化機構を使用する。この７ビットの機構を使用することによって、ＣＪＫ文字がインターネットのような現在の又は未来の通信インフラネットワーク（communication infrastructure network）により切り捨てられる可能性が低くされる。端末表示用の文字として、ファイルのコンテンツとして、電子メールのコンテンツとして又はウェブのコンテンツとして、この７ビットの情報がどのように送信されようともそれは保持される。次にブロック３０に示すように、テキストのコンテンツはディスプレイ画面上に表示される。
【００１９】
ＣＪＫ文字を使用しない場合には、ブロック２６に示すように、通常のＡＳＣＩＩ文字の文字列を使用する。そして、ブロック２８に示すように、ＡＳＣＩＩ文字セット用フォント表示ドライバを使用する。
【００２０】
次に、図２を参照する。プロセッサベースのシステム３２は、デスクトップコンピュータやラップトップコンピュータやハンドヘルドコンピュータや携帯電話又はセットトップボックス等の電気機器の形態でありうる。プロセッサ３４は、ブリッジ３６に接続される。このブリッジ３６は、システムメモリ３８とディスプレイ４０との間に接続される。ディスプレイ４０は、コンピュータのモニタ、液晶ディスプレイ、又はテレビ受信機でありうる。
【００２１】
ブリッジ３６は、別のブリッジ４４に接続するバス４２にも接続される。ブリッジ４４は、ハードディスクドライブ４６又は別の記憶装置に接続される。別の可能な記憶装置は、フラッシュメモリ及びデジタルの多用途の書換可能なディスクドライブを含む。記憶装置４６は、実行する前にブラウザ１２を記憶する。ブラウザ１２は、実行時には、システムメモリ３８に転送される。
【００２２】
ブリッジ４４は、別のバス４８にも接続される。このバス４８は、シリアル入出力（以下、「ＳＩＯ」とよぶ）装置５０に接続する。ＳＩＯ装置５０はモデム５２に接続する。このモデム５２は、プロセッサベースのシステム３２をインターネットにアクセスさせる。
【００２３】
中国語のウェブページのコンテンツは、英語のＨＴＭＬタグ及び周知の中国語文字セット規格に基づいてコード化された中国語のテキスト文字列から構成する。ウェブページがブラウザに読み込まれると、英語のタグ及びコード化された中国語のテキスト文字列を含むその全てのコンテンツが、ユニコードのテキスト文字列に最初に変換される。そして、このユニコードのテキスト文字列がＨＴＭＬパーサ（parser）によって構文解析され、文書オブジェクトモデル（Document Object Model）がウェブページの抽象データ構造を表すために構築される。そして、レンダリングエンジンを適用してこの文書オブジェクトモデルを検索し、ＨＴＭＬタグに関連した形式及びフォントを用いてページの各要素を見つけて表現する。
【００２４】
レンダリング処理の間に、レンダリングエンジンは一度に１つのユニコード文字を表現する。それぞれの特定のユニコード文字については、所定のユニコード文字用のフォントが所定のフォントファイルの中で利用可能かどうかを調べるために、レンダリングエンジンはそのフォントファイルの利用可能なインデックスのマトリックスを素早くチェックする。文字がフォントファイルの中に存在しない場合には、レンダリングエンジンは、次のフォントファイルを捜して、できるだけ文体に近いフォントを検索する。
【００２５】
文字に対応するフォントを見つけた場合には、その文字のユニコードがもとの国語の文字セットのコードに変換され、このコードの値を使用して所定のフォントファイル内のこの文字のフォントバイト（font byte）のオフセットに索引を付ける。そして、レンダリングエンジンは、これらのフォントバイトを取り出して、レイアウトエンジンが計算した所定の位置にその文字用のグリフ像（glyph image）を発生する。
【００２６】
この処理の間に、文字セットの変換を行う２つのステップがある。１つのステップは、ウェブページのソースを構文解析する前にユニコードに変換するステップである。別のステップは、テキスト文字列内の各ユニコード文字の値をフォントファイルの中のフォント情報を取り出すためのインデックスとして使用できるように、その文字セットのコード化規格に各ユニコード文字を変換するステップである。
【００２７】
例えば、ソースのウェブページが、中国語のコンテンツがＧＢＫコードにコード化されるＨＴＭＬのページであり、このウェブページがブラウザの中に読み込まれる場合には、英語のＨＴＭＬタグ及びＧＢＫコードの中国語のテキスト文字列はユニコード変換器を通過する。ここで各中国文字（１６ビットのＧＢＫコード）は、直接的な１対１のマッピングテーブルによってユニコードに変換される。ＧＢＫコード自体は、隣のブロックにある。このため、マッピングテーブルは大きさが約２１，０００エントリー（entry）の一次元のアレイであり、ＧＢＫコードは簡単な計算の後にこのアレイへのインデックスとして使用できる。この処理は、効率的であり、２×２１，０００バイトのアレイを記憶するステップを含む。複雑な検索は含まれていない。
【００２８】
ここで、ユニコードとしてコード化された文字を表現するために、フォントファイルがユニコードを用いて直接にインデックスを付けられるか、又はユニコードがそれに関連したフォントファイルを有する別のコードに再度変換される。中国文字の場合には、ユニコードが１つの隣接するブロックの中で中国文字を表さないため、フォントは特定の規格のレイアウト順序に従って隣接ブロックの中に配置される。この場合には、ブラウザは、ユニコード文字を規格の１つに再度変換する必要がある。
【００２９】
しかしながら、このようにＧＢ２３１２若しくはＢＩＧ５、又はＧＢＫ等の規格にユニコードを変換することは、ＧＢＫをユニコードに変換する場合に含まれるアレイのインデックスを用いて直接に行うことはできない。大きさがユニコード規格全体の別のマッピングテーブルが作られるか、又はＧＢＫからユニコードのマッピングテーブルへの検索による逆変換が行われる。
【００３０】
約２１，０００の中国文字に対応し、ＧＢＫを用いて中国語をコード化するブラウザについては、ＧＢＫからユニコードへのマッピングテーブルは約２×２１，０００バイトであり、ユニコードからＧＢＫへのマッピングテーブルの大きさは約２×６５，０００バイトである。
【００３１】
ＩＳＯ−２０２２−ＣＮ拡張版又はＧＢ１８０３０のいずれかでコード化された１００，０００の中国文字に対応するブラウザは、大きさが約４×１００，０００バイトの（代理領域を使用する）ユニコードへのマッピングテーブルを必要とする。逆マッピングテーブルの大きさは、ユニコードの代理領域が約１，０００，０００バイトの範囲を有するため、約４×１，０００，０００バイトである。ここで、ユニコードの代理領域が表示する各文字用に４バイトを有するため、２ｘではなく４ｘが使用される。
【００３２】
ユニコードをもとのＩＳＯ−２０２２−ＣＮ拡張版又はＧＢ１８０３０にマップする巨大な逆マッピングテーブルを避けるために、ユニコードのマッピングテーブルに対する本来のＩＳＯ−２０２２−ＣＮ拡張版（又は、ユニコードのマッピングテーブルに対するＧＢ１８０３０）が、逆マッピングを行うために検索される。このことは、まさにメモリのためにプロセッサの速度を犠牲にすることである。
【００３３】
ユニコードによりもたらされた変換上の問題は、漢字が国語の文字セットと同じ順序でユニコード上に連続して割り当てられないことである。ユニコードの代理領域は、１００，０００個の漢字の大部分がユニコードの代理領域内で連続したレイアウトを有するような方法で使用される。逆変換するための巨大なマッピングテーブル又はプロセッサの集中検索は、いくつかの実施形態では必要とされない。同時に、ユニコード値がまだ通常の１６ビットのユニコード範囲内にある漢字（これらは代理領域にはない）に対する下位互換性が保持される。
【００３４】
漢字がＩＳＯ−２０２２−ＣＮ拡張版に基づいてコード化され、漢字がいくつかの９５×９５プレーン内に配置されるウェブページについては、これらの１００，０００個の漢字は、各プレーンが９５の行（0x20, 0x21, ..., 0x7f）と９５の列（0x20, 0x21, ..., 0x7f）とを有する１２のプレーンの中に配置される。
【００３５】
これらのプレーンは、ＩＳＯ−２０２２のプレーンと同様である。各プレーンは、９０２５（(0x7f-0x20)x(0x7f-0x20)=95x95）の文字を有する。１２のプレーンは、全ての漢字を保持する。１６のプレーンは約１５０，０００文字を保持しており、これは全ての可能なＣＪＫ文字とベトナム文字とを合計した文字よりも多い。
【００３６】
ユニコードの代理領域では、９５×９５文字のプレーンとユニコードとの間のマッピングが、巨大なマッピングテーブル又は複雑な検索アルゴリズムを必要とせずに、簡単で直接的であるように、プレーンがレイアウトされる。このため、プレーンは、ユニコードの代理領域の連続する領域内に連続的にマップされる。例えば、９５×９５文字の第１のプレーンは、各プレーンと代理領域との間を同じ（行、列）関係にして、代理領域の第１の９５個の行にマップされる。プレーン内の列は、代理領域の第１の９５個の列にマップされる。９５×９５文字の第２のプレーンは、プレーンと代理領域との間を同じ（行、列）関係にして、代理領域の第２の９５個の行にマップされる。プレーン内の列は、代理領域の第１の９５個の列にマップされる。
【００３７】
代理領域は、0xD800 から 0xDBffまでの合計で１０２４個の行を有する。このため、９５個の列は、合計で９７２８０（１０２４×９５）文字を保持することができる。このことは、各プレーンが９０２５文字を有する１０個のプレーンとほとんど同じである。換言すると、１０個のプレーンの漢字を実現するには、９０，２５０文字に対応するために、代理領域の１０×９５×９５０の行にそれらをマップする必要がある。通常のＧＢＫ領域内の現在の漢字（それらは１６ビットのユニコード領域にマップされる）を用いて、１００，０００以上の文字がサポートされる。
【００３８】
１つの実施形態では、プレーン番号と行番号と列番号（以下、「ＰＲＣ」とよぶ）が、極めて簡単な方法で代理領域にマップされる。ユニコードの用語では、代理領域の行及び列は、ハイサロゲイト（High Surrogate）及びローサロゲイト（Low Surrogate）とそれぞれ呼ばれる。プレーンと行と列とにおける文字から、その代理領域の割り当ては次のようになる。
ハイサロゲイト＝プレーン×９５＋行番号
ローサロゲイト＝列番号
【００３９】
逆変換のアルゴリズムも同様に簡単である。代理領域内の周知のユニコード文字については、そのプレーン番号、行番号及び列番号は次のようになる。
プレーン＝（ハイサロゲイト−0xD800）％９５
行＝（ローサロゲイト−0xD800）mod９５＋0x20
列＝（ローサロゲイト−0xDC00）＋0x20
【００４０】
このレイアウトの配列は、ユニコードに対応しており下位互換性がある。その配列は、１６ビット領域における現在のユニコードの割当てに重なり合わない。新たに導入された文字はマッピングテーブルを備えておらず、また複雑な変換アルゴリズムを必要としない。アドレス指定モード（プレーンと行と列）又は（ハイサロゲイトとローサロゲイト）のいずれかを用いて、画面の表示又はプリントを行う間に、フォントファイル内のこの文字用のフォントを直接にインデックス指定することができる。徐々に増加するようにシステムを実現することができる。他の文字の変換、表示、又は他の処理を妨害せずに、どのベンダーも対応するプレーンの数を減少又は増加することができる。例えば、あるベンダーは、１６ビットのＧＢＫ及び１６ビットのユニコードを実現することに加えて、９５×９５文字の１つ以上のプレーンを実現することしか望まない場合がある。この場合には、そのベンダーは約２９，０００文字に対応することができ、このことは、ＧＢ１８０３０規格の中で定義されている２７，０００文字の全てに対応するに十分である。
【００４１】
マッピングテーブルについては、容易に使用できるレイアウトでフォントファイルを配列することもできる。言い換えると、文字自体及びユニコードの代理領域内のそれらの表示は両方とも９５×９５文字の各プレーンの内部の隣接するブロック内にあるため、文字の画面表示及びプリンタ出力はソースのＨＴＭＬページがユニコード文字の文字列に構文解析たれたときに行われるように、フォント検索機構を設計することができる。１６ビット範囲内のユニコード文字に関しては、ハッシュ関数を使用して、特定の文字が特定の国語の文字セットとその関連するフォントファイルとの中で利用できるかどうかを確認するために、６４Ｋのマトリックスをチェックする。利用可能な場合には、そのフォントを使用する。そうでない場合には、次の国語の文字セットに対して文字を検索する。ユーザに好みがある場合には、デフォルトのフォント検索機構を書き換えることができる。
【００４２】
代理領域内のユニコード文字については、ブラウザは新しいフォントファイルのセットを捜す。このフォントファイルのセットの中では、各フォントファイルは（９５×９５文字の）所定のプレーン内にこれらの文字に対するフォントを有している。代理領域内の各ユニコード文字は、その元のプレーン番号と行番号と列番号との位置を知っているため、ブラウザはフォントを検索するためのフォントファイルを知っている。所定の文字のプレーンの中では、各文字に対するフォントは、このユニコード文字の（行、列の）値と同じ順序で配列される。行及び列への変換が極めて簡単なユニコードが代理領域内のこれらの文字に使用されるため、各文字に対するフォントもユニコード文字の代理値の対と同じ順序で配列される。
【００４３】
要約すると、１つの実施形態では、フォントファイルはプレーンに分割され、各プレーンは９５×９５文字のフォントを有する。特定の文字に対するフォントは、簡単な計算により、その（プレーン、行、列の）値から又はその代理のユニコード値から直接に配置することができる。
【００４４】
例えば、プレーンＸと行Ｙと列Ｚとの文字に対して２８バイトを要するビットマップされた１４×１６のフォントについては、フォントプレーンＸ（FontPlaneX）等のフォントファイル名を付ける。このフォントファイルの中で、この文字に対するフォントの開始バイトは、行および列を０から９４まで数えると仮定すると、２８*（Ｙ*９５＋Ｚ）である。
【００４５】
ＩＳＯ−２０２２−ＣＮ拡張版及びＩＳＯ−２０２２−ＣＮ拡張版は、下記の右列で示した文字セットの指定順序を用いて、下記の左列で列挙された文字セットをコード化する手順を定義している。
【００４６】
【表１】
2005501303.tif 000003
【００４７】
所定のテキスト文字列では、アプリケーションがこれらの文字セット指定順序の１つを調べる場合には、アプリケーションはその後のテキスト文字列を解釈するためにモードを切り換えるため、全ての２バイトが文字セット指定順序に対応する文字セットの中の１つの文字として結合される。１００，０００以上の文字をコード化するために、１つの実施形態では、上記の文字セット指定順序の最後の２つの番号が拡張される。
【００４８】
【表２】
2005501303.tif 000004
【００４９】
図３に基づいて、ブラウザ１２を実行するソフトウェア６０は、ブロック６２に示すように、プレーン、行、又は列（ＰＲＣ）形式のＨＴＭＬウェブページを受信することにより開始する。プレーンは、テキスト文字列の開始時に文字セット指定子によって絶対的に表示され、行および列は、テキスト文字列内の全ての２つのバイトによって表される。
【００５０】
菱形６４で決定されるように、文字セットのプレーンが変更されるたびに、ブロック６６に示すように、新しい文字セットの指定子（以下、「ＣＳＧ」とよぶ）がＭＯＤの変化を示すように挿入される。菱形６８で決定されるように、ＩＳＯ−２０２２−ＣＮ及び拡張版ＩＳＯ−２０２２−ＣＮ拡張版により定義された文字については、ブロック７０に示すように、マッピングテーブルを使用してその１６ビットのユニコード値をマップする。そして、ブロック７２に示すように、表現するステップが完了する。
【００５１】
１００，０００以上の文字に対応するブラウザについては、ブロック７４に示すように、これらの新たに定義されコード化された文字は、代理領域にマップされる。代理領域内のユニコード文字については、代理値を使用してプレーンと行と列との本来の値を計算する。そして、ブロック７６に示すように、ブラウザに指示して、フォントファイル内の特定の文字のフォントのバイトのそのファイル位置とオフセットとを見つける。そして、ブロック７８に示すように、グリフ像がＩＳＯ−２０２２−ＣＮ拡張版の状態又は代理領域にマップされた拡張された状態のいずれかに対して生成される。
【００５２】
本発明を限られた数の実施形態に関して説明してきたが、当業者はこれらの実施形態からの多くの修正例及び変更例を理解されよう。特許請求の範囲が、全てのそのような修正例や変更例を本発明の真の精神及び範囲の中に入るものとしてカバーするものとする。
【図面の簡単な説明】
【００５３】
【図１】本発明の１つの実施形態によるソフトウェア用のフローチャートである。
【図２】本発明の１つの実施形態を実行するハードウェアのブロック図である。
【図３】本発明の１つの実施形態によるソフトウェア用のフローチャートである。
【図１】
2005501303.tif 000005
【図２】
2005501303.tif 000006
【図３】
2005501303.tif 000007
【国際公開パンフレット】
2005501303.tif 000008
2005501303.tif 000009
2005501303.tif 000010
2005501303.tif 000011
2005501303.tif 000012
2005501303.tif 000013
2005501303.tif 000014
2005501303.tif 000015
2005501303.tif 000016
2005501303.tif 000017
2005501303.tif 000018
2005501303.tif 000019
2005501303.tif 000020
2005501303.tif 000021
2005501303.tif 000022
2005501303.tif 000023
2005501303.tif 000024
2005501303.tif 000025
2005501303.tif 000026
2005501303.tif 000027
2005501303.tif 000028
【国際公開パンフレット（コレクトバージョン）】
2005501303.tif 000029
2005501303.tif 000030
【国際調査報告】
2005501303.tif 000031
2005501303.tif 000032
2005501303.tif 000033
2005501303.tif 000034
2005501303.tif 000035