JP6799396B2 - 情報処理装置、情報処理方法およびプログラム - Google Patents

Description

本発明は、レンダリングを実行可能な情報処理装置、情報処理方法およびプログラムに関する。

近年、カメラ機能が搭載された可搬型多機能携帯端末（以下、モバイルコンピュータ）が普及している。このようなモバイルコンピュータは、基本的には３つの要素で成り立っている。即ち、コンピュータ自身であるハードウェアと、該ハードウェア上で動作するオペレーティングシステム（以下、ＯＳ）と、ＯＳ上で動作するアプリケーションである。ユーザは、アプリケーションを用いて、地図やメール、インターネット上のウェブサイトの閲覧等、の機能を使用することが可能である。

このようなモバイルコンピュータ上で動作するアプリケーションの形態としては、主に２つのものが存在する。即ち、ネイティブアプリケーションとウェブアプリケーションである。以下、それぞれの特徴を説明する。

ネイティブアプリケーションは、通常、ＯＳ毎に用意される開発環境、及び開発言語を用いて開発される。例えば、Ａ社が提供するＯＳ上ではＣ／Ｃ＋＋言語、Ｂ社が提供するＯＳ上ではＪａｖａ（登録商標）言語、Ｃ社が提供するＯＳ上では更に異なる開発言語が用いられて開発される。通常、ネイティブアプリケーションは、各開発環境において予めコンパイルされ、人間が理解可能ないわゆる高水準言語から、コンピュータのＣＰＵが解釈可能なアセンブラ等の命令セット群に変換される。このように、通常のネイティブアプリケーションでは、命令をＣＰＵが直接解釈するために、高速動作が可能である、という特徴がある。

ウェブアプリケーションは、各コンピュータ上のＯＳに標準的に組み込まれているウェブブラウザ上で動作するアプリケーションである。ウェブアプリケーションは、ウェブブラウザが解釈できるよう、一般的には、ＨＴＭＬ５及びＣＳＳ、さらにＪａｖａＳｃｒｉｐｔ（登録商標）等の言語を用いて開発される。これらはウェブ標準言語であるため、これらのウェブ標準言語でウェブアプリケーションを一旦記述すれば、ウェブブラウザが動作する環境であれば、どこでも動作可能という特徴がある。

近年、ネイティブアプリケーションとウェブアプリケーションの利点を双方保持した、ハイブリッドアプリケーションの形態が注目されている。ハイブリッドアプリケーションでは、そのユーザインタフェース（ＵＩ）の全て、あるいは大部分が、ＨＴＭＬ５、ＣＳＳ３、ＪａｖａＳｃｒｉｐｔといったウェブの標準言語で記述される。また、ウェブ標準言語で記述された内容から、ネイティブ言語で記述された機能を利用することができる。即ち、１つのアプリケーション内部に、ウェブ標準言語によるスクリプト層とネイティブ層とを包含する構成となっている。このような構成により、上記のネイティブアプリケーションとウェブアプリケーションの利点を双方保持したソフトウェア構成とすることができる。

また、印刷コンテンツを印刷するためには、プリンタの印刷エンジンが要求する、一般的には高解像度画像データ（いわゆるビットマップデータ）へ変換する必要がある。この処理をレンダリング処理と呼ぶ。

特許文献１では、ＯＳが、データを一時的に記憶するメモリ領域であるクリップボードに記憶された印刷対象データから印刷データを生成することが記載されている。

特開２０１３−１３７６２２号公報

ハイブリッドアプリケーションの場合、このような印刷コンテンツの描画も、ウェブ標準言語を用いて記述することになる。例えばＨＴＭＬ５のＳＶＧ（Ｓｃａｌａｂｌｅ Ｖｅｃｔｏｒ Ｇｒａｐｈｉｃｓ）で上記のような印刷コンテンツを生成する。ここで、ＳＶＧとは、Ｗｅｂ標準言語で利用可能な、グラフィックを表示するための記述方法の一つである。

上記印刷コンテンツをビットマップデータに変換するために、ハイブリッドアプリケーションにおいては、オフスクリーンの画面にＳＶＧを生成するとする。そして、例えば特許文献１のように、ＯＳが印刷対象の印刷データを生成するとする。

しかしながら、その構成は、キャプチャ（画像データの取得）に関するミスが発生してしまう可能性を含んでいる。各ＯＳは、ＳＶＧの読み込みが完了すると、ＯＳ固有の読み込み完了通知を発行する。しかしながら、ＯＳの提供する読み込み完了通知が、ＳＶＧデータを読み込み終わったという通知である場合、ＳＶＧの内容を画面に描画完了したというタイミングとは異なる。そのため、該通知があったタイミングまたは該通知の直後のタイミングでは、ＯＳが該通知に対応する読み込みで読み込まれたＳＶＧデータについて、描画が完了していないことがある。この場合、ＯＳが描画を行ったデータが書き込まれるメモリ領域においては、該通知に応じてキャプチャを行うべきデータとは異なるデータが格納されている。そのため、このタイミングにキャプチャを行ってしまうと、本来キャプチャを行うべきデータとは異なるデータを出力対象としてキャプチャしてしまう。

本発明の目的は、このような従来の問題点を解決することにある。上記の点に鑑み、本発明は、ハイブリッドアプリケーションが通知に応じて描画データを取得する構成において、該通知が描画の完了に関わらず行われたとしても、該データを印刷対象とするか適切に判定することができる情報処理装置、情報処理方法およびプログラムを提供することを目的とする。

上記課題を解決するため、本発明に係るプログラムは、所定の描画処理を実行する描画部を備えるコンピュータを、印刷対象のコンテンツと所定の要素との描画を前記描画部に指示する指示手段、前記指示手段による指示に対応し且つ前記指示に対する描画の完了に関わらず行われた前記描画部からの通知に基づいて、描画が行われたデータを前記描画部から取得する取得手段、前記取得手段により取得されたデータに基づく印刷を印刷装置に実行させる制御手段、として機能させ、前記取得手段によりデータが取得され且つ当該データに前記所定の要素が含まれる場合、前記制御手段は、当該取得されたデータに基づいて、前記印刷対象のコンテンツの印刷を実行させ、前記取得手段によりデータが取得され且つ当該データに前記所定の要素が含まれない場合、前記取得手段が前記描画部から再度データを取得し、前記制御手段は、前記取得手段により再度取得され且つ前記所定の要素を含む当該データに基づいて、前記印刷対象のコンテンツの印刷を実行させる、ことを特徴とする。

本発明によれば、ハイブリッドアプリケーションが通知に応じて描画データを取得する構成において、該通知が描画の完了に関わらず行われたとしても、該データを印刷対象とするか適切に判定することができる。

情報処理装置のハードウェア構成を示す図である。 情報処理装置のソフトウェア構成を示す図である。 写真画像の印刷処理を示すフローチャートである。 写真画像選択の処理を示すフローチャートである。 画像処理を示すフローチャートである。 スタンプ追加の処理を示すフローチャートである。 プリンタ設定の処理を示すフローチャートである。 レンダリング及びプリントの処理を示すフローチャートである。 アプリケーション画面を示す図である。 印刷設定画面を示す図である。 分割が行われたブロック画像を示す図である。 バンド単位で分割された画像を取得する様子を示す図である。 マーカーを追加した様子を示す図である。 レンダリング及びプリントの処理を示すフローチャートである。 縁ありの場合と縁なしの場合を示す図である。 縁なし印刷における印刷領域を示す図である。 レンダリング及びプリントの処理を示すフローチャートである。 ＳＶＧコンテンツを示す図である。 ＳＶＧコンテンツを示す図である。

以下、添付図面を参照して本発明の実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る本発明を限定するものでなく、また本実施形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。なお、同一の構成要素には同一の参照番号を付して、説明を省略する。

本実施形態では、ハイブリッドアプリケーションにおける写真印刷アプリケーションに関して記載する。例えば該写真印刷アプリケーションのＵＩ上で、印刷対象となる写真を描画し、絵文字などのスタンプを重畳し、その結果をユーザがプリンタにプリントさせる。ハイブリッドアプリケーションの場合、このような印刷コンテンツの描画も、ウェブ標準言語を用いて記述することになる。例えばＳＶＧで上記のような印刷コンテンツを生成する場合、まず写真を選択し、その上にテキストやスタンプを重畳していくことになる。

上記のような、「写真追加」、「スタンプ追加」を実行した後のＳＶＧの一例として、下記のような記述がある。
＜svg width=”印刷コンテンツの横幅” height=”印刷コンテンツの縦幅”＞
＜image xlink:href=”画像ファイルの指定”
width=”写真の横幅”
height=”写真の縦幅”
x=”写真のx座標”
y=”写真のy座標”/＞
＜image
xlink:href=”スタンプファイルの指定”
width=”写真の横幅”
height=”写真の縦幅”

x=”スタンプのx座標”
y=”スタンプのy座標”/＞
＜/svg＞
上記のように、ＳＶＧは、グラフィックの描画コマンドが列挙された文字列であり、これがインタプリタで解釈されることにより、ＵＩに表示される。上記の印刷コンテンツを印刷するためには、プリンタの印刷エンジンが要求する、一般的には高解像度画像データ（いわゆるビットマップデータ）へ変換する必要がある。

しかしながら、ＯＳの提供する読み込み完了通知が、ＳＶＧデータを読み込み終わったという通知である場合、本来キャプチャすべきデータとは異なるデータがキャプチャされてしまうことがある。

そこで、タイマー機能を利用し、一定時間の経過後にキャプチャするという方法も考えられる。ただ、どのタイミングで描画が完了するかはデバイス性能に依存し、差がある。そのため、タイマー機能を利用するのであれば、十分に長い時間を設定しなくてはならず、ユーザビリティを著しく低下させてしまう。また、タイマー機能により待機するだけでは、キャプチャの不確実性は解消されていないので、本質的に上記の課題を解決していない。

本実施形態では、ＯＳからのＳＶＧデータのロード完了通知をハイブリッドアプリケーションが受け取った場合に、描画済みデータに所定の要素が含まれるか判定することで、該データを出力対象（例えば印刷対象）とするか否かを決定する技術について、以下詳細に説明する。

［第１の実施形態］
以下、携帯型情報端末上で、本実施形態におけるハイブリッド型写真印刷アプリケーション（後述）を動作させ、ユーザが選択した画像に対して、様々な画像処理を適用した後に、プリントコンテンツを印刷する手順について説明する。

［ハードウェア構成］
図１は、本実施形態の情報処理装置１１５として、例えば、スマートフォンや携帯電話等の携帯型情報端末の構成例を示すブロック図である。同図において、ＣＰＵ１００（中央演算装置／プロセッサ）は、情報処理装置１１５を統括的に制御し、以下で説明する各種処理をプログラムに従って実行する。図中のＣＰＵ１００は１つであるが、複数のＣＰＵあるいはＣＰＵコアによって構成されていても良い。ＲＯＭ１０１は、汎用的なＲＯＭであり、例えば、ＣＰＵ１００により実行されるプログラムが記憶されている。ＲＡＭ１０２は、汎用的なＲＡＭであり、例えば、ＣＰＵ１００によるプログラムの実行時に、各種情報を一時的に記憶するためのメモリである。ハードディスクやフラッシュメモリ等の２次記憶装置１０３は、ファイルや画像解析等の処理結果を保持するデータベース等のデータや、各種プログラムを記憶するための記憶媒体である。ディスプレイ１０４は、各種処理を実現するためのユーザ操作を受け付けるためのＵＩ（ユーザインタフェース）や、実行された処理の結果等の各種情報を表示する。タッチセンサ１０５は、ディスプレイ１０４上に表示されたタッチパネル上のタッチ操作を検出する。

内部撮像デバイス１１０による撮像によって得られた画像データは、所定の画像処理が実行された後、２次記憶装置１０３に保存される。また、画像データは、外部Ｉ／Ｆ（インタフェース）１０８を介して接続された外部撮像デバイス１１１から読み込む場合もある。情報処理装置１１５は、外部Ｉ／Ｆ（インタフェース）１０９を備え、インターネット等のネットワーク１１３を介して外部と通信する。情報処理装置１１５は、例えば、通信Ｉ／Ｆ１０９を介して、ネットワーク１１３に接続されたサーバ１１４から画像データを取得する。情報処理装置１１５は、加速度センサ１０６を備え、情報処理装置１１５自身の位置姿勢に関する加速度情報を取得する。情報処理装置１１５は、外部Ｉ／Ｆ１０７を介し、プリンタ１１２と接続されており、画像データ等を出力する。プリンタ１１２は、ネットワーク１１３にも接続されており、通信Ｉ／Ｆ１０９経由で、プリント処理に必要なデータを送受信する。

外部Ｉ／Ｆ１０７、１０８、１０９は、有線通信と無線通信の内、少なくともいずれかの通信形態を有するインタフェースであり、用いられる通信形態に応じて外部デバイス（プリンタ１１２あるいはサーバ１１４）との通信を行う。有線通信には、例えば、ＵＳＢ、イーサネット（登録商標）等があり、無線通信には、無線ＬＡＮ、ＮＦＣ（Ｎｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、赤外線通信等がある。また、無線通信として、無線ＬＡＮを利用する場合には、装置同士が直接接続する形態もあれば、無線ＬＡＮルータ等の中継装置を介して接続する形態もある。また、外部Ｉ／Ｆ１０７、１０８、１０９は、図１では別々に構成されているが、一体として構成されていても良い。情報処理装置１１５の動作に必要な電源は、バッテリ１１７によって供給される。情報処理装置１１５が備える各種構成要素は、制御バス／データバス１１６を介して相互に接続され、ＣＰＵ１００は、制御バス／データバス１１６を介して、各種構成要素を制御する。

尚、本実施形態では、情報処理装置１１５が、例えばコントローラボードに搭載されたＣＰＵ１００によって実行されるプログラム等の各ソフトウェアの実行環境となる。

［ソフトウェア構成］
図２は、情報処理装置１１５で動作するソフトウェア構成のブロック図である。情報処理装置１１５は、スクリプト層２１７、スクリプト層２１７の下層のネイティブ層２１８、及び、ネイティブ層２１８の下層のＯＳ層２１９を含むプログラムを実行する。これらの各層の構成は、ＣＰＵ１００がＲＯＭ１０１あるいは２次記憶装置１０３に記憶されているプログラムを読み出して実行することにより実現される。

スクリプト層２１７は、ＨＴＭＬ５やＣＳＳ３、及びＪａｖａＳｃｒｉｐｔ等のウェブ標準言語を使って、テキストデータでスクリプト命令セット（コンテンツの描画や画像の表示や動画の再生等の命令セット）が記述されているプログラム層である。スクリプト層２１７では、アプリケーション実行環境上で、そのアプリケーション実行環境に存在するプロセッサ、例えばＣＰＵ１００が、テキストデータの各種命令セットを翻訳して実行する。その実行形態としては、例えば、実行の度に命令文を一行ずつ動的に翻訳する場合や、アプリケーションを起動したときに翻訳する場合、アプリケーションを情報処理装置１１５にインストールしたときに翻訳する場合がある。以後、スクリプト層２１７で処理することや内容を「スクリプト」と呼ぶ。スクリプトの命令を情報処理装置１１５内で翻訳する形態として、例えば、ネイティブ層２１８やＯＳ層２１９が備えるインタプリタの機能を用いる構成がある。尚、本実施形態においては、アプリケーションのＵＩの大部分が、スクリプト層２１７で記述されているものとする。

ネイティブ層２１８は、アプリケーション実行環境以外で予め翻訳（コンパイル）された命令セットが記述されているプログラム層である。形態としては、ＣもしくはＣ＋＋といった高水準言語で記述されたコードが、予めアプリケーション開発者のＰＣやサーバ上でコンパイルされ、ＣＰＵ１００が解釈可能な命令の集合体とされた構成がある。以後、ネイティブ層２１８で処理することや内容、後述するＯＳ層２１９の機能をネイティブ層２１８から呼び出すことを含め、「ネイティブ」と呼ぶ。尚、ネイティブ層２１８の別の実装系として、Ｊａｖａが挙げられる。Ｊａｖａは、Ｃ／Ｃ＋＋と類似の高水準言語であり、予めアプリケーション開発時の開発環境上で中間コードに翻訳される。翻訳された中間コードは、各ＯＳが備えるＪａｖａ仮想環境上で動作する。本実施形態においては、このようなプログラム形態も、ネイティブ層２１８の一種に含まれる。

ＯＳ層２１９は、情報処理装置１１５のオペレーティングシステム（ＯＳ）に対応する。ＯＳ層２１９は、ハードウェア機能をアプリケーションに提供する役割及び固有の機能を有する。ＯＳ層２１９はＡＰＩを備え、スクリプト層２１７やネイティブ層２１８からＯＳ層２１９の機能を使用可能である。

本実施形態では、スクリプト層２１７からネイティブ層２１８の呼び出しを可能にすることをバインディング、もしくはバインドと呼ぶ。各種ネイティブの機能は、ＡＰＩを備え、該ＡＰＩをスクリプトが呼び出すことでネイティブの機能を使用可能である。このようなバインディング機能は、通常、各種ＯＳが標準的に備えている機能である。尚、本実施形態では、スクリプト層２１７とネイティブ層２１８とが階層構造とされ、各層が連携して所定の機能を実行するアプリケーションのことをハイブリッドアプリケーションと呼ぶ。

以上がソフトウェアの構成に関する説明である。以後、各ブロックについて説明する。

スクリプト層２１７の画像取得部２０１は、ネイティブ層２１８に対し、画像データの取得を依頼する。画像取得部２０１の依頼として、例えば、画像データのパスを指定する方法や、ダイアログ表示を促す方法がある。

ネイティブ層２１８の画像読込部２０２は、画像データ群２１５から画像データを取得する（読み込む）。画像データ群２１５からの画像データの取得方法は、スクリプト層２１７の画像取得部２０１の依頼に依存する。依頼方法として、ＵＩ上に提供されているダイアログボックスから選択する、画像データのパスで直接指定する等がある。画像読み込み時、画像データに対して一意なＩＤが割り当てられる。スクリプト層２１７から、ネイディブ層２１８の画像データを指定する場合に、上記ＩＤが用いられる。

ネイティブ層２１８のデータ変換部２０３は、ネイティブ層２１８のデータ、例えばバイナリ形式の画像データやパラメータを、スクリプト層２１７で処理可能な形式のデータ、例えばテキスト形式（ＢＡＳＥ６４）の画像データやＪＳＯＮに変換する。ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）とは、ＪａｖａＳｃｒｉｐｔで利用可能なデータ形式である。一方、データ変換部２０３は、スクリプト層２１７から送られてきたデータ、例えばテキスト形式（ＢＡＳＥ６４）の画像データやＪＳＯＮを、ネイティブ層２１８で処理可能な形式のデータ、例えばバイナリ形式の画像データやパラメータに変換する。

スクリプト層２１７のデータ変換部２０７は、スクリプト層２１７のデータ、例えばテキスト形式の処理パラメータを、ネイティブ層２１８で処理可能な形式のデータ、例えばバイナリ形式の画像データやパラメータに変換する。一方、データ変換部２０７は、ネイティブ層２１８から送られてきたデータ、例えばバイナリ形式の画像データやパラメータを、スクリプト層２１７で処理可能な形式のデータ、例えばテキスト形式の処理パラメータに変換する。

ネイティブ層２１８のデータ保持部２０４は、画像読込部２０２により読み込まれた画像データ、画像処理部２０８で画像処理が実行された画像データ、分割された画像群を保持する。保持される画像データは、例えば、ＲＧＢ画像データに展開されており、直ちに画像処理が実行可能な形式になっている。

スクリプト層２１７のコンテンツ描画部２０５は、プリントのためのコンテンツ（印刷コンテンツ）をウェブ標準言語により記述する。この記述には、コンテンツ操作部２１０で操作された内容も反映される。コンテンツ描画部２０５で記述されたコンテンツのスクリプトは、ＯＳ層２１９のインタプリタ２１４で解釈され、ディスプレイ１０４に表示される。

スクリプト層２１７の画像処理制御部２０６は、画像処理に用いる補正パラメータと、処理対象となる画像データを決定し、ネイティブ層２１８の画像処理部２０８に画像処理を依頼する。補正パラメータは、データ変換部２０７でネイティブ層２１８へ送信できる形式へ変換された後、処理対象となる画像データのＩＤと共にネイティブ層２１８へ送信される。

ネイティブ層２１８の画像処理部２０８は、画像処理制御部２０６で指定された画像データに対し、画像処理を施す。その際、どのような画像処理を実行するかは、画像処理制御部２０６で設定されたパラメータにより決定される。画像データの指定では、先述のＩＤを用いる方法や、スクリプト層２１７から画像データのパスを受け取る方法などが用いられる。

ＯＳ層２１９のタッチイベント２０９は、ディスプレイ１０４上のタッチ操作に関する情報を取得する。タッチ操作に関する情報とは、ディスプレイ１０４上のタッチ操作検知、タッチされた位置情報等が挙げられる。取得したタッチ操作に関する情報は、ネイティブ層２１８経由でスクリプト層２１７のコンテンツ操作部２１０に送信される。

スクリプト層２１７のコンテンツ操作部２１０は、例えば、画像取得依頼の結果としてネイティブ層２１８から画像データが返却された際、その画像データへの操作内容の反映を行うために、スクリプト命令を変更する。

スクリプト層２１７のプリンタ制御部２１１は、プリンタ検知の依頼、プリンタ設定画面の表示、プリント情報の生成及び送信、などを行う。後述するプリンタ設定画面では、用紙のサイズ、用紙の種類、カラー・モノクロ等のプリンタ設定が行われる。ここで設定された項目に基づいて、プリンタデータ生成部２１２でプリンタデータが生成される。

ネイティブ層２１８のプリンタデータ生成部２１２は、プリンタ制御部２１１からの依頼に基づいて、プリンタ通信に必要なデータやコマンドを生成する。プリンタ通信に必要なデータとは、プリンタ１１２との間での通信プロトコルに則ったデータであり、コマンドとは、印刷やスキャン等、プリンタの動作を決定するためのデータである。つまり、プリンタデータ生成部２１２は、プリンタの動作を決定するためのコマンドを含むプリンタデータを生成する。

ネイティブ層２１８の外部デバイス通信部２２１は、プリンタ１１２などの、情報処理装置１１５と接続している外部デバイスとの通信を行うためのインタフェース（ＩＦ）である。ここでは、プリンタデータ生成部２１２から受け取ったデータを送信したり、プリンタ１１２からの情報を受信する。本実施形態ではＯＳ層２１９の通信制御部２１３を介して通信するが、外部デバイス通信部２２１が直接、外部ＩＦ１０７へデータを送信してもよい。ＯＳ層２１９の通信制御部２１３が外部デバイスが用いる通信プロトコルに対応していれば、その機能が用いられて通信が行われる。一方、通信制御部２１３が外部デバイスが用いる通信プロトコルに対応していなければ、外部デバイス通信部２２１がその通信プロトコルに従って通信する。

ＯＳ層２１９のインタプリタ２１４は、スクリプト層２１７で生成されたウェブ標準言語で記述された命令を解釈・実行する。例えば、画像描画等の命令は、インタプリタ２１４を通して実行され、ディスプレイ１０４に表示される。

画像データ群２１５は、画像データを保持している領域である。データ保存部２２０は、必要に応じて、データ保持部２０４が保持する画像データを画像データ群２１５に保存する。

スクリプト層２１７のレンダリング依頼部２２２は、ネイティブ層２１８のレンダリング２１６にレンダリングの依頼をする。その際、コンテンツ描画部２０５で記述されている内容をデータ変換部２０７で変換してからレンダリング部２１６に受け渡す。レンダリング部２１６に受け渡す前に必要な処理があれば、コンテンツ操作部２１０により、コンテンツ記述を編集する場合もある。また、コンテンツ記述を直接編集するとＵＩに影響がある場合、編集操作はコンテンツ記述の複製を作成して、作成された複製に対して行われる。

レンダリング部２１６は、レンダリング依頼部２１７から受け取った内容から、プリンタ１１２へ送信する画像データを生成するためのレンダリングを行う。このレンダリングには、例えば、スクリプト層２１７で、プリンタ１１２への出力解像度で画像を生成することも含まれる。また、オフスクリーン画面が生成される場合には、ネイティブ層２１８におけるレンダリング結果、及び、生成途中の画像は、ディスプレイ１０４には表示されない。

ＯＳ層２１９の状態検知部２２３は、デバイスの状態、アプリケーションの実行状況の変化を検知する。例えば、アプケーションを実行している状態で、着信などの他の通知があった場合、そのイベントの発生や状態変化をネイティブ層２１８へ送信する。

［写真画像のプリント処理］
図３は、写真画像のプリント処理を示すフローチャートである。図３を用いて、Ｓ３１からＳ３５の各処理の概要を説明し、詳細は後述する。なお、以下のフローチャートの各処理は、情報処理装置１１５のＣＰＵ１００が、ＲＯＭ１０１あるいは２次記憶装置１０３に記憶されているプログラムを実行することにより実現される。アプリケーション画面９００は、スクリプト層２１７によって生成される。アプリケーション画面９００上のユーザ操作は、例えばタッチセンサ１０５を介して受け付けられる。

Ｓ３１では、ＣＰＵ１００は、アプリケーション画面９００の写真画像選択ボタン９０１に対するユーザ操作（タッチ操作入力も含む。以下同様）を検知すると、その操作に応じた画像データを選択する。画像データが選択されると、ＣＰＵ１００は、ネイティブ層２１８で特定の処理を実行した後、アプリケーション画面９００の描画領域９０６に選択された画像データの画像を表示する。

Ｓ３２では、ＣＰＵ１００は、表示されている画像の輝度を調整するためのスライドバー９０２に対するユーザ操作を検知すると、そのユーザ操作に応じて、画像処理時に用いる補正パラメータを設定する。そして、実行開始の指示操作により、ＣＰＵ１００は、設定した補正パラメータに従って画像データに画像処理を実行し、特定の処理を行った後、その処理内容及び処理結果を描画領域９０６に表示する。

Ｓ３３では、ＣＰＵ１００は、スタンプ追加ボタン９０３に対するユーザ操作を検知すると、スタンプを表示する。ＣＰＵ１００は、スタンプ一覧に対するユーザ操作によってスタンプの選択を検知すると、描画領域９０６に、選択されたスタンプを追加・表示する。さらに、スタンプにタッチイベント（タップ、スワイプ）検知機能を付与することで、スタンプの拡大・縮小、移動などが行われても良い。この検知機能は、Ｗｅｂ標準言語に標準として備えられているものであり、ａｄｄＥｖｅｎｔＬｉｓｔｅｎｅｒ関数が相当する。スタンプがタッチされた時の動作を示す記述例を下記に示す。
var stamp = 対象のスタンプ;
stamp.addEventListener(“touchstart”, function(e){
//スタンプがタッチされた時に行いたい処理をここに記述
}, false);
Ｓ３４では、ＣＰＵ１００は、プリントボタン９０５に対するユーザ操作を検知すると、プリントに必要な情報を設定するための図１０の設定画面１００１を表示する。プリントに必要な情報とは、例えば、図１０の設定画面１００１に示されるように、用紙サイズ、用紙種類、印刷品位、縁あり／なしの設定項目である。これ以外にも、両面／片面、モノクロ・カラー等、使用するプリンタが有する機能に応じて、設定可能な設定項目が表示される。

Ｓ３５では、ＣＰＵ１００は、設定画面１００１の設定完了ボタン１００２に対するユーザ操作を検知すると、描画領域９０６に表示されている画像を、プリンタ１１２に出力するためのデータへ変換するためのレンダリングを実行する。

レンダリングによってプリンタデータが作成された後、ＣＰＵ１００は、プリンタデータを、プリンタ制御のコマンドと共にプリンタ１１２に送信する。以上の処理により、ユーザにより選択された画像がプリンタ１１２でプリントされる。

尚、図３に示す処理は一例であり、処理内容はこれに限定されず、図３の各処理の処理順序もこれに限定されるものではない。また、本実施形態において、プロセッサで翻訳され実行されるための命令セットを含む第１のプログラム層（第１の層）をスクリプト層２１７、プロセッサ以外で予め翻訳された命令セットを含む第２のプログラム層（第２の層）をネイティブ層２１８と定義する。本実施形態では、これらの第１のプログラム層と第２のプログラム層とが階層構造とされたプログラムがハイブリッドアプリケーションを実現する。

［写真画像選択］
次に、以上のような構成の情報処理装置１１５において実行する写真画像選択とそれに伴う画像処理について説明する。これらの処理を実行する場合、情報処理装置１１５は、画像処理装置として機能する。

図９の写真画像選択ボタン９０１のユーザ操作を検出することにより、Ｓ３１が開始する。ここで、図３のＳ３１の写真画像選択の詳細について、図４を用いて説明する。なお、Ｓ４０１、Ｓ４１１は、ＣＰＵ１００がスクリプト層２１７のプログラムを用いて実行する処理であり、Ｓ４０２〜Ｓ４１０は、ＣＰＵ１００がネイティブ層２１８のプログラムを用いて実行する処理である。

Ｓ４０１では、ＣＰＵ１００は、スクリプト層２１７において、写真画像選択ボタン９０１に対するユーザ操作に応じて、画像選択をネイティブ層２１８に依頼する。その依頼では、バインディング機能によりスクリプト層２１７から、ネイティブ層２１８固有の画像選択ＡＰＩが直接呼び出される。ここで、直接ネイティブ層２１８固有の画像選択ＡＰＩを呼び出せない場合には、ネイティブ層２１８にスクリプト層２１７から直接呼び出せる関数を用意しておき、その関数内にネイティブ層２１８固有の画像選択ＡＰＩを呼び出す関数を記述しておいても良い。これは、ラッパを予め用意しておく方法である。また、他に、画像選択ＵＩを独自に実装するという構成としても良い。

Ｓ４０２では、ＣＰＵ１００は、ネイティブ層２１８において、画像選択ＵＩをディスプレイ１０４に表示する。そして、表示された画像選択ＵＩに対するユーザ操作に基づいて、任意の画像を１枚選択する。なお、本実施形態ではデバイス内の画像フォルダから画像を１枚選択しているが、それに限定されるものではない。例えば、インターネット上の画像や、脱着可能な記憶媒体内の画像が選択されても良いし、デバイスのカメラ機能を利用して画像を撮影し、それが選択されるようにしても良い。

Ｓ４０３では、ＣＰＵ１００は、ネイティブ層２１８において、一意なＩＤを生成する。このＩＤは、数値、文字列等、ネイティブ層２１８からスクリプト層２１７へ送信できる形式であれば、どのような形式でも良い。ここで、ＩＤの生成は、ネイティブ層２１８で実行される構成に限られず、スクリプト層２１７で生成してネイティブ層２１８に送る構成でも良い。

Ｓ４０４では、ＣＰＵ１００は、ネイティブ層２１８において、選択された画像を取得する。例えば、選択された画像が画像ファイルの状態であれば、ＣＰＵ１００は、ファイルを開き、その内容を読み取って取得する。

Ｓ４０５では、ＣＰＵ１００は、ネイティブ層２１８において、取得した画像をＲＧＢ空間に展開する。ここでは、ＲＧＢデータをネイティブ層２１８に保持しているが、これに限定されるものではない。例えば、ＪＰＥＧ（Ｊｏｉｎｔ Ｐｈｏｔｏｇｒａｐｈｙ Ｅｘｐｅｒｔ Ｇｒｏｕｐ）、ＰＮＧ（Ｐｏｒｔａｂｌｅ Ｎｅｔｗｏｒｋ Ｇｒａｐｈｉｃｓ）、ＲＧＢＡ形式などで保持するようにしても良い。ここで、ＲＧＢＡ形式とは、画像データのＲＧＢ（赤、緑、青）成分に、透明度としてＡを組み合わせたデータ形式である。

Ｓ４０６では、ＣＰＵ１００は、ネイティブ層２１８において、展開したＲＧＢデータを分割し、小領域毎のＲＧＢデータを作成する。ここで、小領域毎のＲＧＢデータを「ブロック画像」と呼ぶ。ブロック画像は、タイル状と帯状（バンド状）のどちらでも良い。タイル状とは、図１１（ａ）に示すように、ブロック画像の横幅・縦幅が、両方とも分割元データの横幅・縦幅に満たない場合をいう。対して、帯状とは、図１１（ｂ）に示すように、ブロック画像の横幅・縦幅のどちらか一方のみが、分割元データに対して満たない場合をいう。

本実施形態では、ブロック画像は、本来の画像データを帯状に二分割する方法を採用するものとする。分割の個数は、特定の個数を指定する方法や、一つのブロック画像が特定の画素数未満になるようにするなど、どのような方法でも良い。また、ブロック画像のサイズは一律同じである必要はない。例えば、３０００ｐｘ（ピクセル）×２０００ｐｘの画像を２分割する際、３０００ｐｘ×１５００ｐｘと３０００ｐｘ×５００ｐｘのような分割であっても良い。

Ｓ４０７では、ＣＰＵ１００は、ネイティブ層２１８において、展開したＲＧＢデータと生成したブロック画像群を、Ｓ４０３で生成したＩＤと関連付けてデータ保持部２０４に保持する。ここで、関連付ける方法として、例えば、ＩＤとＲＧＢデータ、ブロック画像群を有するオブジェクトを作成し、ＩＤによりＲＧＢデータとブロック画像群を特定可能にするという方法が用いられる。ＩＤの関連付け方法は、これに限られず、ＩＤからＲＧＢ画像、ブロック画像群を特定できるのであれば他の方法が用いられても良い。

また、ＲＧＢデータ、ブロック画像群はオンメモリで保持しても良いし、ファイルとして保存しても良い。本実施形態では、ブロック画像群を、スクリプト層２１７が処理可能なＤＩＢ（Ｄｅｖｉｃｅ Ｉｎｄｅｐｅｎｄｅｎｔ Ｂｉｔｍａｐ）フォーマットに変換してファイルに保存しておくこととする。この場合、ＩＤとの関連付けは「block1_ID.bmp」、「block2_ID.bmp」のように、決められた名前にＩＤを追記することで実現される。また、画像フォーマットとして、ＤＩＢ以外のフォーマットが用いられても良い。

Ｓ４０８では、ＣＰＵ１００は、ネイティブ層２１８において、ＲＧＢデータからＵＩで用いるための縮小ＲＧＢデータを作成する。縮小には、ＯＳの機能が用いられても良いし、独自の実装で行われても良い。スクリプトは、返却された画像が大きい場合には、画像をＵＩの大きさ、ディスプレイ１０４の解像度に合わせて縮小処理を行う。ＵＩに対して過多な画素数の画像をスクリプトで扱うと、ＣＰＵ１００に処理負荷が掛かり、かつ、大容量のメモリが必要となる。本実施形態では、縮小処理を実行するので、メモリの大容量化を回避することができる。縮小処理の目安としては、例えば、ディスプレイ１０４の表示サイズやＵＩで画像を表示する箇所のサイズを上限とし、それを越える画素数を持つ画像に対して縮小処理を行うよう制御する。画像に対して画像処理を実行する場合には、元の画像（ＲＧＢ展開した画像データ）に対して画像処理を実行し、上記の縮小処理を実行後に縮小された画像をスクリプト層２１７に引き渡す。

Ｓ４０９では、ＣＰＵ１００は、ネイティブ層２１８において、Ｓ４０８で作成した縮小ＲＧＢデータをスクリプト層２１７で処理可能な形式（サポート可能な形式）の画像データに変換する。本実施形態では、変換するデータ形式をＪＰＥＧ（Ｊｏｉｎｔ Ｐｈｏｔｏｇｒａｐｈｙ Ｅｘｐｅｒｔ Ｇｒｏｕｐ）とする。

Ｓ４１０で、ＣＰＵ１００は、ネイティブ層２１８において、ＪＰＥＧ形式のデータをＢＡＳＥ６４データに変換し、スクリプト層２１７へ送信する。これは、ネイティブ層２１８で扱うＪＰＥＧデータは、スクリプト層２１７では直接処理できない形式であるからである。ＢＡＳＥ６４とは、バイナリデータを文字列データとして扱うためのエンコード方式であり、ＪａｖａＳｃｒｉｐｔ（商標登録）で処理可能なデータ形式となっている。スクリプト層２１７で画像を扱う方法として、ネイティブ層２１８でＪＰＥＧを一旦ファイルに保存したのち、その保存パスを利用する方法もあるが、本実施形態では、ＢＡＳＥ６４データを利用する方法を用いるものとして説明する。

Ｓ４１１で、ＣＰＵ１００は、スクリプト層２１７において、ネイティブ層２１８で変換されたＢＡＳＥ６４データを受信し、描画領域に画像を描画する。例えば、ＣＰＵ１００は、スクリプト層２１７で指定されたＢＡＳＥ６４データをＯＳ層２１９のインタプリタ２１４に送信する。そして、インタプリタ２１４がＢＡＳＥ６４データのスクリプトを解釈し、描画領域に画像として表示する。以下、描画領域にＢＡＳＥ６４データを反映させるサンプルコードの一例を示す。
--------------------------------------------------
var base64Data = ネイティブ層からのＢＡＳＥ６４データ;
var ID = ネイティブ層で生成された一意なID;
//画像の反映させたい領域を指定
var svg = “http://www.w3.org/2000/svg”;
var xlink = “http://www.w3.org/1999/xlink”;
var img = document.createElementNS(svg, "image");
img.setAttributeNS(xlink, “href”, base64Data);
img.setAttribute(“id”, ID);
img.setAttribute(“width”, 200);
img.setAttribute(“height”, 200);
var target = document.getElementById(“追加先のSVGのID”);
target.appendChild(img);
--------------------------------------------------
上記では、描画領域９０６に対しＳＶＧが動的に追加可能な方法を示している。後述するスタンプに関しても同様の操作で描画領域９０６に追加することが可能である。

［画像処理］
図９のスライドバー９０２を変化させる操作が行われることにより、Ｓ３２が開始する。ここでは、図３のＳ３２の画像処理の詳細について、図５を用いて説明する。なお、Ｓ５０１〜Ｓ５０３、Ｓ５１０、Ｓ５１２は、ＣＰＵ１００がスクリプト層２１７のプログラムを用いて実行する処理であり、Ｓ５０４〜Ｓ５０７、Ｓ５０９は、ＣＰＵ１００がネイティブ層２１８のプログラムを用いて実行する処理である。ここでは、画像の明るさを変更する画像処理を実行することとし、その変化度合は、ユーザが操作したスライドバー９０２の設定値に対応するものとする。

Ｓ５０１では、ＣＰＵ１００は、スクリプト層２１７において、補正パラメータを設定する。補正パラメータは、スライドバー９０２の値に対応する。Ｓ５０２では、ＣＰＵ１００は、スクリプト層２１７において、インジケータを起動し、ディスプレイ１０４に表示する。ここで、インジケータとは、ユーザに処理中である旨を伝えるための表示であり、プログレスバーや、時計マーク、図形の回転等である。インジケータは、実行時間のかかる処理を行う場合に用いられる。また、本実施形態では、スクリプト層２１７でインジケータの起動と停止を行っているが、ネイティブ層２１８でインジケータの起動と停止を行うようにしても良い。

Ｓ５０３で、ＣＰＵ１００は、スクリプト層２１７において、Ｓ５０１で設定された補正パラメータと、画像処理を実行する画像のＩＤ（Ｓ４０３で生成した画像のＩＤ）を、ＪＳＯＮ形式としてネイティブ層２１８へ送信する。ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）とは、ＪａｖａＳｃｒｉｐｔで利用可能なデータ記述方法であり、ネイティブ層２１８と送受信可能なデータフォーマットの一つである。例えば、ＩＤと輝度補正の値を送信する記述例を以下に示す。
----------------------------------------------------
var json = {
ID : 画像処理対象の画像ID,
Brightness : 20
};
----------------------------------------------------
Ｓ５０４では、ＣＰＵ１００は、ネイティブ層２１８において、スクリプト層２１７から取得したＩＤに基づいて、図４のＳ４０５で展開されたＲＧＢデータを特定する。

Ｓ５０５では、ＣＰＵ１００は、ネイティブ層２１８において、取得した補正パラメータに基づいて、ＲＧＢデータに対して明るさ補正を実行する。本実施形態では、スライドバー９０２に設定された２０の値に基づいて、全ての画素のＲＧＢ値に２０を加算する処理を行うとする。画像処理については、補正パラメータに他の画像処理情報を追加することで、実行する画像処理を増やすようにしても良い。例えば、モノクロ変換、セピア色変換、「ＩｍａｇｅＦｉｘ」、「ＲｅｄｅｙｅＦｉｘ」、「ＳｍａｒｔＳｋｉｎ」などを追加するようにしても良い。

ここで、「ＩｍａｇｅＦｉｘ」とは、写真画像を、人物顔検出やシーン解析部を用いて自動で解析し、適切な明るさ・ホワイトバランス調整を行う機能（顔検出機能）である。また、「ＲｅｄｅｙｅＦｉｘ」とは、画像中から自動で赤目画像を検出して補正する機能（赤目検出機能）である。また、「ＳｍａｒｔＳｋｉｎ」とは、写真画像から人物の顔を検出して、その顔の肌領域を加工する機能である。なお、画像処理機能の種類は、これらに限定されるものではなく、用途や目的に応じて、様々な画像処理を利用可能である。さらに、画像処理において、ＯＳ層２１９が提供する機能が用いられても良い。

Ｓ５０６では、ＣＰＵ１００は、ネイティブ層２１８において、Ｓ５０５で画像処理が実行されたＲＧＢデータからＳ４０６と同様の処理でブロック画像群を作成する。ここで、Ｓ４０７でＩＤと関連付けたブロック画像群は、Ｓ５０６で作成したブロック画像群と置き換わり、Ｓ４０６で作成されたブロック画像群は破棄される。

Ｓ５０７では、ＣＰＵ１００は、ネイティブ層２１８において、Ｓ５０５で画像処理の実行されたＲＧＢデータから、ＵＩで用いるための縮小ＲＧＢデータを作成する。Ｓ５０８では、ＣＰＵ１００は、ネイティブ層２１８において、Ｓ５０７で作成された縮小ＲＧＢデータをスクリプト層２１７でサポート可能な形式のデータに変換する。ここでは、Ｓ４０９と同様に、ＪＰＥＧ形式のデータに変換される。

Ｓ５０９では、ＣＰＵ１００は、ネイティブ層２１８において、スクリプト層２１７にインジケータの停止を依頼する。これは、ネイティブ層２１８から、スクリプト層２１７で定義されているインジケータ停止の関数を呼び出すことで実現される。

Ｓ５１０では、ＣＰＵ１００は、スクリプト層２１７において、インジケータを停止して、ディスプレイ１０４の表示からインジケータを消去する。一方、Ｓ５１１では、ＣＰＵ１００は、ネイティブ層２１８において、変換されたＪＰＥＧ形式のデータをＢＡＳＥ６４データに変換し、スクリプト層２１７へ送信する。

Ｓ５１２では、ＣＰＵ１００は、スクリプト層２１７において、ネイティブ層２１８で変換されたＢＡＳＥ６４データを受信し、それに従って、Ｓ４１１で描画した内容を変更する。例えば、ＣＰＵ１００は、スクリプト層２１７で指定されたＢＡＳＥ６４データをＯＳ層のインタプリタ２１４に送信する。そして、インタプリタ２１４がＢＡＳＥ６４データのスクリプトを解釈し、既にある描画領域に画像データの描画結果を表示する。以上の処理により、補正パラメータに基づく画像処理が適用された画像データが表示される。

本実施形態では、図９に示すようなスライドバー９０２の変化に応じて画像処理が開始されるが、その開始方法はこれに限定されるものではない。例えば、画面にプラスボタン、マイナスボタンが配置されており、そのボタンが押下されるごとに明るさが調整されるという構成であっても良い。他にも、画像の右半分がタッチされたら明るさを増す、左半分がタッチされたら暗くするなど、タッチイベントと連動させた処理によって実現されても良い。また、ユーザ操作で補正パラメータだけ変化させておいて、画像処理の実行指示があった時に、全ての画像処理が一括して行われるというように構成されても良い。

［スタンプ追加］
図９のスタンプ追加ボタン９０３が押下され、ハートスタンプ９０８が選択されることにより、Ｓ３３の処理が開始する。ここでは、図３のＳ３３のスタンプ追加の処理について、図６を用いて説明する。以下の説明では、ユーザ操作によって、図９のアプリケーション画面９００のスタンプ追加ボタン９０３が押下されてスタンプ一覧が表示された後、ハートスタンプ９０８が選択された場合を例として説明する。なお、スタンプ追加は、ＣＰＵ１００がスクリプト層２１７のプログラムを用いて実行する処理である。また、用いられるスタンプは、アプリケーションが予めリソースファイルとして保持しているとする。

Ｓ６０１では、ＣＰＵ１００は、スクリプト層２１７において、スタンプとして用いられる画像データが保存されているパスを取得する。スタンプは予め決まったファイルを読み込む処理により取得されるので、例えば、ハートスタンプ９０８がタップされると、ハートスタンプが保存されているパスが返却される構成とする。

Ｓ６０２では、ＣＰＵ１００は、スクリプト層２１７において、スタンプ描画用のオブジェクトを作成する。Ｓ６０３では、ＣＰＵ１００は、スクリプト層２１７において、作成したスタンプ描画用オブジェクトに、Ｓ６０１で取得したパスの情報をセットする。Ｓ６０２及びＳ６０３の処理は、Ｓ４１１で画像を追加する場合とほぼ同様の方法で実現可能である。Ｓ４１１との違いは、画像の情報元がＢＡＳＥ６４の画像データではなく、スタンプのパスとなっている点である。また、スタンプに対してタッチイベントを付与するようにしても良い。タッチイベントを付与すると、スタンプがタップされたか、スワイプされたか等のタッチ操作に関する情報を取得可能になる。この情報を用いることでスタンプを移動したり、拡大縮小を行うなどの操作が可能となる。

Ｓ６０４では、ＣＰＵ１００は、Ｓ６０３の内容をインタプリタ２１４で解釈させ、描画領域９０６にスタンプが追加される。

［プリンタ設定］
図９に示したプリントボタン９０５が押下されることにより、図３のＳ３４の処理が開始する。ここでは、図３のＳ３４のプリンタ設定の詳細について、図７を用いて説明する。Ｓ７０１、Ｓ７０９〜Ｓ７１１は、ＣＰＵ１００がスクリプト層２１７のプログラムを用いて実行する処理である。また、Ｓ７０２、Ｓ７０４、Ｓ７０５、Ｓ７０７、Ｓ７０８、Ｓ７１２は、ＣＰＵ１００がネイティブ層２１８のプログラムを用いて実行する処理である。また、Ｓ７０３とＳ７０６は、プリンタ１１２が実行する処理である。

Ｓ７０１では、ＣＰＵ１００は、スクリプト層２１７において、ネイティブ層２１８へデバイス情報としてのプリンタ情報取得を依頼する。これは、プリンタ１１２と通信を行うための、スクリプト層２１７からの要求である。依頼の方法は、画像選択時と同様に、バインディング機能によりスクリプトからネイティブ固有のＡＰＩを呼び出すことで行われる。ネイティブ層２１８には、スクリプト層２１７から直接呼び出せる関数もしくはその関数を間接的に呼び出す、いわゆるラッパが予め用意されている。例えば、ＧｅｔＰｒｉｎｔｅｒＩｎｆｏというネイティブ関数を用意しておき、スクリプト側からその関数を呼び出す。このようにして、ネイティブ層２１８は、スクリプト層２１７からの外部デバイスとの通信要求を取得する。

通常、スクリプト層２１７からはセキュリティ上の制限により、外部デバイスと直接通信することはできない。そのため、上記のように、スクリプト層２１７から、一旦、ネイティブ層２１８へ外部デバイス情報の取得を依頼し、ネイティブ層２１８を介して外部デバイスとの通信が行われる。ネイティブ層２１８は、ＯＳ層２１９を介して、外部デバイス、例えばプリンタ１１２と通信する機能を備えている。

Ｓ７０２では、ネイティブ層２１８で該関数が呼び出されると、ＣＰＵ１００は、ネイティブ層２１８において、プリンタの検出、いわゆるディスカバリを行う。例えば、同一無線ＬＡＮルータで繋がっているプリンタを検出する。ここでは、通信可能なプリンタの検出を行うため、例えば、ＣＰＵ１００は、Ｂｏｎｊｏｕｒ（登録商標）などのプロトコルにより、ブロードキャストやマルチキャスト等の方法を用いてプリンタ１１２に対して通信を試みる。Ｓ７０３では、プリンタ１１２は、ネイティブ層２１８からの要求に応じて応答する。

Ｓ７０４では、ＣＰＵ１００は、ネイティブ層２１８において、応答のあったプリンタ１１２のＩＰアドレスを取得して記憶する。さらに、Ｓ７０５では、ＣＰＵ１００は、応答のあったプリンタ１１２のＩＰアドレスへプリンタ情報の提供を要求する。応答のあったプリンタが複数の場合、ＣＰＵ１００は、全てのプリンタに対して情報の提供を要求する。そのために、ＣＰＵ１００は、ネイティブ層２１８で、プリンタ１１２の情報を取得するためのコマンドを生成する。そのコマンドとは、プリンタ１１２の動作を指定する命令であり、以下に、ＸＭＬで記述された一例を示す。
----------------------------------------------
01: ＜?xml version="1.0" encoding="utf-8" ?＞
02: ＜cmd xmlns:trans="http://www.xxxx/yyyyy/"＞
03: ＜contents＞
04: ＜operation＞GetInformation＜/operation＞
05: ＜/contents＞
06: ＜/cmd＞
----------------------------------------------
上記各行の左側の「０１：」等の数値は、説明を行うために付加した行番号であり、本来のＸＭＬ形式のテキストには記述されない。１行目は、ヘッダであり、ＸＭＬ形式で記述していることを表している。２行目のｃｍｄは、コマンドの開始を意味する。ｘｍｌｎｓで名前空間が指定され、コマンドの解釈の定義が指定されている。尚、６行目の＜／ｃｍｄ＞は、コマンドの終了を示している。３行目は、以降に内容を記載する宣言であり、５行目は、その終了を示している。４行目には、要求する命令が記述されており、＜ｏｐｅｒａｔｉｏｎ＞と＜／ｏｐｅｒａｔｉｏｎ＞の間に実際の命令文言が存在する。命令文言であるＧｅｔＩｎｆｏｒｍａｔｉｏｎは、外部デバイスであるプリンタの情報を取得するための命令である。例えば、プリンタが対応している用紙種類、サイズ、縁なし印刷機能の有無、印刷品位、等のケーパビリティ情報の要求である。

尚、プリンタ情報取得コマンドの生成は、例えば、ＲＯＭ１０１に予め記憶した固定のテキストを読み込むことで行われても良い。また、ＸＭＬ等のテキスト形式に限らず、バイナリ形式で記述し、それに従ったプロトコルで通信しても良い。また、生成したプリンタ情報取得コマンドは、ＨＴＴＰ等のプリンタ１１２が対応している通信プロトコルに従った形式で、外部デバイス通信部２２１を介してプリンタ１１２へ送信される。また、通信方法はこれに限定されるものではない。Ｗｉ−Ｆｉ（登録商標）ダイレクトやＢｌｕｅｔｏｏｔｈ（登録商標）、赤外線通信、電話回線、有線ＬＡＮ、ＵＳＢを用いた接続でも良く、その方法に従ったプロトコルで通信を行えば同様の効果を得ることができる。

図７では、ネイティブ層２１８でコマンドを生成する構成としているが、スクリプト層２１７で、コマンドを生成する構成でも、同様の効果が得られる。その場合、スクリプト層２１７で、例えば、上記のＸＭＬ形式の命令文を含むコマンドを作成し、ネイティブ層２１８へ渡す。それを受けて、ネイティブ層２１８は、通信プロトコルに従った形式でプリンタ１１２へそのコマンドを送信する。

Ｓ７０６では、プリンタ１１２は、情報処理装置１１５からコマンドを受信すると、デバイス情報であるプリンタ情報をＸＭＬ形式で通信プロトコルに従って、情報処理装置１１５へ送信する。以下に、プリンタ情報の一例を示す。
----------------------------------------------
01: ＜?xml version="1.0" encoding="utf-8" ?＞
02: ＜cmd xmlns:trans="http://www.xxxx/yyyyy/"＞
03: ＜contents＞
04: ＜device id=”Printer001” /＞
05: ＜memory receive= 7680000 /＞
06: ＜mode = 1＞
07: ＜media＞GlossyPaper＜/media＞
08: ＜size＞A4＜/size＞
09: ＜quality＞1＜/quality＞
10: ＜border＞no＜/border＞
11: ＜dpi x=1200 y=1200 /＞
12: ＜/mode＞
13: ＜mode = 2＞
〜中略〜
＜/mode＞
＜mode = 3＞
〜中略〜
＜/mode＞
〜中略〜
＜/contents＞
＜/cmd＞
----------------------------------------------
１行目は、ヘッダであり、ＸＭＬ形式で記述していることを表している。２行目のｃｍｄは、コマンドの開始を意味する。ｘｍｌｎｓで名前空間が指定され、コマンドの解釈の定義が指定されている。尚、最下行の＜／ｃｍｄ＞は、コマンドの終了を示している。３行目は、以降に内容を記載する宣言であり、下の＜／ｃｏｎｔｅｎｔｓ＞までその内容は継続する。４行目は、デバイスＩＤを示している。ここでは、プリンタ１１２の機種名が「Ｐｒｉｎｔｅｒ００１」であることを表している。５行目については、本実施形態では用いられないが、他の実施形態で説明する。６行目以降は、プリンタ１１２が有する各モードについての記述である。＜ｍｏｄｅ＞から＜／ｍｏｄｅ＞までで、１つのモードにおける情報が記述されている。６行目では、モードの番号が１である。以降の＜ｍｅｄｉａ＞は印刷用紙の種類、＜ｓｉｚｅ＞は用紙サイズ、＜ｑｕａｌｉｔｙ＞は印刷品位、＜ｂｏｒｄｅｒ＞は縁あり／なしの情報をそれぞれ記述している。１１行目の＜ｄｐｉ＞は出力解像度を表しており、横方向が１２００［ｄｐｉ］、縦方向が１２００［ｄｐｉ］である。

１３行目以降は、他のモードであるモード２についての情報が記述されている。このように、プリンタ１１２の機種名と、そのプリンタ１１２が対応している全てのモードが記述されている。尚、プリンタ情報の記述方法は、これに限定されることはなく、タグ形式でないテキストや、バイナリ形式等の他の形式で実現されても良い。

また、上記はプリンタ１１２の印刷機能の情報を受け渡しする例であるが、これに限定されるものではない。例えば、プリンタ１１２が処理可能な画像処理や解析処理、静かに印刷するモードの有無、メモリカードの利用有無、インク残量などのステータスなどの情報を受け渡しするようにしても良い。画像処理の例としては、モノクロやセピア、彩度強調などの色変換、複数画像のレイアウト、ホワイトバランス補正、ノイズ除去、その他自動で写真を好ましい色や輝度に補正する処理などが挙げられる。

Ｓ７０７では、ＣＰＵ１００は、ネイティブ層２１８において、プリンタ１１２からプリンタ情報を取得する。ＣＰＵ１００は、ネイティブ層２１８で、受信したプリンタ情報から、例えば、プリンタ１１２が有する全てのモードにおける印刷用紙の種類、サイズ、印刷品位、縁あり／なしの項目と項目数等を取得する。

Ｓ７０８では、ＣＰＵ１００は、ネイティブ層２１８において、受信したプリンタ情報をスクリプト層２１７が解釈可能な形式に変換して、スクリプト層２１７へ送信する。つまり、ＣＰＵ１００は、プリンタ１１２との通信によって得られた情報をスクリプト層２１７へ渡す。これは、例えば、ネイティブ関数を設けておき、バインディング機能を用いることで行われる。また、受け取ったＸＭＬ形式のプリンタ情報で送信したり、タグなしのテキスト形式に変更して送信する等の方法が用いられても良い。加えて、スクリプト層２１７から特定のネイティブ関数を呼び出す毎に、その戻り値として情報を取得するようにしても良い。また、ネイティブ関数に取得するモードなどの引数を渡し、その戻り値として情報を取得するようにしても良い。さらに、上述のＪＳＯＮ文字列を用いた受け渡しや、データ変換部２０７及び２０３を用いて、ＢＡＳＥ６４等の文字列で受け渡しを行うようにしても良い。

Ｓ７０９では、ＣＰＵ１００は、スクリプト層２１７において、ネイティブ層２１８から受信したプリンタ情報に基づいて、プリンタ１１２で利用可能な機能を含む図１０に示す設定画面を生成して表示する。ここで、接続可能なプリンタが複数ある場合には、プリンタ名を表示し、設定画面１００１を表示する前にユーザに印刷するプリンタを選択させるための表示画面を生成する。そして、ＣＰＵ１００は、選択されたプリンタに対応するプリンタ情報を用いて、選択されたプリンタの設定画面を表示する。尚、プリンタの選択は、上記に限らず、最も早く応答してきたプリンタや、より機能が多いプリンタ、印刷ジョブが混雑していないプリンタを選択する等の方法によって行われても良い。

このように、ＣＰＵ１００は、印刷用紙の種類・サイズ、印刷品位、縁あり／なし等のプリンタ１１２で利用可能な機能を選択させる設定画面１００１を表示する。設定画面の生成方法の一例として、以下に、ＨＴＭＬ記述のサンプルを示す。
------------------------------------------------
＜!DOCTYPE html＞
＜head＞
＜title＞印刷設定 ＜/title＞
＜script＞
＜!-- 用紙サイズ --＞
var PaperSizeNum = GetPaperSizeNum();
var p = document.getElementById("PaperList");
var i;
for(i=0; i＜PaperSizeNum; i++){
p.options[i] = new Option(GetPaperSizeT(i), GetPaperSizeV(i));
}
＜!-- 用紙種類--＞
var MediaTypeNum = GetMediaTypeNum();
var m = document.getElementById("MediaList");
var j;
for(j=0; j＜MediaTypeNum; j++){
m.options[j] = new Option(GetMediaTypeT(j), GetMediaTypeV(j));
}
＜!-- 印刷品位 --＞
var QualityNum = GetQualityNum();
var q = document.getElementById("QualityList");
var k;
for(k=0; k＜ QualityNum; k++){
q.options[k] = new Option(GetQualityT(k), GetQualityV(k));
}
＜!-- 縁あり/なし--＞
var BorderNum = GetBorderNum();
var b = document.getElementById("BorderList");
var l;
for(l=0; l＜BorderNum; l++){
b.options[l] = new Option(GetBorderT(l), GetBorderV(l));
}
＜!-- 印刷関数--＞
function printer() {
SetPrint(document.getElementById("PaperList").value,
document.getElementById("MediaList").value,
document.getElementById("QualityList").value,
document.getElementById("BorderList").value);
}
＜/script＞
＜/head＞
＜!-- 表示部 --＞
＜body＞
用紙サイズ ＜select id="PaperList"＞＜/select＞＜br /＞
用紙種類 ＜select id="MediaList"＞＜/select＞＜br /＞
印刷品位 ＜select id="QualityList"＞＜/select＞＜br /＞
縁あり/なし ＜select id="BorderList"＞＜/select＞＜br /＞
＜br /＞
＜button id="btn1" onclick="printer()"＞設定完了＜/button＞
＜/body＞
＜/html＞
------------------------------------------------
上記のＧｅｔＰａｐｅｒＳｉｚｅＮｕｍ（）、ＧｅｔＭｅｄｉａＴｙｐｅＮｕｍ（）、ＧｅｔＱｕａｌｉｔｙＮｕｍ（）、ＧｅｔＢｏｒｄｅｒＮｕｍ（）は、ネイティブ関数であり、それぞれの項目数を取得する機能を備える。例えば、プリンタが対応している用紙サイズがＡ４、Ａ５、Ｂ５、Ｌ判の４種類である場合、ＧｅｔＰａｐｅｒＳｉｚｅＮｕｍ（）は４を返す。

ＧｅｔＰａｐｅｒＳｉｚｅＴ（ｎ）、ＧｅｔＭｅｄｉａＴｙｐｅＴ（ｎ）、ＧｅｔＱｕａｌｉｔｙＴ（ｎ）、ＧｅｔＢｏｒｄｅｒＴ（ｎ）もネイティブ関数であり、引数ｎの値番目の文字列を返す。例えば、用紙サイズのテキストを返す関数のＧｅｔＰａｐｅｒＳｉｚｅ（０）の返り値は「Ａ４」、ＧｅｔＰａｐｅｒＳｉｚｅ（１）の返り値は「Ａ５」となる。これらの値は、プリンタから受信するプリンタ情報からネイティブ関数が取り出す。

ＧｅｔＰａｐｅｒＳｉｚｅＶ（ｎ）、ＧｅｔＭｅｄｉａＴｙｐｅＶ（ｎ）、ＧｅｔＱｕａｌｉｔｙＶ（ｎ）、ＧｅｔＢｏｒｄｅｒＶ（ｎ）もネイティブ関数であり、引数ｎの値番目の文字列を返す。例えば、用紙種類のテキストを返す関数のＧｅｔＭｅｄｉａＴｙｐｅＴ（ｎ）の返り値は「光沢紙」のように、ユーザに表示する際の文言である。これに対して、ＧｅｔＭｅｄｉａＴｙｐｅＶ（０）の返り値は「ＧｌｏｓｓｙＰａｐｅｒ」とプリンタが解釈可能な表現となっている。

これらの文言や表現は、プリンタ１１２から送られてきた情報と関連付けてネイティブが決定する。例えば、プリンタ１１２から送られてきた情報から取り出した値が「ＧｌｏｓｓｙＰａｐｅｒ」であった場合、表示するテキストは「光沢紙」と決定される。決定の方法として、例えば、ネイティブは、予め保持されたこれらの対応テーブルに従って、表示するテキストを決定する。

尚、上記では、例として、用紙サイズ、用紙種類、印刷品位、縁あり／なしの設定を行う仕様であるが、これに限定されるものではない。他の例として、両面／片面、カラー／モノクロ、画像補正のオン／オフ等の他の設定項目でも良い。また、前述のように印刷機能のみではなく、プリンタ１１２が処理可能な画像処理や解析処理、静かに印刷するモードの有無、メモリカードの利用有無、インク残量などのステータスなどの情報を表示するようにしても良い。

Ｓ７１０では、ＣＰＵ１００は、スクリプト層２１７において、設定画面１００１に対するユーザ操作に基づいて、プリンタ１１２に設定する機能を選択する。上記の例で示したＨＴＭＬを、レンダリング部２１６を用いてディスプレイ１０４に表示した例が、図１０に示す設定画面１００１である。ネイティブ層２１８を介してプリンタ情報を要求し、プリンタ情報から上記のネイティブ関数を用いて取得した情報に基づいて、設定画面１００１が生成されている。尚、上記ＨＴＭＬは、スクリプト層２１７、ネイティブ層２１８のいずれで生成されても良い。

また、図１０に示す用紙サイズ等の設定項目は、それぞれプルダウンメニューになっており、ユーザ操作によって項目を選択することができる。ここで、設定画面１００１は、プルダウンメニューによって、用紙サイズの設定項目として選択可能な項目の一覧が表示されている状態を示しており、ユーザ操作によってＡ４やＡ５等の用紙サイズの選択を受け付けることができる。

Ｓ７１１では、ＣＰＵ１００は、設定完了ボタン１００２に対するユーザ操作を検知すると、スクリプト層２１７において、ユーザ操作によって選択された設定項目を含む設定情報を生成して、ネイティブ層２１８へ送信する。上記ＨＴＭＬ記述の例にあるＳｅｔＰｒｉｎｔ（）もバインディング機能を有するネイティブ関数である。上記の例では、ＳｅｔＰｒｉｎｔ（）を用いて、用紙サイズ、用紙種類、印刷品位、縁あり／なしの設定を文字列としてネイティブ層２１８へ渡している。

Ｓ７１２では、ＣＰＵ１００は、ネイティブ層２１８において、バインディング機能によりスクリプト層２１７から設定情報を受信する。ネイティブ層２１８では、受信した設定情報に基づいて、プリンタ１１２の通信プロトコルに従って、プリントコマンドが生成される。そして、生成されたプリントコマンドは、通信制御部２１３を介してプリンタ１１２へ送信される。

［レンダリング及びプリント］
図１０に示した設定画面１００１の設定完了ボタン１００２が押下されることにより、図３のＳ３５のレンダリング及びプリント処理が開始する。ここでは、図３のＳ３５のレンダリング及びプリントの詳細について、図８を用いて説明する。本実施形態では、レンダリング及びプリントに関しては、アプリケーションがバックグランドに入っても処理を継続するように記述されていることとする。例えば、ｉＯＳであれば、ｂｅｇｉｎＢａｃｋｇｒｏｕｎｄＴａｓｋＷｉｔｈＥｘｐｉｒａｔｉｏｎＨａｎｄｌｅｒなどの機能を利用することで、バックグランドでの処理継続が可能となる。

Ｓ８０１では、ＣＰＵ１００は、スクリプト層２１７において、インジケータ起動依頼をＯＳ層２１９に送信し、Ｓ８０２では、ＣＰＵ１００は、ＯＳ層２１９において、インジケータを表示する。

Ｓ８０３では、ＣＰＵ１００は、スクリプト層２１７において、ＵＩ表示に用いていた印刷対象となる印刷コンテンツをネイティブ層２１８へ送信する。なお、Ｓ８０４、Ｓ８０５、Ｓ８０６など、スクリプト層２１７でも実行可能な処理は、スクリプト層２１７で実行されるようにしても良い。

本実施形態では、印刷コンテンツは、写真１枚、スタンプ１つのＳＶＧ（Ｓｃａｌａｂｌｅ Ｖｅｃｔｏｒ Ｇｒａｐｈｉｃｓ）を例として説明する。写真１枚、スタンプ１つのＳＶＧコンテンツの記述例を以下に示す。
-------------------------------------------------------------------------------
＜svg
xmlns=”http://www.w3.org/2000/svg”
xmlns:xlink=”http://www.w3.org/1999/xlink”
width=”640” height=”480” viewBox=”0 0 640 480”＞
＜image width=”640” height=”480” x=”0” y=”0”
xlink:href=”画像データ” id=”画像ID”＞＜/image＞
＜image width=”200” height=”200” x=”300” height=”50”
xlink:href=”スタンプのパス指定”
id=”スタンプのID”＞＜/image＞
＜/svg＞
-------------------------------------------------------------------------------
以後、上記のＳＶＧ記述に基づいて、レンダリングについて説明する。但し、上記ＳＶＧは概略を説明するためのものであるので、設定の詳細な記述については省略している。

Ｓ８０４では、ＣＰＵ１００は、ネイティブ層２１８において、印刷情報からプリンタ１１２へ送信する出力解像度を取得し、そのサイズへＳＶＧを変更する。例えば、プリンタ１１２から取得した出力解像度のサイズが４０００ｐｘ×３０００ｐｘであれば、ＳＶＧは下記のように書き換えられる。
-------------------------------------------------------------------------------
＜svg
xmlns=”http://www.w3.org/2000/svg”
xmlns:xlink=”http://www.w3.org/1999/xlink”
width=”4000” height=”3000” viewBox=”0 0 640 480”＞
＜image width=”640” height=”480” x=”0” y=”0”
xlink:href=”画像データ” id=”imageID”＞＜/image＞
＜image width=”200” height=”200” x=”300” height=”50”
xlink:href=”スタンプのパス指定”
id=”スタンプのID”＞＜/image＞
＜/svg＞
-------------------------------------------------------------------------------
上記では、ＳＶＧの横幅、縦幅がプリンタ１１２へ送信する画像サイズに合わせて変更されている。

Ｓ８０５では、ＣＰＵ１００は、ネイティブ層２１８において、上記ＳＶＧの画像に関する記述を、ブロック画像群を用いた記述へと変更する。ここで、Ｓ４０７、Ｓ５０６において、ＲＧＢデータが上半分、下半分に二分割されたブロック画像群が作成され、「imageID_above.bmp」、「imageID_below.bmp」でアクセス可能な状態で保存されているものとする。ＳＶＧの画像に関する記述を上記の２つのブロック画像群を用いた記述へ変更したＳＶＧは、以下となる。
-------------------------------------------------------------------------------
＜svg
xmlns=”http://www.w3.org/2000/svg”
xmlns:xlink=”http://www.w3.org/1999/xlink”
width=”4000” height=”3000” viewBox=”0 0 640 480”＞
＜symbol id=”imageID” viewBox=”0 0 640 480”＞
＜image width=”640” height=”240” x=”0” y=”0”
xlink:href=”imageID_above.bmp”＞＜/image＞
＜image width=”640” height=”240” x=”0” y=”240”
xlink:href=”imageID_below.bmp”＞＜/image＞
＜/symbol＞
＜use xlink:href=”#imageID” x=”0” y=”0” width=”640” height=”480”/＞
＜image width=”200” height=”200” x=”300” height=”50”
xlink:href=”スタンプのパス指定”
id=”スタンプのID”＞＜/image＞
＜/svg＞
-------------------------------------------------------------------------------
上記では、画像に関する記述箇所が、ブロック画像群を用いた記述へ変更されている。ブロック画像群を用いた記述では、ファイル保存されたデータをパスで指定する方法が用いられても良いし、ＢＡＳＥ６４として画像データの実体を入れ込む方法が用いられても良い。

Ｓ８０６では、ＣＰＵ１００は、ネイティブ層２１８において、ＳＶＧに対して特定のマーカー要素（以下、マーカーという）を付与する。本実施形態では、ＣＰＵ１００は、印刷コンテンツの描画を行う際、描画完了のタイミングを判断するために、その印刷コンテンツに対して、判断基準となる要素を特定する。本実施形態で特定されるマーカーは、赤帯であり、ＳＶＧコンテンツの右端に付与される。本実施形態では、一例として赤帯を用いているが、これに限られず、付与された情報が判別できるものであればどのようなものでも良い。

赤帯を付与したＳＶＧは以下となる。
-------------------------------------------------------------------------------
＜svg
xmlns=”http://www.w3.org/2000/svg”
xmlns:xlink=”http://www.w3.org/1999/xlink”
width=”4005” height=”3000” viewBox=”0 0 4005 3000”＞
＜svg width=”4000” height=”3000” viewBox=”0 0 640 480”＞
＜symbol id=”imageID” viewBox=”0 0 640 480”＞
＜image width=”640” height=”240” x=”0” y=”0”
xlink:href=”imageID_above.bmp”＞＜/image＞
＜image width=”640” height=”240” x=”0” y=”240”
xlink:href=”imageID_below.bmp”＞＜/image＞
＜/symbol＞
＜use xlink:href=”#imageID” x=”0” y=”0” width=”640” height=”480”/＞
＜image width=”200” height=”200” x=”300” height=”50”
xlink:href=”スタンプのパス指定”
id=”スタンプのID”＞＜/image＞
＜/svg＞
＜rect x=”4000” y=”0” width=”5” height=”100%” fill=”red”/＞
＜/svg＞
-------------------------------------------------------------------------------
上記では、４０００ｐｘ×３０００ｐｘの領域を示すＳＶＧが、４００５ｐｘ×３０００ｐｘの領域のＳＶＧとされている。それらのサイズの差分となる領域は、赤帯が付与される領域となる。赤帯が付与されたＳＶＧ例を図１３に示す。ここで、マーカーとなる赤帯は、描画を最後に実行させるために、ＳＶＧの最後の要素として追加される。赤帯については、Ｓ８１５で後述する。

Ｓ８０７では、ＣＰＵ１００は、ネイティブ層２１８により、アプリケーションがフォアグランドで動作しているか、バックグランドで動作しているかを判定する（端末状態の判断）。モバイル端末においては、着信や、別のアプリケーションを立ち上げるなどの処理が入ると、実行中のアプリケーションは、バックグランドにまわされる。アプリケーションがバックグランドにまわったにも関わらず、負荷の高い処理を続けていると、他のアプリケーションに対して影響を及ぼしてしまう。本実施形態では、これを回避するために、ＣＰＵ１００は、アプリケーションの実行状況を判断し、アプリケーションがバックグランド状態である場合は、そのアプリケーションの処理負荷を低減させる。その動作については後述する。

Ｓ８０８では、ＣＰＵ１００は、ネイティブ層２１８において、ＳＶＧコンテンツから特定の単位領域分をレンダリングするためのＳＶＧを作成する。アプリケーションにおいて、４０００ｐｘ×３０００ｐｘのサイズを一括でレンダリングすることはメモリ的に負荷が高い。これを、例えば４０００ｐｘ×１５００ｐｘのレンダリング２回に分けることができれば、メモリ使用量を減らすことができる。この省メモリ化を目的としたのが、特定の単位領域分をレンダリングするためのＳＶＧであり、以後、この特定の単位領域分をレンダリングするためのＳＶＧをバンドＳＶＧと呼ぶ。ここで、Ｓ８０８では、アプリケーションがフォアグランドで動作していると判定されたとして説明する。

Ｓ８０８では、ＣＰＵ１００は、ネイティブ層２１８において、例えば以下のような記述により一つ目のバンドを作成する。
-------------------------------------------------------------------------------
＜svg
xmlns=”http://www.w3.org/2000/svg”
xmlns:xlink=”http://www.w3.org/1999/xlink”
width=”4005” height=”3000” viewBox=”0 0 4005 3000”＞
＜svg x=”0” y=”0”＞
＜svg width=”4000” height=”3000” viewBox=”0 0 640 480”＞
＜symbol id=”imageID” viewBox=”0 0 640 480”＞
＜image width=”640” height=”240” x=”0” y=”0”
xlink:href=”imageID_above.bmp”＞＜/image＞
＜image width=”640” height=”240” x=”0” y=”240”
xlink:href=”imageID_below.bmp”＞＜/image＞
＜/symbol＞
＜use xlink:href=”#imageID” x=”0” y=”0” width=”640” height=”480”/＞
＜image width=”200” height=”200” x=”300” height=”50”
xlink:href=”スタンプのパス指定”
id=”スタンプのID”＞＜/image＞
＜/svg＞
＜rect x=”4000” y=”0” width=”5” height=”3000” fill=”red” /＞
＜/svg＞
＜/svg＞
上記では、ＳＶＧに対しｘ座標、ｙ座標を操作するための情報が付与されている。このｘ、ｙ座標の値を変更することで、描画されるＳＶＧの領域を変更することが可能となる。一つ目のバンドとしては、ｘ、ｙ座標ともに０である。

Ｓ８０９では、ＣＰＵ１００は、ネイティブ層２１８により、ＯＳ層２１９に対してバンドサイズ用の画面生成を依頼する。本実施形態では、一つ目のバンドＳＶＧから４００５ｐｘ×１５００ｐｘの領域を取得する。そのような構成により、４００５ｐｘ×３０００ｐｘを一括でレンダリングする場合に比べて、メモリの使用量を低減することができる。

Ｓ８１０では、ＣＰＵ１００は、ＯＳ層２１９において、バンドＳＶＧ用の画面生成（４００５ｐｘ×１５００ｐｘ）を実行する。ここで生成される画面領域は、描画の実行領域となる。バンドＳＶＧのサイズに関する情報は、バンドＳＶＧ自体ではなく、ネイティブ層２１８が保持している。また、生成する画面は、ＵＩに表示されないオフスクリーン画面として生成される。

Ｓ８１１では、ＣＰＵ１００は、ネイティブ層２１８において、一つ目のバンドＳＶＧをＳ８１０で生成した画面に描画するようにＯＳ層２１９に依頼する描画依頼の制御を行う。Ｓ８１２では、ＣＰＵ１００は、ＯＳ層２１９において、バンドＳＶＧの情報をロードして描画を実行する。バンドＳＶＧの情報がロードできたタイミングで、ネイティブ層２１８は、ロード完了の通知を受け取ることができる。この通知は、ＯＳに標準的に備わっているものが用いられる。例えばｉＯＳアプリ作成で利用するＯｂｊｅｃｔｉｖｅ−Ｃ言語であればｗｅｂＶｉｅｗＤｉｄＦｉｎｉｓｈＬｏａｄ関数である。また、Ａｎｄｒｏｉｄアプリを作成で利用するＪａｖａ言語であれば、ｏｎＰａｇｅＦＩｎｉｓｈｅｄ関数などが相当する。また、この通知は、Ｓ８１２における描画の完了に関わらず行われる。そのため、ネイティブ層２１８がこの通知を受け取ったタイミングにおいて、Ｓ８１１で依頼された描画が完了していないことが起こり得る。

Ｓ８１３では、ＣＰＵ１００は、ネイティブ層２１８において、ＯＳ層２１９に対し画像情報を依頼する。ここでの画像情報とは、オフスクリーン画面に表示されているＲＧＢＡデータのことである。言い換えれば、画面キャプチャを実行するということである。

Ｓ８１４では、ＣＰＵ１００は、ＯＳ層２１９において、画面キャプチャを実行し、取得したＲＧＢＡデータをネイティブ層２１７へ送信する。ここで、バンドＳＶＧには、４００５ｐｘ×３０００ｐｘの情報が記述されている。しかしながら、実際のＯＳ層２１９で確保された描画の実行領域は４００５ｐｘ×１５００ｐｘしかない。この場合、確保した実行領域からはみ出した部分に関しては描画が実行されない。そのため、４００５ｐｘ×１５００ｐｘの領域を確保することで、バンドＳＶＧの上半分のみが描画され、結果として、ネイティブ層２１８は、上半分の情報のみを取得することが可能となる。この方法により、４００５ｐｘ×１５００ｐｘの領域に、ｙ座標を変化させた下記のバンドＳＶＧを読み込ませることで、ＳＶＧコンテンツの下半分のみを取得することが可能となる。
＜svg
xmlns=”http://www.w3.org/2000/svg”
xmlns:xlink=”http://www.w3.org/1999/xlink”
width=”4005” height=”3000” viewBox=”0 0 4005 3000”＞
＜svg x=”0” y=”-1500”＞
＜svg width=”4000” height=”3000” viewBox=”0 0 640 480”＞
＜symbol id=”imageID” viewBox=”0 0 640 480”＞
＜image width=”640” height=”240” x=”0” y=”0”
xlink:href=”imageID_above.bmp”＞＜/image＞
＜image width=”640” height=”240” x=”0” y=”240”
xlink:href=”imageID_below.bmp”＞＜/image＞
＜/symbol＞
＜use xlink:href=”#imageID” x=”0” y=”0” width=”640” height=”480”/＞
＜image width=”200” height=”200” x=”300” height=”50”
xlink:href=”スタンプのパス指定”
id=”スタンプのID”＞＜/image＞
＜/svg＞
＜rect x=”4000” y=”0” width=”5” height=”3000” fill=”red”/＞
＜/svg＞
＜/svg＞
ＳＶＧで記述されたサイズより小さい実行領域にロードする例を図１２（ａ）に示し、ｙ座標をずらし、かつ、ＳＶＧで記述されたサイズより小さい実行領域にロードする例を図１２（ｂ）に示す。

Ｓ８１５では、ＣＰＵ１００は、ネイティブ層２１８において、取得したＲＧＢＡデータの右端が赤色になっているかを確認する。Ｓ８１２でＯＳ層２１９からロード完了の情報が送られてきているが、これはＳＶＧデータ読み込み完了のタイミングであり、ＳＶＧの描画が完了したタイミングというわけではない。つまり、ＳＶＧデータ読み込み完了と描画完了との間にはタイムラグがあり、この間に画面キャプチャを実行してしまうと、所望の画像を得ることができない。そのため、本実施形態では、上記のように、ロードさせるＳＶＧデータに、所定の要素として、描画が最後に行われる赤帯のマーカー要素を付与し、ＳＶＧコンテンツの描画が完了したか否かの判断基準としている。

Ｓ８１６では、ＣＰＵ１００は、ネイティブ層２１８において、赤帯の有無を判定する。赤帯がないと判定された場合は、Ｓ８１３の処理から繰り返す。その場合、所定時間経過してからＳ８１３から繰り返すことにより、ＣＰＵ１００の負荷を低減するようにしても良い。赤帯があると判定された場合、ＣＰＵ１００は、Ｓ８１５において取得されたデータを出力対象（印刷対象）であると判定し、処理がＳ８１７へ進む。

Ｓ８１７では、ＣＰＵ１００は、ネイティブ層２１８において、オフスクリーン画面のリセットをＯＳ層２１９に依頼する。

Ｓ８１８では、ＣＰＵ１００は、ＯＳ層２１９において、オフスクリーン画面の破棄を行う。この画面破棄には二つの理由がある。一つ目の理由は、次のバンドＳＶＧをロードしたときに、前回の赤帯が残ったままとなり、ＯＳからの通知に対応するデータとして誤ってキャプチャしてしまうことをなくすためである。しかしながら、画面破棄の代わりに、バンドＳＶＧ毎に付けるマーカーの色や形などを変化させてもよい。キャプチャを行うときに、キャプチャすべきデータに付与したマーカーの色や形と、キャプチャ対象としてメモリに展開されている画面内のマーカーの色や形とが一致するかネイティブ装置が比較する。その比較の結果、両者が一致した場合、ネイティブ層がキャプチャを行い、両者が一致していない場合、キャプチャを行わないようにしてもよい。

Ｓ８１８における画面破棄の二つ目の理由は、バンドＳＶＧのサイズを動的に変える可能性があるためである。バンドＳＶＧサイズが途中で変更される例は後述する。

なお、Ｓ８１８における画面破棄により、ＯＳ層により描画が行われ且つネイティブ層が描画データを取得するメモリ領域（例えばＲＡＭ１０２内の領域）において、データ削除が行われる。このとき、例えば該メモリ領域の全データが削除されてもよいし、または描画されたデータ全体が削除されてもよいし、または描画されたデータのうち、マーカーの部分が削除されてもよい。

Ｓ８１９では、ＣＰＵ１００は、ネイティブ層２１８において、取得したＲＧＢＡデータをＪＰＥＧデータへ変換する。ここで、Ｓ８１４で送られてくるＲＧＢＡデータには印刷には不要な透過度（Ａ）の情報と、赤帯の情報とが入っている。ＪＰＥＧ変換は、この二つの情報を印刷対象の画像から除くように実行される。

Ｓ８２０では、ＣＰＵ１００は、ネイティブ層２１８において、プリンタ１１２へ送信するためのプリントコマンドをＳ８１９で生成したＪＰＥＧデータに付与する。ここで、ＪＰＥＧデータに付与するプリントコマンドは、プリンタ設定の情報に基づいて生成される。プリントコマンドは、プリンタ１１２を制御するためのコマンドであり、送信する情報が何番目のバンドかを示す情報や、末尾のバンドかを判断するためのフッタ情報などを含む。

Ｓ８２１では、ＣＰＵ１００は、ネイティブ層２１８において、ＯＳ層２１９に対して、プリントコマンドやＪＰＥＧデータを含む印刷情報の送信（プリンタへの出力）を依頼する。Ｓ８２２では、ＣＰＵ１００は、ＯＳ層２１９において、ネイティブ層２１８から受け取った印刷情報をプリンタ１１２へ送信する。印刷情報の送信の完了後、Ｓ８２４へ進む。Ｓ８２３では、プリンタ１１２は、ＯＳ層２１９から受け取った印刷情報に基づいて、印刷を実行する。

Ｓ８２４では、ＣＰＵ１００は、ネイティブ層２１８において、レンダリングが終了したか否かを判定する。レンダリング終了の判定は、例えば、取得した画像の高さの合計が出力サイズの高さと一致しているか、終了判断のためのフラグが立っているかなどに基づいて行われる。上記は一例であり、その他の判断方法が用いられても良い。レンダリングが終了していないと判定された場合は、Ｓ８０７の処理から繰り返す。

Ｓ８２４でレンダリング終了と判定された場合、Ｓ８２５へ進み、ＣＰＵ１００は、スクリプト層２１７において、インジケータの停止依頼をＯＳ層２１９へ送信する。Ｓ８２６では、ＣＰＵ１００は、ＯＳ層２１９において、インジケータを停止し、その後、図８の処理を終了する。本例では、まだ４０００ｐｘ×３０００ｐｘのうち、４０００ｐｘ×１５００ｐｘのＳＶＧまでしかレンダリングが終了していないので、Ｓ８２４から引き続きＳ８０７へ戻る。以下、その続きの処理について説明する。

以下では、Ｓ８０７でアプリケーションがバックグランドで実行されていると判定されたとして説明する。一つ目のバンドＳＶＧは４０００ｐｘ×１５００ｐｘのサイズで画像の取得を行った。ここで、バックグラウンド実行時には、前述のように、メモリ使用量をなるべく低減することが重要である。

Ｓ８０８では、ＣＰＵ１００は、ネイティブ層２１８において、Ｓ８０７の結果を受け、Ｓ８０８以降の処理を行う。本実施形態では、バンドＳＶＧのサイズを小さくすることでメモリ使用量を低減する。そのため、二つ目のバンドは、一例として４０００ｐｘ×７５０ｐｘのサイズとする。その場合のバンドＳＶＧの記述は以下となる。
-------------------------------------------------------------------------------
＜svg
xmlns=”http://www.w3.org/2000/svg”
xmlns:xlink=”http://www.w3.org/1999/xlink”
width=”4005” height=”3000” viewBox=”0 0 4005 3000”＞
＜svg x=”0” y=”-1500”＞
＜svg width=”4000” height=”3000” viewBox=”0 0 640 480”＞
＜symbol id=”imageID” viewBox=”0 0 640 480”＞
＜image width=”640” height=”240” x=”0” y=”0”
xlink:href=”imageID_above.bmp”＞＜/image＞
＜image width=”640” height=”240” x=”0” y=”240”
xlink:href=”imageID_below.bmp”＞＜/image＞
＜/symbol＞
＜use xlink:href=”#imageID” x=”0” y=”0” width=”640” height=”480”/＞
＜image width=”200” height=”200” x=”300” height=”50”
xlink:href=”スタンプのパス指定”
id=”スタンプのID”＞＜/image＞
＜/svg＞
＜rect x=”4000” y=”0” width=”5” height=”3000” fill=”red”/＞
＜/svg＞
＜/svg＞
-------------------------------------------------------------------------------
先述のように、描画は、ＯＳ層２１９が確保したサイズの領域で実行されるので、バンドＳＶＧ自体には４００５ｐｘ×３０００ｐｘの情報が記述されていても良い。但し、既に取得した情報を再度取得することがないように、バンドＳＶＧのｙ座標は適切に変更される必要がある。また、ＳＶＧの特定の領域を表示する方法として、例えば、ＳＶＧのｖｉｅｗＢｏｘという属性を操作する方法などが用いられても良い。

Ｓ８０９では、ＣＰＵ１００は、ネイティブ層２１８において、ＯＳ層２１９に対して情報を取得するサイズ（４００５ｐｘ×７５０ｐｘ）のオフスクリーン画面を生成するよう依頼する。

Ｓ８１０〜Ｓ８２３は、既に説明した処理と同じ処理が行われる。本例の場合、Ｓ８２４では、印刷コンテンツの全領域のレンダリングは終了していないことになるが、以降の処理は既に行った説明と同じであるので、その説明を省略する。

以上のように、本実施形態によれば、ハイブリッドアプリケーションにおいて、レンダリング対象のＳＶＧコンテンツの描画完了のタイミングが判断可能となる。

［第２の実施形態］
第１の実施形態では、バンドＳＶＧの描画完了次第、描画完了したバンドＳＶＧのデータをプリンタ１１２へ送信する処理を繰り返していた。本実施形態では、全てのバンドＳＶＧのレンダリングが完了したデータを一括でプリンタ１１２へ送信する。その結果、プリンタ１１２は印刷対象のデータを全て受け取ってから印刷を開始するので、印刷途中での情報処理装置１１５とのタイムアウト等による通信断による印刷中断を防ぐことができる。

以下、図１４を参照しながら、第１の実施形態と異なる点について説明する。Ｓ１４０１〜Ｓ１４０４は、Ｓ８０１〜Ｓ８０４と同じであるのでその説明を省略する。

Ｓ１４０５では、ＣＰＵ１００は、ネイティブ層２１８において、バンドＳＶＧを作成し、マーカーを付加する。本実施形態では、４０００ｐｘ×３０００ｐｘのＳＶＧコンテンツについて、４０００ｐｘ×１５００ｐｘのバンドＳＶＧを２つ作成するものとする。また、それら２つのバンドＳＶＧは、赤帯のマーカーが付加されるバンドＳＶＧと、青帯のマーカーが付加されるバンドＳＶＧである。２つのバンドＳＶＧの記述例を下記に示す。
-------------------------------------------------------------------------------
［一つ目のバンドＳＶＧ］
＜svg
xmlns=”http://www.w3.org/2000/svg”
xmlns:xlink=”http://www.w3.org/1999/xlink”
width=”4005” height=”3000” viewBox=”0 0 4005 3000”＞
＜svg x=”0” y=”0”＞
＜svg width=”4000” height=”3000” viewBox=”0 0 640 480”＞
＜image xlink:href=”image.bmp” x=”0” y=”0” width=”640” height=”480”/＞
＜image width=”200” height=”200” x=”300” height=”50”
xlink:href=”スタンプのパス指定”
id=”スタンプのID”＞＜/image＞
＜/svg＞
＜rect x=”4000” y=”0” width=”5” height=”3000” fill=”red”/＞
＜/svg＞
＜/svg＞
［二つ目のバンドＳＶＧ］
＜svg
xmlns=”http://www.w3.org/2000/svg”
xmlns:xlink=”http://www.w3.org/1999/xlink”
width=”4005” height=”3000” viewBox=”0 0 4005 3000”＞
＜svg x=”0” y=”-1500”＞
＜svg width=”4000” height=”3000” viewBox=”0 0 640 480”＞
＜image xlink:href=”image.bmp” x=”0” y=”0” width=”640” height=”480”/＞
＜image width=”200” height=”200” x=”300” height=”50”
xlink:href=”スタンプのパス指定”
id=”スタンプのID”＞＜/image＞
＜/svg＞
＜rect x=”4000” y=”0” width=”5” height=”3000” fill=”blue”/＞
＜/svg＞
＜/svg＞
-------------------------------------------------------------------------------
複数のバンドＳＶＧでマーカーが同じであると、一つ前のマーカーを間違えて取得し、それを描画完了と誤認識してしまう可能性がある。本実施形態では、上記のように異なるマーカーを付加することにより、そのような誤認識を防ぐことができる。

Ｓ１４０６〜Ｓ１４１１は、Ｓ８０９〜Ｓ８１４と同じであるので、その説明を省略する。

Ｓ１４１２では、ＣＰＵ１００は、ネイティブ層２１８において、マーカーを確認する。その際、現在のバンドＳＶＧはどのようなマーカーがあるかをネイティブ層２１８が認識しておく必要があるので、ネイティブ層２１８において、赤帯もしくは青帯であるというマーカー情報をＳＶＧの記述から読み取って別途管理しておく。

Ｓ１４１３〜Ｓ１４１５は、Ｓ８１６〜Ｓ８１８と同じであるので、その説明を省略する。

Ｓ１４１６で、ＣＰＵ１００は、ネイティブ層２１８において、取得したＲＧＢＡデータからＪＰＥＧデータを作成する。この操作はバンドＳＶＧの数分繰り返され、１つのＪＰＥＧデータとして生成する。本例では、４０００ｐｘ×３０００ｐｘのＪＰＥＧデータが生成されることになり、それは、印刷対象のＳＶＧコンテンツに相当する。

Ｓ１４１７は、Ｓ８２４と同じであるのでその説明を省略する。Ｓ１４１７でレンダリングが終了したと判定された場合、Ｓ１４１８に進み、レンダリングが終了していないと判定された場合、Ｓ１４０５に戻る。Ｓ１４１８は、Ｓ８２０と同じであるのでその説明を省略する。

４０００ｐｘ×３０００ｐｘのＪＰＥＧデータが生成されると、Ｓ１４１９では、ＣＰＵ１００は、ネイティブ層２１８において、プリンタ制御に必要なプリントコマンドがＪＰＥＧデータに付与される。本実施形態では、全てのデータを受け取ってから印刷を始めるモードであることを認識可能なプリントコマンドが追加される。また、全てのデータを受け取ってから印刷を始めるモードをプリントコマンドで指定しているが、方法はこれに限られない。例えば、プリンタ１１２本体を直接操作してそのようなモードを設定する方法や、ユーザ任意のデフォルト設定を予め登録しておくなどの方法でも良い。Ｓ１４１９では、ＣＰＵ１００は、ネイティブ層２１８において、ＯＳ層２１９に対し、印刷情報送信依頼とともに、プリントコマンドを含む印刷情報をＯＳ層２１９へ送信する。Ｓ１４２０では、ＣＰＵ１００は、ＯＳ層２１９において、プリンタ１１２へ印刷情報を送信する。

Ｓ１４２１では、プリンタ１１２は、印刷情報を取得する。Ｓ１４２２では、プリンタ１１２は、印刷するのに必要な情報を全て受け取ったか否かを判定する。Ｓ１４２２では、プリンタ１１２は、印刷するのに必要な情報を全て受け取ったと判定後、Ｓ１４２３において印刷を実行する。印刷するのに必要な情報を全て受け取っていないと判定された場合は、Ｓ１４２１の処理を繰り返す。印刷情報を全て受け取ったか否かの判定は、例えば、Ｓ１４２０での送信の際にデータ末尾に終了を意味する特定の情報を付与しておき、その情報に基づいて行うようにしても良い。プリンタ１１２は、所定時間の経過後においても、Ｓ１４２２で印刷するのに必要な情報を全て受け取っていないと判定した場合には、警告メッセージを情報処理装置１１５に送信するようにしても良い。

Ｓ１４２４、Ｓ１４２５は、Ｓ８２５、Ｓ８２６と同じであるので、その説明を省略する。

以上のように、本実施形態によれば、全てのバンドＳＶＧのレンダリングが完了したデータを一括でプリンタ１１２へ送信する。その結果、プリンタ１１２は印刷対象のデータを全て受け取ってから印刷を開始するので、印刷途中での情報処理装置１１５とのタイムアウト等による通信断による印刷中断を防ぐことができる。

［第３の実施形態］
第１の実施形態では、印刷コンテンツの印刷画像領域外にマーカーを付加していたが、本実施形態では、印刷コンテンツの印刷画像領域内にマーカーを付加する。プリンタ１１２では、縁なし印刷が行われる場合がある。縁なし印刷とは、印刷画像の周囲に余白がない状態での印刷のことである。縁がある場合と縁がない場合の例を図１５に示す。ここで、プリンタ１１２は、例えば、図１６に示すように、印刷画像を印刷対象の記録媒体上（用紙等）の印刷対象領域のサイズより大きなサイズに拡大し、印刷画像の一部（内部）を印刷対象とすることで縁なし印刷を行うことがある。このような縁なし印刷においては、図１６に示すように、印刷コンテンツの印刷画像領域内で、印刷対象領域から溢れる部分へのマーカー配置が可能となる。例えば、Ｓ８０６で付与される赤帯をＳＶＧコンテンツ内に追加する場合のＳＶＧは下記となる。
-------------------------------------------------------------------------------
＜svg
xmlns=”http://www.w3.org/2000/svg”
xmlns:xlink=”http://www.w3.org/1999/xlink”
width=”4000” height=”3000” viewBox=”0 0 640 480”＞
＜symbol id=”imageID” viewBox=”0 0 640 480”＞
＜image width=”640” height=”240” x=”0” y=”0”
xlink:href=”imageID_above.bmp”＞＜/image＞
＜image width=”640” height=”240” x=”0” y=”240”
xlink:href=”imageID_below.bmp”＞＜/image＞
＜/symbol＞
＜use xlink:href=”#imageID” x=”0” y=”0” width=”640” height=”480”/＞
＜image width=”200” height=”200” x=”300” height=”50”
xlink:href=”スタンプのパス指定”
id=”スタンプのID”＞＜/image＞
＜/svg＞
＜rect x=” 0” y=”0” width=”5” height=”100%” fill=”red”/＞
＜/svg＞
-------------------------------------------------------------------------------
上記のＳＶＧと、Ｓ８０６で赤帯を付与した場合のＳＶＧの違いは二つある。一つは、ＳＶＧのサイズが４０００ｐｘ×３０００ｐｘであり、本実施形態によれば、マーカー分のサイズを低減することができる。一つは、赤帯がＳＶＧコンテンツの印刷画像領域内に付与される点である。上記の例では、ｘ座標０、ｙ座標０の位置に横幅５ｐｘ、縦幅３０００ｐｘ（縦幅１００％指定）の赤帯を付与したものとなっている。しかしながら、マーカーの設定はこれに限られず、縁なし印刷を実行する際に、印刷対象領域からはみ出る領域であればどこに付与されても良い。また、マーカーを印刷コンテンツの印刷画像領域内に付与するか否かの判定は、Ｓ３４におけるユーザ設定で、縁あり印刷が選択されたか、若しくは、縁なし印刷が選択されたかの情報に基づいて行われるようにしても良い。

［第４の実施形態］
本実施形態では、第１〜第３の実施形態で説明したようなマーカー要素を用いるのではなく、ＯＳ層２１９からのデータ（ＲＧＢＡデータ）のキャプチャを行う度に、前に取得したデータと内容を比較し、内容に変化がなければ、描画が完了していると判定する。以下、上記の実施形態と異なる点について説明する。

Ｓ１７０１〜Ｓ１７０４は、Ｓ８０１〜Ｓ８０４と同じであるので、その説明を省略する。

Ｓ１７０５では、ＣＰＵ１００は、ネイティブ層２１８において、ＯＳ層２１９に対し、Ｓ１７０４で変更された印刷サイズのオフスクリーン画面を生成するように依頼する。Ｓ１７０６では、ＣＰＵ１００は、ＯＳ層２１９において、Ｓ１７０５で指示されたサイズのオフスクリーン画面を生成する。

Ｓ１７０７では、ＣＰＵ１００は、ネイティブ層２１８において、印刷サイズのＳＶＧを、Ｓ１７０６で確保したオフスクリーン画面に描画するようＯＳ層２１９へ依頼する。Ｓ１７０８では、ＣＰＵ１００は、ＯＳ層２１９において、ネイティブ層２１８からＳＶＧをロードし、描画を実行する。ここで、ネイティブ層２１８は、ＯＳ層２１９がロードを完了したタイミングでロード完了情報を受け取る。

Ｓ１７０９では、ＣＰＵ１００は、ネイティブ層２１８において、ロード完了情報を受け取った後、ＯＳ層２１９に対し、画面情報を依頼する。ここで、画面情報とは、Ｓ１７０６で生成したオフスクリーン画面に描画されているＲＧＢＡデータのことである。Ｓ１７１０では、ＣＰＵ１００は、ＯＳ層２１９において、ネイティブ層２１８へＲＧＢＡデータを送信する。

Ｓ１７１１では、ＣＰＵ１００は、ネイティブ層２１８において、ＯＳ層２１９からＲＧＢＡデータを受信する。Ｓ１７１２では、ＣＰＵ１００は、ネイティブ層２１８において、比較画像の有無を判定する。比較画像とは、例えば、ＯＳ層２１９から前回取得したＲＧＢＡデータである。比較画像がないと判定された場合はＳ１７１３へ進み、比較画像があると判定された場合はＳ１７１４へ進む。

Ｓ１７１３では、ＣＰＵ１００は、ネイティブ層２１８において、Ｓ１７１１で取得したＲＧＢＡデータを比較画像としてデータ保存部２２０へ保存する。その後、Ｓ１７０９から処理を繰り返す。つまり、１回目のＯＳ層２１９からのデータ取得の場合、この保存処理が行われることとなる。ここで、Ｓ１７１３では、取得したＲＧＢＡデータをそのまま比較画像として保存するのではなく、縮小を行ったＲＧＢＡデータを保存するようにしてＳ１７１５での比較時間を短縮するようにしても良い。

Ｓ１７１４では、ＣＰＵ１００は、ネイティブ層２１８において、Ｓ１７１１で受信したＲＧＢＡデータが、Ｓ１７１３で保存された比較画像のＲＧＢＡデータと一致しているか否かを判定する。一致していないと判定された場合は、Ｓ１７１１で受信したＲＧＢＡデータを比較画像として登録し（Ｓ１７１３）、Ｓ１７０９からの処理を繰り返す。一致していると判定された場合はＳ１７１６へ進む。

Ｓ１７１６では、ＣＰＵ１００は、ネイティブ層２１８において、ＲＡＭ１０２等の記憶領域に確保された一致回数を示す値をインクリメント（１を加算）する。なお、Ｓ１７１５で一致していないと判定された場合は、ＣＰＵ１００は、一致回数を示す値をリセットする。

Ｓ１７１７で、ＣＰＵ１００は、ネイティブ層２１８において、一致回数を示す値が指定した回数に達したか否かを判定する。指定した回数に達していないと判定された場合はＳ１７０９からの処理を繰り返す。ここで、Ｓ１７０９へ戻る場合に、所定時間待機するなどの処理を行うようにしても良い。指定した回数に達したと判定された場合は、Ｓ１７１８に進む。Ｓ１７１８では、ＣＰＵ１００は、ＯＳ層２１９において、オフスクリーン画面の破棄を行う。

Ｓ１７１９〜Ｓ１７２６は、Ｓ８１９〜Ｓ８２６と同じであるので、その説明を省略する。

以上のように、本実施形態においては、ＯＳ層２１９からキャプチャしたデータを比較画像として保存した上で、再度、ＯＳ層２１９からキャプチャを行う。そして、再度キャプチャしたデータを比較画像と比較し、一致している場合には、描画が完了したと判断する。第１の実施形態では、描画完了の判断基準として赤帯のマーカーを特定し、それを印刷コンテンツの印刷画像領域外に付与していた。また、第２の実施形態では、データの単位領域ごとに、異なる色のマーカーを特定し、それらを印刷コンテンツの印刷画像領域外に付与していた。また、第３の実施形態では、描画完了の判断基準としての赤帯のマーカーを特定し、それを印刷コンテンツの印刷画像領域内で且つ印刷対象領域外に付与していた。そして、本実施形態では、描画完了の判断基準となる要素として、印刷コンテンツ自体を特定している。本実施形態では、そのような構成によって、上記各実施形態と同様に、レンダリング対象のＳＶＧコンテンツの描画完了のタイミングが判断可能となる。

［第５の実施形態］
本実施形態では、印刷コンテンツのうちで最後に描画される要素をマーカーとして用いる。本実施形態におけるＳＶＧコンテンツは下記のものとする。
-------------------------------------------------------------------------------
＜svg id=”SVG”
xmlns=”http://www.w3.org/2000/svg”
xmlns:xlink=”http://www.w3.org/1999/xlink”
width=”640” height=”480” viewBox=”0 0 640 480”＞
＜image width=”640” height=”480” x=”0” y=”0”＞
xlink:href=”image.bmp”＞＜/image＞
＜rect x=”320” y=”240” width=”320” height=”240” fill=”green”/＞
＜/svg＞
-------------------------------------------------------------------------------
上記のＳＶＧコンテンツは、図１８に示すように画面全体に写真（画像領域）１８０１がある例を示す。図１８に示すように、ｘ座標３２０ｐｘ、ｙ座標２４０ｐｘの位置に、横幅３２０ｐｘ、縦幅２４０ｐｘの緑色の四角形領域１８０２が配置されている。

ＳＶＧを描画する際において、＜ｒｅｃｔ＞で記述される要素が最後に描画される。従って、本実施形態では、ＣＰＵ１００は、描画順番が最後の要素である＜ｒｅｃｔ＞を、描画完了の判断基準となる要素として特定する。図１８の例では、最後に描画される要素は緑色の四角形領域である。この要素には、「どの位置に」、「どのサイズで」、「どの色で」という情報が含まれている。ネイティブ層２１８は、それらの情報に基づいて、キャプチャ後の画像において、該当する箇所を参照し、その位置に所定サイズの緑色の四角形領域が出現していれば、描画が完了したと判断する。

ここで、図１８の６４０ｐｘ×４８０ｐｘのコンテンツを、３２００ｐｘ×２４００ｐｘに縦横５倍にした場合を想定する。マーカーの役割を果たす緑色の四角形領域の位置とサイズが縦横５倍に移動するので、ｘ座標１６００ｐｘ、ｙ座標１２００ｐｘの位置を原点に、縦幅１６００ｐｘ、横幅１２００ｐｘの領域に緑色の四角形領域が出現するはずである。ネイティブ層２１８は、上記領域において緑色の四角形領域の有無を判定することで、印刷コンテンツの描画の完了を判断することができる。

また、最後に描画される要素は四角形である必要はなく、「どの位置に」、「どのような情報をもって出現するか」が判定可能なものであれば、テキストでも画像でも他のどのような属性のオブジェクトであっても良い。

画像が最後に描画される要素である場合のＳＶＧコンテンツを下記に示す。
-------------------------------------------------------------------------------
＜svg id=”SVG”
xmlns=”http://www.w3.org/2000/svg”
xmlns:xlink=”http://www.w3.org/1999/xlink”
width=”640” height=”480” viewBox=”0 0 640 480”＞
＜rect x=”0” y=”0” width=”640” height=”480” fill=”green”/＞
＜image width=”320” height=”240” x=”320” y=”240”
xlink:href=”image.bmp”＞＜/image＞
＜/svg＞
-------------------------------------------------------------------------------
上記ＳＶＧは、図１８に示す画像領域と緑色の四角形領域の位置とサイズを入れ替えたものであり、その描画例を図１９に示す。

上記ＳＶＧを、３２００ｐｘ×２４００ｐｘに縦横５倍にした場合、画像領域は、ｘ座標１６００ｐｘ、ｙ座標１２００ｐｘの位置を原点に、１６００ｐｘ×１２００ｐｘで出現することが算出される。ここで、印刷コンテンツとして用いられる画像データはｉｍａｇｅ．ｂｍｐであると分かっているので、予めｉｍａｇｅ．ｂｍｐのＲＧＢデータを取得し、画像領域１９０２を１６００ｐｘ×１２００ｐｘのＲＧＢデータへ変倍しておく。キャプチャ後の画像データからｘ座標１６００ｐｘ、ｙ座標１２００ｐｘを原点とした１６００ｐｘ×１２００ｐｘのＲＧＢデータを抽出してその抽出したデータと、変倍されたＲＧＢデータとを比較することで、印刷コンテンツの描画の完了を判定する。ここでの判定は、例えば、２つのＲＧＢデータの各画素値の差分を取り、差分の総和が閾値以下であるか否かに基づいて行われても良い。

以上のように、ＳＶＧにおける描画順番が最後になる要素をマーカーとして特定することによって、レンダリング対象のＳＶＧコンテンツの描画完了のタイミングが判断可能となる。

［その他の実施形態］
上述の実施形態はマーカーを検知することで、画像取得の判断をおこなうものであるが、逆にマーカーの消失を画像取得の判断に用いても良い。

つまり、あるコンテンツが描画されるべき箇所の下にマーカーを配置しておくことで、マーカーが検出できなくなったタイミングが描画完了のタイミングと判断することも可能である。この場合、マーカーはＳＶＧコンテンツの末尾に書く必要がなく、また、マーカー用に描画領域を広げるなどの処理が不要となる。

例えば、下記のようなＳＶＧの最後のコンテンツが画像（スタンプ）だった場合を考える。
-------------------------------------------------------------------------------
＜svg
xmlns=”http://www.w3.org/2000/svg”
xmlns:xlink=”http://www.w3.org/1999/xlink”
width=”640” height=”480” viewBox=”0 0 640 480”＞
＜image width=”640” height=”480” x=”0” y=”0”
xlink:href=”画像データ” id=”画像ID”＞＜/image＞
＜image width=”200” height=”200” x=”300” height=”50”
xlink:href=”スタンプのパス指定”
id=”スタンプのID”＞＜/image＞
＜/svg＞
-------------------------------------------------------------------------------
上記のＳＶＧに対して青いマーカーを追加し、下記のようなＳＶＧとする。青いマーカーは最後の要素の一個前に追加されている。
-------------------------------------------------------------------------------
＜svg
xmlns=”http://www.w3.org/2000/svg”
xmlns:xlink=”http://www.w3.org/1999/xlink”
width=”640” height=”480” viewBox=”0 0 640 480”＞
＜image width=”640” height=”480” x=”0” y=”0”
xlink:href=”画像データ” id=”画像ID”＞＜/image＞
＜rect width=”200” height=”200” x=”300” height=”50” fill=”blue”/＞
＜image width=”200” height=”200” x=”300” height=”50”
xlink:href=”スタンプのパス指定”
id=”スタンプのID”＞＜/image＞
＜/svg＞
-------------------------------------------------------------------------------
青いマーカーは最後のスタンプ画像と同じ位置、同じサイズで追加されている。このＳＶＧを読み込ませた場合、最後のスタンプ画像が描画されるまで、その領域は青い、もしくは何も描画されていない状態となる。そして、ＳＶＧデータの描画が完了すると、最後のスタンプ画像が青いマーカーに上書きされる。これにより、マーカーを追加した領域に何か描画されてはいるが青色ではないという状態であれば、それが描画完了のタイミングだと判断することが可能である。上記は例として青いマーカーであるが、本来は画像を解析するなどして、スタンプ画像と被らない色をマーカーとして使うことが望ましい。
このように、マーカーの出現を検知するのではなく、マーカーの消失を検知するという方法でも描画完了を検知することが可能である。

本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

１００ ＣＰＵ： １０１ ＲＯＭ： １０２ ＲＡＭ： １１５ 情報処理装置： ２１７ スクリプト層： ２１８ ネイティブ層

Claims (17)

1. 所定の描画処理を実行する描画部を備えるコンピュータを、
   印刷対象のコンテンツと所定の要素との描画を前記描画部に指示する指示手段、
   前記指示手段による指示に対応し且つ前記指示に対する描画の完了に関わらず行われた前記描画部からの通知に基づいて、描画が行われたデータを前記描画部から取得する取得手段、
   前記取得手段により取得されたデータに基づく印刷を印刷装置に実行させる制御手段、
   として機能させ、
   前記取得手段によりデータが取得され且つ当該データに前記所定の要素が含まれる場合、前記制御手段は、当該取得されたデータに基づいて、前記印刷対象のコンテンツの印刷を実行させ、
   前記取得手段によりデータが取得され且つ当該データに前記所定の要素が含まれない場合、前記取得手段が前記描画部から再度データを取得し、前記制御手段は、前記取得手段により再度取得され且つ前記所定の要素を含む当該データに基づいて、前記印刷対象のコンテンツの印刷を実行させる、
   ことを特徴とするプログラム。
2. 前記プログラムは、アプリケーションの実行の際に前記コンピュータが実行可能に翻訳されて実行されるスクリプト命令で構成された第１の層と、前記コンピュータが実行可能な予め翻訳された命令で構成された第２の層と、を有するハイブリッドアプリケーションであり、
   前記コンピュータは、前記第１の層により、ユーザの指示を受け付ける画面をディスプレイに表示し、
   前記コンピュータは、前記画面における前記ユーザの指示に応じて、前記第２の層により、前記指示手段と前記取得手段と前記制御手段として機能することを特徴とする請求項１に記載のプログラム。
3. 前記コンピュータは、前記第２の層により、印刷装置から情報を取得し、
   前記コンピュータは、前記第１の層により、前記印刷装置から取得された前記情報に基づいて前記画面を表示することを特徴とする請求項２に記載のプログラム。
4. 前記コンピュータは、前記第２の層により、前記印刷装置から取得された前記情報を、前記第１の層により解釈可能な形式に変換し、
   前記コンピュータは、前記第１の層により、前記変換が行われた後の前記情報に基づいて、前記画面を表示することを特徴とする請求項３に記載のプログラム。
5. 前記コンピュータは、前記第２の層により、前記情報を所定のテキスト形式に変換することを特徴とする請求項４に記載のプログラム。
6. 前記コンピュータは、前記第２の層により、画像データを前記所定のテキスト形式に変換し、
   前記コンピュータは、前記第１の層により、前記変換が行われた後の前記画像データに基づいて、前記ディスプレイに画像を表示することを特徴とする請求項５に記載のプログラム。
7. 前記コンピュータを、
   前記取得手段により取得されたデータに前記所定の要素が含まれ、前記制御手段により当該取得されたデータに基づいて前記印刷対象のコンテンツの印刷が実行される場合、当該取得されたデータを前記描画部から削除するための処理を実行する削除手段、
   としてさらに機能させることを特徴とする請求項１乃至６のいずれか１項に記載のプログラム。
8. 前記所定の要素は、前記描画部が前記描画を行う際に最後に描画される要素であることを特徴とする請求項１乃至７のいずれか１項に記載のプログラム。
9. 前記コンピュータを、
   前記所定の要素を前記印刷対象のコンテンツに付加するための処理を実行する付加手段、
   としてさらに機能させることを特徴とする請求項１乃至８のいずれか１項に記載のプログラム。
10. 前記付加手段は、前記印刷対象のコンテンツの外部に前記所定の要素を付加するための処理を実行し、
    前記制御手段は、前記印刷装置に前記印刷対象のコンテンツの印刷を実行させ、前記所定の要素の印刷を実行させない、
    ことを特徴とする請求項９に記載のプログラム。
11. 前記指示手段は、前記印刷対象のコンテンツの単位領域ごとに前記描画部に描画を実行させ、単位領域ごとに異なる前記所定の要素の描画を前記描画部に指示することを特徴とする請求項１乃至８のいずれか１項に記載のプログラム。
12. 前記指示手段は、前記印刷対象のコンテンツの単位領域ごとに前記描画部に描画を実行させ、
    前記描画部は、前記単位領域のサイズに対応した、当該描画の実行領域を確保し、当該確保された実行領域において、前記コンテンツの単位領域分を描画する、
    ことを特徴とする請求項１乃至１１のいずれか１項に記載のプログラム。
13. 前記取得手段により取得されたデータに前記所定の要素が含まれない場合、前記取得手段は、前記所定の要素を含む描画されたデータが取得されるまで、前記取得を繰り返すことを特徴とする請求項１乃至１２のいずれか１項に記載のプログラム。
14. 前記コンピュータを、
    ＳＶＧ（Ｓｃａｌａｂｌｅ Ｖｅｃｔｏｒ Ｇｒａｐｈｉｃｓ）により前記印刷対象のコンテンツを生成する生成手段、
    としてさらに機能させることを特徴とする請求項１乃至１３のいずれか１項に記載のプログラム。
15. 前記コンピュータは、ＯＳを実行することで、前記描画部として前記印刷対象のコンテンツと前記所定の要素を描画することを特徴とする請求項１乃至１４のいずれか１項に記載のプログラム。
16. 所定の描画処理を実行する描画部を備える情報処理装置であって、
    印刷対象のコンテンツと所定の要素との描画を前記描画部に指示する指示手段と、
    前記指示手段による指示に対応し且つ前記指示に対する描画の完了に関わらず行われた前記描画部からの通知に基づいて、描画が行われたデータを前記描画部から取得する取得手段と、
    前記取得手段により取得されたデータに基づく印刷を印刷装置に実行させる制御手段と、
    を有し、
    前記取得手段によりデータが取得され且つ当該データに前記所定の要素が含まれる場合、前記制御手段は、当該取得されたデータに基づいて、前記印刷対象のコンテンツの印刷を実行させ、
    前記取得手段によりデータが取得され且つ当該データに前記所定の要素が含まれない場合、前記取得手段が前記描画部から再度データを取得し、前記制御手段は、前記取得手段により再度取得され且つ前記所定の要素を含む当該データに基づいて、前記印刷対象のコンテンツの印刷を実行させる、
    ことを特徴とする情報処理装置。
17. 所定の描画処理を実行する描画部を備える情報処理装置により実行される情報処理方法であって、
    印刷対象のコンテンツと所定の要素との描画を前記描画部に指示する指示工程と、
    前記指示工程における指示に対応し且つ前記指示に対する描画の完了に関わらず行われた前記描画部からの通知に基づいて、描画が行われたデータを前記描画部から取得する取得工程と、
    前記取得工程において取得されたデータに基づく印刷を印刷装置に実行させる制御工程と、
    を有し、
    前記取得工程においてデータが取得され且つ当該データに前記所定の要素が含まれる場合、前記制御工程において、当該取得されたデータに基づいて、前記印刷対象のコンテンツの印刷を実行させ、
    前記取得工程においてデータが取得され且つ当該データに前記所定の要素が含まれない場合、前記取得工程において前記描画部から再度データを取得し、前記制御工程において、前記取得工程において再度取得され且つ前記所定の要素を含む当該データに基づいて、前記印刷対象のコンテンツの印刷を実行させる、
    ことを特徴とする情報処理方法。

Images