(57)【要約】  本発明のある実施形態は、プラットホームとは独立した仕方でドキュメントを植字し、レンダリングするシステムを提供する。オペレーション中に、このシステムは、先ず、ドキュメントを得、ドキュメントは、テキストコンテンツと、１つ以上のフォントを含む関連スタイル情報とを有する。又、システムは、１つ以上のフォントに対してプラットホーム独立のフォントメトリックを得、該プラットホーム独立のフォントメトリックは、ドキュメントのレンダリングにおける個々のキャラクタの位置を決定するのに使用できる情報を含む。次いで、システムは、プラットホーム独立のフォントメトリックを使用して、ドキュメントが行断片及びページへどのように分割されるか決定する。最終的に、システムは、ドキュメントをレンダリングする間にその決定された分割を使用して、行断片及びページへのドキュメントの分割が異なるコンピューティングプラットホームにわたって同じであるようにする。【選択図】図２
2013511088.tif 000002
【特許請求の範囲】
【請求項１】
プラットホームとは独立した仕方でドキュメントを植字しそしてレンダリングする方法において、
テキストコンテンツ、及び１つ以上のフォントを含む関連スタイル情報を有するドキュメントを得る段階と、
前記１つ以上のフォントに対し、ドキュメントのレンダリングにおける個々のキャラクタの位置を決定するのに使用できる情報を含むプラットホーム独立のフォントメトリックを得る段階と、
前記プラットホーム独立のフォントメトリックを使用して、ドキュメントが行断片及びページへどのように分割されるか決定する段階と、
ドキュメントをレンダリングする間に前記決定された分割を使用して、行断片及びページへのドキュメントの分割が異なるコンピューティングプラットホームにわたって同じであるようにする段階と、
を備えた方法。
【請求項２】
前記プラットホーム独立のフォントメトリックを使用して、ドキュメントが行断片及びページへどのように分割されるか決定する前記段階は、ドキュメントのレンダリングにおける行断片内の個々のキャラクタの位置を決定することを含む、請求項１に記載の方法。
【請求項３】
前記ドキュメントをレンダリングすることは、行断片及びページへのドキュメントの前記決定された分割を使用し、そして行断片内の前記決定された位置で個々のキャラクタをレンダリングする高忠実度レンダリングを遂行することを含む、請求項２に記載の方法。
【請求項４】
前記ドキュメントをレンダリングすることは、行断片及びページへのドキュメントの前記決定された分割を使用する低忠実度レンダリングを遂行することを含み、この低忠実度レンダリングは、個々のキャラクタの前記決定された位置を使用せず、むしろ、レンダラーがプラットホーム特有のレンダリングメカニズムを使用して行断片内の個々のキャラクタの位置を決定できるようにする、請求項２に記載の方法。
【請求項５】
前記ドキュメントをレンダリングすることは、
ドキュメントのためのレンダリングを指定するコードをプラットホーム独立のマークアップ言語で発生し、
前記コードを実行してドキュメントをレンダリングする、
ことを含む請求項１に記載の方法。
【請求項６】
前記ドキュメントをレンダリングすることは、ドキュメントの目に見える部分だけをレンダリングすることを含む、請求項１に記載の方法。
【請求項７】
前記方法は、ウェブブラウザ内で遂行される、請求項１に記載の方法。
【請求項８】
前記方法は、ウェブブラウザ内で動作するプラットホーム独立のワード処理アプリケーションにより遂行される、請求項７に記載の方法。
【請求項９】
前記プラットホーム独立のフォントメトリックを得る段階は、
１つ以上の書体及び太さを選択し、
書体及び太さごとに、標準フォントサイズを選択し、
当該グリフのセットを列挙し、
各々の列挙されたグリフ、及び１つ以上の書体に関連した各フォントに対して、フォントのデータに問合せして、グリフのための１つ以上のメトリックを決定する、
ことを含む請求項１に記載の方法。
【請求項１０】
各グリフに対し、前記プラットホーム独立のフォントメトリックは、
グリフのための境界ボックスの水平及び垂直位置、
グリフのための境界ボックスの水平及び垂直サイズ、及び
グリフを描いた後にペンの位置がどれほど水平に及びどれほど垂直に移動するか指定するグリフのための水平及び垂直アドバンス、
を指定する請求項９に記載の方法。
【請求項１１】
各グリフに対して、前記プラットホーム独立のフォントメトリックは、
高さ、太さ及び行間を含むグリフ幾何学情報、
余白、
リガチャ、及び
カーニングペア、
を考慮する請求項１０に記載の方法。
【請求項１２】
前記プラットホーム独立のフォントメトリックは、
ＪａｖａＳｃｒｉｐｔTMオブジェクトノーテーション（ＪＳＯＮ）、又は
ｅＸｔｅｎｓｉｂｌｅマークアップ言語（ＸＭＬ）、
を使用して指定される請求項１に記載の方法。
【請求項１３】
プラットホームとは独立した仕方でドキュメントを植字しそしてレンダリングする装置において、
レイアウトマネージャーであって、
テキストコンテンツ、及び１つ以上のフォントを含む関連スタイル情報を有するドキュメントを得、
前記１つ以上のフォントに対し、ドキュメントのレンダリングにおける個々のキャラクタの位置を決定するのに使用できる情報を含むプラットホーム独立のフォントメトリックを得、及び
前記プラットホーム独立のフォントメトリックを使用して、ドキュメントが行断片及びページへどのように分割されるか決定する、
ように構成されたレイアウトマネージャーと、
ドキュメントをレンダリングする間に前記決定された分割を使用して、行断片及びページへのドキュメントの分割が異なるコンピューティングプラットホームにわたって同じであるようにするよう構成されたレンダラーと、
を備えた装置。
【請求項１４】
前記プラットホーム独立のフォントメトリックを使用して、ドキュメントが行断片及びページへどのように分割されるか決定する間に、前記レイアウトマネージャーは、ドキュメントのレンダリングにおける行断片内の個々のキャラクタの位置を決定するよう構成された、請求項１３に記載の装置。
【請求項１５】
前記レンダラーは、行断片及びページへのドキュメントの前記決定された分割を使用し、そして行断片内の前記決定された位置で個々のキャラクタをレンダリングする高忠実度レンダリングを遂行するよう構成された、請求項１４に記載の装置。
【請求項１６】
前記レンダラーは、行断片及びページへのドキュメントの前記決定された分割を使用する低忠実度レンダリングを遂行するよう構成され、この低忠実度レンダリングは、個々のキャラクタの前記決定された位置を使用せず、むしろ、レンダラーがプラットホーム特有のレンダリングメカニズムを使用して行断片内の個々のキャラクタの位置を決定できるようにする、請求項１４に記載の装置。
【請求項１７】
前記レンダラーは、
ドキュメントのためのレンダリングを指定するコードをプラットホーム独立のマークアップ言語で発生し、
前記コードを実行してドキュメントをレンダリングする、
ように構成された請求項１３に記載の装置。
【請求項１８】
前記レンダラーは、ドキュメントの目に見える部分だけをレンダリングするよう構成された、請求項１３に記載の装置。
【請求項１９】
前記レイアウトマネージャー及びレンダラーは、ウェブブラウザ内に存在する、請求項１３に記載の装置。
【請求項２０】
前記レイアウトマネージャー及びレンダラーは、ウェブブラウザ内で動作するプラットホーム独立のワード処理アプリケーションの一部分である、請求項１９に記載の装置。
【請求項２１】
フォントメトリック発生メカニズムを更に備え、前記プラットホーム独立のフォントメトリックを発生する間に、そのフォントメトリック発生メカニズムは、
１つ以上の書体及び太さを選択し、
書体及び太さごとに、標準フォントサイズを選択し、
当該グリフのセットを列挙し、
各々の列挙されたグリフ、及び１つ以上の書体に関連した各フォントに対して、フォントのデータに問合せして、グリフのための１つ以上のメトリックを決定する、
ように構成された請求項１３に記載の装置。
【請求項２２】
各グリフに対し、前記プラットホーム独立のフォントメトリックは、
グリフのための境界ボックスの水平及び垂直位置、
グリフのための境界ボックスの水平及び垂直サイズ、及び
グリフを描いた後にペンの位置がどれほど水平に及びどれほど垂直に移動するか指定するグリフのための水平及び垂直アドバンス、
を指定する請求項２１に記載の装置。
【請求項２３】
各グリフに対して、前記プラットホーム独立のフォントメトリックは、
高さ、太さ及び行間を含むグリフ幾何学情報、
余白、
リガチャ、及び
カーニングペア、
を考慮する請求項２２に記載の装置。
【請求項２４】
前記プラットホーム独立のフォントメトリックは、
ＪａｖａＳｃｒｉｐｔTMオブジェクトノーテーション（ＪＳＯＮ）、又は
ｅＸｔｅｎｓｉｂｌｅマークアップ言語（ＸＭＬ）、
を使用して指定される請求項１３に記載の装置。
【請求項２５】
プラットホームとは独立した仕方でドキュメントを植字しそしてレンダリングするプラットホーム独立のワードプロセッサにおいて、
テキストコンテンツ、及び１つ以上のフォントを含む関連スタイル情報を有するドキュメントをユーザが編集できるようにするよう構成されたユーザインターフェイスと、
ドキュメントのレンダリングにおける個々のキャラクタの位置を決定するのに使用できる情報を含むプラットホーム独立のフォントメトリックを使用して、ドキュメントが行断片及びページへどのように分割されるか決定するように構成されたレイアウトマネージャーと、
ドキュメントをレンダリングする間に前記決定された分割を使用して、行断片及びページへのドキュメントの分割が異なるコンピューティングプラットホームにわたって同じであるようにするよう構成されたレンダラーと、
を備えたプラットホーム独立のワードプロセッサ。
【請求項２６】
前記プラットホーム独立のフォントメトリックを使用して、ドキュメントが行断片及びページへどのように分割されるか決定する間に、前記レイアウトマネージャーは、ドキュメントのレンダリングにおける行断片内の個々のキャラクタの位置を決定するよう構成された、請求項２５に記載のプラットホーム独立のワードプロセッサ。
【請求項２７】
前記レンダラーは、行断片及びページへのドキュメントの前記決定された分割を使用し、そして行断片内の前記決定された位置で個々のキャラクタをレンダリングする高忠実度レンダリングを遂行するよう構成された、請求項２６に記載のプラットホーム独立のワードプロセッサ。
【請求項２８】
前記レンダラーは、行断片及びページへのドキュメントの前記決定された分割を使用する低忠実度レンダリングを遂行するよう構成され、この低忠実度レンダリングは、個々のキャラクタの前記決定された位置を使用せず、むしろ、レンダラーがプラットホーム特有のレンダリングメカニズムを使用して行断片内の個々のキャラクタの位置を決定できるようにする、請求項２６に記載のプラットホーム独立のワードプロセッサ。
【請求項２９】
前記レンダラーは、
ドキュメントのためのレンダリングを指定するコードをプラットホーム独立のマークアップ言語で発生し、
前記コードを実行してドキュメントをレンダリングする、
ように構成された請求項２５に記載のプラットホーム独立のワードプロセッサ。
【請求項３０】
前記レンダラーは、ドキュメントの目に見える部分だけをレンダリングするよう構成された、請求項２５に記載のプラットホーム独立のワードプロセッサ。
【請求項３１】
前記プラットホーム独立のワードプロセッサは、ウェブブラウザ内で動作するよう構成された、請求項１３に記載のプラットホーム独立のワードプロセッサ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータシステムにおいてドキュメントを植字し及びレンダリングする技術に係る。より詳細には、本発明は、ドキュメントを行及びページに分割することが、異なるコンピュータシステム及びコンピューティングプラットホームにわたって同じであるように保証する、ドキュメントを植字し及びレンダリングするプラットホーム独立技術に係る。
【背景技術】
【０００２】
ウェブブラウザ及びコンピュータネットワークが最近急増したことで異なるコンピューティングプラットホーム上で同じドキュメントを表示することが容易になった。しかしながら、異なるコンピューティングプラットホーム間でフォントをレンダリングする仕方が一致しないことで、異なるコンピューティングプラットホームのユーザにとって同じドキュメントが異なる仕方でレンダリングされる。より詳細には、所与のフォントについて、キャラクタの高さ、巾、行間及び余白のような、種々のフォント特徴のメトリックを解釈する仕方は、コンピューティングプラットホーム間で相違する。これらの解釈の相違は、ドキュメントの個々のキャラクタを異なる位置でレンダリングさせることになり、結局、ドキュメント内のワードを異なるコンピューティングプラットホーム上の行及びページ間で異なる仕方で配置させることになる。
【０００３】
この不一致のレンダリングは、ドキュメント上で協力する人々にとって問題となる。例えば、１人の協力者が特定のページの特定の行のエラーを指摘する場合に、異なるコンピューティングプラットホームで同じドキュメントを見ている別の協力者は、先ず、異なるページの異なる行においてそのエラーの位置を探さねばならない。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
従って、異なるコンピュータシステム及びコンピューティングプラットホームにわたりドキュメントにとって一致したレンダリングを与える技術が要望される。
【課題を解決するための手段】
【０００５】
本発明のある実施形態は、プラットホームとは独立した仕方でドキュメントを植字し、レンダリングするシステムを提供する。オペレーション中に、このシステムは、先ず、ドキュメントを得、ドキュメントは、テキストコンテンツと、１つ以上のフォントを含む関連スタイル情報とを有する。又、システムは、１つ以上のフォントに対してプラットホーム独立のフォントメトリックを発生し、プラットホーム独立のフォントメトリックは、ドキュメントのレンダリングにおける個々のキャラクタの位置を決定するのに使用できる情報を含む。次いで、システムは、プラットホーム独立のフォントメトリックを使用して、ドキュメントが行断片及びページへどのように分割されるか決定する。最終的に、システムは、ドキュメントをレンダリングする間にその決定された分割を使用して、行断片及びページへのドキュメントの分割が異なるコンピューティングプラットホームにわたって同じであるようにする。
【０００６】
ある実施形態では、プラットホーム独立のフォントメトリックを使用して、ドキュメントが行断片及びページにどのように分割されるか決定する間に、システムは、ドキュメントのレンダリングにおける行断片内の個々のキャラクタの位置を決定する。
【０００７】
ある実施形態では、ドキュメントをレンダリングすることは、行断片及びページへのドキュメントの決定された分割を使用し、そして行断片内の決定された位置で個々のキャラクタをレンダリングする高忠実度のレンダリングを遂行することを含む。
【０００８】
ある実施形態では、ドキュメントをレンダリングすることは、行断片及びページへのドキュメントの決定された分割を使用する低忠実度レンダリングを遂行することを含む。しかしながら、高忠実度のレンダリングとは異なり、この低忠実度のレンダリングは、個々のキャラクタの決定された位置を使用せず、むしろ、レンダラーがプラットホーム特有のレンダリングメカニズムを使用して行断片内の個々のキャラクタの位置を決定できるようにする。
【０００９】
ある実施形態では、ドキュメントをレンダリングすることは、先ず、ドキュメントのためのレンダリングを指定するコードをプラットホーム独立のマークアップ言語で発生し、次いで、その発生されたコードを実行してドキュメントをレンダリングすることを含む。
【００１０】
ある実施形態では、ドキュメントをレンダリングすることは、ドキュメントの目に見える部分だけをレンダリングすることを含む。
【００１１】
ある実施形態では、システムは、ウェブブラウザ内で動作する。
【００１２】
ある実施形態では、システムは、ウェブブラウザ内で動作するプラットホーム独立のワード処理アプリケーション内で動作する。
【００１３】
ある実施形態では、プラットホーム独立のフォントメトリックを発生することは、多数のオペレーションを含む。先ず、システムは、１つ以上の書体及び太さ(weight)を選択する。次いで、書体及び太さごとに、システムは、標準フォントサイズを選択する。（所与のフォントサイズに対するメトリックは、この標準フォントサイズからスケーリングすることができる。）次いで、システムは、当該グリフのセットを列挙する。最終的に、各々の列挙されたグリフ、及び１つ以上の書体に関連した各フォントに対して、システムは、フォントのデータに問合せして、グリフのための１つ以上のメトリックを決定する。
【００１４】
ある実施形態では、各グリフに対して、プラットホーム独立のフォントメトリックは、グリフのための境界ボックスの水平及び垂直位置、グリフのための境界ボックスの水平及び垂直サイズ、並びにグリフを描いた後にペンの位置がどれほど水平に及びどれほど垂直に移動するか指定するグリフのための水平及び垂直アドバンス、を指定する。
【００１５】
ある実施形態では、各グリフに対して、プラットホーム独立のフォントメトリックは、高さ、太さ及び行間を含むグリフ幾何学情報、余白、リガチャ、及びカーニングペアを考慮する。
【００１６】
ある実施形態において、プラットホーム独立のフォントメトリックは、ＪａｖａＳｃｒｉｐｔTMオブジェクトノーテーション（ＪＳＯＮ）、又はｅＸｔｅｎｓｉｂｌｅマークアップ言語（ＸＭＬ）を使用して指定される。
【図面の簡単な説明】
【００１７】
【図１】本発明の一実施形態によるコンピューティング環境を示す図である。
【図２】本発明の一実施形態によるレンダリングプロセスを示す図である。
【図３Ａ】本発明の一実施形態によりフォントメトリックを発生するプロセスを示すフローチャートである。
【図３Ｂ】本発明の一実施形態による規範的なフォントメトリックを示す図である。
【図４】本発明の一実施形態によりブラウザベースのアプリケーションをどのように実行するか示すフローチャートである。
【図５】本発明の一実施形態によりドキュメントを行断片及びページにどのように分割するか決定するためにプラットホーム独立のフォントメトリックをどのように使用するか示すフローチャートである。
【図６】本発明の一実施形態によりテキストを低忠実度レンダリングのためにＨＴＭＬへどのようにレンダリングするか示すフローチャートである。
【図７】本発明の一実施形態によりテキストを高忠実度レンダリングのためにＨＴＭＬへどのようにレンダリングするか示すフローチャートである。
【発明を実施するための形態】
【００１８】
以下の説明は、当業者が本発明を実施及び利用できるようにするためのもので、特定の用途及びその要件に関して述べる。ここに開示する実施形態に対する種々の変更が当業者に容易に明らかであろうし、ここに定義する一般的な原理を、本発明の精神及び範囲から逸脱せずに他の実施形態及び用途に適用することができる。従って、本発明は、ここに示す実施形態に制限されず、ここに開示される原理及び特徴に一致する最も広い範囲に従うものである。
【００１９】
この詳細な説明に述べるデータ構造及びコードは、典型的に、コンピュータシステムにより使用するためのコード及び／又はデータを記憶できる装置又は媒体であるコンピュータ読み取り可能な記憶媒体に記憶される。コンピュータ読み取り可能な記憶媒体は、揮発性メモリ、不揮発性メモリ、磁気及び光学記憶装置、例えば、ディスクドライブ、磁気テープ、ＣＤ（コンパクトディスク）、ＤＶＤ（デジタル多様性ディスク又はデジタルビデオディスク）、或いは現在知られている又は今後開発されるコード及び／又はデータ記憶可能な他の媒体を含むが、これらに限定されない。
【００２０】
この詳細な説明の章で述べる方法及びプロセスは、上述したコンピュータ読み取り可能な記憶媒体に記憶できるコード及び／又はデータとして実施することができる。コンピュータシステムは、コンピュータ読み取り可能な記憶媒体に記憶されたコード及び／又はデータを読み取って実行するときに、コンピュータ読み取り可能な記憶媒体内に記憶されたデータ構造及びコードとして実施される方法及びプロセスを遂行する。更に、以下に述べる方法及びプロセスは、ハードウェアモジュールに含ませることもできる。例えば、ハードウェアモジュールは、特定用途向け集積回路（ＡＳＩＣ）チップ、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、及び現在知られている又は今後開発される他のプログラマブルロジック装置を含むが、それらに限定されない。ハードウェアモジュールは、それがアクチベートされたとき、そのハードウェアモジュール内に含まれた方法及びプロセスを遂行する。
【００２１】
コンピューティング環境
図１は、本発明の一実施形態によるコンピューティング環境１００を示す。図１を参照すれば、コンピューティング環境１００は、ユーザ１０２、クライアント１０６、ネットワーク１０８、サーバー１１０及びデータベース１１２を含む。
【００２２】
クライアント１０６及びサーバー１１０は、マイクロプロセッサ、メインフレームコンピュータ、デジタル信号プロセッサ、ポータブルコンピューティング装置、パーソナルオーガナイザ、装置コントローラ、又は機器内の計算エンジンをベースとする任意の形式のコンピュータシステムを含む。更に、クライアント１０６は、計算能力を含むと共に、ネットワーク１０８を横切って通信するためのメカニズムを含むネットワーク上の任意のノードを含む。同様に、サーバー１１０は、一般的に、計算及び／又はデータ記憶リソースに対するクライアントからの要求にサービスするためのメカニズムを含むネットワーク上の任意のノードを含む。
【００２３】
ユーザ１０２は、個人、個人のグループ、組織、組織のグループ、コンピューティングシステム、コンピューティングシステムのグループ、又はコンピューティング環境１００と対話できる他のエンティティを含む。
【００２４】
ネットワーク１０８は、コンピューティングノードを一緒に結合できる任意の形式のワイヤード又はワイヤレス通信チャンネルを含む。これは、ローカルエリアネットワーク、ワイドエリアネットワーク、又はそれらネットワークの組み合わせを含むが、それに限定されない。本発明の１つの実施形態において、ネットワーク１０８は、インターネットを含む。本発明の幾つかの実施形態において、ネットワーク１０８は、電話及びセルラー電話ネットワークを含む。
【００２５】
データベース１１２は、データを不揮発性記憶装置に記憶するための任意の形式のシステムを含む。これは、磁気、光学又は磁気・光学記憶装置をベースとするシステム、並びにフラッシュメモリ及び／又はバッテリバックアップメモリをベースとする記憶装置を含むが、それらに限定されない。データベース１１２は、サーバー１１０に直結することもできるし、或いはネットワークを通してサーバー１１０に結合できることにも注意されたい。
【００２６】
クライアント１０６は、ウェブブラウザ１１４をホストする。ブラウザ１１４は、一般的に、プラットホーム独立のマークアップ言語で指定されるコードを含むウェブページを表示することのできる任意のプログラムを含む。図１に示す実施形態では、ブラウザ１１４は、プラットホーム独立のワードプロセッサ１１６をホストし、これは、ユーザ１０２がドキュメントを編集できるようにする。ドキュメントを編集する間に、プラットホーム独立のワードプロセッサ１１６は、異なるコンピューティングプラットホームにわたって同じ仕方でドキュメントが行断片及びページに分割されるよう保証する。このプラットホーム独立の分割プロセスは、以下に詳細に説明する。
【００２７】
本発明は、ブラウザベースのワード処理システムに関して説明するが、本発明は、プラットホームとは独立した仕方でテキスト情報をレンダリングするシステムに一般的に適用することができ、ワード処理システム又はブラウザベースシステムに限定されるものではない。
【００２８】
レンダリングプロセス
図２は、本発明の一実施形態によるレンダリングプロセスを示す。先ず、ドキュメントを表示することを求めるアプリケーション２０２（例えば、ワードプロセッサ）は、ドキュメントに関連した情報をレイアウトマネージャー２１０へ送信する。この情報は、ドキュメントに対するテキストコンテンツ２０４及びスタイル情報２０６と、アプリケーション２０２に関連したユーザインターフェイスにおいてテキストをどこに表示すべきか指定する幾何学情報２０８とを含む。１つの実施形態において、アプリケーション２０２は、ＪａｖａＳｃｒｉｐｔTMで書かれたウェブベースのワード処理アプリケーションであり、ウェブブラウザ内で実行される。
【００２９】
次いで、レイアウトマネージャー２１０は、植字器２１１へコールを発する。植字器２１１は、コンピューティングプラットホームにローカル記憶されたフォント２１２と、サーバーから得られたプラットホーム独立のフォントメトリック２１３とを使用し、行断片及びページ内にキャラクタを配置する。これは、結局、ドキュメントを行断片及びページへどのように分割するか指定すると共に、ドキュメントのレンダリングにおける各キャラクタの正確な位置も指定するドキュメントのレイアウト２１４を発生する。
【００３０】
次いで、テキストレンダラー２１６がレイアウト情報を使用して、ドキュメントの目に見える部分をレンダリングする。これは、ＨＴＭＬ２１８のようなプラットホーム独立のマークアップ言語で、レンダリングされるドキュメントの表示を発生する。最終的に、ブラウザに関連したレンダリングエンジン２２０は、ＨＴＭＬ２１８をレンダリングして、レンダリングされたテキスト２２２を発生する。このプロセスは、以下に詳細に説明するが、先ず、プラットホーム独立のフォントメトリックをどのように発生するか説明する。
【００３１】
プラットホーム独立のフォントメトリックの発生
図３Ａは、本発明の一実施形態によりプラットホーム独立のフォントメトリックを発生するプロセスを示すフローチャートである。このプロセス中に、各当該フォントに対し、システムは、フォントメトリックを予め計算し、そしてそれをオブジェクトに記憶し、このオブジェクトは、フォントメトリックが必要とされるときにブラウザへダウンロードすることができる。
【００３２】
これらのフォントメトリックを予め計算する間に、システムは、先ず、１つ以上の当該書体及び太さを選択する（ステップ３０２）。（書体とは、スタイリスティックユニティで設計された１つ以上のフォントのセットであることに注意されたい。例えば、「アリアル(Arial)」のような所与の書体は、レギュラー、ボールド及びイタリックフォントを含む。）次いで、各書体及び太さについて、システムは、おそらくレンダリングされる最も大きなフォントサイズの倍数である標準フォントサイズを選択する（ステップ３０４）。トゥルータイプ（オープンタイプ）のような最も一般的なフォントについては、システムは、標準フォントサイズをフォント仕様から直接得ることができる（「ｅｍスクエア当たりのフォントユニット」の数；これは、トゥルータイプフォント使用の一部分で、通常、１０２４又は２０４８に等しく、そして全てのフォント及びグリフメトリックが記述されるアブストラクトスペースを定義する）。次いで、所与のフォントサイズの具体的なメトリックをこの標準フォントサイズからスケーリングすることができる。例えば、標準フォントサイズが１０００であると選択された場合には、標準フォントメトリックに１６／１０００を乗算することにより、１６ｐｔのフォントサイズに対するフォントメトリックを決定することができる。
【００３３】
標準フォントサイズから所与のフォントサイズ（１６ｐｔのような）へフォントメトリックをスケーリングすることは、必ずしも、プラットホーム独立のフォントメトリックを発生するシステムコンポーネントによって遂行されるものではないことに注意されたい。このスケーリングは、スタイルから検索された所与のフォントサイズ（例えば、１６ｐｔ）を使用してテキストのレイアウトを行うとき、クライアント側でブラウザベースのアプリケーションにおいて行うことができる。又、フォントをスケーリングする問題は、一般的に、そのメトリックにファクタを乗算するよりもビットが複雑になることである。この簡単な乗算は、充分に高い解像度及びポイントサイズにしか作用しない。小さなポイントサイズについては、トゥルータイプフォントは、レンダリングされるテキストのクオリティを改善するために幾つかのテーブル及びインストラクションを含む。そのようにする際に、グリフの輪郭を微調整するか、又はそれらをビットマップ等効物に置き換えることが要求される。これらの調整は、レンダリングされるテキストの全体的なレイアウトに影響し、グリフメトリックのみに基づく計算を不適切なものにする。例えば、トゥルータイプフォントは、特定の（通常は小さな）ポイントサイズに対して輪郭グリフに代わって使用すべきグリフのビットマップを含む。システムは、これを考慮し、そしてそれに対応するデータをクライアントへ搬送し、クライアントがブラウザアプリケーションにおいてレイアウトを充分に遂行できるよう保証することができる。
【００３４】
次いで、システムは、フォント太さ、フォントがイタリック体であるかどうか、及び標準フォントサイズにおけるフォントのアセント及びデセントのようなフォント全体の情報をエンコードする（ステップ３０６）。
【００３５】
フォント全体の情報がエンコードされた後に、システムは、当該グリフのセットを列挙する（ステップ３０８）。「グリフ」は、グラフィックユニットであり、一方、「キャラクタ」は、テキストユニットであることに注意されたい。ある場合には、複数のキャラクタが単一のグリフへとマップされる。例えば、リガチャの場合には、隣接する文字“ｆ”及び“ｉ”は、単一のグリフ“ｆｉ”へとマップされる。他のケースでは、単一のキャラクタが複数のグリフより成る。例えば、文字及びそれに関連した区別的マーク、例えば、
2013511088.tif 000003
は、個別のグリフで構成されてもよい。
【００３６】
次いで、列挙された各グリフに対し、システムは、グリフの関連フォントデータに問合せして、グリフのための１つ以上のメトリックを決定する（ステップ３１０）。例えば、システムは、各グリフの境界ボックスを決定するために問合せすることができる。又、システムは、グリフのアドバンスについて、グリフを描いた後にペンの位置をどれほど下方に及び／又は右側に移動すべきか問合せることもできる。システムは、更に、グリフの順序付けされたペア間のカスタム距離を指定するカーニングペアについて問合せすることもできる。例えば、ほとんどのフォントは、シーケンス“ａｗ”についてカーニングペアを指定する。というのは、さもなければ、“ａ”及び“ｗ”が離れ過ぎてレンダリングされるように見えるからである。
【００３７】
それにより得られるフォントメトリックは、図３Ｂに示すように、オブジェクトに記憶することができる。図３Ｂのデータ構造は、先ず、姓、太さ、アセント及びデセントのようなフォント全体情報と、標準フォントサイズ１０００とを指定することに注意されたい。次いで、各グリフに対して、データ構造は、水平及び垂直のアドバンスと、境界ボックスの大きさのパラメータとを指定する。図３Ｂに示すデータ構造は、比較的高いポイントサイズに対して良好に働くが、考えられる全ての拡張性の問題は考慮していない簡単なデータ構造であることに注意されたい。付加的な拡張性の問題（上述した問題のような）は、異なるデータ構造を使用して取り扱うことができる。
【００３８】
ブラウザベースアプリケーションの実行
図４は、本発明の一実施形態によりテキスト情報を表示するブラウザベースのアプリケーションをユーザがどのように実行するか示すフローチャートである。図１を参照すれば、ユーザ１０２は、先ず、アプリケーションを通してドキュメントにアクセスするための要求を、ブラウザ１１４を通して行う（ステップ４０２）。例えば、ユーザ１０２は、ブラウザベースのワード処理アプリケーション１１６を通して特定のドキュメントを編集するように要求することができる。
【００３９】
次いで、その要求に応答して、サーバー１１０は、ドキュメントのコンテンツ、アプリケーションのためのプラットホーム独立のコード、及びプラットホーム独立のフォントメトリックを得て、それらをブラウザへストリーミングする（ステップ４０４）。より詳細には、ドキュメントのコンテンツは、ドキュメントに対するテキスト及びスタイル情報を含むことができる。アプリケーションに対するプラットホーム独立のコードは、ドキュメントのコンテンツを表示しそしてサーバーと通信するためのアプリケーションロジックを実施するＪａｖａＳｃｒｉｐｔTMを含む。又、プラットホーム独立のコードは、ブラウザベースのワード処理システムを実施するコードも含む。プラットホーム独立のフォントメトリックは、ドキュメントのレンダリングにおける個々のキャラクタの位置を決定するのに使用できる予め計算されたフォントメトリック（ＪａｖａＳｃｒｉｐｔオブジェクトノーション（ＪＳＯＮ）で表される）を含むことができる。
【００４０】
次いで、ブラウザ１１４は、サーバー１１０から受け取られた情報をキャッシュする（ステップ４０６）。これは、ブラウザ１１４が、キャッシュされた情報を使用してアプリケーションを実行できるようにする（ステップ４０８）。
【００４１】
プラットホーム独立のフォントメトリックの使用
図５は、本発明の一実施形態によりドキュメントを行断片及びページへどのように分割するか決定するためにプラットホーム独立のフォントメトリックをどのように使用するか示すフローチャートである。ブラウザ１１４がアプリケーションの実行をスタートするときに、アプリケーションは、先ず、テキストコンテンツ２０４、スタイル情報２０６及び幾何学情報２０８をレイアウトマネージャー２１０へ通す（ステップ５０２）。次いで、レイアウトマネージャー２１０は、パラグラフ及びスタイルランを繰り返し、そして植字器２１１への植字コールをバッチ処理する（ステップ５０４）。植字器２１１は、各パラグラフを別々に処理することに注意されたい。というのは、各パラグラフに適用しなければならないパラグラフインデント及び末尾孤立行ルールのような特定パラグラフフォーマットルールがあるからである。各パラグラフ内で、植字器２１１は、同じフォント、サイズ及びスタイルキャラクタを共有する連続キャラクタのセットを含む個々のスタイルランを処理する。
【００４２】
テキストコンテンツ２０４及びスタイル情報２０６のキャラクタに基づいて、植字器２１１は、関連するプラットホーム独立のフォントメトリックをルックアップする（ステップ５０６）。次いで、植字器２１１は、表示されるキャラクタを繰り返し、プラットホーム独立のフォントメトリックを使用して、キャラクタをレンダリング内のどこに配置すべきか決定する（ステップ５０８）。これは、キャラクタのエントリーを有する行断片データ構造を埋めることを含む。例えば、各エントリーは、ユニコードキャラクタ、及びそのキャラクタに対する幾何学的位置を含む。次いで、植字器２１１は、行断片をレイアウトマネージャー２１０へ返送する（ステップ５１０）。レイアウトマネージャー２１０は、キャラクタが存在しなくなるまで又は特定の幾何学的ボックスに適合できる付加的なキャラクタがなくなるまで、前記プロセスを繰り返す。その時点で、レイアウト２１４は、完了となる。
【００４３】
テキストレンダリング
レイアウト２１４が発生されると、システムは、テキストをレンダリングする。これは、行断片及びページへのドキュメントの決定された分割を使用し、そして行断片内の決定された位置で個々のキャラクタをレンダリングする高忠実度テキストレンダリングを通して達成することができる。又、これも行断片及びページへのドキュメントの決定された分割を使用する低忠実度レンダリングを通して達成することもできる。しかしながら、高忠実度レンダリングとは異なり、低忠実度レンダリングは、個々のキャラクタに対する決定された位置を使用せず、むしろ、レンダラーがプラットホーム特有のレンダリングメカニズムを使用して、行断片内の個々のキャラクタの位置を決定できるようにする。
【００４４】
更に、システムは、目に見えるテキストだけをレンダリングすればよい。例えば、ワード処理アプリケーションでは、現在目に見えて編集されているドキュメントの一部分だけをレンダリングすればよい。
【００４５】
図６は、本発明の一実施形態によりテキストを低忠実度テキストレンダリングのためにＨＴＭＬへどのようにレンダリングするか示すフローチャートである。第１に、システムは、テキスト行のために行断片及びスタイルラン情報を得る（ステップ６０２）。次いで、システムは、行断片及びラン情報を使用して、テキスト行を表示するためのＨＴＭＬを発生する（ステップ６０４）。例えば、システムは、次の規範的な擬似ＨＴＭＬスパンタグを使用して、テキスト行を表示することができる。
<Span font=”Times”, font size=12>
“line of text”
</Span>
このプロセスは、目に見える全ての行について繰り返される。システムは、ローカルオペレーティングシステムにおけるフォントシステムのようなローカルプラットホーム特有レンダリングメカニズムを使用して、テキスト行をレンダリングすることに注意されたい。ここで、プラットホーム従属のレンダリングメカニズムは、行断片内の個々のキャラクタの位置を決定し、これらの位置は、レイアウト２１４における予め計算された位置に一致しない。（これは、所与のプラットホーム上に指定のフォントがないときに生じるフォント置き換えの場合に特に言えることである。）しかしながら、ドキュメントを行断片及びページへ分割することは、レイアウト２１４に指定された分割と同じである。
【００４６】
対照的に、図７は、本発明の一実施形態により高忠実度テキストレンダリングを使用してテキストをＨＴＭＬへどのようにレンダリングするか示すフローチャートである。第１に、システムは、テキスト行のために行断片及びスタイルラン情報を得る（ステップ７０２）。次いで、行の各キャラクタについて、システムは、行断片データ構造からキャラクタに対する予め計算された水平及び垂直位置を得る（ステップ７０４）。システムは、次いで、得られた水平及び垂直位置にキャラクタを表示するためにＨＴＭＬを発生する（ステップ７０６）。例えば、システムは、次の規範的な擬似ＨＴＭＬ分割タグを使用して、ｘ位置及びｙ位置で指定される特定位置に単一のキャラクタを表示することができる。
<div font=”Times”, font size=12, position=abs, x=xpos, y=ypos>
“Z”
</div>
このプロセスは、テキスト行における各キャラクタに対して繰り返される。次いで、目に見える別のテキスト行がある場合には、システムは、目に見える次のテキスト行を処理するように進む（ステップ７０８）。
【００４７】
上述した高忠実度及び低忠実度のレンダリング技術を使用するのではなく、システムは、行断片内の決定された位置に（個々のキャラクタではなく）個々のワードをレンダリングする中間忠実度のレンダリング技術も使用できることに注意されたい。
【００４８】
実施形態の以上の説明は、例示のためになされたものである。それらは、余すところのないものでもないし、又、本発明をその開示された形態に限定するものでもない。従って、当業者であれば、多数の変更や修正が明らかであろう。更に、以上の開示は、本発明の説明を限定するものでもない。本発明の範囲は、特許請求の範囲によって限定される。
【符号の説明】
【００４９】
１００：コンピューティング環境
１０２：ユーザ
１０６：クライアント
１０８：ネットワーク
１１０：サーバー
１１２：データベース
１１４：ブラウザ
１１６：プラットホーム独立のワードプロセッサ
２０２：アプリケーション
２０４：テキストコンテンツ
２０６：スタイル情報
２０８：幾何学
２１０：レイアウトマネージャー
２１１：植字器
２１２：フォント
２１３：プラットホーム独立のフォントメトリック
２１４：レイアウト
２１６：テキストレンダラー
２１８：ＨＴＭＬ
２２０：レンダリングエンジン
２２２：レンダリングされたテキスト
【図１】
2013511088.tif 000004
【図２】
2013511088.tif 000005
【図３Ａ】
2013511088.tif 000006
【図３Ｂ】
2013511088.tif 000007
【図４】
2013511088.tif 000008
【図５】
2013511088.tif 000009
【図６】
2013511088.tif 000010
【図７】
2013511088.tif 000011
【手続補正書】
【提出日】平成24年5月15日(2012.5.15)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
プラットホームとは独立した仕方でドキュメントを植字しそしてレンダリングする方法において、
テキストコンテンツ、及び１つ以上のフォントを含む関連スタイル情報を有するドキュメントを得る段階と、
前記１つ以上のフォントに対し、ドキュメントのレンダリングにおける個々のキャラクタの位置を決定するのに使用できる情報を含むプラットホーム独立のフォントメトリックを得る段階と、
前記プラットホーム独立のフォントメトリックを使用して、ドキュメントが行断片及びページへどのように分割されるか決定する段階と、
ドキュメントをレンダリングする間に前記決定された分割を使用して、行断片及びページへのドキュメントの分割が異なるコンピューティングプラットホームにわたって同じであるようにする段階と、
を備えた方法。
【請求項２】
前記プラットホーム独立のフォントメトリックを使用して、ドキュメントが行断片及びページへどのように分割されるか決定する前記段階は、ドキュメントのレンダリングにおける行断片内の個々のキャラクタの位置を決定することを含む、請求項１に記載の方法。
【請求項３】
前記ドキュメントをレンダリングすることは、行断片及びページへのドキュメントの前記決定された分割を使用し、そして行断片内の前記決定された位置で個々のキャラクタをレンダリングする高忠実度レンダリングを遂行することを含む、請求項２に記載の方法。
【請求項４】
前記ドキュメントをレンダリングすることは、行断片及びページへのドキュメントの前記決定された分割を使用する低忠実度レンダリングを遂行することを含み、この低忠実度レンダリングは、個々のキャラクタの前記決定された位置を使用せず、むしろ、レンダラーがプラットホーム特有のレンダリングメカニズムを使用して行断片内の個々のキャラクタの位置を決定できるようにする、請求項２に記載の方法。
【請求項５】
前記ドキュメントをレンダリングすることは、
ドキュメントのためのレンダリングを指定するコードをプラットホーム独立のマークアップ言語で発生し、
前記コードを実行してドキュメントをレンダリングする、
ことを含む請求項１に記載の方法。
【請求項６】
前記プラットホーム独立のフォントメトリックを得る段階は、
１つ以上の書体及び太さを選択し、
書体及び太さごとに、標準フォントサイズを選択し、
当該グリフのセットを列挙し、
各々の列挙されたグリフ、及び１つ以上の書体に関連した各フォントに対して、フォントのデータに問合せして、グリフのための１つ以上のメトリックを決定する、
ことを含む請求項１に記載の方法。
【請求項７】
各グリフに対し、前記プラットホーム独立のフォントメトリックは、
グリフのための境界ボックスの水平及び垂直位置、
グリフのための境界ボックスの水平及び垂直サイズ、及び
グリフを描いた後にペンの位置がどれほど水平に及びどれほど垂直に移動するか指定するグリフのための水平及び垂直アドバンス、
を指定する請求項６に記載の方法。
【請求項８】
各グリフに対して、前記プラットホーム独立のフォントメトリックは、
高さ、太さ及び行間を含むグリフ幾何学情報、
余白、
リガチャ、及び
カーニングペア、
を考慮する請求項７に記載の方法。
【請求項９】
プラットホームとは独立した仕方でドキュメントを植字しそしてレンダリングする装置において、
レイアウトマネージャーであって、
テキストコンテンツ、及び１つ以上のフォントを含む関連スタイル情報を有するドキュメントを得、
前記１つ以上のフォントに対し、ドキュメントのレンダリングにおける個々のキャラクタの位置を決定するのに使用できる情報を含むプラットホーム独立のフォントメトリックを得、及び
前記プラットホーム独立のフォントメトリックを使用して、ドキュメントが行断片及びページへどのように分割されるか決定する、
ように構成されたレイアウトマネージャーと、
ドキュメントをレンダリングする間に前記決定された分割を使用して、行断片及びページへのドキュメントの分割が異なるコンピューティングプラットホームにわたって同じであるようにするよう構成されたレンダラーと、
を備えた装置。
【請求項１０】
前記プラットホーム独立のフォントメトリックを使用して、ドキュメントが行断片及びページへどのように分割されるか決定する間に、前記レイアウトマネージャーは、ドキュメントのレンダリングにおける行断片内の個々のキャラクタの位置を決定するよう構成された、請求項９に記載の装置。
【請求項１１】
前記レンダラーは、行断片及びページへのドキュメントの前記決定された分割を使用し、そして行断片内の前記決定された位置で個々のキャラクタをレンダリングする高忠実度レンダリングを遂行するよう構成された、請求項１０に記載の装置。
【請求項１２】
前記レンダラーは、行断片及びページへのドキュメントの前記決定された分割を使用する低忠実度レンダリングを遂行するよう構成され、この低忠実度レンダリングは、個々のキャラクタの前記決定された位置を使用せず、むしろ、レンダラーがプラットホーム特有のレンダリングメカニズムを使用して行断片内の個々のキャラクタの位置を決定できるようにする、請求項１０に記載の装置。
【請求項１３】
前記レンダラーは、
ドキュメントのためのレンダリングを指定するコードをプラットホーム独立のマークアップ言語で発生し、
前記コードを実行してドキュメントをレンダリングする、
ように構成された請求項９に記載の装置。
【請求項１４】
フォントメトリック発生メカニズムを更に備え、前記プラットホーム独立のフォントメトリックを発生する間に、そのフォントメトリック発生メカニズムは、
１つ以上の書体及び太さを選択し、
書体及び太さごとに、標準フォントサイズを選択し、
当該グリフのセットを列挙し、
各々の列挙されたグリフ、及び１つ以上の書体に関連した各フォントに対して、フォントのデータに問合せして、グリフのための１つ以上のメトリックを決定する、
ように構成された請求項９に記載の装置。
【請求項１５】
各グリフに対し、前記プラットホーム独立のフォントメトリックは、
グリフのための境界ボックスの水平及び垂直位置、
グリフのための境界ボックスの水平及び垂直サイズ、及び
グリフを描いた後にペンの位置がどれほど水平に及びどれほど垂直に移動するか指定するグリフのための水平及び垂直アドバンス、
を指定する請求項１４に記載の装置。
【国際調査報告】
2013511088.tif 000012
2013511088.tif 000013
2013511088.tif 000014