(57)【要約】      （修正有）【課題】必要とされるフォントデータのみ送信することにより、帯域幅の浪費を防止する。【解決手段】特定のフォントを利用して作成される文書には、そのフォントについて定義された全てのグリフが含まれていないことがままある。従って、ネットワークを介してその文書の作成に用いられるフォントを取得するのに必要な帯域幅の量を減少させるため、縮小グリフ集合を含むフォントファイルを作成する。閲覧される文書に用いられるグリフのみをフォントファイルに含める。縮小グリフフォントファイルはオンザフライ方式で生成され、これに加えてあるいは代えて、後の迅速な検索に対応すべくキャッシュされる。【選択図】図９Ａ
2011138482.tif 000002
【特許請求の範囲】
【請求項１】
フォントの要求の受付けと、
前記フォントについて定義された全てのグリフよりも少ない数のグリフのセットを前記要求が特定しているかの判定と、
前記フォントについて定義された全てのグリフよりも少ない数のグリフのセットを前記要求が特定していると判定された場合の、当該特定されたグリフのセットのみを含む縮小グリフフォントファイルの生成と、を行なう方法。
【請求項２】
前記グリフのセットはユニコードを用いて特定される請求項１に記載の方法。
【請求項３】
前記要求はシリアル番号を更に含み、
前記シリアル番号に基づく前記要求の有効性の確認を更に行なう請求項１に記載の方法。
【請求項４】
前記フォントについて定義された全てのグリフよりも少ない数のグリフのセットを前記要求が特定していないと判定された場合に、前記フォントについて定義された全てのグリフを含むフォントファイルの検索を更に行なう請求項１に記載の方法。
【請求項５】
前記要求を発行したユーザエージェントに適合可能なフォントファイル形式の決定と、
前記決定されたフォントファイル形式に基づく前記縮小グリフフォントファイルの生成と、を更に行なう請求項１に記載の方法。
【請求項６】
前記要求に対応するネットワーク文書の識別子に関連付けて前記縮小グリフフォントファイルのキャッシュを更に行なう請求項１に記載の方法。
【請求項７】
前記グリフのセットを特定すると共に前記ネットワーク文書の識別子を含んだ、前記フォントに係る後続の要求の受付けと、
前記後続の要求に応じて前記キャッシュされた縮小グリフフォントファイルの検索と、を更に行なう請求項６に記載の方法。
【請求項８】
プロセッサと、
前記プロセッサと協働可能とされ、コンピュータ読み取り可能な命令群を記憶保持したメモリとを備える装置であって、
前記コンピュータ読み取り可能な命令群の実行に伴い、
フォントの要求の受付けと、
前記フォントについて定義された全てのグリフよりも少ない数のグリフのセットを前記要求が特定しているかの判定と、
前記フォントについて定義された全てのグリフよりも少ない数のグリフのセットを前記要求が特定していると判定された場合の、当該特定されたグリフのセットのみを含む縮小グリフフォントファイルの生成と、を行なう装置。
【請求項９】
前記要求はシリアル番号を更に含み、
前記シリアル番号に基づく前記要求の有効性の確認を、前記コンピュータ読み取り可能な命令群の実行に伴って更に行なう請求項８に記載の装置。
【請求項１０】
前記フォントについて定義された全てのグリフよりも少ない数のグリフのセットを前記要求が特定していないと判定された場合に、前記フォントについて定義された全てのグリフを含むフォントファイルの検索を、前記コンピュータ読み取り可能な命令群の実行に伴って更に行なう請求項８に記載の装置。
【請求項１１】
前記要求を発行したユーザエージェントに適合可能なフォントファイル形式の決定と、
前記決定されたフォントファイル形式に基づく前記縮小グリフフォントファイルの生成と、を前記コンピュータ読み取り可能な命令群の実行に伴って更に行なう請求項８に記載の装置。
【請求項１２】
前記コンピュータ読み取り可能な命令群の実行に伴い、前記要求に対応するネットワーク文書の識別子に関連付けて前記縮小グリフフォントファイルのキャッシュを更に行なう請求項８に記載の装置。
【請求項１３】
前記グリフのセットを特定すると共に前記ネットワーク文書の識別子を含んだ、前記フォントに係る後続の要求の受付けと、
前記後続の要求に応じて前記キャッシュされた縮小グリフフォントファイルの検索と、を前記コンピュータ読み取り可能な命令群の実行に伴って更に行なう請求項１２に記載の装置。
【請求項１４】
コンピュータ読み取り可能な命令群を記憶保持したコンピュータ読み取り可能な媒体であって、
前記コンピュータ読み取り可能な命令群の実行に伴い、
フォントの要求の受付けと、
前記フォントについて定義された全てのグリフよりも少ない数のグリフのセットを前記要求が特定しているかの判定と、
前記フォントについて定義された全てのグリフよりも少ない数のグリフのセットを前記要求が特定していると判定された場合の、当該特定されたグリフのセットのみを含む縮小グリフフォントファイルの生成と、を装置に行なわせるコンピュータ読み取り可能な媒体。
【請求項１５】
前記要求はシリアル番号を更に含み、
前記シリアル番号に基づく前記要求の有効性の確認を、前記コンピュータ読み取り可能な命令群の実行に伴って更に前記装置に行なわせる請求項１４に記載のコンピュータ読み取り可能な媒体。
【請求項１６】
前記フォントについて定義された全てのグリフよりも少ない数のグリフのセットを前記要求が特定していないと判定された場合に、前記フォントについて定義された全てのグリフを含むフォントファイルの検索を、前記コンピュータ読み取り可能な命令群の実行に伴って更に前記装置に行なわせる請求項１４に記載のコンピュータ読み取り可能な媒体。
【請求項１７】
前記要求を発行したユーザエージェントに適合可能なフォントファイル形式の決定と、
前記決定されたフォントファイル形式に基づく前記縮小グリフフォントファイルの生成と、を前記コンピュータ読み取り可能な命令群の実行に伴って更に前記装置に行なわせる請求項１４に記載のコンピュータ読み取り可能な媒体。
【請求項１８】
前記コンピュータ読み取り可能な命令群の実行に伴い、更に前記装置に、前記要求に対応するネットワーク文書の識別子に関連付けて前記縮小グリフフォントファイルのキャッシュを行なわせる請求項１４に記載のコンピュータ読み取り可能な媒体。
【請求項１９】
前記グリフのセットを特定すると共に前記ネットワーク文書の識別子を含んだ、前記フォントに係る後続の要求の受付けと、
前記後続の要求に応じて前記キャッシュされた縮小グリフフォントファイルの検索と、を前記コンピュータ読み取り可能な命令群の実行に伴って更に前記装置に行なわせる請求項１８に記載のコンピュータ読み取り可能な媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
縮小グリフフォントファイルの作成および配布に関する様々な態様を開示する。
【背景技術】
【０００２】
ウェブページのようなネットワーク文書は、様々なフォントを用いて様式を伝達し、美観を高めている。しかしながらネットワーク文書を閲覧するのに用いるウェブブラウザまたはユーザエージェントのシステムに当該文書に対応するフォントが装備されていないために、当該文書を閲覧できない場合が多くある。したがってユーザエージェントまたはユーザエージェントが動作している装置は、ネットワークを通じてフォントを取得することが必要になる。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
フォントファイルには大規模なものがあり、よって伝送にかなりの帯域幅を必要とする場合がある。一般にフォントファイルには、そのグリフがネットワーク文書に用いられているか否かにかかわらず、全てのグリフに関する定義情報が含まれている。つまり必要のないデータでありながらユーザエージェント装置に送信されていることになるので、帯域幅の浪費につながる。
【０００４】
本発明のいくつかの態様に関する基本的理解ができるように、簡略化された概要を以下に示す。この概要は本発明を詳細に見渡すものではない。本発明の重要または必要不可欠な要素を特定することを意図したものでもないし、本発明の及ぶ範囲を規定することを意図したものでもない。以下の概要は、続く詳細な説明の前置きとして、本発明の概念のいくつかについて簡略化した形式で記述したものに過ぎない。
【課題を解決するための手段】
【０００５】
ユーザエージェント種（例えばブラウザ種）を特定することによってフォント要求を処理するフォントサーバに関する態様が開示される。ネットワークサーバは特定されたユーザエージェント種に適合するフォントファイル形式において要求されたフォントを検索し、これを応答として送る。従って、ページまたは文書のディベロッパは、特定のフォントを参照するのに単一のフォントファイル形式を定める必要がない。代わりに、全てのブラウザ種をサポートすることができるように、その決定をフォントサーバに委ねることが可能になる。
【０００６】
別の態様によれば、あるフォントファイルはネットワーク文書またはこれに関連付けられたスタイルシート内において識別子を用いて参照される。識別子はあるフォントまたはフォントファミリーに固有であるものの、当該フォントまたはフォントファミリーに係る全てのフォントファイル形式にとって共通のものである。
【０００７】
さらに別の態様によれば、文書作成アプリケーションは、ウェブ文書に加えて当該ウェブ文書のレイアウトおよび見た目を定義するためのスタイルシートを生成するように構成できる。更にこのアプリケーションは、フォントサーバからフォントまたはフォント識別情報を検索し、選択されたフォントまたはフォントファミリを参照するスタイルシートまたはウェブ文書中においてコードフラグメントを生成するように構成することもできる。
【０００８】
さらに別の態様によれば、ネットワークサーバがあるフォントのフォントファイルあるいは適合する形式のフォントファイルを備えていない場合、ネットワークサーバは、そのフォントまたはフォントファイルのリストを更新できる。あるフォントサーバにおいて当該フォントが入手可能になると、ネットワークサーバは特定された他のフォントサーバまたは当該フォントサーバに当該フォントファイルが格納されていない場合はフォントの所在地へ向けて要求を転送できる。よって適合するフォントファイルが特定された他のフォントサーバから、あるいは元のフォントサーバを経由して、要求を発行した装置に送信され得る。
【０００９】
さらに別の態様によれば、ウェブディベロッパは、ある特定のフォントについて縮小グリフ範囲を指定することが可能であり、ユーザエージェントはそれを要求できる。これは、ディベロッパが発行したネットワーク文書を閲覧するのに必要な情報を得るのに求められる帯域幅の量の減少に資する。フォントサーバまたはそれに関連付けられたサーブレットは、要求の有効性を評価し、当該要求が有効であることを確認すると、要求されたフォントに関して要求された範囲のグリフだけを含むフォントファイルを生成できる。要求グリフ範囲は前記要求中にて与えられ得る。例えば、グリフ範囲はＨＴＴＰ要求の要求ストリングで指定できる。
【００１０】
本発明の様々な目的、特徴、および利点については、添付の図面を参照してなされる下記の詳細説明からより容易に明らかになり、より十分な理解が得られるであろう。
【図面の簡単な説明】
【００１１】
【図１】本発明に係る少なくとも１つの態様を実施することが可能なコンピュータシステムおよび環境の例を示す図である。
【図２】本明細書に記載の少なくとも１つの態様において用いることが可能なウェブ文書に埋め込まれたスタイルシートの例を示す図である。
【図３】ユーザエージェント適合性に基づいてフォントサーバからフォントを取得することが可能な方法の例を示すフローチャートである。
【図４】ウェブ文書をその構造を定義するスタイルシートを含んで生成する方法の例を示すフローチャートである。
【図５】本明細書に記載の少なくとも１つの態様における文書作成アプリケーションインターフェースの例を示す図である。
【図６】適合するフォントファイルの選択に用いることが可能なフォントサーバの例を示す図である。
【図７】フォントサーバが別のサーバまたは記憶場所にフォントファイル要求を転送できるようにする方法の例を示すフローチャートである。
【図８】本明細書に記載の少なくとも１つの態様に基づいて縮小グリフ範囲要求を定義する構文の例を示す図である。
【図９Ａ】本明細書に記載の少なくとも１つの態様に基づいて縮小グリフフォントファイル要求を処理し、縮小グリフフォントファイルを生成する方法の例を示す図である。
【図９Ｂ】本明細書に記載の少なくとも１つの態様に基づいてフォントサーバから縮小グリフフォントファイルを取得する処理フローの例を示す図である。
【発明を実施するための形態】
【００１２】
上述のように、開示の態様は、オンラインウェブ環境でフォントを取得し、処理するシステム、装置、方法、および、コンピュータが読み取り可能な媒体に関するものである。本明細書で用いられる限りにおいて、フォントとはある書体の文字集合を指すものとし、開示の例においては、その特定の書体について定義された全ての文字の集合を指すものとする。ユーザは、ウェブブラウザのような１つ以上の特定種のアプリケーションとだけ適合することが可能なフォントファイル形式のフォントファイルをウェブサーバにアップロードできる。従ってウェブサーバは、他種のアプリケーションおよびウェブブラウザと適合する別のフォントファイル形式で第２のフォントファイルを生成できる。或いは、ユーザはウェブサーバに別形式のフォントファイル生成を要求せずに、マルチフォントファイル形式のフォントファイルをアップロードできる。ウェブサーバを利用すると、ブラウザは適当な形式のフォントファイルを取得できる。これによって、ユーザは、ウェブページをブラウザ種に合わせてカスタマイズすることを必要とせずに、ユーザのウェブページにおいて様々なスタイルおよびフォントを利用できる。
【００１３】
図１には、ウェブページのようなネットワーク文書のテキストを生成するためにフォントファイルの送信および利用が可能なネットワーク環境が例示されている。ネットワーク１００は、クライアント装置１０３を含む様々な装置とネットワークサーバ１０５との間で通信を行えるように構成される。通信は、インターネットプロトコル（ＩＰ）、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、ファイル転送プロトコル（ＦＴＰ）等を含む１つ以上の通信プロトコルに準拠し得る。装置１０３には、パーソナルコンピュータ（ＰＣ）１０３ａのような固定装置、並びに、携帯情報端末（ＰＤＡ）１０３ｂ、携帯電話１０３ｃ、および、ラップトップコンピュータ１０３ｄのような携帯通信装置を含み得る。ネットワークサーバ１０５は、ウェブページ、ミュージックコンテンツ、ビデオコンテンツ、アプリケーション等を含む様々な種の情報を記憶し、提供するように構成される。例えばネットワークサーバ１０５ａは、ユーザまたは組織のために１つ以上のウェブページまたはウェブサイトを提供するように構成できる。
ウェブページは、例えば、ハイパーテキストマークアップ言語（ＨＴＭＬ）に従ってフォーマットされ得る。拡張可能なマークアップ言語（ＸＭＬ）、拡張可能なハイパーテキストマークアップ言語（ＸＨＴＭＬ）等のような他のウェブフォーマットも可能である。ウェブページおよびサイトは、さらに、ＨＴＭＬまたはＸＭＬのようなマークアップ言語で記述された文書のレイアウトおよび表示について記述するように構成されたカスケーディングスタイルシート（ＣＳＳ）に基づいて定義され得る。ＣＳＳは、色、フォント、およびレイアウト（例えば、マージン、境界線）を含む文書表示から（ＨＴＭＬまたは同様のマークアップ言語で記述された）文書内容を分離することを基本に設計されている。
従って、装置１０３の１つがネットワークサーバ１０５ａからのページを要求すると、ネットワークサーバ１０５ａは、そこで参照される１つ以上の対応するスタイルシートと共にウェブ文書を返すことができる。装置１０３は、ウェブブラウザのようなアプリケーションを用いて、文書コーディング並びに対応するスタイルシートに基づいて当該ウェブ文書をレンダリングできる。例えばスタイルシートは、あるフォントに係るフォントファイルの所在を特定するＵＲＩを記憶する又はそれに対応するフォントパラメータ（例えば@font-face rule）を含み得る。フォントファイルにはウェブ文書の１つ以上の部分がレンダリングされる。一般にフォントファイルとは、演算装置がある特定のフォントの記号および文字集合をレンダリングするのに必要な情報を記憶しているデータファイルを指す。装置１０３は、ウェブ文書のそれらの部分を作成者／著者が意図するようにレンダリングするため、フォントファイルを検索できる。
【００１４】
ネットワークサーバ１０５ｂは、フォントファイルを記憶するように構成される。フォントファイルは、様々な形式に従って作成することが可能であり、よって様々な種のブラウザおよびアプリケーションがそれらの形式との様々な適合性を備えている可能性がある。例えば、フォントは、TrueType、OpenType、またはEmbedded OpenType形式に従って作成され得る。しかしながら、マイクロソフト社のインターネットエクスプローラのような一部のウェブブラウザには、TrueTypeおよびOpenTypeフォントファイル形式に適合しないものもあり得るし、他のブラウザには、Embedded OpenTypeフォントファイル形式に適合しないものもあり得る。こうした適合性問題を解決するため、ネットワークサーバ１０５ｂは、複数のブラウザおよびアプリケーション種に適合できるように、複数形式のフォントファイルを記憶できる。１つ以上の装置１０３からフォントファイル要求を受信すると、ネットワークサーバ１０５ｂは、ブラウザまたはアプリケーション種を確認して適合する形式のフォントファイルを選択し、要求装置に送ることができる。これによって文書の著者は、何れのフォントファイル形式を選択するかで不適合性問題により潜在的読者の一部を失うことを考慮する必要がなくなる。
【００１５】
本明細書に記載のフォント検索に基づいて利用することが可能なスタイルシートの例を図２に示す。カスケーディングスタイルシート２００には、現在フォントファミリ２０５がインストールされていないユーザ装置のために、フォントファミリ２０５のようなフォントまたはフォントファミリを定義する@font-face rule２０１が含まれている。カスケーディングスタイルシート２００は、さらに、フォントファミリ２０５に関するフォントファイルを取得することが可能な場所２１０（例えば、ＵＲＩ）を定義する。その後、フォントファミリを用いて、ＨＴＭＬファイル２２０によって定義された文書の本体に用いられるフォント２１５を定義できる。例示のカスケーディングスタイルシート２００は、単一フォントの定義を行うだけであるが、使用対象のウェブ文書に応じて追加フォントまたはフォントファミリの定義を加えることができる。例えば１つのフォントをヘッダに利用し、別のフォントを本体テキストに用いることができる。本例ではスタイルシート２００はＨＴＭＬファイル２２０内に埋め込まれているが、スタイルシートをＨＴＭＬ文書の外部に設け、ＨＴＭＬファイルに外部スタイルシートへの参照を含める構成としてもよい（詳しくは後述する）。
【００１６】
要求アプリケーションの適合性に基づいてフォントサーバからフォントを取得することが可能な方法の例を図３に示す。ステップ３００において、フォントサーバは、ウェブ文書の著者または他の情報源から新しいフォントに対応するフォントファイルを受信する。例えば、文書の著者がフォントサーバに現在設けられていないフォントをウェブページで利用することを望む可能性がある。こうした場合、当該ページの訪問者が著者の意図する形式およびスタイルで記述されたページを閲覧でき、かつ他の著者も当該フォントを利用できるように、著者は当該フォントをフォントサーバに通知（アップロード）する。ステップ３０５において、フォントサーバは、そのフォントファイルを合法的に配布可能であるか確認する。そのフォントまたはフォントファイルを合法的に配布できない場合、ステップ３５０において、フォントサーバは、フォントまたはフォントファイルの受入れおよび／または配布を拒否する。例えばそのフォントの製作者が埋め込んだメタデータをフォントファイルから抽出し、当該メタデータが当該フォントファイルの配布が可能であることを示しているかを判定することによって確認が為される。
フォントサーバはそのフォントファイルが合法的に配布可能であると判定すると、次にステップ３１０において、当該フォントファイルを作成した形式を特定する。フォントファイル形式の例としては、TrueType、OpenType、またはEmbedded OpenType等がある。その形式は、ファイル名、ファイル拡張情報、メタデータ、コーディング構造、および／またはそれらの組合せによって識別できる。フォントファイル形式の識別が済むと、ステップ３１５において、フォントサーバはそのフォントに関するフォントファイルが別のフォントファイル形式で存在するかを判定する。存在しなければ、ステップ３２０において、フォントサーバは受信したフォントファイルに記憶されているフォントデータに基づいて別のフォントファイル形式のフォントファイルを生成する。例えばマイクロソフト社のWeb Embedding Fonts Tool（ＷＥＦＴ）のようなフォントファイル作成ツールを利用できる。これに加えてあるいは代えて、http://www.w3.org/Submission/EOT/で入手可能なEmbedded OpenTypeに関する規格のようなフォントファイル形式規格を利用して、フォントファイルを作成することも可能である。必要とされる形式は、デフォルトリストとして定義することもできるし、フォントまたはフォントファミリ毎にカスタマイズすることも可能である。
【００１７】
ステップ３２５において、フォントサーバまたはそのサーブレットは、受信したフォントファイルに対応するフォントまたはフォントファミリの要求を受信する。例えば当該要求は、要求元であるユーザエージェント（すなわち情報を要求するブラウザまたはアプリケーション）に関する情報を含むユーザエージェント要求ヘッダフィールドを含み得るHTTP GET要求に基づいて構造化できる。ステップ３３０において、フォントサーバまたはサーブレットは様々なパラメータや各種情報を抽出する。これらは要求されたフォントまたはフォントファミリ、および当該フォントまたはフォントファミリを参照するページにアクセスするために用いられるブラウザ種に係る識別情報を含んでいる。例えば、フォント名およびブラウザアプリケーション名は、HTTP GETヘッダで指定できる。
ステップ３３５において、フォントサーバまたはサーブレットは要求されたフォントのレンダリングに用いられているユーザエージェントを特定する。次にステップ３４０において、フォントサーバは使用されているユーザエージェント（例えばある種のウェブブラウザ）に適合するフォントファイル形式を特定する。例えばマイクロソフトのインターネットエクスプローラは、Embedded OpenTypeフォントファイル形式としか適合しない場合がある。上記のブラウザ種情報は、例えばブラウザのバージョン情報を含むあるいは参照するものとしてもよい。
適合するフォントファイル形式の特定が済むと、ステップ３４５において、フォントサーバまたはサーブレットは、特定された形式における要求されたフォントまたはフォントファミリファイルを検索して、要求装置に送信する。
【００１８】
フォントファイルの受信後かつ当該フォントファイルを配布可能にする前のある時点において、フォントサーバは、例えばフォントファイルを処理および／またはフォントデータを圧縮して、グリフ集合をなすフォントをウェブ設計者（または当該フォントが参照されるウェブ文書）が必要とする集合にまで縮小する。例えば、フォントファイルはその受信直後に処理してもよいし、対応するフォント要求の受信に応えて処理してもよい。フォントファイルは、そのフォントを利用するウェブ文書で用いられる文字または記号だけしか含まないように縮小される。
【００１９】
ウェブページまたはスタイルシートのようなネットワーク文書における特定のフォントに関する縮小グリフ範囲（定義あるいは利用可能とされた全グリフよりも少ない）を定義する構文例を図８に示す。縮小フォントファイルが不要かまたは利用できない場合、構文８００には代替またはデフォルトフォントに係るフォント定義８０１を含み得る。フォント定義８０１には、ネットワーク記憶場所情報８０５に加え、フォントファミリ名８０３を含み得る。ネットワーク記憶場所またはアドレスは、「サーバアドレス／フォントファイルを利用するウェブサイトのシリアル番号／フォントファイル名」という構文に基づいて指定できる。ここでフォントファイル名は、例えばFontName.eotまたはFontName.ttfとできる。ウェブサイトで指定されるフォントファイルのネットワーク記憶場所またはアドレス（ＵＲＩ）は、そのフォントファイルを仮想的に参照するのに用いることができる。すなわち、フォントまたはフォントファイルはそのネットワーク記憶場所には記憶されていない場合があり得るが、一方でフォントおよび／またはフォントファイルは様々なサーバまたは記憶場所に記憶できる。従ってネットワーク記憶場所に対応するサーバまたはサーブレットは、ルックアップテーブルを用いればフォントファイルの実記憶場所を特定できる。ルックアップテーブルは、フォントサーバからサーブレットにロードできる。
一方、フォント定義８０７は、縮小フォントまたは動的縮小フォントファイルの要求を指定する。シリアル番号は、フォントサービスの顧客に関連付けられた識別子に対応できる。従って、識別および請求書発行の目的で各ウェブディベロッパまたはウェブサイトに固有のシリアル番号を与えることができる。シリアル番号を用いると、フォント参照の相互リンク（すなわちもとの顧客からのフォント参照を別のウェブサイトが利用）を阻止することも可能になる。フォント定義８０７はフォント定義８０１と同じフォントを要求するが、所望のグリフ集合（例えば000-5FF、1E00-1FFF、2000-2003）を指定する。グリフ範囲は、独立したユニコード範囲フィールド８０９で指定することもできる。範囲フィールド８０９は、スタイルシート仕様に応じて任意選択が可能である。
上記定義８０１および８０７を利用すると、例えば、ユーザの帯域幅が制限されるか、または、全フォントファイル（全グリフを含む）が特に大きい場合、ユーザエージェントは、フォント定義８０７で指定された縮小グリフ集合だけを要求することが可能になる。ユーザは何れのフォントファイルをダウンロードするかを、ウェブ閲覧オプションの定義によって、あるいは選択を促されて、選択することができる。
【００２０】
グリフを動的に縮小する方法の例を図９Ａに示す。ステップ９００において、フォントサーバはフォントの要求を受信する。フォント要求は例えばＨＴＴＰ要求に対応し得る。ステップ９０５において、サーバはその要求を構文解析し、その要求に関連付けられたシリアル番号を特定する。ステップ９１０において、サーバはシリアル番号に基づいて要求の有効性を検証する。要求の有効性確認および検証にはウェブサービスおよび／またはウェブインターフェースを使用できる。ウェブインターフェースは顧客がウェブサイトとセキュリティトークン（例えばシリアル番号）およびフォント群との対応付けをできるようにするものである。この情報セットは、フォントサーバまたはサーブレットにロードすることが可能であり、ＨＴＴＰ要求が送信されてくると、その要求は記憶されているセットと照査される。例えば、シリアル番号およびウェブサイトアドレスは、ＨＴＴＰ獲得要求および当該要求に含まれる参照ストリング（例えばHTTP_REFERER）において指定されているシリアル番号と比較される。
そのフォントは、更にシリアル番号およびアドレスに対応付けて記憶されている１つ以上のフォントからなるフォント群と比較され、その要求が有効であるか、およびそのフォントを提供すべきかを判定する。要求が有効であれば、フォントサーバはステップ９１５および９２０において引き続きその要求の構文解析を行ない、全フォントファイルが要求されているのか、あるいは縮小グリフ集合フォントファイルが要求されているのかを判定できる。判定は要求において指定されているパラメータに基づいて行なわれる。例えばサーバは、要求にグリフ範囲が含まれている場合、そのグリフ範囲が要求されたフォントに関して利用可能なまたは定義されている全てのグリフより少ないかを判定する。これに代えてあるいは加えて、要求がグリフ範囲を含んでいないか指定していない場合、サーバは全てのグリフフォントファイルが要求されているものと判定する。要求は、例えば特定のフォントサーバまたはユーザエージェントに関連付けられたサーブレットによって構文解析される。全フォントファイルが要求されると、ステップ９２５において、全フォントファイルが検索され、フォントサーバから要求エージェントに送信される。
【００２１】
しかしながら、サーバは要求が縮小グリフフォントファイルに関するものであると判定すると、ステップ９３０において、所望のグリフ範囲を特定する。グリフ範囲は例えばＨＴＴＰ要求で指定できる。上述のように、グリフ範囲は各種グリフに対応するユニコード値によって定義できる。所望の範囲が特定されると、ステップ９３５において、サーバは所望のグリフ範囲だけのフォントファイルを作成する。こうした縮小グリフフォントファイルは、全フォントファイルをコピーし、そのコピーから全ての不要なグリフに係るグリフデータを削除することによって作成できる。グリフデータには、文字および記号の輪郭を定義するデータ（例えばTrueType、OpenType、またはEmbedded OpenTypeデータ）、ビットマップ情報、文字とグリフのマッピングテーブル等を含み得る。これに加えてあるいは代えて、フォントの他の特性または態様を縮小グリフフォントファイルの作成時に削除してもよい。例えばグリフの１つを動的に削除する場合、合字（２つ以上のグリフが並んだ場合に、フォントレンダラによって動的に置き換えられるグリフ）を削除できる。あるいはフォントサーバは、縮小グリフフォントファイルを作成し、指定されたグリフデータだけを縮小グリフフォントファイルにコピーしてもよい。さらにフォントサーバは、例えば使用されているユーザエージェント種を考慮し、前述の通り当該ユーザエージェント種に適合するフォントファイル形式を使用できる。
縮小グリフフォントファイルが作成されると、ステップ９４０において、関連するネットワーク文書（例えばウェブページ）のレンダリングに供されるべくユーザエージェントに送信される。ステップ９４５において縮小グリフフォントファイルは、後続の要求者に迅速に供給することができるようにフォントサーブレット（例えば一次記憶装置）にキャッシュされる。縮小グリフフォントファイルは、自身の適用対象であるウェブサイトのアドレスに対応付けて記憶される。従って、同じウェブサイトについて縮小グリフフォントファイルの要求を続いて受信すると、キャッシュされたフォントファイルを検索して要求者に提供できる。
【００２２】
動的に縮小グリフフォントファイルの作成が可能な処理フローの別の例を図９Ｂに示す。ユーザエージェントは、ウェブサーバにネットワーク文書を要求し、これを受信するに際して縮小グリフフォントファイルを要求する。従ってフォントサーバは、縮小グリフフォントファイルを動的に作成することが求められる。すなわちフォントサーバは、特定の要求があるとその応答としてフォントファイルを作成することが必要とされる。まずフォントサーバに対応するフォントサーブレットによって要求が受信され、構文解析が行なわれる。ネットワーク文書および／または対応するスタイルシートがウェブディベロッパによって作成および公開される。従ってウェブディベロッパは、ネットワーク文書の閲覧に必要なグリフ範囲を決定する。
【００２３】
スタイルシートにおけるフォントの記憶場所の参照は、特定のフォントファイルに対する直接的な参照ではない場合がある。代わりにフォントまたはフォントファミリに固有の識別子に対する参照とすることができる。フォントまたはフォントファミリに固有であるが、特定のフォントファイル（およびフォントファイル形式）に固有ではない識別子を用いると、フォントサーバは要求装置およびユーザのために適合するフォントファイル形式を選択することが可能になる。識別子は、フォントサーバまたは他の何らかのエンティティによって割り当てることができる。
【００２４】
ウェブ文書をその構造を定義するスタイルシートを含んで生成する方法の例を図４に示す。ステップ４００において、フォント管理アプリケーションは遠隔フォントサーバとインターフェース接続し、そのサーバによって提供される利用可能なフォントリストを検索する。ステップ４０５においてこのアプリケーションは、ユーザが様々なフォントで閲覧できるようにするユーザインターフェースを提供する。
ステップ４１０においてこのアプリケーションはユーザ選択を受信する。ユーザ選択は、ユーザが作成したウェブ文書にて使用されるフォントの１つを選択するものである。例えばユーザは、ウェブ文書の本体テキストにHelvetica Boldと称するフォントを利用したいと思う場合がある。これに代えてあるいは加えて、ユーザは文書の閲覧に必要なグリフ範囲を指定あるいは決定するようにフォント管理アプリケーションに要求する場合がある（文書があるフォントについて定義されたグリフの一部のみを含む場合等）。従ってこのアプリケーションは、文書に組み込まれているグリフ集合を特定すべく、ネットワークと当該ネットワーク中で用いられている記号および文字とを評価することができる。
ステップ４１５において、このアプリケーションは、スタイルシートのコードセグメントを生成して、選択されたフォントおよび／またはグリフ範囲を基礎をなすウェブ文書に組み込むことができる。生成されるコードセグメントには、そのフォントまたはフォントファミリには固有であるが、その特定フォントまたはフォントファミリに関する全フォントファイル形式に対して包括的なフォント識別子を含むことができる。それに加えてまたは代わりに、生成されるコードセグメントは、図８に例示のように縮小グリフ範囲を指定することも可能である。これによって、ユーザが文書閲覧のためにダウンロードしなければならないデータ量を減少させることが可能になる。
ステップ４２０において、このアプリケーションは、対応するスタイルシートを用いてウェブ文書のプレビューを生成できる。本明細書に記載のように、スタイルシートは、ウェブ文書コードへの埋め込みスタイルシートとすることもできるし、あるいは、外部スタイルシートとすることも可能である。さらに、単一ネットワーク文書において、複数スタイルシートを参照または利用できる。
【００２５】
文書入力部５０１、フォント選択バー５０３、プレビューオプション５０５、画像挿入パネル５０７、および、フォーマット制御バー５０９を含む文書作成アプリケーションインターフェース５００の例を図５に示す。文書入力部５０１は、著者がテキスト、画像、および他のコンテンツを入力し、発行されるウェブページまたは他のネットワーク文書を規定する書式を提供する。例えば画像は画像挿入パネル５０７を用いて選択し、文書入力部５０１に挿入する。文書入力部５０１は、エンドユーザに表示されるように（すなわち、基本コードを隠して）、またはページコードを示すようにして文書を表示する。画像挿入パネル５０７は、ユーザが画像ファイルを見つけて選択できるようにする参照機能５１５を備える。さらに画像挿入パネル５０７は、ユーザが画像サイズを定義できるようにすることも可能である。文書作成アプリケーションは、文書における画像のサイズ、位置、および、他の特性を定義する文書コードを自動的に生成できる。
フォーマット制御バー５０９は、マージンの修正、文字揃えの調整、新しいパラグラフの定義等の制御を可能にする。フォント選択バー５０３は、文書の様々な部分に関してフォントを選択および決定するのに用いる。例えば、フォント選択バー５０３には利用可能なフォントを列挙するドロップダウンメニュー５１１を備え得る。遠隔フォントサーバからフォントリストを検索してドロップダウンメニュー５１１に取り込む構成としてもよい。
文書作成アプリケーションは、画像の挿入およびコードのフォーマットに際して文書に用いるべく選択されるフォントを定義するコードを生成する。フォントコードおよびカラーコードのようないくつかのコードは、実際のネットワーク文書ではなく、外部スタイルシート（例えばmystyle.css）において定義できる場合があるので、ネットワーク文書にはスタイルシートの参照を含むことができる。インターフェース５００において参照されるスタイルシートは選択タブ５１３によって閲覧できる。あるいは、スタイルシートをネットワーク文書に埋め込む（すなわちスタイルシートコードがネットワーク文書コードの一部として含まれる）構成とすることができる。
【００２６】
フォントを要求するブラウザ種に基づいて適合するフォントファイルを選択するために利用し得るフォントサーバの例を図６に示す。フォントサーバ６００は、フォントデータベース６０１、ユーザエージェント決定モジュール６０３、応答ジェネレータ６０５、および要求パーサ６０７を備える。フォントデータベース６０１は、マルチフォントに関するフォントファイルを記憶するように構成される。つまりフォントデータベース６０１は、マルチフォントファイル形式であるフォントのフォントファイルを記憶できる。フォント要求を受信すると、要求パーサ６０７は当該要求に含まれているヘッダフィールドの構文解析および抽出を行なう。例えば、要求パーサ６０７はHTTP GET要求からユーザエージェント種ヘッダフィールドを抽出する。次いでユーザエージェント種ヘッダ情報は、フォントおよびフォントファイルを要求するユーザエージェント種（例えばウェブブラウザ種）を特定するように構成されたユーザエージェント種決定モジュール６０３に送られる。さらに要求パーサ６０７は、参照者ストリング（例えばHTTP_REFERER）を分析し、参照者情報とフォント要求およびシリアル番号を組み合わせるように構成される。この情報の収集および組合せは、上記要求が有効であるか否か、およびフォントを供給すべきかどうかの決定を支援すべく行なわれる。
【００２７】
ユーザエージェント決定モジュール６０３は、特定されたユーザエージェント種に適合するフォントファイル形式の決定も担う。例えばユーザエージェント決定モジュール６０３は、フォーマット種とユーザエージェント種との対応付けを記憶しているルックアップテーブルを調べて、適合ファイル形式を決定する。応答ジェネレータ６０５は、適合ファイル形式が決定されると当該形式における要求されたフォントをデータベース６０１から検索するように構成される。次いで応答ジェネレータ６０５によってフォントファイルを含む応答が生成され、要求元の装置に送信される。
【００２８】
例えばフォントデータベース６０１に要求されたフォントまたは適合するフォントファイルが記憶されていない場合に、別のサーバにフォント要求を転送するように構成された要求リディレクタ６０９をフォントサーバ６００が備える構成としてもよい。リディレクタ６０９は、利用可能なフォントおよびフォントファイル形式をそれらの所在と対応付けて記憶しているルックアップテーブルを用い、適合するフォントファイルまたは要求されたフォントの所在を特定できる。さらにリディレクタ６０９は、応答ジェネレータ６０５が要求元の装置に対する応答を生成できるように、他のサーバからフォントファイルを受信するように構成され得る。あるいは、単に他のサーバによって既に生成されている応答を要求元の装置に送る送信媒介手段として機能するようにリディレクタ６０９を構成することもできる。フォントサーバ６００が他のサーバからフォントファイルを受信するように構成されている場合、フォントデータベース６０１に当該フォントファイルを記憶して以後は要求を必要としないようにする。
【００２９】
上述のモジュールは、ファームウェア、ソフトウェア、ハードウェア、および／またはそれらの組合せを含み得る。さらにフォントサーバ６００は、処理命令の記憶および実行を支援すべく１つ以上のプロセッサ（不図示）、ＲＡＭおよびＲＯＭのようなメモリモジュールを備え得る。
【００３０】
フォントサーバが、サーバの認識していないフォントの要求を処理できるようにする方法の例を図７に示す。ステップ７００において、フォントサーバまたはそのサーブレットは、フォントファイル要求を受信する。フォントファイル要求には、フォント識別子およびユーザエージェント種を含むことができる。ステップ７０５において、フォントサーバまたはサーブレットは、要求されたフォントが取得可能かを判定する。例えば、フォントサーバまたはサーブレットは、要求されたフォントに対応するエントリを求めてルックアップテーブルを調べる。フォントサーバまたはサーブレットに要求されたフォントに関する情報がない場合、ステップ７１０において、サーブレットは、例えばフォントサーバのデータベースからルックアップテーブル情報の再ロードまたは再読み取りを実行する。そしてステップ７１５において、フォントおよびその所在に関するサーブレットの内部リストは、再ロードまたは更新されたルックアップテーブル情報を利用して更新される。
【００３１】
フォントおよびその所在に関するサーブレットの内部リストが更新されると、ステップ７２０において、サーブレットは要求されたフォントが取得可能かを再判定する。取得可能な場合には、ステップ７２５において、サーブレットは、要求されたフォントの所在地へその要求を転送する。それに代えてあるいは加えて、サーブレットは、指定された記憶場所から要求されたフォントを検索することも可能である。それでもフォントが取得不可能な場合には、ステップ７３０において、サーブレットは要求者またはエージェントにフォント要求拒否を送信する。
【００３２】
フォント以外の情報種に関して、同一または同様の検索システム、技法、および装置を利用できる。例えば画像は、要求ユーザエージェントとの適合を確実にするため、画像サーバによって複数形式で記憶できる。よってブラウザが画像を検索しようとする場合、画像サーバは要求ユーザエージェント種を確認し、適合する画像ファイル形式の画像を検索して、その画像を要求元の装置に返すことができる。
【００３３】
さらに上記の方法および特徴は、コンピュータ読み取り可能な命令を記憶し得る任意の数のコンピュータ読み取り可能な媒体によって実現できる。例としてＲＡＭ、ＲＯＭ、ＥＥＰＲＰＭ、フラッシュメモリ、または他のメモリ技術、ＣＤ−ＲＯＭ、ＤＶＤ、または他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気記憶装置等が挙げられる。
【００３４】
それに加えてまたは代えて、上記の方法および特徴は１つ以上の集積回路（ＩＣ）によって実現できる。集積回路は、例えば読み取り専用メモリ（ＲＯＭ）に記憶されているプログラミング命令または他のデータにアクセスするマイクロプロセッサとできる。この場合、ＲＯＭは上記の方法の１つ以上に基づく動作をＩＣに実行させるプログラミング命令を記憶している。あるいは上記の方法の１つ以上をＩＣにおける回路配線により実現することとしてもよい。すなわちこのような場合において当該ＩＣは、演算やその他上記の動作専用のゲートや論理回路を備えた特定用途向け集積回路（ＡＳＩＣ）である。またあるいは、ＩＣがＲＯＭやＲＡＭから読み込んだプログラミング命令の実行を通じて行なわれる幾つかの動作を、当該ＩＣにおけるゲートや論理回路といった回路配線により行なわれる動作と組み合わせて実行する構成としてもよい。ＩＣは画像データを表示バッファに出力することもできる。
【００３５】
様々な特徴を実現する特定の実施例について説明してきたが、添付の請求項に記載された思想および範囲内で、上述のシステムおよび方法に係る多くの変形態様および置換態様が存在することが当業者には明らかであろう。また当業者が本明細書の開示を考慮して得られる多くの他の実施形態、修正および変更が添付請求項の思想および範囲に含まれ得る。
【図１】
2011138482.tif 000003
【図２】
2011138482.tif 000004
【図３】
2011138482.tif 000005
【図４】
2011138482.tif 000006
【図５】
2011138482.tif 000007
【図６】
2011138482.tif 000008
【図７】
2011138482.tif 000009
【図８】
2011138482.tif 000010
【図９Ａ】
2011138482.tif 000011
【図９Ｂ】
2011138482.tif 000012
【外国語明細書】
2011138482.tif 000013
2011138482.tif 000014
2011138482.tif 000015
2011138482.tif 000016
2011138482.tif 000017
2011138482.tif 000018
2011138482.tif 000019
2011138482.tif 000020
2011138482.tif 000021
2011138482.tif 000022
2011138482.tif 000023
2011138482.tif 000024
2011138482.tif 000025
2011138482.tif 000026
2011138482.tif 000027
2011138482.tif 000028
2011138482.tif 000029
2011138482.tif 000030
2011138482.tif 000031
【図１】
2011138482.tif 000032
【図２】
2011138482.tif 000033
【図３】
2011138482.tif 000034
【図４】
2011138482.tif 000035
【図５】
2011138482.tif 000036
【図６】
2011138482.tif 000037
【図７】
2011138482.tif 000038
【図８】
2011138482.tif 000039
【図９Ａ】
2011138482.tif 000040
【図９Ｂ】
2011138482.tif 000041