(57)【要約】  ベクトルベースのコードで表されたオブジェクトを検出するために、ベクトルベースの画像の構文解析を行うことによって、ＳＶＧ及びアドビフラッシュで記述されているようなベクトルベースの画像及びドキュメントを等価のビットマップ又は他の非ベクトルベースの画像に変換することが可能となる。個々の検出済みオブジェクトに対して、オブジェクトの別個のビットマップが作成され、次いで、画像がＺ軸のどこに存在しているかに関する情報が保持される。個々のオブジェクトに対して別個のビットマップ画像が作成され、次いで、これら別個のビットマップ画像は上下に層化される。すなわちこれらビットマップ画像のＺ軸座標に基づいて上記ビットマップ画像はＺ軸に沿って配列される。透過的な画像としてビットマップ画像の様々な画像を選択的に描画することによって画像のアニメーションを実現することが可能となる。
2010532513.tif 000002
【特許請求の範囲】
【請求項１】
ベクトルベースのコンピュータ可読言語で記述されたドキュメント内の１以上の画像オブジェクトを、ビットマップベースのコンピュータ可読言語で記述されたドキュメント内の対応する画像オブジェクトに変換する方法であって、
前記ベクトルベースのドキュメント内の１以上のそれぞれのオブジェクトに関連する１以上のオブジェクト識別子を検出するステップと、
前記検出済みの１以上のオブジェクト識別子に対応する前記１以上のオブジェクトのビットマップを生成するステップと、ここで、前記生成されたビットマップは、前記ドキュメントの平面に垂直な軸線に沿った前記ビットマップの位置に関する情報を前記ベクトルベースのドキュメントから保持する
を有することを特徴とする方法。
【請求項２】
前記ビットマップを生成するステップは、前記オブジェクトのバウンディングボックスを決定するステップと、前記バウンディングボックスによって決定される前記ドキュメントの領域のラスタ化を行うステップとを有することを特徴とする請求項１に記載の方法。
【請求項３】
同様の複数のオブジェクト又はそれぞれのオブジェクトに関連づけられた複数のオブジェクト識別子が検出され、
前記複数のオブジェクトのそれぞれのビットマップが生成され、
前記方法は、該複数のオブジェクトのそれぞれの座標に基づいて前記軸線に沿った前記ビットマップの層化するステップをさらに有することを特徴とする請求項１に記載の方法。
【請求項４】
１以上の層化されたビットマップの透過属性を選択するステップをさらに有することを特徴とする請求項３に記載の方法。
【請求項５】
前記ビットマップは、絶対位置決定方式によって前記ビットマップベースの言語で記述された前記ドキュメント内に配置されることを特徴とする請求項１に記載の方法。
【請求項６】
前記軸線に沿った前記ビットマップの位置を明示的にセットするステップをさらに有することを特徴とする請求項１に記載の方法。
【請求項７】
プログラム可能な電子プロセッサ（３００）であって、
ベクトルベースのプロセッサ可読言語で記述されたドキュメントにおいて１以上の画像オブジェクトを、ビットマップベースのプロセッサ可読言語で記述されたドキュメント内の対応する画像オブジェクトに変換する旨の命令を実行するように構成された処理ユニット（３０２）と、
前記処理ユニットによって実行される命令を格納するように構成されたアプリケーションメモリ（３０６）とを有し、
前記処理ユニットは、以下の処理を実行する：
前記ベクトルベースのドキュメント内の１以上のそれぞれのオブジェクトに関連する１以上のオブジェクト識別子を検出するステップと、
前記検出済みの１以上のオブジェクト識別子に対応する前記１以上のオブジェクトのビットマップを生成するステップ、ここで、前記生成されたビットマップは、前記ドキュメントの平面に垂直な軸線に沿った前記ビットマップの位置に関する情報を前記ベクトルベースのドキュメントから保持する
ことを特徴とするプログラム可能な電子プロセッサ。
【請求項８】
前記処理ユニットは、前記オブジェクトのバウンディングボックスを少なくとも決定するように構成され、かつ、前記バウンディングボックスによって決定された前記ドキュメントの領域のラスタ化を行うことを特徴とする請求項７に記載のプログラム可能な電子プロセッサ。
【請求項９】
前記処理ユニットは、複数のビットマップの座標に基づいて前記軸線に沿って該複数のビットマップを層化するようにさらに構成されることを特徴とする請求項７に記載のプログラム可能な電子プロセッサ。
【請求項１０】
前記処理ユニットは、前記層化されたビットマップのうちの少なくとも１つのビットマップの透過属性を選択するようにさらに構成されることを特徴とする請求項９に記載のプログラム可能な電子プロセッサ。
【請求項１１】
絶対位置決定方式によって、前記ビットマップベースの言語で記述された前記ドキュメント内にビットマップを配置するように構成されることを特徴とする請求項７に記載のプログラム可能な電子プロセッサ。
【請求項１２】
前記処理ユニットは、前記ビットマップの所定位置を前記軸線に沿ってセットするように構成されることを特徴とする請求項７に記載のプログラム可能な電子プロセッサ。
【請求項１３】
実行されるとき、ベクトルベースのコンピュータ可読言語で記述されたドキュメント内の１以上の画像オブジェクトをビットマップベースのコンピュータ可読言語で記述されたドキュメント内の対応する画像オブジェクトに変換する請求項１乃至６のいずれか１項に記載の方法を前記コンピュータに実行させる格納済みの命令を有することを特徴とするコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータ及びソフトウェアを用いる画像の描画（rendering)に関し、特に、ベクトルグラフィックス形式のドキュメントをビットマップドキュメントに変換するための装置及びソフトウェアコンポーネントに関する。
【背景技術】
【０００２】
スケーラブルベクトルグラフィック（ＳＶＧ）は、拡張マークアップ言語（ＸＭＬ）に基づくコンピュータ可読言語であり、静的及び動的ベクトルグラフィック画像を表現すために用いられる。ＳＶＧは、画像属性（サイズ、形状、色など）を決定するＸＭＬに準拠するタグを用いて２次元画像を定義することができる。ＳＶＧは２次元ベクトルグラフィック画像の形状だけでなく、ビットマップグラフィック及びテキストも表示することができる。ＳＶＧはベクトルベースのものであり、このことはコンテンツが特定の画面解像度及び画面サイズ用として記述されるのではなく、コンテンツを容易に拡大縮小できることを意味する。ＳＶＧは、Ｗ３Ｃ推奨としてＳＶＧバージョン１．１を採用したワールドワイドウェブコンソーシアム（Ｗ３Ｃ）によって標準化されている。
【０００３】
ハイパーテキストマークアップ言語（ＨＴＭＬ）は、タグを用いて記述される別のコンピュータ可読言語であり、少なくとも、かかる点でＸＭＬに類似している。ＸＨＴＭＬはＸＭＬに準拠するＨＴＭＬのバージョンである。当初から、ＨＴＭＬは、テキストの論理構造を表すように意図されたものであって、ドキュメント及びウェブページのようなコンテンツ内のグラフィックを表すように意図されたものではなかった。画像はＨＴＭＬではビットマップとして表される。見出し、パラグラフなどの物理的表現はＨＴＭＬコードを提供するブラウザによって決定される。時間の経過につれて、ウェブページの視覚的外観に対するさらなる制御がＨＴＭＬに関して望まれるようになった。ウェブ開発者及び他のコンテンツ開発者がテキストの書体、サイズ、重み付け、色をＨＴＭＬページで指定できるようにするフォントタグのようなタグが導入されるようになった。ゼロ幅の境界を持つテーブル要素を用いることによって、ページコンテンツの高度のレイアウトと配置を行うことが可能とはなったが、ＨＴＭＬコードは雑然となり、理解し難いものになった。今日、ＨＴＭＬは、ドキュメントの構造を表すために再び記述されるようになってはいるが、プレゼンテーション関連フォーマットは、（例えばフォント、色、間隔などの）スタイルをウェブページとドキュメントに追加するためのメカニズムであるカスケーディングスタイルシート（ＣＳＳ）に委ねられている。
【０００４】
近年、正規のソフトウェアアプリケーションの振舞いの模倣を試みるウェブページであるウェブアプリケーションが現れてきている。例えば、最新のブラウザは、別のコンピュータ可読言語であるＪａｖａＳｃｒｉｐｔをサポートしていると共に、ＨＴＭＬドキュメントは、ウェブページ上にある画像用コンテンツ要素にアクセスするためのＷ３Ｃ−標準のオブジェクト指向アプリケーションプログラムインタフェース（ＡＰＩ）であるドキュメントオブジェクトモデルを介してオブジェクトとしてアクセス可能である。ＪａｖａＳｃｒｉｐｔは、ウェブアプリケーション（ウェブコンテンツ又はウェブページ）の中に挿入又は組み込まれ、かつ、ウェブページに表示されるプロセッサによって実行可能な多くのタイプの記述ロジックのうちの１つである。
【０００５】
多くの電子通信システム用の仕様を普及させる第３世代パートナプロジェクト（３ＧＰＰ）は、３ＧＰＰリリース５仕様のためのＳＶＧ１．１を採用し、そして、ＳＶＧは、今日画像を生成しかつ表示するためにほぼ１億台のモバイル電話ハンドセット及び他のユーザ機器（ＵＥ）によって用いられている。例えば、ＵＥは現在、上記機器の中に含まれている一般に狭いスクリーン用の画像及び他のダウンロード済みのコンテンツを調整するブラウザアプリケーションを用いてワールドワイドウェブに定常的にアクセスしている。
【０００６】
ＳＶＧ  Ｔｉｎｙの仕様１．２はＳＶＧバージョン１．２用としてＷ３Ｃにより現在開発されているところである。ＳＶＧ  Ｔｉｎｙは特にモバイル通信装置用として設計されたものであるが、典型的には限られたメモリと処理リソースとを有している。ＳＶＧ  Ｔｉｎｙ１．２はリリース６仕様用として３ＧＰＰによっても採用されている。オーディオ及びビデオの完全な制御を含む種々の新たなマルチメディア機能に対するサポートがマイクロＤＯＭ（μＤＯＭ）及びスクリプトと共に含まれている。μＤＯＭとはサブセットのドキュメントオブジェクトモデル（ＤＯＭ）である。ＳＶＧ属性のなかには、多くの種類のアニメーションを可能にするμＤＯＭスクリプトによって操作できるものもある。オブジェクトを追加したり、取り除いたりして、動的コンテンツをページ上に生みだすようにすることが可能である。
【０００７】
特に、ＳＶＧ及び他のベクトルベースの表現によってアニメーションが容易になる。なぜなら、前景オブジェクトによって視野から現在隠されている後景オブジェクトに関する情報が失われていないからである。したがって、異なる画像内の異なる位置に前景オブジェクトを出現させるとき、その異なる位置の画像の中に以前に隠された（単複の）後景オブジェクトを含むことが可能となる。特に、ＳＶＧでは、描画（rendering)の「ペインタモデル」が用いられ、このモデルでは「塗り潰し(paint)」が連続処理で適用される。換言すれば、一連の「塗り潰し」処理を行うことによって電子プロセッサが出力装置やディスプレイ上にオブジェクトを描画することになる。個々の処理によってプロセッサは出力ディスプレイの対応する領域にわたって塗り潰しを行うと共に、塗り潰された領域が以前に塗り潰された領域に重なり合うと、新たな塗り潰しは部分的に又は完全に古い塗り潰しを覆い隠すことになる。
【０００８】
ＨＴＭＬの中に定義されている画像はビットマップであるため、前景オブジェクトによって隠された後景オブジェクトの外観に関する情報は存在しない。この情報不足のために、前景オブジェクトを異なる位置に出現させるとき、プロセッサは以前の後景オブジェクトを描画することが困難となる。
【０００９】
ＳＶＧ又は等価のベクトルベースの画像をビットマップ画像に変換することは簡単ではあるが、そうすることにはいくつかの欠点がある。例えば、動きを示すために画像を変更することは、ひとたび、例えば画像がＳＶＧからビットマップ画像へ変換されてしまった場合、非常に困難となる（不可能でさえある）。上述したように、前景オブジェクトによって隠された後景オブジェクトの外観であって、ＳＶＧ又は他のベクトルベースの表現の中に存在していた外観に関する情報は、ＨＴＭＬ又は他の非ベクトルベースの表現の中には存在していない。さらに、ＳＶＧ  Ｔｉｎｙ１．２がまだ完全には展開されていないという理由のために、ＳＶＧ内の高度のアプリケーションは多くのＵＥによって実行可能ではなく、さらに、すべてのタイプのＵＥにおいてＳＶＧがサポートされているわけではない。
【００１０】
ＳＶＧ及び等価のベクトルベースの画像をビットマップ及び等価の非ベクトルベースの画像に変換できることが望ましい。なぜなら、このことはＳＶＧに源を発するコンテンツの表示及び他のベクトルグラフィックコンテンツをさらに多くのタイプのＵＥ及び他の表示装置上に表示することを可能にするからである。
【発明の概要】
【発明が解決しようとする課題】
【００１１】
ＳＶＧ画像（アプリケーション又はドキュメント）は、ビットマップ画像に変換された複数の主たるコンポーネントに分割され、かつ、対応するＨＴＭＬページに配置され得る。このようにして、ＳＶＧドキュメントのダイナミクスの保持が可能となる。ＤＯＭなどのＳＶＧと共通の機能が同じ方法で行われるように何らかの方法でＨＴＭＬページを構成することが可能である。例えば、ＳＶＧドキュメント内のコンポーネントから得られるＩＤ属性は、対応するＨＴＭＬドキュメント内の同じ変換済みのコンポーネントであってもよい。本発明はＳＶＧとＨＴＭＬ以外のフォーマットに対しても適用可能であると共に、例えば、ＳＶＧからＨＴＭＬへ、並びに、ＨＴＭＬからＳＶＧへの両方向に実施することが可能である。
【課題を解決するための手段】
【００１２】
本発明の諸側面によれば、ベクトルベースのコンピュータ可読言語で記述されたドキュメント内の１以上の画像オブジェクトを、ビットマップベースのコンピュータ可読言語で記述されたドキュメント内の対応する画像オブジェクトに変換する方法が提供される。本方法は、ベクトルベースのドキュメント内の１以上のそれぞれのオブジェクトに関連づけられた１以上のオブジェクト識別子を検出するステップと、検出された１以上のオブジェクト識別子に対応する１以上のオブジェクトのビットマップを生成するステップとを含む。生成されたビットマップは、ドキュメントの平面に垂直な軸線に沿ったビットマップの位置に関する情報をベクトルベースのドキュメントから保持する。
【００１３】
本発明の他の側面によれば、プロセッサが、ベクトルベースのプロセッサ可読言語で記述されたドキュメント内の１以上の画像オブジェクトを、ビットマップベースのプロセッサ可読言語で記述されたドキュメント内の対応する画像オブジェクトに変換する旨の命令を実行するように構成された処理ユニットを含むプログラム可能な電子プロセッサと、処理ユニットによって実行される命令を格納するように構成されたアプリケーションメモリとが提供される。処理ユニットは、次のアクション、すなわち、ベクトルベースのドキュメント内の１以上のそれぞれのオブジェクトに関連づけられた１以上のオブジェクト識別子を検出するステップと、検出された１以上のオブジェクト識別子に対応する１以上のオブジェクトのビットマップを生成するステップとを実行するように構成される。生成されたビットマップは、ドキュメントの平面に垂直な軸線に沿ったビットマップの位置に関する情報をベクトルベースのドキュメントから保持する。
【００１４】
本発明のさらなる諸側面によれば、ベクトルベースのコンピュータ可読言語で記述されたドキュメント内の１以上の画像オブジェクトを、ビットマップベースのコンピュータ可読言語で記述されたドキュメント内の対応する画像オブジェクトに変換する方法を、実行時にコンピュータに実行させる格納済みの命令を有するコンピュータ可読媒体が提供される。
【００１５】
本発明の様々な特徴、目的及び効果は、本発明を実施するための形態を図面と共に読むと明らかとなるであろう。
【図面の簡単な説明】
【００１６】
【図１Ａ】ベクトルベースのフォーマットのドキュメント及び画像をドキュメント及びビットマップフォーマットの画像に変換する方法を示すフローチャートである。
【図１Ｂ】ＨＴＭＬのような非ベクトルベースのフォーマットからＳＶＧのようなベクトルベースのフォーマットへ変換を行う方法を示すフローチャートである。
【図２】変換可能な画像の描画を描く図である。
【図３】ベクトルベースのフォーマットのドキュメント及び画像をビットマップフォーマットのドキュメント及び画像に変換する電子プロセッサのブロック図である。
【図４】例示のモバイル通信装置を描く図である。
【発明を実施するための形態】
【００１７】
本願発明者らは、アドビフラッシュ（Ａｄｏｂｅ  Ｆｌａｓｈ）のようなＳＶＧ又は他のベクトルベースの画像が、オリジナルのＳＶＧコードで表されるオブジェクトを検出するために、描画済みＳＶＧ画像の構文解析を行うことによって（ＨＴＭＬドキュメント用の）等価のビットマップ又は他の非ベクトルベースの画像に変換され得ることを認識した。個々の検出済みオブジェクトに対して、オブジェクトの別個のビットマップが作成され、次いで、画像がＺ軸に沿ってどこに（すなわち、どの塗り潰し層に）存在するかに関する情報が保持される。個々のオブジェクトに対して別個のビットマップ画像が作成され、次いで、別個のビットマップ画像が上下に層化される。すなわちこれら層化されたビットマップ画像はそのＺ軸座標に基づいてＺ軸に沿って配列される。透過的な又は不可視の画像としてビットマップ画像からなる様々な画像を選択的に描画することによって、画像のアニメーションを実現することが可能となる。
【００１８】
当業者であれば透過性と可視性との区別を理解するであろう。ビットマップ画像内の透過性によって、正方形や長方形の形状を持たないオブジェクトの表現が可能になる。例えば、空（すなわち別のビットマップ画像によって表される後景）が光線の間から「見える」「光線」を伴った円として太陽を描くことができる。透過性を用いて、複数のビットマップ画像を上下に積重ねることにより「完全な」画像の構成が可能となる。可視性とは、ビットマップが目に見える形で又は隠された状態で描画されることを意味する用語である。このような可視属性を用いて、例えばオブジェクトがスクリーン上に現れるとき、オブジェクトの属性を変更することが可能となる。例えば、青い円を隠し、それによってディスプレイ上の同じ位置に赤い円が見えるようにすることが可能となる。
【００１９】
オブジェクトを識別できるようにＳＶＧドキュメントにはラベルが付けられる。例えば、画像又はドキュメント内の個々のオブジェクトは、オブジェクト名のような対応するオブジェクト識別子を有し、そして識別子はベクトル形式から作成された抽象化層に存在していると考えることができる。ＤＯＭツリー内のオブジェクトの所在位置を突止めるためには一般に識別子が用いられる。したがって、スクリプト可能に（すなわち記述ロジックによって実行可能に）作成される任意のＳＶＧドキュメントは通常（単複の）好適な識別子を有することになる。ＳＶＧドキュメントは通常インクスケイプ（Inkscape）のような好適な描画ツールによって作成される。インクスケイプとは、ＳＶＧファイル形式を用いるベクトルグラフィックエディタである。インクスケイプに関する情報はインターネット上でｗｗｗ．ｉｎｋｓｃａｐｅ．ｏｒｇから入手可能である。
【００２０】
一般に、オブジェクトとは、ＨＴＭＬで表されるオブジェクトとして表現されるべき、ＳＶＧドキュメント又は他のベクトル・グラフィックドキュメントの明確な部分である。オブジェクトは一体にグループ化された単一の画像要素又は複数の要素であってもよく、このグループはある特定のラベルを有している。したがって、１つの可能性として、ＳＶＧ要素がオブジェクトであることが考えられる。但し、オブジェクトのグループ化も可能であり、このグループ化は好適な描画ツールにより行うことができる。このようなグループ化は、マイクロソフト社の「パワーポイント（PowerPoint)」及び「ワード(Word)」のようなアプリケーションにおける非ＳＶＧ描画オブジェクトのための「グループ」機能を示唆するものである。オブジェクト名は、オブジェクトを表すコンピュータ可読コードで識別子（ＩＤ）属性により好便に表される。上述したように、ＨＴＭＬだけでなくＳＶＧ及び同等の言語によってもＩＤ属性が提供される。
【００２１】
したがって、ドキュメント又はベクトルベースのコードで記述された画像をビットマップコードで記述されたドキュメント又は画像に変換する方法は、フローチャートによって図１Ａに示される次のステップを含んでよい。ステップ１０２において、ＳＶＧ又は他のベクトル・グラフィックドキュメント内のオブジェクト（特に画像オブジェクト）に関連するオブジェクト識別子は、例えばオブジェクト識別子を表すドキュメントＳＶＧコードを走査することによって検出される。このようなオブジェクト検出を実行するために、コンピュータを適切にプログラムしてもよいし、あるいは、必要な画像以外の多くのビットマップ画像が作成されないように、スクリプト開発者がドキュメントをレビューして、「関心対象の」識別子の位置をピンポイントで正確に指定できるようにしてもよい。このオブジェクト検出ステップは、個々の画像要素をグループ化するステップと、（要素の動き又はアニメーションなどの）グループ化された要素の振舞いが様々なグループ化に対応して変化するかどうかを判定するステップとを含んでよい。ＳＶＧドキュメントのすべての主要部分のビットマップ画像を作成することは一般に可能であるが、そうすることは必ずしも実際的であるとは限らない。
【００２２】
オブジェクト識別子の検出時に、ビットマップのような対応するオブジェクトの非ベクトル・グラフィックバージョンが生成される。このバージョンのオブジェクトは、対応する画像がｚ平面のどこに存在しているかに関するベクトルグラフィックコード情報から保持される（ステップ１０４）。オブジェクトのバウンディングボックスを決定し、次いで、当該特定領域をラスタライズしてビットマップに変えることにより好適なビットマップの生成が可能となる。バウンディングボックスとは、一般に、オブジェクト及びその派生オブジェクトを完全に取り囲むオブジェクトの座標系の軸と位置合わせされる一番ぴったりフィットする（tightest-fitting）矩形である。オブジェクトがラスタライズされると、他のすべてのオブジェクトは不可視にされ、それによってこれら他のオブジェクトは上記ビットマップの中に現れなくなる。当業者であれば理解できるように、すべてのオブジェクトの適切なプロセッサのメモリ内にあるＳＶＧドキュメントを描画することによって、ドキュメント内のすべてのオブジェクトのバウンディングボックスが認知されると共に、バウンディングボックスの描画済みコンテンツの簡単な取得に関与するラスタ化がよく知られている。
【００２３】
さらなる検出済みオブジェクトが存在すれば（ステップ１０６のイエス）、反復ステップ１０２及び１０４によって当該オブジェクトの非ベクトル・グラフィックバージョンが生成される。検出済みオブジェクトがそれ以上存在しなければ（ステップ１０６のノー）、ＳＶＧコードで検出された１以上のオブジェクトに対応する１以上の別個のビットマップ画像が、原ＳＶＧドキュメントをＨＴＭＬに変換する際に該画像のそれぞれのｚ平面座標に基づいて上下に層化される（ステップ１０８）。
【００２４】
これらのビットマップは、好適には絶対位置決定方式を用いて、ＳＶＧドキュメントの場合のようにＨＴＭＬドキュメント内の同じ場所に配置される。オブジェクトが現れる順序は２つのドキュメントに関して同じであるため、これらのオブジェクトがＺ軸上に現れる順序、すなわち、ドキュメントのビューイング平面に対して垂直な方向は同じになる。上記とは別に、Ｚ軸上のオブジェクトの位置が明示的に設定されるようにドキュメント用ＨＴＭＬコードを記述することができる。
【００２５】
オプションの追加ステップ１１０として、画像が透過的になるように、１以上のビットマップベースの画像の透過属性が選択される。この結果、変換済みの画像が非ベクトル・グラフィックフォーマットを有しているにもかかわらず、この画像を容易にアニメーション化することが可能となる。当業者であれば理解できるように、例えばプログラム可能な電子プロセッサのコンポーネントを用いるためにステップ１０２〜１０６の順序を変更してもよい。
【００２６】
ＳＶＧドキュメント及び他のベクトルベースのドキュメントは埋め込まれた画像をサポートする。そのため、ＨＴＭＬのような非ベクトルベースのフォーマットから、ＳＶＧのようなベクトルベースのフォーマットへの変換が行われる逆方向の方法は簡単である。但し、これらのベクトル表現が非ベクトルベースの元のベクトル表現の中に含まれていないのでオブジェクトのベクトル表現を利用することはできない。
【００２７】
図１Ｂは例示の逆方向の方法を示すフローチャートであり、この図では、ステップ１２２において、ＨＴＭＬで表されるビットマップ画像に関連づけられた１以上のオブジェクト識別子が、例えばオブジェクト識別子用のＨＴＭＬコードを走査することによって検出される。ステップ１２４において、検出済みのビットマップ画像が該画像のそれぞれの座標でＳＶＧドキュメントの中に埋め込まれる。別の検出オブジェクトが存在すれば（ステップ１２６のイエス）、当該オブジェクトのビットマップは反復ステップ１２２及び１２４によってＳＶＧドキュメントの中に埋め込まれる。検出済みオブジェクトがそれ以上存在しなくなれば（ステップ１２６のノー）、ドキュメントの変換は完了し、処理フローは他のタスクを続行する（ステップ１２８）。
【００２８】
図２は、正方形によって覆われる黒塗りの青色の円を含む画像オブジェクトの描画である。（特許出願書式の制限に起因して図２の円は図を明瞭にするために曖昧にされず、黒になっている。）図２に描かれている画像オブジェクトはＳＶＧで以下のように記述することができる：
<svg>
<circle cx="100" cy="50" r="30" style="fill:blue"/> 
</svg>
そして、このＳＶＧコードでは、ｅｘ、ｃｙ、ｒの動画化は可能ではあるが引き継ぐことはできないＳＶＧ属性として認識される。すなわち、属性ｅｘ、ｃｙ（円の中心の座標）、ｒ（円の半径）を記述することは可能であるが、これらの属性をＨＴＭＬドキュメントへ直接引き継ぐことは不可能である。円の半径や色のような他の属性を変えるためには、２つの（またはそれ以上の）円が作成され、１つの円は目に見える状態にされ、同時に１つの円（またはそれ以上の円）は隠された状態にされる。
【００２９】
当業者であれば理解できるように、明確なＺ軸座標はＳＶＧでは存在せず、ドキュメント内の要素の順序によって要素のＺ軸位置が決定されることになる。ｚ座標が指定されていない場合、上記はＨＴＭＬの場合にもあてはまることである。ＨＴＭＬドキュメントにおいて、これらの要素を別の何らかの順序で配置することを選択した場合、ＳＶＧドキュメント内のｚ位置が追跡され、例えばこれらのｚ位置を好適なメモリに格納することによって、ｚ座標をＨＴＭＬドキュメントに適宜セットすることが可能となる。
【００３０】
図２に描かれている画像オブジェクトはＨＴＭＬでは以下のように記述することができる：
<html>
<div style= "position: absolute ; left : 70px; top: 20px;">
<img src="bluecircle.png">
</div> 
</html>
ＳＶＧのような言語で表される単一のＤＯＭコマンドを用いて、図２のカバー用正方形を削除し、円を可視にすることが可能となる。例えば、上述のようなラスタによって、図２の画像が典型的なビットマップに変換された場合、円はもはや画像内の別個のオブジェクトとしては提示されなくなる。換言すれば、典型的ビットマップは単一層のみを有することになる。
【００３１】
上述のように、ＳＶＧ画像（ドキュメント）は複数のさらに小さな画像に変換される。この変換は個々のＳＶＧオブジェクトを表す１つの画像を用いて実行可能であるか、ＳＶＧオブジェクトのグループ化を行うことが可能である。上述した変換及びその他のステップは１以上のスクリプトにより容易に実行可能である。これらのスクリプトは好適にはＳＶＧ及びＨＴＭＬに共通のものであることが望ましい。すなわち、位置、名称などに対する参照のみがスクリプトで用いられる
本発明を用いて、同じ（又は非常に類似した）外見及び機能の達成が同じクライアントの２以上のバージョンにおいて可能となる。本発明は、異なるバージョンが例えばＤＯＭ  ＡＰＩなどを有するという共通ＡＰＩの利点を利用するものである。これによって共通スクリプトの利用が可能となる。スクリプトとＨＴＭＬ  ＤＯＭとの組み合わせは、アニメーション、対話機能、及び表現効果のために利用できる「動的ＨＴＭＬ」と呼ぶことができる。
【００３２】
このような変換方法は多くのプログラム可能な電子プロセッサによって好適に実行することが可能である。図３は上述した方法を実行できる適切なプロセッサ３００のブロック図である。プロセッサ３００は処理ユニット３０２を含み、この処理ユニット３０２は１又は２以上のソフトウェアモジュール及びアプリケーションを実行し、本願において説明する方法を実行する。キーボード又は他の装置を介してプロセッサ３００へのユーザ入力が提供され、ユーザに対してディスプレイ３０４に情報を示すことができる。キーボード／ディスプレイ３０４はオプションと見なされ、したがって破線によって示されている。これは上述した方法のなかにはユーザの対話処理を必要としないで実行できるものもあるという理由による。上記方法を定義するソフトウェア命令は好適なアプリケーションメモリ３０６に保存できると共に、プロセッサは所望情報のダウンロードとキャッシュの少なくともいずれかを好適なメモリ３０８において実行することも可能である。プロセッサ３００は、他のプロセッサ、通信装置などのような別のコンポーネントをプロセッサ３００と接続するために用いることができるインタフェース３１０を含んでもよい。
【００３３】
図４はプロセッサ３００を含んでよいモバイル電話機のようなＵＥ４００を描く図である。ＵＥ４００は、ジョイスティック又は他のナビゲーション装置４１０及びディスプレイ４２０を含んでもよい。ウェブブラウザアプリケーション４３０はユーザ機器４００においてプロセッサ３００により実行することができる（図４には図示せず）。ウェブアプリケーション４４０はダウンロードされることができると共に、ブラウザ４３０内において実行されることができる。ウェブアプリケーションはユーザには不可視な１組のリンク４４３又はディスプレイ４２０上で閲覧可能にすることができるアプリケーションを含んでもよい。ウェブアプリケーション４４０は、本願に記載の方法を実行するためのスクリプト用ロジック４４５を含むこともできる。
【００３４】
当業者であれば理解できるように、本願は、ＳＶＧ及びＨＴＭＬに焦点を当てるものである。これらＳＶＧとＨＴＭＬの双方は、ＨＴＭＬよりもさらに自由度の高いＳＶＧを有するマークアップ言語であると共に、このマークアップ言語は単に便宜を図るためのものであって、本発明を限定するためのものではない。マークアップ言語間においてドキュメントを変換するための従来の技術は典型的には、マークアップ（コード）を変換するステップを含むものである。このような従来の技術の一例として拡張可能なスタイルシート言語変換（ＸＳＬＴ）があり、これはＸＭＬ文書を他のＸＭＬや他のドキュメントに変換するために用いることができるＷ３ＣＸＭＬベースの言語である。逆に、本願に基づく技術は、ディスプレイ上に表示されている（又は表示されるべき）特筆すべきスクリプト可能な／動画化可能な属性を保持する技術である。この技術は、ＳＶＧ要素のグループ化を行い、それによって１ビットマップ画像又は（オブジェクトがスクリーン上に現れる際の）オブジェクトが、変換済み（ＨＴＭＬ）ドキュメントのスクリプト化／動画化を行う所望の方法に応じて、積層された（グループ化された）（透過的な）ビットマップ層から構成される等価の画像に要素を変換するステップを含むことができる。
【００３５】
例えば、時と共に変化するドキュメントあるいは別様に変動するドキュメントに対応するために、上述の手続が必要に応じて繰り返し実行される、ということは了解されるであろう。変換方法はオフラインで実行することができるが、これらの変換方法は、例えばウェブブラウザリンク上でのユーザのクリックに応答してモバイル電話機や他のＵＥなどにおいてリアルタイムで実行することも可能である。理解を簡単にするために、プログラム可能なコンピュータシステムのコンポーネントが実行できる行為のシーケンスなどに関して本発明の多くの側面を説明した。専用回路（例えば専用機能を実行するように相互接続された離散論理ゲートや特定用途向け集積回路）、１又は２以上のプロセッサが実行するプログラム命令、又はこれらの組合せによって様々な行為が、実行可能であることは認識されるであろう。
【００３６】
さらに、適当な命令セット（この命令セットは、コンピュータ・ベースのシステム、プロセッサ内蔵システム、または媒体から命令をフェッチしてその命令を実行できるその他のシステムなどの命令実行システム、装置又はデバイスによって、またはこれらと結合して使用される）を格納した任意の形式のコンピュータ可読記憶媒体内において、本発明は、完全に具体化されるものであるとさらに考えることができる。本明細書での使用では、「コンピュータ可読媒体」とは、命令実行システム、装置、またはデバイスによって、またはそれと結合して使用するための、プログラムを装備、格納、通信、伝搬または転送できる任意の手段であってよい。コンピュータ可読媒体は、例えば、電子的、磁気的、光学的、電磁的、赤外線、半導体のシステム、機器、装置、伝播媒体であってもよいが、これらに限定されない。コンピュータ可読媒体のより詳細な例（網羅的なリストではないが）は、１つ以上の結線を含む電気的な接続、可搬型コンピュータ・ディスケット、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、消去可能でプログラム可能な読み出し専用メモリ（ＥＰＲＯＭまたはフラッシュメモリ）、及び光ファイバを含む。
【００３７】
以上に述べたように、本発明は、多くの異なる形式（必ずしもその全てについて上記では説明されてはいないが）で具体化されてもよく、全てのそのような形式は本発明の範囲に含まれると思量するものである。本発明の多様な形態の各々について、任意のそのような形式は、説明の動作を実行する「ように構成された論理」、または別案として、説明の動作を実行する「ところの論理」と呼ばれてもよい。
【００３８】
用語「含む」及び「備える」は、本出願での使用では、述べられた特徴、整数、工程、またはコンポーネントが存在することを指定するものであり、その他の１つ以上の特徴、整数、工程、コンポーネントまたはそれらのグループの存在または付加を排除するものではないことに重々留意されたい。
【００３９】
以上で説明した個々の実施形態は、単に説明のためのものであって、いかなる手法であれ本発明を限定するものとは考えないようにされたい。本発明の範囲は、添付の特許の範囲によって決定されるものであり、特許の範囲に帰着する全ての派生形態及び等価案は本発明に包含されることを意図するものである。
【図１Ａ】
2010532513.tif 000003
【図１Ｂ】
2010532513.tif 000004
【図２】
2010532513.tif 000005
【図３】
2010532513.tif 000006
【図４】
2010532513.tif 000007
【手続補正書】
【提出日】平成21年6月15日(2009.6.15)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】０００９
【補正方法】変更
【補正の内容】
【０００９】
ＳＶＧ又は等価のベクトルベースの画像をビットマップ画像に変換することは簡単ではあるが、そうすることにはいくつかの欠点がある。例えば、動きを示すために画像を変更することは、ひとたび、例えば画像がＳＶＧからビットマップ画像へ変換されてしまった場合、非常に困難となる（不可能でさえある）。上述したように、前景オブジェクトによって隠された後景オブジェクトの外観であって、ＳＶＧ又は他のベクトルベースの表現の中に存在していた外観に関する情報は、ＨＴＭＬ又は他の非ベクトルベースの表現の中には存在していない。さらに、ＳＶＧ  Ｔｉｎｙ１．２がまだ完全には展開されていないという理由のために、ＳＶＧ内の高度のアプリケーションは多くのＵＥによって実行可能ではなく、さらに、すべてのタイプのＵＥにおいてＳＶＧがサポートされているわけではない。
米国特許公開番号ＵＳ２００３／０２２２８８３Ａ１は、混合メディアストリームに応じ、演算処理量を最小限にして、プレゼンテーションワークステーションにて混合メディアを描画する方法及びシステムの記載を開示している。木構造(tree structure)は、ノードを含んでいる。個々のノードはサブ木へのポイントとなりえ、且つ、それぞれは幾何学的なオブジェクト、幾何学的なオブジェクトに適用する変換、又は、時間変化に表現を指示する。シーンは、そのシーン中の各要素のノードを含む。また、これらとは別に、例えばテクスチャや形状のような、これら要素の外観を記述するものでも良い。ルートノードは、シーンの各オブジェクトの記述をつなぐ。演算量の最適化は、木のノードの選択の工程と、各サブ木を如何にして描画するかの演算工程を含む。可能であれば、情報の描画は、ユーザに見せることになるオブジェクトの部分についてのみ演算されることである。
Ｄｉ  ｌｏｒｉｏ，Ａ．等による“ベクトルグラフィックスにおけるＸＭＬベースの言語間の動的変換(Dynamic Ccnversion between XML-Based languages for Vector Graphics)”, Internet Imaging VII, Proc. SPIE-IS&T Electronic Imaging, SPIE vol. 6061, pp. 60610N-1 thru 60610N-9, 18 January 2006 には、２つのベクトルフォーマットであるＳＶＧ及びＶＭＬと、ラスターフォーマットであるＧＩＦとの間の変換を、簡単に、しかも、自動的、無理なく良好に行うツールが記載されている。このツールは、変換ルール、近似性及び経験則を適用させることで、異なる機能性及び表現性で言語間の良好な変換を行っている。
【手続補正２】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ベクトルベースのコンピュータ可読言語で記述されたドキュメント内の１以上の画像オブジェクトを、ビットマップベースのコンピュータ可読言語で記述されたドキュメント内の対応する画像オブジェクトに変換する方法であって、
前記ベクトルベースのドキュメント内の１以上のそれぞれのオブジェクトに関連する１以上のオブジェクト識別子を検出するステップと、
前記検出済みの１以上のオブジェクト識別子に対応する前記１以上のオブジェクトのビットマップを生成するステップと、ここで、前記生成されたビットマップは、前記ドキュメントの平面に垂直な軸線に沿った前記ビットマップの位置に関する情報を前記ベクトルベースのドキュメントから保持し、前記情報は前記軸に沿ったオブジェクトの位置を決定するベクトルベースドキュメント内のオブジェクトの順序を含む
を有することを特徴とする方法。
【請求項２】
前記ビットマップを生成するステップは、前記オブジェクトのバウンディングボックスを決定するステップと、前記バウンディングボックスによって決定される前記ドキュメントの領域のラスタ化を行うステップとを有することを特徴とする請求項１に記載の方法。
【請求項３】
同様の複数のオブジェクト又はそれぞれのオブジェクトに関連づけられた複数のオブジェクト識別子が検出され、
前記複数のオブジェクトのそれぞれのビットマップが生成され、
前記方法は、該複数のオブジェクトのそれぞれの座標に基づいて前記軸線に沿った前記ビットマップの層化するステップをさらに有することを特徴とする請求項１に記載の方法。
【請求項４】
１以上の層化されたビットマップの透過属性を選択するステップをさらに有することを特徴とする請求項３に記載の方法。
【請求項５】
前記ビットマップは、絶対位置決定方式によって前記ビットマップベースの言語で記述された前記ドキュメント内に配置されることを特徴とする請求項１に記載の方法。
【請求項６】
前記軸線に沿った前記ビットマップの位置を明示的にセットするステップをさらに有することを特徴とする請求項１に記載の方法。
【請求項７】
プログラム可能な電子プロセッサ（３００）であって、
ベクトルベースのプロセッサ可読言語で記述されたドキュメントにおいて１以上の画像オブジェクトを、ビットマップベースのプロセッサ可読言語で記述されたドキュメント内の対応する画像オブジェクトに変換する旨の命令を実行するように構成された処理ユニット（３０２）と、
前記処理ユニットによって実行される命令を格納するように構成されたアプリケーションメモリ（３０６）とを有し、
前記処理ユニットは、以下の処理を実行する：
前記ベクトルベースのドキュメント内の１以上のそれぞれのオブジェクトに関連する１以上のオブジェクト識別子を検出するステップと、
前記検出済みの１以上のオブジェクト識別子に対応する前記１以上のオブジェクトのビットマップを生成するステップ、ここで、前記生成されたビットマップは、前記ドキュメントの平面に垂直な軸線に沿った前記ビットマップの位置に関する情報を前記ベクトルベースのドキュメントから保持し、前記情報は前記軸に沿ったオブジェクトの位置を決定するベクトルベースドキュメント内のオブジェクトの順序を含む
ことを特徴とするプログラム可能な電子プロセッサ。
【請求項８】
前記処理ユニットは、前記オブジェクトのバウンディングボックスを少なくとも決定するように構成され、かつ、前記バウンディングボックスによって決定された前記ドキュメントの領域のラスタ化を行うことを特徴とする請求項７に記載のプログラム可能な電子プロセッサ。
【請求項９】
前記処理ユニットは、複数のビットマップの座標に基づいて前記軸線に沿って該複数のビットマップを層化するようにさらに構成されることを特徴とする請求項７に記載のプログラム可能な電子プロセッサ。
【請求項１０】
前記処理ユニットは、前記層化されたビットマップのうちの少なくとも１つのビットマップの透過属性を選択するようにさらに構成されることを特徴とする請求項９に記載のプログラム可能な電子プロセッサ。
【請求項１１】
絶対位置決定方式によって、前記ビットマップベースの言語で記述された前記ドキュメント内にビットマップを配置するように構成されることを特徴とする請求項７に記載のプログラム可能な電子プロセッサ。
【請求項１２】
前記処理ユニットは、前記ビットマップの所定位置を前記軸線に沿ってセットするように構成されることを特徴とする請求項７に記載のプログラム可能な電子プロセッサ。
【請求項１３】
実行されるとき、ベクトルベースのコンピュータ可読言語で記述されたドキュメント内の１以上の画像オブジェクトをビットマップベースのコンピュータ可読言語で記述されたドキュメント内の対応する画像オブジェクトに変換する請求項１乃至６のいずれか１項に記載の方法を前記コンピュータに実行させる格納済みの命令を有することを特徴とするコンピュータ可読媒体。
【国際調査報告】
2010532513.tif 000008
2010532513.tif 000009
2010532513.tif 000010