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

Abstract

【課題】情報処理装置で動作するアプリーエションがバックグランドに移行してもメモリから消去される可能性を低減させることを可能とする。【解決手段】情報処理装置上で動作するアプリケーションのプログラムは、アプリケーションがフォアグランドからバックグランドへ移行したことを検知する検知工程と、アプリケーションがバックグランドへ移行したことを検知した場合、そのアプリケーションが使用するメモリの量を、フォアグランドで動作していた場合より少なくする低減工程と、を有する。【選択図】図８

Description

本発明は、情報処理装置、情報処理方法およびプログラムに関し、詳しくは、携帯型情報端末などの情報処理装置で動作するアプリケーションに関するものである。

この種のアプリケーションの例として印刷用アプリケーションは、特許文献１に記載されるようなラスタライズ（以下、「レンダリング」と言う）などの印刷用処理を行うものである。この印刷処理の一例は、次のようなものである。ＯＳの描画エンジンのコマンドで記述されたコンテンツが、ＰＤＬ（Page Discription Language）形式に変換されて、プリンタドライバに入力される。プリンタドライバでは、表示されたダイアログを介してユーザーが設定した用紙の種類やサイズ、印刷品位などに応じて、ＰＤＬ形式のコンテンツを所定解像度の画素からなる画像に変換、生成する処理、すなわちレンダリング処理が行われる。そして、レンダリングによる画像に対して、色域変換、色分解などの色変換処理が行われ、さらにディザや誤差拡散等による量子化処理が行われた後、所定のプリンタ制御コマンドが付与された状態でプリンタに送信される。

ここで、上記の一連の印刷用処理において、レンダリングやその後の色変換は、１ページ分の画像を分割して得られる複数のバンドについて、バンドごとに行われる。また、プリンタへの送信は、バンドごとの上記レンダリングなどが終了するごとにバンド単位で送信する場合と１ページ分の処理が終了したときに送信する場合がある。これに対し、前者の場合、プリンタ側では、バンド単位の送信を受けると印刷を開始することから、ユーザーが印刷を指示してからプリンタが印刷を開始するまでの時間が短くなる。

特開２００８−１０８００６号公報

しかしながら、印刷用アプリケーションが動作している情報処理装置に、他の処理が起動されたときに印刷用アプリケーションがバックグランドに移行する場合がある。例えば、モバイルフォンなどの携帯型情報端末では、印刷用処理実行中に、他からのコールによって通話のため処理が起動されると印刷用アプリケーションがフォアグラウンドからバックグラウンドに移行する場合がある。そして、このバックグランドでは、これに移行したアプリケーションが利用可能なメモリ量が少ない状態となると、そのアプリケーションがメモリから消去される場合がある。特に、上述した印刷用の処理を実行している間は、比較的大量のメモリ量を必要とすることから、印刷アプリケーションがメモリから削除される可能性が高くなる。このように、印刷用の処理を実行中のアプリケーションがメモリから削除されると、例えば、プリンタとの通信が中断し、その結果、印刷中の用紙が強制排紙されそれまでの印刷が無駄になるなどの不都合を生じる。

上述したレンダリングなどの印刷用処理を実行しつつ、１ページ分の処理が終了した後にプリンタにデータを送信する場合は、レンダリングの対象となる画像は比較的高い解像度であることから、印刷用アプリケーションは多くのメモリを使用することになる。従って、この場合においても、アプリケーションがバックグラウンドに移行した後は、それがメモリから削除される可能性はより高いものとなる。そして、この場合は、プリンタに送信前ではあるが、ユーザーが一度指示した印刷ジョブが取り消されることになるため、同様に印刷処理上の不都合を生じる。

なお、印刷用アプリケーションをバックグランドに移行させるきっかけとなる処理は、上述した通話に限ったことではなく、例えば、ビデオ通話アプリケーションの自動起動等も、印刷アプリケーションをバックグラウンドに移行させるトリガーになり得る。

本発明は、上述した問題を解決するものであり、情報処理装置で動作するアプリーエションがバックグランドに移行してもメモリから消去される可能性を低減させることが可能な情報処理装置、情報処理方法およびプログラムを提供することを目的とする。

上記目的を達成するために本発明は、情報処理装置上で動作するアプリケーションのプログラムであって、前記アプリケーションがフォアグランドからバックグランドへ移行したことを検知する検知工程と、前記アプリケーションがバックグランドへ移行したことを検知した場合、当該アプリケーションが使用するメモリの量を、フォアグランドで動作していた場合より少なくする低減工程と、を有したことを特徴とする。

以上の構成によれば、情報処理装置で動作するアプリーエションがバックグランドに移行してもメモリから消去される可能性を低減させることが可能となる。

本発明の情報処理装置の一実施形態である携帯型情報端末の構成を示すブロック図である。 図１に示した情報処理装置で動作するソフトウェアの構成を示すブロック図である。 本実施形態に係る情報処理装置における、ユーザー操作を含む処理の一例を示すフローチャートである。 図３のステップＳ３１の写真画像選択の詳細を示すフローチャートである。 図３のステップＳ３２の画像処理の詳細を示すフローチャートである。 図３のステップＳ２３のスタンプ追加の詳細を示すフローチャートである。 図３のステップＳ３４のプリンタ設定の詳細を示すフローチャートである。 図３のステップＳ３５のレンダリングおよびプリントの詳細を示すフローチャートである。 実施形態の情報処理装置におけるアプリケーション画面を模式的に示す図である。 実施形態の情報処理装置における、印刷のための情報を設定するための設定画面を示す図である。 画像を分割したブロック画像のタイル状および帯状の２つの形態を示す図である。 （ａ）および（ｂ）はそれぞれ、ＳＶＧ記述より小さい画面でロードする例と、ｙ座標をずらし、かつ、ＳＶＧ記述より小さい画面でロードする例を説明する図である。 本発明の第３実施形態に係るレンダリングおよびプリントの詳細を示すフローチャートである。

以下、図面を参照して本発明の実施形態を詳細に説明する。
（第１実施形態）
以下では、本発明の印刷用アプリケーションの一実施形態として携帯型情報端末上で動作する写真印刷アプリケーションについて、ユーザーが選択した画像に対して、種々の画像処理を施した後に、それによって得られる印刷用コンテンツを印刷するまでの手順について説明する。なお、本実施形態では該写真印刷アプリケーションとして、Ｗｅｂ技術とネイティブ技術を融合した、いわゆるハイブリッドアプリケーションの形態を説明する。

＜ハードウェア構成の説明＞
図１は、主に、本発明の情報処理装置の一実施形態である、スマートフォンや携帯電話等の携帯型情報端末の構成を示すブロック図である。同図において、ＣＰＵ（中央演算装置／プロセッサ）１００は、以下で説明する各種処理をそれぞれの処理に対応するプログラムに従って実行する。なお、図示の例ではＣＰＵ１００は１つが示されているが、複数のＣＰＵあるいはＣＰＵコアによって構成されていてもよい。この場合、マルチプロセッサの構成とすることができる。ＲＯＭ１０１は、ＣＰＵ１００によって実行されるプログラムを記憶している。ＲＡＭ１０２は、ＣＰＵ１００によるプログラム実行の際に、各種情報を一時的に記憶するためのメモリである。

２次記憶装置１０３は、ハードディスクやフラッシュメモリ等からなり、ファイルや画像解析等の処理結果を保持するデータベース等のデータや、各種プログラムを記憶するための記憶媒体である。ディスプレイ１０４は、各種処理を実現するための操作を受け付けるためのＵＩ（ユーザインタフェース）や、実行された処理による処理結果等の各種情報を表示する。ディスプレイ１０４は、タッチセンサ１０５を備えることもできる。ディスプレイ１０４に表示されるＵＩとして図９にて後述されるアプリケーション画面がある。内部撮像デバイス１１０による撮像によって得られた画像データは、所定の画像処理を経た後、２次記憶装置１０３に保存される。また、画像データは、外部Ｉ／Ｆ（インタフェース）１０８を介して接続された外部撮像デバイス１１１から読み込むこともできる。

情報処理装置１１５は、外部Ｉ／Ｆ（インタフェース）１０９を備えることにより、インターネット等のネットワーク１１３を介して通信を行うことができる。また、情報処理装置１１５は、この通信Ｉ／Ｆ１０９を介して、ネットワーク１１３に接続されたサーバ１１４から画像データを取得することもできる。加速度センサ１０６は、情報処理装置１１５自身の位置姿勢に関する加速度情報を取得することができる。

情報処理装置１１５は、外部Ｉ／Ｆ１０７を介し、プリンタ１１２と接続されており、画像データ等からなる印刷用データを出力することができる。また、情報処理装置１１５は、通信Ｉ／Ｆ１０９を介してネットワーク１１３に接続されており、これにより、プリンタ１１２との間で必要なデータを送受信することができる。

外部Ｉ／Ｆ１０７、１０８、１０９は、有線通信と無線通信のうち、少なくともいずれかの通信形態を有するインタフェースであり、利用する通信形態に応じて外部デバイス（プリンタ１１２あるいはサーバ１１４）との通信を行う。有線通信には、例えば、ＵＳＢ、イーサネット（登録商標）等があり、無線通信には、無線ＬＡＮ、ＮＦＣ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、赤外線通信等がある。また、無線通信として、無線ＬＡＮを用いる場合には、装置同士が直接接続する形態もあれば、無線ＬＡＮルータ等の中継装置を介して接続する形態もある。また、外部Ｉ／Ｆ１０７〜１０９は、図に示す例では別々に構成されているが、一体となって構成されていてもよい。

情報処理装置１１５の動作に必要な電源は、バッテリ１１７から供給される。情報処理装置１１５が備える各種構成要素は、制御バス／データバス１１６を介して相互に接続され、ＣＰＵ１００は、この制御バス／データバス１１６を介して、各種構成要素を制御する。

本実施形態では、情報処理装置１１５が、情報処理装置１１５が備える制御部（ＣＰＵ１００）によって実行されるプログラム等のソフトウェアの実行場所（ソフトウェア実行環境）となる。

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

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

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

ＯＳ層２１９は、情報処理装置１１５のオペレーティングシステム（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ：ＯＳ）に対応する。ＯＳ層２１９は、ハードウェア機能の使用をアプリケーションに提供する役割および固有の機能を有する。ＯＳ層２１９は、ＡＰＩを備え、スクリプト層２１７やネイティブ層２１８から機能を使用することができる。

また、本実施形態では、スクリプト層２１７からネイティブ層２１８の呼び出しを可能にすることをバインディングまたはバインドと称する。各種ネイティブの機能は、ＡＰＩを備え、そのＡＰＩをスクリプトが呼び出すことでネイティブの機能を使用することができる。このようなバインディング機能は、通常、各種ＯＳが標準的に備えている機能である。また、本実施形態では、スクリプト層２１７とネイティブ層２１８を含むアプリケーションのことをハイブリッドアプリケーションと称する。

以上説明したソフトウェア構成の各層における処理ないし機能ついて説明する。

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

ネイティブ層２１８のデータ変換部２０３は、ネイティブ層２１８のデータ（例：バイナリ形式の画像データやパラメータ）をスクリプト層２１７で利用できる形式のデータ（例：テキスト形式（ＢＡＳＥ６４）の画像データやＪＳＯＮなど）に変換する。一方で、データ変換部２０３は、スクリプト層２１７から送られてきたデータ（例：テキスト形式（ＢＡＳＥ６４）の画像データやＪＳＯＮなど）をネイティブ層２１８で利用できる形式のデータ（例：バイナリ形式の画像データやパラメータ）にする変換を行う。スクリプト層２１７のデータ変換部２０７は、スクリプト層２１７のデータ（例：テキスト形式の処理パラメータ）をネイティブ層２１８で利用できる形式のデータ（例：テキスト形式（ＪＳＯＮ形式）の処理パラメータ）に変換する。

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

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

スクリプト層２１７の画像処理制御部２０６は、画像処理に用いる補正パラメータと、処理対象となる画像を決定し、画像処理部２０８に画像処理を依頼する。補正パラメータはデータ変換部２０７でネイティブ層へ送信できる形式へ変換された後、処理対象となる画像のＩＤと共にネイティブ層へ送信される。ネイティブ層の画像処理部２０８は、画像処理制御部２０６で指定された画像に対し画像処理を施す。その際、どのような画像処理を施すかは、画像処理制御部２０６で設定されたパラメータにより決定される。画像の指定については、先述のＩＤを利用する方法に加え、スクリプト層から画像のパスを受け取る、画像データごと受け取る方法などが考えられる。

ＯＳ層２１９のタッチイベント２０９は、ディスプレイ１０４のタッチに関する情報を取得する。タッチに関する情報とは、ディスプレイ１０４のタッチ検知、タッチされた位置情報等が挙げられる。取得したタッチに関する情報は、ネイティブ層２１８経由でスクリプト層２１７のコンテンツ操作部２１０に送信される。スクリプト層２１７のコンテンツ操作部２１０は、例えば、画像取得依頼の結果としてネイティブ層２１８から画像データが送信された際、その画像データを反映すべく、スクリプト命令を変更する。

スクリプト層２１７のプリンタ制御部２１１は、プリンタ検知の依頼、プリンタ設定画面の表示、プリント情報の生成と送信を制御する。プリンタ設定画面では、用紙のサイズ、用紙の種類、カラー・モノクロ等のプリンタ設定がなされる。ここで設定された項目を基に、プリンタデータ生成部２１２でプリンタデータが生成される。ネイティブ層２１８のプリンタデータ生成部２１２は、プリンタ制御部２１１からの依頼に基づき、プリンタ通信に必要なデータ、コマンドを生成する。プリンタ通信に必要なデータとは、通信プロトコルに則ったデータであり、コマンドとは、印刷やスキャン等、プリンタの動作を決定するためのデータである。よって、プリンタデータ生成部２１２は、プリンタの動作を決定するためのコマンドを含むプリンタデータを生成する。

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

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

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

スクリプト層２１７のレンダリング依頼部は、ネイティブ層２１８のレンダリング部２１６にレンダリングの依頼をする。その際、コンテンツ描画部２０５で記述されている内容をデータ変換部２０７で変換してからレンダリング部２１６に受け渡す。レンダリング部２１６に受け渡す前に必要な処理がある場合は、コンテンツ操作部２１０を用いて、コンテンツ記述を編集するようにしてもよい。また、コンテンツ記述を直接編集するとＵＩに影響がある場合は、上述の操作はコンテンツ記述の複製を作成して、それを利用する。レンダリング部２１６は、レンダリング依頼部２１７から受け取った内容に応じて、プリンタへ送信するため画像データを生成するためのレンダリングを行う。このレンダリングには、例えば、スクリプト層２１７でプリンタ１１２への出力解像度で画像を生成することが含まれる。また、ネイティブ層２１８におけるレンダリング結果、および生成途中の画像はディスプレイ１０４に表示されない。

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

＜ユーザー操作に伴う処理＞
図３は、本実施形態に係る情報処理装置１１５における、ユーザー操作を含む処理の一例を示すフローチャートであり、写真画像をプリンタ１１２によって印刷するための処理を示している。図３に示す各ステップの処理は、情報処理装置１１５のＣＰＵ１００が、ＲＯＭ１０１あるいは２次記憶装置１０３に記憶されているプログラムを実行することにより実現される。また、図３に示す各ステップは、本実施形態のＵＩの１つである、アプリケーション画面に対するユーザーの操作に従って遷移する。

図９は、本実施形態の情報処理装置１１５におけるアプリケーション画面９００を模式的に示す図である。このアプリケーション画面は、図１に示したディスプレイ１０４によって表示される。そして、このアプリケーション画面９００は、スクリプト層２１７によって生成され、また、アプリケーション画面９００の操作は、例えば、タッチセンサ１０５（図１）によって検知される。

図３において、先ず、ステップＳ３１で、ＣＰＵ１００は、図９に示すアプリケーション画面９００の写真画像選択ボタン９０１に対するユーザーの操作（タッチ操作入力も含む。以下、同様）を検知すると、その操作に応じて、ユーザーが画像を選択するための処理および表示を行う。ユーザーが画像を選択すると、ＣＰＵ１００は、ネイティブ層で所定の処理を実行した後、アプリケーション画面９００の描画領域９０６に選択された画像を表示する。本ステップの詳細は図４にて後述する。

ステップＳ３２おいて、ＣＰＵ１００は、表示されている画像の輝度を調整するための、図９に示すスライドバー９０２に対するユーザー操作を検知すると、そのユーザー操作に応じて、画像処理時に利用する補正パラメータを設定する。そして、実行指示のもと、ＣＰＵ１００は、設定した補正パラメータに従って、表示されている画像に画像処理を施し所定の処理を行った後、その処理内容及び処理結果を描画領域９０６に表示する。本ステップの詳細は図５にて後述する。

ステップＳ３３おいて、ＣＰＵ１００は、図９に示すスタンプ追加ボタン９０３に対するユーザー操作を検知すると、スタンプを表示する。そして、そのスタンプ一覧に対するユーザー操作によってスタンプの選択を検知すると、ＣＰＵ１００は、描画領域９０６に、選択されたスタンプを追加、表示する。さらに、スタンプにタッチイベント（タップ、スワイプ）検知機能を付与することにより、スタンプの拡大、縮小、移動などを可能とする。この検知機能は、Ｗｅｂ標準言語に標準として備えられているものであり、ａｄｄＥｖｅｎｔＬｉｓｔｅｎｅｒ関数がそれに該当する。スタンプがタッチされた時に反応する例を下記に示す。
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" > ＜/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=”Base64の表示用画像データ” 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=” Base64の表示用画像データ”
id=”imageID”></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”>
<symbol id=”imageID” viewBox=”0 0 640 480”>
<image width=”640” height=”240” x=”0” y=”0”
xlink:href=”上半分画像のBase64” ></image>
<image width=”640” height=”240” x=”0” y=”240”
xlink:href=”下半分画像のBase64” ></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=” 上半分画像のBase64” ></image>
<image width=”640” height=”240” x=”0” y=”240”
xlink:href=” 下半分画像のBase64” ></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=” 上半分画像のBase64” ></image>
<image width=”640” height=”240” x=”0” y=”240”
xlink:href=” 下半分画像のBase64” ></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=”上半分画像のBase64” ></image>
<image width=”640” height=”240” x=”0” y=”240”
xlink:href=”下半分画像のBase64” ></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=”上半分画像のBase64” ></image>
<image width=”640” height=”240” x=”0” y=”240”
xlink:href=”下半分画像のBase64” ></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タグのy要素が、−１５００となっている。以降は、上記書き換えたＳＶＧに基づいてバンドレンダリング処理を行う。

以上の第２実施形態によれば、レンダリング時にファイルを展開し直す時間は要するものの、アプリケーションがＲＡＭ上に占有するメモリ量を削減することが可能となる。上述した例では、画像１枚当たり３０ＭＢのメモリを有するとしたが、画像を複数枚保持することを考慮すると、本実施形態によるメモリ削減量は比較的大きく、アプリケーションが削除される可能性をさらに低下させることができる。

なお、本実施形態では、ステップＳ８１０における画像生成に係る領域情報は、４００５×１５００画素のままとしたが、本発明の適用はこれに限定されるものではない。実行中のメモリ量をさらに削減するために、上述した第１実施形態と本実施形態を組み合わせて動作するように構成してもよい。

（第３実施形態）
本発明の第３実施形態は、レンダリング処理の画像データの解像度を低減することによってアプリケーションが使用するメモリ量を削減する形態に関する。図１３は、本発明の第３実施形態に係るレンダリングおよびプリントの詳細を示すフローチャートである。以下、図８に示す処理を異なる点を説明する。

先ず、ステップＳ１３０７で、端末状態判断を行う。一例として、最初のバンドに関する判断では、アプリケーションがフォアグラウンドで動作しているものとする。その結果、ステップＳ１３０８では、第１実施形態と同様、４００５×３０００画素の印刷用ＳＶＧファイルを作成し、ステップＳ１３０９〜Ｓ１３１９で、この最初のバンドのレンダリングを実行する。このバンドのレンダリングの画像サイズは、第１実施形態と同様に、４００５×１５００画素である。

次に、２バンド目のレンダリングを実施する際に、ステップＳ１３０７の端末状態判断で、アプリケーションがバックグラウンドに移行したものと判断する。この場合、本実施形態では、先ず、上記最初にレンダリングしたバンドの４００５×１５００画素の画像データを一度破棄する。次に、ステップＳ１３０８で、解像度を１／２に低下させたＳＶＧデータを構築する。具体的には、以下の記述となる。
<svg
xmlns=”http://www.w3.org/2000/svg”
xmlns:xlink=”http://www.w3.org/1999/xlink”
width=”2005” height=”1500” viewBox=”0 0 2005 1500”>
<svg x=”0” y=”0”>
<svg width=”2000” height=”1500” viewBox=”0 0 320 240”>
<symbol id=”imageID” viewBox=”0 0 320 240”>
<image width=”320” height=”120” x=”0” y=”0”
xlink:href=” imageID_above.bmp” ></image>
<image width=”320” height=”120” x=”0” y=”120”
xlink:href=” imageID_below.bmp” ></image>
</symbol>
<use xlink:href=”#imageID” x=”0” y=”0” width=”320” height=”240” />
<image width=”100” height=”100” x=”150” height=”25”
xlink:href=”スタンプのパス指定”
id=”スタンプのID”></image>
</svg>
<rect x=”2000” y=”0” width=”5” height=”1500” fill=”red” />
</svg>
</svg>
上記ＳＶＧの記述においては、解像度を２０００×１５００画素として、対応する各箇所を変更している。この記述を用いて、ステップＳ１３１０で、バンドＳＶＧの画面生成を行う。このときの画面生成のサイズは、２０００×７５０画素とする。もちろん、レンダリング終了を検知するためのマーカーライン５画素分は、本実施形態においても必要となる。

以上のように、本発明の第３実施形態によれば、レンダリング処理の最中にアプリケーションがバックグラウンド移行した際、それまでのレンダリング結果を一旦破棄し、解像度を低下させた状態でレンダリングを行う。これにより、ステップＳ１３１０で確保する画面生成用のメモリ量を低減することが可能となる。上述の例では、４００５×１５００画素領域を、２０００×７５０画素領域に削減することができ、画像キャプチャ用のメモリを、１８ＭＢから、４．５ＭＢに削減することが可能となる。その結果、アプリケーションがＯＳによってメモリから削除される可能性を低減することができる。

なお、解像度を低下させた状態は、アプリケーションがバックグラウンドに移行している間は保持されるものとする。そして、その印刷アプリケーションがフォアグラウンドに移行したことを検知した場合には、次の印刷ジョブから、印刷解像度を再び４０００×１５００画素に戻すことにより、解像度の高い印刷処理を実行することが可能となる。

（他の実施形態）
上述した第１〜第３本実施形態は、ハイブリッドアプリケーションの形態に関するものであるが、本発明の適用はこの形態に限定されるものではない。ＯＳ毎に定義された言語によって開発されたアプリケーションであっても本発明を適用できることは上述の説明からも明らかである。

なお、図８にて上述したレンダリング処理において、ＳＶＧの印刷コンテンツを、ステップＳ８１２でＯＳが保持しているレンダリング機能（ブラックボックス）を用いて描画処理を行う。そして、その結果は、ステップＳ８１５で、ＲＧＢＡデータとしてネイティブ層が受け取る。この場合に、ハイブリッドアプリケーションの形態では、ＯＳ部とネイティブ部で、レンダリング後の画像バッファを２面要する。また、ＯＳが内部で保持している画像バッファの管理はＯＳに任されていることから、アプリケーション側から明示的にメモリを解放することができず、２つのバッファを保持し続ける状態が存在する。従って、ハイブリッドアプリケーションの形態では、バックグランドにおいて使用するメモリ（バッファ）の量が他の形態のアプリケーションより多くなることがある。このように、本発明は、ハイブリッドアプリケーションの形態に適用することにより、バックグランドで使用するメモリ量を低減する上でより顕著な効果を得ることができる。

また、上述した第１〜第３実施形態の情報処理装置１５上で動作するＯＳが、マルチタスク動作またはシングルタスク動作のいずれであっても本発明を適用することができる。シングルタスク動作のアプリケーションの場合、他のアプリケーションの起動によってバッググラウンドへ移行する際、直ちにそのアプリケーションが強制終了されない。すなわち、バックグランドへの移行によってアプリケーションの動作は停止するが、アプリケーション自体は終了せず、その状態を維持し続ける。これにより、フォアグラウンドでの上記他のアプリケーションが終了すると、再びフォアグランドに移行して、バックグランドに移行したときの状態から動作を再開する。しかし、この構成において、バックグラウンドに移行したシングルタスクのアプリケーションが、上述した状態の維持のために比較的大量のメモリを利用し続けている場合や、長時間バックグラウンドに移行した状態を続ける場合は、ＯＳの処理によってバックグラウンドのアプリケーションを強制終了されることがある。この場合、本発明の適用が効果的となる。

また、上述した各実施形態は、情報処理装置上で動作する印刷用アプリケーションの特にレンダリングの処理がバックグランドに移行したときの形態に関するものであるが、本発明の適用はこの形態に限られない。例えば、印刷用アプリケーションによる、レンダリング以外の他の処理、例えば、色変換の処理がバックグランドに移行したときに、使用するメモリ量を低減する上述の各実施形態の処理を行う形態でであってもよい。さらには、印刷用アプリケーション以外の他のアプリケーションが情報処理装置において動作しているときに、それがバックグランドに移行したときに同じく使用するメモリ量を低減する上述の各実施形態の処理を行う形態でであってもよい。

さらに、上述の各実施形態ではモバイルフォンを想定したが、本発明はこれに限定されない。例えば、液晶画面サイズが５インチを超えるようなタブレットと言われるデバイスにおいても、同様の構成を適用することができる。また、上記各実施形態中で記載した数値は、説明を簡単にするために設定した値に過ぎない。別の数値を用いたとしても、本発明の効果を得られる実施形態は、本発明の範疇に含まれる。

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

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

Claims (10)

1. 情報処理装置上で動作するアプリケーションのプログラムであって、
   前記アプリケーションがフォアグランドからバックグランドへ移行したことを検知する検知工程と、
   前記アプリケーションがバックグランドへ移行したことを検知した場合、当該アプリケーションが使用するメモリの量を、フォアグランドで動作していた場合より少なくする低減工程と、
   を有したことを特徴とするプログラム。
2. 前記アプリケーションは、印刷用コンテンツをレンダリングする処理を実行し、前記低減工程は、レンダリングの対象である画像データの量を低減することによって、前記使用するメモリの量を少なくすることを特徴とする請求項１に記載のプログラム。
3. 前記低減工程は、レンダリングの対象である画像データのサイズを小さくすることによって、前記使用するメモリの量を少なくすることを特徴とする請求項２に記載のプログラム。
4. 前記低減工程は、レンダリングの対象である画像データの解像度を低下させることによって、前記使用するメモリの量を少なくすることを特徴とする請求項２に記載のプログラム。
5. 前記アプリケーションは、印刷用コンテンツをレンダリングする処理を実行し、前記低減工程は、レンダリングの対象である画像データを前記メモリにオンメモリで保持せずにファイル名の形態で保持することによって、前記使用するメモリの量を少なくすることを特徴とする請求項１に記載のプログラム。
6. 前記アプリケーションはハイブリッドアプリケーションであることを特徴とする請求項１ないし５のいずれか１項に記載のプログラム。
7. 前記アプリケーションは、レンダリングが終了した後に、印刷情報をプリンタへ送信することを特徴とする請求項１ないし６のいずれか１項に記載のプログラム。
8. 前記アプリケーションは、前記レンダリングを所定の画像領域ごとに行い、前記所定の画像領域ごとのレンダリング後に生成した印刷情報をプリンタへ送信することを特徴とする請求項２ないし６のいずれか１項に記載のプログラム。
9. アプリケーションのプログラムを動作させる情報処理装置であって、
   前記アプリケーションがフォアグランドからバックグランドへ移行したことを検知する検知手段と、
   前記アプリケーションがバックグランドへ移行したことを検知した場合、当該アプリケーションが使用するメモリの量を、フォアグランドで動作していた場合より少なくする低減手段と、
   を有したことを特徴とする情報処理装置。
10. アプリケーションのプログラムを動作させるための情報処理方法であって、
    前記アプリケーションがフォアグランドからバックグランドへ移行したことを検知する検知工程と、
    前記アプリケーションがバックグランドへ移行したことを検知した場合、当該アプリケーションが使用するメモリの量を、フォアグランドで動作していた場合より少なくする低減工程と、
    を有したことを特徴とする情報処理方法。