JP6649832B2 - 情報処理装置およびその制御方法、並びにプログラム - Google Patents

Description

本発明は、情報処理装置およびその制御方法、並びにプログラムに関する。

近年、多機能携帯端末（以下、モバイルコンピュータ）が普及している。このようなモバイルコンピュータ上で動作するアプリケーションの形態としては、主に、ネイティブアプリケーションとウェブアプリケーションの２つが存在する。ネイティブアプリケーションは、通常、ＯＳ毎に用意される開発環境、及び開発言語を用いて開発されるアプリケーションである。また、ネイティブアプリケーションは、各開発環境において予めコンパイルされ、人間が理解可能ないわゆる高水準言語から、コンピュータのＣＰＵが解釈可能なアセンブラ等の命令セット群に変換される。ネイティブアプリケーションは、命令をＣＰＵが直接解釈するために、高速動作が可能というメリットがある。一方、ウェブアプリケーションは、各コンピュータ上のＯＳに標準的に組み込まれているウェブブラウザ上で動作するアプリケーションである。ウェブアプリケーションは、ウェブブラウザが解釈できるようにウェブ標準言語で記述され、ウェブブラウザが動作する環境であれば、どこでも動作可能というメリットがある。

近年、ネイティブアプリケーションとウェブアプリケーションの利点を双方保持した、ハイブリッドアプリケーションの形態が注目されている。ハイブリッドアプリケーションは、そのユーザーインターフェース（ＵＩ）の全てあるいは大部分が、ウェブの標準言語で記述される。また、ウェブ標準言語で記述された内容から、ネイティブ言語で記述された機能を利用することもできる。すなわち、一つのアプリケーション内部に、ウェブ標準言語によるスクリプト層とネイティブ層を双方包含する構成となっている。

特許文献１では、携帯端末において、Ｗｅｂデータを用いて、プリンタが解釈可能なフォーマットを有する印刷データを生成し、プリンタに送信する構成が提案されている。

特開２０１５−０２６３９３号公報

しかしながら、特許文献１では、Ｗｅｂデータの表示におけるサイズ制限について考慮していなかった。例えば、ウェブの機能を使って画像を配置したコンテンツを表示する場合、表示の高速化のために画像サイズに対する制限がかかる場合がある。これは、ウェブの機能が表示を前提としており、高解像度の画像は表示のパフォーマンスを低下させてしまうため、ＯＳ側で制限をかけていることによる。

上記理由により、ウェブの機能を使って高解像度の画像が含まれたコンテンツを印刷する場合、画像のサイズ制限がかかり、印刷物が低画質になってしまうという課題があった。

本発明は、上記課題を鑑み、ウェブの機能を利用して高解像度の画像が含まれた印刷コンテンツを印刷する場合でも、高画質な印刷物を得ることを目的とする。

上記課題を解決するために本願発明は以下の構成を有する。すなわち、プロセッサで翻訳され実行されるための命令セットを含む第１のプログラム層と、予め翻訳され前記プロセッサで実行されるための命令セットを含む第２のプログラム層とを包含するアプリケーションが動作可能な情報処理装置であって、前記第１および第２のプログラム層の少なくとも一方が動作することにより、印刷コンテンツに配置される画像の情報および前記情報処理装置の情報のうちの少なくとも一つに基づいて前記画像の分割条件を決定する決定手段と、前記第２のプログラム層が動作することにより、前記決定手段で決定した分割条件に従って前記画像を分割して分割画像を作成する分割手段と、前記第１のプログラム層および前記第２のプログラム層の少なくとも一方が動作することにより、前記分割画像を配置した印刷コンテンツを構築する構築手段と、前記第２のプログラム層が動作することにより、前記分割画像を配置した印刷コンテンツをレンダリングしてレンダリング画像を生成するレンダリング手段と、前記第２のプログラム層が動作することにより、前記レンダリング画像を用いて印刷データを生成する生成手段とを備える。

本発明では、ウェブの機能を利用して高解像度の画像が含まれた印刷コンテンツを印刷する場合でも、高画質な印刷物を得ることができる。

本発明に係るハードウェアの構成例を示す図。 本発明に係るソフトウェアの構成例を示す図。 本発明に係る処理の流れを示すフローチャート。 本発明に係る写真画像選択処理のフローチャート。 本発明に係る画像処理のフローチャート。 本発明に係るスタンプ追加処理のフローチャート。 本発明に係るプリンタ設定処理のフローチャート。 本発明に係るレンダリング＆プリント処理のフローチャート。 本発明に係る画面の構成例を示す図。 本発明に係るタイル状分割、帯状分割を説明するための図。 本発明に係るバンドＳＶＧからの画像取得を説明するための図。 本発明に係る分割画像の作成処理のフローチャート。 第二の実施形態に係る画像の分割条件を決定するためのテーブルの例を示す図。 本願発明に係るプログラムコードの記述例を示す図。 本願発明に係るプログラムの記述例を示す図。 本願発明に係るプログラムの記述例を示す図。 本願発明に係るプログラムの記述例を示す図。 本願発明に係るプログラムの記述例を示す図。 本願発明に係るプログラムの記述例を示す図。

以下、添付の図面を参照して、本発明を好適な実施形態に基づいて詳細に説明する。

＜第一の実施形態＞
以下、携帯型の情報処理装置である携帯端末上で、本発明に係るハイブリッドアプリケーションによる写真印刷アプリケーションを動作させ、ユーザーが選択した画像に対して、画像処理を適用した後に、コンテンツを印刷するまでの手順について説明する。

なお、印刷に使用されるコンテンツはウェブ標準言語（ＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）、ＣＳＳ、ＪａｖａＳｃｒｉｐｔ（登録商標）等）を用いて記述される。本実施形態ではＨＴＭＬにおけるグラフィック表記手法の一つであるＳＶＧ（Ｓｃａｌａｂｌｅ Ｖｅｃｔｏｒ Ｇｒａｐｈｉｃｓ）で印刷コンテンツを記述した例を用いて説明を行う。しかしこれに限定するものではなく、例えば、ＨＴＭＬでグラフィックを記述するのに使用されるＣａｎｖａｓを用いてもよい。

［ハードウェア構成］
図１は、本実施形態に係るシステムの構成例を示す。本実施形態に係るシステムでは、ネットワークを介して、情報処理装置１１５、プリンタ１１２、サーバ１１４が接続される。情報処理装置１１５は、例えば、スマートフォンや携帯電話等の携帯型情報端末が該当する。図１において、ＣＰＵ（中央演算装置／プロセッサ）１００は、以下で説明する各種処理をプログラムに従って実行する。図１において１つのＣＰＵ１００が示されているが、複数のＣＰＵあるいはＣＰＵコアによって構成されていてもよい。ＲＯＭ１０１は、ＣＰＵ１００により実行されるプログラムを記憶している。ＲＡＭ１０２は、ＣＰＵ１００によるプログラムの実行時に、各種情報を一時的に記憶するためのメモリである。

２次記憶装置１０３は、ハードディスクやフラッシュメモリ等の記憶媒体であり、ファイルや画像解析等の処理結果を保持するデータベース等のデータや、各種プログラムを記憶する。ディスプレイ１０４は、各種処理を実現するための操作を受け付けるためのＵＩ（ユーザインタフェース）や、実行された処理による処理結果等の各種情報を表示する。ディスプレイ１０４は、タッチセンサ１０５を備えてもよい。

内部撮像デバイス１１０は撮像を行い、撮像によって得られた画像データは、所定の画像処理を経た後、２次記憶装置１０３に保存される。また、画像データは、外部ＩＦ（インタフェース）１０８を介して接続された外部撮像デバイス１１１から読み込まれてもよい。

外部ＩＦ（インタフェース）１０９は、インターネット１１３等のネットワークを介して外部装置と通信を行うことができる。加速度センサ１０６は、情報処理装置１１５自身の位置姿勢に関する加速度情報を取得することができる。

外部ＩＦ１０７〜１０９は、有線通信と無線通信の内、少なくともいずれかの通信形態を有するインタフェースであり、利用する通信形態に応じて外部デバイス（プリンタ１１２あるいはサーバ１１４）との通信を行う。情報処理装置１１５は、外部ＩＦ１０７〜１０９を介して、インターネット１１３に接続されたサーバ１１４より画像データを取得したり、プリンタ１１２に対し画像データ等を出力することができる。有線通信には、例えば、ＵＳＢ、イーサネット（登録商標）等がある。無線通信には、無線ＬＡＮ、ＮＦＣ（Ｎｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、赤外線通信等がある。

情報処理装置１１５の動作に必要な電源は、バッテリ１１７によって供給される。情報処理装置１１５が備える各種構成要素は、内部バス１１６を介して相互に接続され、ＣＰＵ１００は、内部バス１１６を介して、各種構成要素を制御する。なお、本実施形態では、情報処理装置１１５が、情報処理装置１１５が備える制御部（ＣＰＵ１００）によって実行されるプログラム等のソフトウェアの実行場所（ソフトウェア実行環境）となる。

なお、ここでは、外部デバイスの一例としてプリンタを例に挙げて説明するが、これに限定するものでは無く、複合機（ＭＦＰ）など他の画像形成装置やＦＡＸ等の通信装置であってもよい。

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

スクリプト層２１０は、ＨＴＭＬ５やＣＳＳ３、及びＪａｖａＳｃｒｉｐｔ等のウェブ標準言語を用いて、テキストデータにより命令セット（コンテンツの描画や画像の表示、動画の再生等）が記述されているプログラム層である。スクリプト層２１０では、アプリケーション実行環境上で、そのアプリケーション実行環境に存在するプロセッサ（例えば、ＣＰＵ１００）を用いて、テキストデータの各種命令セットを翻訳して実行する。その実行形態としては、実行の度に命令文を一行ずつ動的に翻訳する場合、アプリケーションを起動した際に翻訳する場合、もしくは、アプリケーションを情報処理装置１１５にインストールした際に翻訳する場合などが考えられる。

以後、スクリプト層２１０で処理することや内容をスクリプトと呼ぶ。スクリプトの命令を情報処理装置１１５内で翻訳する形態の例として、ネイティブ層２２０やＯＳ層２３０が備えるインタプリタの機能を使用することが挙げられる。本実施形態では、アプリケーションのＵＩの大部分が、スクリプトで記述されていることを想定している。

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

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

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

スクリプト層２１０の画像取得部２１２は、ネイティブ層２２０に対し画像データの取得を要求する。画像取得部２１２の要求は、例えば、画像のパスを指定する方法や、ダイアログ表示を促す方法等が挙げられる。

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

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

スクリプト層２１０のデータ変換部２１５は、スクリプト層２１０のデータ（例：テキスト形式の処理パラメータ）をネイティブ層２２０で利用できる形式のデータ（例：テキスト形式（ＪＳＯＮ形式）の処理パラメータ）に変換する。

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

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

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

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

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

スクリプト層２１０のコンテンツ操作部２１７は、例えば、画像取得要求の応答としてネイティブ層２２０から画像データが返却された際、その画像データを反映すべく、スクリプト命令を変更する。

スクリプト層２１０のプリンタ制御部２１１は、プリンタ検知の要求、プリンタ設定画面の表示、プリント情報の生成と送信を制御する。プリンタ設定画面では、用紙のサイズ、用紙の種類、カラー・モノクロ等のプリンタ設定がなされる。ここで設定された項目を基に、ネイティブ層２２０のプリンタデータ生成部２２３はプリンタデータを生成する。

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

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

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

画像データ群２２９は、画像データを保持している領域である。データ保存部２２６は、必要に応じて、データ保持部２２７が保持する画像データを画像データ群２２９に保存させる。

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

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

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

［処理フロー］
図３は、ユーザ操作を含む、本実施形態に係る処理を示すフローチャートである。まず、図３を用いて、各処理の概要を説明し、各処理の詳細については図４〜図８を用いて後述する。なお、本願のフローチャートの各ステップの処理は、情報処理装置１１５のＣＰＵ１００が、ＲＯＭ１０１あるいは２次記憶装置１０３に記憶されているプログラムを実行することにより実現される。また、図３に示す各ステップは、ＵＩの１つである図９に示すアプリケーション画面９００に対するユーザ操作に従って遷移する。アプリケーション画面９００は、スクリプト層２１０によって生成される。アプリケーション画面９００への操作は、例えば、タッチセンサ１０５を介して実現される。

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

Ｓ３２にて、ＣＰＵ１００は、表示されている画像の輝度を調整するためのスライドバー９０２に対するユーザ操作を検知すると、そのユーザ操作に応じて、画像処理時に利用する補正パラメータを設定する。なお、図９では輝度を調整するためのスライドバーを備える、輝度とは異なる項目について調整を受け付けても良い。例えば、図９のＵＩが、濃度や解像度等の調整を受け付けてもよい。そして、実行指示のもと、ＣＰＵ１００は、設定した補正パラメータに従って、表示されている画像に画像処理を施し特定の処理を行う。その後、ＣＰＵ１００は、その処理内容及び処理結果を描画領域９０６に表示する。

Ｓ３３にて、ＣＰＵ１００は、スタンプ追加ボタン９０３に対するユーザ操作を検知すると、スタンプを表示する。スタンプ一覧に対するユーザ操作によってスタンプの選択を検知すると、ＣＰＵ１００は、選択されたスタンプを描画領域９０６に追加・表示する。さらに、スタンプに対するタッチイベント（タップ、スワイプ）の検知することで、スタンプの拡大・縮小、移動などが実現可能となる。この検知機能はＷｅｂ標準言語に標準として備えられ、例えば、ａｄｄＥｖｅｎｔＬｉｓｔｅｎｅｒ関数がそれに該当する。

Ｓ３４にて、ＣＰＵ１００は、プリントボタン９０５に対するユーザ操作を検知すると、プリントに必要な情報を設定するための設定画面９１１（図９（ｂ））を表示する。プリントに必要な情報とは、例えば、図９（ｂ）の設定画面９１１に示されるように、用紙サイズ、用紙種類、印刷品位、縁あり／なしの設定項目がある。これ以外にも、両面／片面、モノクロ・カラー等、使用するプリンタが有する機能に応じて、設定可能な設定項目が構成される。

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

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

なお、図３に示す処理は写真印刷アプリケーションが提供する機能の一例であり、処理内容はこれに限定されず、処理順序もこれに限定されるものではない。本実施形態において、プロセッサで翻訳され実行されるための命令セットを含む第１のプログラム層をスクリプト層２１０、プロセッサ以外で予め翻訳されプロセッサにて実行される命令セットを含む第２のプログラム層をネイティブ層２２０と定義する。そして、これらの第１のプログラム層と第２のプログラム層とを包含するプログラムがハイブリッドアプリケーションを実現する。

続いて、図３に示した各処理の詳細について説明する。上述したように、各処理は情報処理装置１１５のＣＰＵ１００が、ＲＯＭ１０１あるいは２次記憶装置１０３に記憶されているプログラムを実行することにより実現される。ここでは、ハイブリッドアプリケーション（スクリプト層およびネイティブ層）、およびＯＳ（ＯＳ層）のいずれのプログラムにより、各処理工程が行われるかを明確にしながら説明を行う。

［写真画像選択処理の詳細］
写真画像選択とそれに伴う画像処理について説明する。ユーザが図９（ａ）に示した写真画像選択ボタン９０１を押下することでＳ３１が開始する。図３のＳ３１の写真画像選択の詳細について、図４を用いて説明する。図４において、Ｓ４０１、Ｓ４１１はＣＰＵ１００がスクリプト層２１０のプログラムを用いて実行する処理であり、Ｓ４０２〜Ｓ４１０はＣＰＵ１００がネイティブ層２２０のプログラムを用いて実行する処理である。

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

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

Ｓ４０３にて、ネイティブ層２２０は、選択された画像を一意に識別するための識別情報（ＩＤ）を生成する。このＩＤは、数値、文字列等、ネイティブ層２２０からスクリプト層２１０へ送信できる形式であればどのような形でもよい。なお、ＩＤの生成はネイティブ層２２０にて行うことに限定するものではなく、スクリプト層２１０で生成してネイティブ層２２０に送る方法でもよい。

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

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

Ｓ４０６にて、ネイティブ層２２０は、展開したＲＧＢデータを分割し、分割領域毎のＲＧＢデータを作成する。分割領域毎のＲＧＢデータを「ブロック画像」と記述する。このようなブロック画像を生成する理由として、画像のサイズ制限回避がある。上述したように、ハイブリッドアプリケーションにおいて、ウェブの機能を利用して画像を配置したＳＶＧコンテンツを表示する場合、表示の高速化のために画像サイズ制限がかかる場合がある。そのため、ハイブリットアプリケーションで高解像度の画像が含まれたコンテンツを印刷する場合、画像のサイズ制限により、印刷物が低画質になってしまう。具体的には、制限されたサイズ内に収まるように解像度が変更される。本実施形態において、ブロック画像への分割は、これを回避するために行われる。ブロック画像は、タイル状と帯状のどちらでもよい。タイル状とは、ブロック画像の横幅・縦幅が、両方とも分割元データの横幅・縦幅に満たない場合を示す。帯状とは、ブロック画像の横幅・縦幅のどちらか一方のみが、分割元データに対して満たない場合を示す。

ブロック画像への分割パターン例について、図１０に示す。図１０において、元画像を４０００ｐｘ×３０００ｐｘからなる１２００万画素の画像とする。この元画像に対し、３つの帯状のブロック画像に分割した２つの例（等量分割および上限内分割）と、４つのタイル状のブロック画像に分割した２つの例（等量分割および上限内分割）を示す。等量分割は、元画像を同じサイズのブロック画像に等分する分割方法である。また、上限内分割は、所定の上限値よりも小さなサイズのブロック画像となるように元画像を分割する方法である。

帯状の分割は、比較的処理が容易であるというメリットがある。また、印刷コンテンツのレンダリングをバンド分割して行う時に、バンドの境目に画像がある場合は、横方向の帯状で分割していた方がレンダリングに使用する画像が少なくなるというメリットもある。一方、タイル状は、分割のための画素数Ｘより横幅または縦幅が小さい場合に使用することができる。例えば、横幅３０００ｐｘの画像を１５００ｐｘずつに極小分割する際には、タイル状で分割する必要がある。

より具体的には、図１０に示すように、帯状のブロックに分割する場合、４００万画素の３枚の画像に分割する等量分割や、５００万画素、５００万画素、２００万画素の３枚に分割する上限内分割がある。等量分割は、分割数が固定であった場合、使用メモリを最小化できるメリットがある。一方、上限内分割は、分割数を最小にできるメリットがある。他に、画素数が大きい場合、５００万画素以下になるまで画像の等量分割を繰り返して条件を決定する方法が考えられる。例えば、１２００万画素を２分割して６００万×２、さらに２分割して３００万×４の画像とする。タイル状のブロック画像についても、同様の考えで分割条件を決定できる。

ここで、図１２を用いて、Ｓ４０６における分割画像を作成する処理の詳細について説明する。ここでの処理は、例えば、ネイティブ層２２０の画像処理部２２４にて行われる。

Ｓ１２０１にて、ネイティブ層２２０は、画像情報の取得を行う。本実施形態では、ブロック画像へ分割する条件は、コンテンツに配置する画像情報から決定する。画像情報は、垂直方向の画素（ｐｘ：ピクセル）数（Ｗ）、水平方向の画素数（Ｈ）を含む。これらの情報は、画像を読み込む時点で容易に取得することが可能である。例えば、画像の展開前元画像がＪＰＥＧ画像であった場合、ＥＸＩＦ情報から取得することも可能である。

Ｓ１２０２にて、ネイティブ層２２０は、取得した画像情報から、画像の総画素数ｉを算出する。総画素数ｉは、ｉ＝Ｗ×Ｈで求められる。例えば、図１０の元画像の例にて示すように、画像の画素数がＷ＝４０００ｐｘ、Ｈ＝３０００ｐｘの場合、ｉ＝４０００×３０００＝１２００万画素となる。

Ｓ１２０３にて、ネイティブ層２２０は、総画素数ｉが所定の値Ｘ（例えば５００万画素）を超えているか否かを判定する。所定の値Ｘを超えていれば（Ｓ１２０３にてＹＥＳ）、Ｓ１２０４へ進み、超えていなければ（Ｓ１２０３にてＮＯ）、分割画像を作成せずに、分割画像の作成処理を終了する。ここでの所定の値Ｘについては、情報処理装置１１５のメモリサイズやＯＳにて制限される上限値等に基づいて決定される。

Ｓ１２０４にて、ネイティブ層２２０は、分割条件の決定をする。画像の総画素数ｉが１２００万画素である場合、Ｘを超えない範囲でブロック画像へ分割する条件を決定する。本実施形態において、分割条件は、Ｘを超えない範囲であれば、どのような条件でもよい。例えば、上述したように、分割の個数を、所定の個数で分割する条件や、１つのブロック画像が所定の画素数未満になるように分割する条件が挙げられる。なお、本実施形態では分割条件の決定はネイティブ層２２０で行っているが、取得した画像情報をもとにスクリプト層２１０にて分割条件を決定する構成としてもよい。

Ｓ１２０５にて、ネイティブ層２２０は、Ｓ１２０４にて決定した分割条件に従って、画像を分割する。そして、本処理フローを終了する。

以下では、元画像が６００万画素として、帯状に二分割して３００万画素のブロック画像を２つ生成したものとして説明を行う。図４の説明に戻る。

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

また、ＲＧＢ画像およびブロック画像群はオンメモリで保持しておいてもよいし、ファイルとして保存しておいてもよい。ここでは、ブロック画像群を、スクリプト層２１０が利用しやすいＤＩＢ（Ｄｅｖｉｃｅ Ｉｎｄｅｐｅｎｄｅｎｔ Ｂｉｔｍａｐ）フォーマットに変換してファイルに保存しておくこととする。この場合、ＩＤとの関連付けは「ｂｌｏｃｋ１＿ＩＤ．ｂｍｐ」、「ｂｌｏｃｋ２＿ＩＤ．ｂｍｐ」のように、決められた名前にＩＤを追記することで実現可能である。画像フォーマットは、ＤＩＢ以外を利用してもよい。

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

Ｓ４０９にて、ネイティブ層２２０は、Ｓ４０８で作成した縮小ＲＧＢデータをスクリプト層２１０で利用可能な形式（サポート可能な形式）の画像データに変換する。本実施形態では、変換するデータ形式をＪＰＥＧ形式とする。

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

Ｓ４１１にて、スクリプト層２１０は、ネイティブ層２２０で変換されたＢＡＳＥ６４データを受信し、描画領域に画像を描画する。具体的には、スクリプト層２１０は、指定されたＢＡＳＥ６４データをＯＳ層２３０のインタプリタ２３２に送信する。そして、インタプリタ２３２がＢＡＳＥ６４データのスクリプトを解釈し、描画領域に画像として表示する。ここで、描画領域に、ＢＡＳＥ６４データを反映させるサンプルコードの一例を、図１４（ａ）示す。

図１４（ａ）の例では、図９（ａ）に示す描画領域９０６に対しＳＶＧが動的に追加する方法を示している。後述するスタンプに関しても同様の操作で描画領域９０６に追加することが可能である。

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

Ｓ５０１にて、スクリプト層２１０は、補正パラメータを設定する。補正パラメータはスライドバー９０２の値を利用する。

Ｓ５０２にて、スクリプト層２１０は、インジケータを起動し、ディスプレイ１０４に表示する。インジケータとは、ユーザに処理中である旨を伝える表示であり、プログレスバーや、時計マーク、図形の回転等のなどが利用される。インジケータは、例えば、実行時間のかかる処理を行う場合に表示される。また、本実施形態ではスクリプト層２１０でインジケータの起動と停止を行っているが、ネイティブ層２２０でインジケータを利用することも可能である。

Ｓ５０３にて、スクリプト層２１０は、Ｓ５０１にて設定された補正パラメータと画像処理を実行する画像のＩＤ（Ｓ４０３で生成した画像のＩＤ）をＪＳＯＮ形式としてネイティブ層２２０へ送信する。なお、ＪＳＯＮは、ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎであり、ＪａｖａＳｃｒｉｐｔで利用できるデータ記述方法である、ＪＳＯＮは、ネイティブ層２２０と送受信可能なデータフォーマットの一つである。例えば、ＩＤと輝度補正の値を送るプログラムコードの記述例を図１４（ｂ）に示す。

Ｓ５０４にて、ネイティブ層２２０は、スクリプト層２１０から取得したＩＤを基に、図４のＳ４０５で展開されたＲＧＢ画像を特定する。

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

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

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

Ｓ５０７にて、ネイティブ層２２０は、Ｓ５０５で画像処理の実行されたＲＧＢ画像から、ＵＩで利用するための縮小ＲＧＢ画像を作成する。

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

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

Ｓ５１０にて、スクリプト層２１０は、ネイティブ層２２０からの要求に基づいて、インジケータを停止し、ディスプレイ１０４の表示からインジケータを消去する。

一方、Ｓ５１１にて、ネイティブ層２２０は、変換されたＪＰＥＧ形式のデータをＢＡＳＥ６４データに変換し、スクリプト層２１０へ送信する。

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

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

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

Ｓ６０１にて、スクリプト層２１０は、スタンプとして利用される画像が保存されているパスを取得する。スタンプは予め定義されたファイルを読み込むため、ハートスタンプ９０８をユーザがタップした際に、ハートスタンプが保存されているパスが返却される構成としておけばよい。

Ｓ６０２にて、スクリプト層２１０は、スタンプ描画用のオブジェクトを作成する。

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

Ｓ６０４にて、スクリプト層２１０は、Ｓ６０３の内容がインタプリタ２３２で解釈され、描画領域９０６へユーザ操作により選択されたスタンプが追加される。そして、本処理フローを終了する。

［プリンタ設定］
図９（ａ）のプリントボタン９０５をユーザが押下することで図３のＳ３４の処理が開始する。図３のＳ３４のプリンタ設定の詳細について、図７を用いて説明する。図７において、Ｓ７０１、Ｓ７０９〜Ｓ７１１は、ＣＰＵ１００がスクリプト層２１０のプログラムを用いて実行する処理である。Ｓ７０２、Ｓ７０４、Ｓ７０５、Ｓ７０７、Ｓ７０８、Ｓ７１２はＣＰＵ１００がネイティブ層２２０のプログラムを用いて実行する処理である。Ｓ７０３とＳ７０６は外部デバイス（ここでは、プリンタ１１２）が実行する処理である。

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

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

Ｓ７０３にて、プリンタは、情報処理装置１１５（ネイティブ層２２０）からの要求に応じて応答する。

Ｓ７０４にて、ネイティブ層２２０は、応答のあったプリンタのＩＰアドレスを検知して記憶する。

Ｓ７０５にて、ネイティブ層２２０は、応答のあったプリンタのＩＰアドレスに対し、プリンタ情報の提供を要求する。応答のあったプリンタが複数存在する場合、ネイティブ層２２０は、全てのプリンタに対して情報の提供を要求する。そのために、ネイティブ層２２０は、プリンタの情報を取得するためのコマンドを生成する。ここでのコマンドは、プリンタの動作を指定する命令であり、例えば、図１５（ａ）に示すようなＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）で表現される。

図１５（ａ）に示す各行の左側に書かれている「０１：」等の数値は、便宜上、説明を行うために付加した行番号であり、本来のＸＭＬ形式のテキストには記載されない。以下のプログラムコードの記述例においても同様であるとする。

１行目はヘッダであり、ＸＭＬ形式で記述していることを表す。２行目のｃｍｄはコマンドの開始を意味する。ｘｍｌｎｓで名前空間を指定し、コマンドの解釈の定義を指定する。６行目の＜／ｃｍｄ＞は、コマンドの終了を示す。３行目は以後に内容を記載する宣言であり、５行目でその終了を示す。４行目には要求する命令が記載されており、＜ｏｐｅｒａｔｉｏｎ＞と＜／ｏｐｅｒａｔｉｏｎ＞の間に実際の命令文言が存在する。命令文言であるＧｅｔＩｎｆｏｒｍａｔｉｏｎは、外部デバイスであるプリンタの情報を取得する命令である。例えば、プリンタが対応している用紙種類、サイズ、縁なし印刷機能の有無、印刷品位、等のケーパビリティ情報を提供するよう要求する。

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

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

Ｓ７０６にて、プリンタは、情報処理装置１１５からコマンドを受信すると、デバイス情報であるプリンタ情報をＸＭＬ形式で通信プロトコルに沿って、情報処理装置１１５へ送信する。図１５（ｂ）に、プリンタの情報の記述例を示す。

１行目はヘッダであり、ＸＭＬ形式で記述していることを表す。２行目のｃｍｄはコマンドの開始を意味する。ｘｍｌｎｓで名前空間を指定し、コマンドの解釈の定義を指定する。２１行目の＜／ｃｍｄ＞は、コマンドの終了を示す。

３行目は以後に内容を記載する宣言であり、２０行目の＜／ｃｏｎｔｅｎｔｓ＞までその内容は継続する。４行目でデバイスＩＤを示す。ここでは、本プリンタ情報を送信したプリンタの機種名が「Ｐｒｉｎｔｅｒ００１」であることを表す。５行目に記述された情報については本実施形態では用いず、これに関しては、第二の実施形態にて述べる。本プリンタ情報を送信した６行目以降はプリンタが有する各モードについての記述である。＜ｍｏｄｅ＞から＜／ｍｏｄｅ＞までで、１つのモードにおける情報が記述されている。６行目では、モードの番号が１である（ｍｏｄｅ＝１）。以降の＜ｍｅｄｉａ＞は印刷用紙の種類、＜ｓｉｚｅ＞は用紙サイズ、＜ｑｕａｌｉｔｙ＞は印刷品位、＜ｂｏｒｄｅｒ＞は縁あり／なしの情報をそれぞれ記述している。１１行目の＜ｄｐｉ＞は入力解像度を表しており、横方向が１２００［ｄｐｉ］、縦方向が１２００［ｄｐｉ］である。入力解像度についての詳細は後述する。

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

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

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

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

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

このように、スクリプト層２１０は、印刷用紙の種類・サイズ、印刷品位、縁あり／なし等のプリンタで利用できる機能を選択させる設定画面９１１を表示する。図１６に設定画面のＨＴＭＬによる記述例を示す。

図１６において、ＧｅｔＰａｐｅｒＳｉｚｅＮｕｍ（）、ＧｅｔＭｅｄｉａＴｙｐｅＮｕｍ（）、ＧｅｔＱｕａｌｉｔｙＮｕｍ（）、ＧｅｔＢｏｒｄｅｒＮｕｍ（）はネイティブ関数であり、それぞれの項目数を取得する機能を備える。例えば、プリンタが対応している用紙サイズがＡ４、Ａ５、Ｂ５、Ｌ判の４種類である場合、ＧｅｔＰａｐｅｒＳｉｚｅＮｕｍ（）は「４」を返す。

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

ＧｅｔＰａｐｅｒＳｉｚｅＶ（ｎ）、ＧｅｔＭｅｄｉａＴｙｐｅＶ（ｎ）、ＧｅｔＱｕａｌｉｔｙＶ（ｎ）、ＧｅｔＢｏｒｄｅｒＶ（ｎ）もネイティブ関数であり、引数ｎの値番目の文字列を返す。ここでは、用紙種類として、光沢紙が保持されているものとする。この場合、用紙種類のテキストを返す関数のＧｅｔＭｅｄｉａＴｙｐｅＴ（ｎ）の返り値は「光沢紙」のように、表示してユーザに示す文言である。これに対して、ＧｅｔＭｅｄｉａＴｙｐｅＶ（０）の返り値は「ＧｌｏｓｓｙＰａｐｅｒ」とプリンタが解釈可能な表現となっている。これらの文言や表現は、プリンタから送られてきた情報と結び付けてネイティブが決定する。例えば、プリンタから送られてきた情報より取り出した値が「ＧｌｏｓｓｙＰａｐｅｒ」であった場合、表示するテキストは「光沢紙」と決定する。決定の方法として、ネイティブはこれらの対応表を予め保持しておき、その対応表に沿ってテキストを決定すればよい。

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

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

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

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

Ｓ７１２にて、ネイティブ層２２０は、バインディング機能によりスクリプト層２１０から設定情報を受信する。ネイティブ層２２０では、後に、受信した設定情報を基に、プリンタ１１２の通信プロトコルに従って、プリントコマンドを生成する。そして、プリンタコマンドは、プリンタ通信部２３１を介して選択されたプリンタへ送信される。そして、本処理フローを終了する。

［レンダリング＆プリント処理］
ユーザが、図９（ｂ）に示す設定画面９１１の設定完了ボタン９１２を押下することで図３のＳ３５のレンダリング＆プリント処理が開始する。図３のＳ３５のレンダリング＆プリントの詳細について、図８を用いて説明する。また、レンダリング＆プリント処理に関しては、アプリケーションがバックグランドにて処理を行う際にも処理を継続するように記述されていることとする。例えば、ｉＯＳ（登録商標）ではｂｅｇｉｎＢａｃｋｇｒｏｕｎｄＴａｓｋＷｉｔｈＥｘｐｉｒａｔｉｏｎＨａｎｄｌｅｒなどであり、Ａｎｄｒｏｉｄ（登録商標）ではＳｅｒｖｉｃｅなどの、バックグラウンドでも動作可能とする機能を利用すればよい。図８において、Ｓ８０１、Ｓ８０２、Ｓ８２５は、ＣＰＵ１００がスクリプト層２１０のプログラムを用いて実行する処理である。Ｓ８０４〜Ｓ８０９、Ｓ８１１、Ｓ８１３、Ｓ８１５〜Ｓ８１７、Ｓ８１９〜Ｓ８２１、Ｓ８２４は、ＣＰＵ１００がネイティブ層２２０のプログラムを用いて実行する処理である。Ｓ８０２、Ｓ８１０、Ｓ８１２、Ｓ８１４、Ｓ８１８、Ｓ８２２、Ｓ８２６は、ＣＰＵ１００がＯＳ層２３０のプログラム（ＯＳ）を用いて実行する処理である。Ｓ８２３は、外部デバイス（ここでは、プリンタ１１２）が実行する処理である。

Ｓ８０１にて、スクリプト層２１０は、ＯＳ層２３０へインジケータ起動要求を送信する。

Ｓ８０２にて、ＯＳ層２３０は、スクリプト層２１０からの要求に基づき、インジケータを表示する。

Ｓ８０３にて、スクリプト層２１０は、ＵＩ表示に利用していたＳＶＧを、ネイティブ層２２０へ送信する。なお、Ｓ８０４〜Ｓ８０６など、スクリプト層２１０で実行可能な操作はスクリプト層２１０で実行してもよい。本実施形態は写真一枚、スタンプ一つのＳＶＧを例として用いる。写真一枚、スタンプ一つの場合のＳＶＧの記述例を図１７（ａ）に示す。以後、図１７（ａ）のＳＶＧの記述例を基にレンダリングについて説明する。ただし、図１７（ａ）のＳＶＧの記述例は概略を説明するためのものであり、細かい設定の記述は省略している。

Ｓ８０４にて、ネイティブ層２２０は、印刷情報からプリンタへ送信する出力解像度を取得し、そのサイズへＳＶＧを変更する。例えば、プリンタから取得した出力解像度のサイズが４０００ｐｘ×３０００ｐｘであれば、ＳＶＧは図１７（ｂ）のように書き換えられる。図１７（ｂ）では、ＳＶＧの横幅、縦幅がプリンタへ送信する画像サイズに合わせて変更されている。具体的には、４行目のｗｉｄｔｈが「４０００」に変更され、ｈｅｉｇｈｔが「３０００」に変更されている。

Ｓ８０５にて、ネイティブ層２２０は、ＳＶＧの画像に関する記述を、ブロック画像群を利用した記述へと変更する。Ｓ４０７、Ｓ５０６では、ＲＧＢ画像を上半分、下半分に二分割したブロック画像群が作成され、「ｉｍａｇｅＩＤ＿ａｂｏｖｅ．ｂｍｐ」、「ｉｍａｇｅＩＤ＿ｂｅｌｏｗ．ｂｍｐ」でアクセス可能な状態で保存されているものとする。図１７（ｂ）のＳＶＧの画像に関する記述を、先述の二つのブロック画像群を利用した記述へ変更したＳＶＧは、図１８（ａ）に示すような記述となる。図１８（ａ）では、先述の通り、画像に関する記述箇所を、ブロック画像群を利用した記述へ変更している。ブロック画像群はファイル保存されたデータをパスで指定する方法であるが、ＢＡＳＥ６４として画像データの実体を入れ込む方法を用いても実現可能である。なお、ブロック画像を用いた印刷用コンテンツの構築は、スクリプト層２１０またはネイティブ層２２０のいずれか一方で実施する構成でもよいし、両方で実施してもよい。なお、本実施形態では、Ｓ４０７、Ｓ５０６にて画像の分轄処理を行っているためＳ８０５を実施しているが、画像の分轄処理が行われていない場合、Ｓ８０５の処理がスキップされてもよい。

Ｓ８０６にて、ネイティブ層２２０は、Ｓ８０５にて変更したＳＶＧに対してマーカーを付与する。マーカーはＳＶＧコンテンツの右端に赤い帯を付与する例で説明を行う。本実施形態では赤帯を利用しているが、マーカーはこれに限らず、付与された情報が判別できるものであればどのようなものでもよい。図１８（ａ）のＳＶＧに対し、赤帯を付与したＳＶＧは、図１８（ｂ）に示すような記述となる。図１８（ｂ）では、４０００ｐｘ×３０００ｐｘのＳＶＧをさらに大きな４００５ｐｘ×３０００ｐｘのＳＶＧで囲っている。この差分となっている箇所が赤帯を付ける領域である。マーカーとなる赤帯は、描画を一番最後に実行させるために、ＳＶＧの一番最後の要素として追加をする。赤帯の利用についてはＳ８１５で説明する。

Ｓ８０７にて、ネイティブ層２２０は、端末状態の判定を行う。モバイル端末においては、着信や、別のアプリケーションを立ち上げるなどの処理が入ると、実行しているアプリケーションの処理はバックグランドにて動作するように制御される。アプリケーションがバックグランドにて行うにも関わらず、負荷の高い処理を続けていると他のアプリケーションに対して影響を及ぼす可能性がある。これを回避するためには、アプリケーションがバックグランド状態である場合は、なるべく負荷を減らすような工夫が必要となる。Ｓ８０７における端末状態の判定とは、情報処理装置１１５においてアプリケーションがフォアグランドで動作しているか、バックグランドで動作しているかをチェックすることである。

Ｓ８０８にて、ネイティブ層２２０は、ＳＶＧコンテンツから特定の領域のみをレンダリングするためのＳＶＧを作成する。アプリケーションにおいて、４０００ｐｘ×３０００ｐｘのサイズを一括でレンダリングすることはメモリ的に負荷が高い。これを、例えば４０００ｐｘ×１５００ｐｘのレンダリングの２回に分けることができれば、メモリ使用量を減らすことができる。この省メモリ化を目的としたのが、特定領域のみをレンダリングするためのＳＶＧであり、以後、この特定の領域をレンダリングするためのＳＶＧをバンドＳＶＧと呼ぶ。Ｓ８０８では、アプリケーションがフォアグランドで動作していると判定されたとして説明する。Ｓ８０８にて、ネイティブ層２２０は、例えば、図１９（ａ）に示すような一つ目のバンドを作成する。図１９（ｂ）では、ＳＶＧに対しｘ座標、ｙ座標を操作するための情報が付与されている（５行目および２０行目）。このｘ、ｙ座標の値を変更することで、描画されるＳＶＧの領域を変更することが可能となる。一つ目のバンドとしては、ｘ、ｙ座標ともに「０」である。

Ｓ８０９にて、ネイティブ層２２０は、ＯＳ層２３０に対してバンドサイズ用の画面生成を要求する。ここでは、一つ目のバンドＳＶＧから４００５ｐｘ×１５００ｐｘの領域を取得する。なお、メモリ（リソース）が潤沢であれば、４００５ｐｘ×３０００ｐｘを一括でレンダリングしてもよい。

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

Ｓ８１１にて、ネイティブ層２２０は、一つ目のバンドＳＶＧをＳ８１０で生成された画面に描画するように要求する。

Ｓ８１２にて、ＯＳ層２３０は、バンドＳＶＧの情報をロードし、Ｓ８１０で生成した画面に対して描画処理を実行する。なお、Ｓ８１０により生成した画面に描画処理が行われるため、この画面を、枠と呼ぶこともできる。バンドＳＶＧの情報がロードできたタイミングで、ネイティブ層２２０はロード完了の通知を受け取ることができる。この通知はＯＳに標準的に備わっている機能を利用すればよい。例えばｉＯＳアプリケーションの作成で利用するＯｂｊｅｃｔｉｖｅ−Ｃ言語であればｗｅｂＶｉｅｗＤｉｄＦｉｎｉｓｈＬｏａｄ関数などがそれに該当する。また、Ａｎｄｒｏｉｄアプリケーションの作成で利用するＪａｖａ言語であればｏｎＰａｇｅＦＩｎｉｓｈｅｄ関数などがそれに該当する。また、ＯＳ層２３０は、バンドＳＶＧのコマンドを上から順次処理する。そして、図１９（ｂ）から明らかなようにバンドＳＶＧの最後のコマンドとして赤帯の描画が指定されているので、ＯＳ層２３０は、赤帯を最後に描画する。

Ｓ８１３にて、ネイティブ層２２０は、ＯＳ層２３０に対し画像情報を要求する。ここでの画像情報とは、画面に表示されているＲＧＢＡデータのことである。Ｓ８１３は、端的にいえば、画面キャプチャの実行を要求するということである。

Ｓ８１４にて、ＯＳ層２３０は、ネイティブ層２２０からの要求に応じて、表示されている画面の画面キャプチャを実行し、取得したＲＧＢＡ情報をネイティブ層２２０へ送信する。ここで、バンドＳＶＧには４００５ｐｘ×３０００ｐｘの情報が記述されている。しかしながら、実際のＯＳ層２３０が用意した画面は４００５ｐｘ×１５００ｐｘしかない。この場合、用意した画面からはみ出した部分に関しては描画が実行されない。この性質より、４００５ｐｘ×１５００ｐｘの画面を用意することで、バンドＳＶＧにより定められる４００５ｐｘ×３０００ｐｘの上半分のみ（４００５ｐｘ×１５００ｐｘ）が描画される。結果として、ネイティブ層２２０は、上半分の情報（４００５ｐｘ×１５００ｐｘのＲＧＢＡ情報）のみを取得することが可能となる。上半分のＲＧＢＡ情報を取得するために、ＳＶＧ記述より指定される４００５ｐｘ×３０００ｐｘよりも小さい画面でロードする例を図１１（ａ）に示す。なお、図１１の右端における帯が、本実施形態の赤帯に対応する。この図１１（ａ）のような処理により上半分のＲＧＢＡ情報が取得される。これを応用して、４００５×１５００の画面に、ｙ座標（具体的には、５行目のｙ座標の値）を変化させた図１９（ｂ）に示すＳＶＧバンドを読み込ませることで、ＳＶＧコンテンツの下半分のみを取得することが可能となる。例えば、ｙ座標を０から１５００に変更することでＳＶＧコンテンツの下半分のみが取得される。下半分のＲＧＢＡ情報を取得するために、ＳＶＧ記述より指定される４００５ｐｘ×３０００ｐｘよりも小さい画面をｙ座標方向にずらし、かつ、ＳＶＧ記述より小さい画面でロードする例を図１１（ｂ）に示す。この図１１（ｂ）のような処理により下半分のＲＧＢＡ情報が取得される。

Ｓ８１５にて、ネイティブ層２２０は、取得したＲＧＢＡデータの右端が赤色になっているか否かを確認する。Ｓ８１２にて、ＯＳ層２３０からネイティブ層２２０へロード完了の情報が送られてきているが、これはＳＶＧデータ読み込み完了のタイミングであり、ＳＶＧの描画が完了したタイミングというわけではない。つまり、ＳＶＧデータ読み込み完了と描画完了にはタイムラグがあり、この間に画面キャプチャを実行してしまうと、求める画像を得ることができない。そのためにロードさせるＳＶＧデータに赤帯を付与し、求める画像が取得できているか否かの判定基準としている。

Ｓ８１６にて、ネイティブ層２２０は、赤帯（マーカ）が有るか否かを確認する。赤帯が確認できない場合は（Ｓ８１６にてＮＯ）、Ｓ８１３へ戻る。そしてネイティブ層２２０は、ＯＳ層２３０に対し画像情報を要求する。つまり、この段階では、ネイティブ層２２０は、上半分の情報（４００５ｐｘ×１５００ｐｘのＲＧＢＡ情報）を再度要求する。この際、一定時間待ってからやり直し、ＣＰＵ負荷を減らすなどの工夫も考えられる。赤帯（マーカ）が確認できた場合は、ＯＳ層２３０が４００５ｐｘ×１５００ｐｘの画面に対する描画が完了したことを示すので、図８の処理は（Ｓ８１６にてＹＥＳ）Ｓ８１７の処理へ進む。

Ｓ８１７にて、ネイティブ層２２０は、画面のリセットをＯＳ層２３０に要求する。

Ｓ８１８にて、ＯＳ層２３０は、ネイティブ層２２０からの要求に基づき、画面の破棄を行う。ここでの画面破棄には二つ意味がある。一つ目は、次のＳＶＧバンドをロードした際に、前回の赤帯（マーカ）が残ったままとなり、描画完了と誤認識してしまうことをなくすためである。これに関しては、バンドＳＶＧ毎に付けるマーカーの色や形などを変化させることで対応してもよい。二つ目は、ＳＶＧバンドのサイズを動的に変える可能性があるためである。ＳＶＧバンドサイズが途中で変更される例については後述する。

Ｓ８１９にて、ネイティブ層２２０は、取得したＲＧＢＡデータをＪＰＥＧ画像へ変換する。ここで、Ｓ８１４にてＯＳ層２３０からネイティブ層２２０に送られてくるＲＧＢＡデータには印刷には不要なＡ（透過度）の情報と、赤帯（マーカ）の情報が含まれる。そのため、ＪＰＥＧ変換は、この二つの情報を除いて実行する。

Ｓ８２０にて、ネイティブ層２２０は、プリンタへ送信するためのプリントコマンドをＳ８１９で生成したＪＰＥＧ画像に付与する。ここで、ＪＰＥＧ画像に付与するデータは、プリンタ設定の情報を基に生成される。また、必要であれば、プリンタを制御するためのコマンドを付与してもよい。付与される情報としては、例えば、送信する情報が何番目のバンドかを示す情報や、一番末尾のバンドかを判定するためのフッタなどが挙げられる。

Ｓ８２１にて、ネイティブ層２２０は、ＯＳ層２３０に対して印刷情報（印刷処理に用いられる印刷データ）の送信を要求する。

Ｓ８２２にて、ＯＳ層２３０は、ネイティブ層２２０から受け取った印刷情報をプリンタへ送信する。印刷情報の送信が完了した後、処理はＳ８２４へ進む。

Ｓ８２３にて、プリンタは、情報処理装置１１５（ＯＳ層２３０）から受け取った印刷情報を基に、印刷を実行する。

Ｓ８２４にて、ネイティブ層２２０は、レンダリングが終了したか否かの判定を行う。レンダリング終了の判定は、例えば、取得した画像の高さの合計が出力サイズの高さと一致している、終了判定のためのフラグが立っているなどに基づいて行われる。なお、その他の判定方法を用いてもよい。レンダリングが終了していない場合は（Ｓ８２４にてＮＯ）Ｓ８０７へ戻り、処理を繰り返す。レンダリングが終了している場合は（Ｓ８２４にてＹＥＳ）、Ｓ８２５の処理へ進む。

Ｓ８２５にて、スクリプト層２１０は、インジケータの停止要求をＯＳ層２３０へ送信する。

Ｓ８２６にて、ＯＳ層２３０は、スクリプト層２１０からの要求に基づき、インジケータを停止し、レンダリング＆プリント処理を終了する。

ここで、上述した説明では、４０００ｐｘ×３０００ｐｘのうち、４０００ｐｘ×１５００ｐｘのデータまでしか作成できていない。そこで、ここからは後半部分のデータ作成について説明する。また、Ｓ８２４においてＮｏと判定されてＳ８０７の処理に遷移した際に、本アプリケーションがバックグランドで実行されていると判定されたとして説明を行う。一つ目のバンドＳＶＧは４０００ｐｘ×１５００ｐｘのサイズで画像の取得を行ったが、バックグラウンド実行時は前述の通りメモリをなるべく節約することが重要である。

Ｓ８０８にて、ネイティブ層２２０は、Ｓ８０７の結果を受け、Ｓ８０８以降の処理を行う。先述の通り、取得する画像のサイズを小さくすることでメモリ使用量を減らすことが可能である。そのため、二つ目のバンドは４０００ｐｘ×７５０ｐｘのサイズとし、以後の説明をする。ＳＶＧバンドの記述例は図１９（ｂ）と同等であるものとする。

先述の通り、データ取得をする領域は実際にＯＳ層２３０が用意した画面サイズになるので、バンドＳＶＧ自体は４００５ｐｘ×３０００ｐｘの情報が記載されていてよい。ただし、すでに取得した情報を再度取得することがないように、バンドＳＶＧのｙ座標は適切に変更する必要がある。つまり、ネイティブ層２２０は、４００５ｐｘ×３０００ｐｘのうち、（０，１５００）から（４００５，２２５０）のデータを取得することになる。そのため、図１９（ｂ）の５行目のｙ座標を１５００へ変更する。また、ＳＶＧの特定エリアを表示する方法は、ＳＶＧのｖｉｅｗＢｏｘという属性を操作するなど、どのような方法を利用してもよい。

Ｓ８０９にて、ネイティブ層２２０は、ＯＳ層２３０に対して情報を取得するサイズ（４００５ｐｘ×７５０ｐｘ）の画面の生成を要求する。Ｓ８１０〜Ｓ８２３は、先述と同じ処理が行われる。この処理により、ネイティブ層２２０は、（０，１５００）から（４００５，２２５０）のＲＧＢＡ情報を取得することができる。更に、Ｓ８２４にて、全領域のレンダリングが終了しているか否かを判定し、ここでは、４００５ｐｘ×７５０ｐｘのサイズの画面のレンダリングが残っているため、Ｓ８０７に戻り処理を繰り返す。この時のバンドＳＶＧのｙ座標は２２５０となる。以降の処理は先述の説明と同様であるため省略する。

本実施形態により、ウェブの機能を利用して高解像度の画像が含まれた印刷用コンテンツを印刷する場合でも、高画質な印刷物を得ることができる。なお、本実施形態では、取得できたＲＧＢＡ情報からＪＰＥＧ画像を生成して、順次ＯＳ層２３０へ印刷情報の送信を要求しているが、他の方法でもよい。例えば、ネイティブ層２２０は、全てのＲＧＢＡ情報が揃ってから、まとめてＪＰＥＧ画像に変換し、ＯＳ層２３０に対して印刷情報の送信を要求してもよい。また、全てのＪＰＥＧ画像が揃ってから、まとめて１つのＪＰＥＧ画像を生成し、ＯＳ層２３０に対して印刷情報の送信を要求してもよい。

＜第二の実施形態＞
第一の実施形態にて述べた図４のＳ４０６（図１２）では、展開したＲＧＢデータのブロック画像への分割条件を、コンテンツに配置する画像情報から決定した。本実施形態では、分割条件を、画像情報に加えて、ソフトウェアがインストールされている携帯端末（ここでは、情報処理装置１１５）の情報との組み合わせから決定する例について説明する。

端末情報は、例えばプラットフォームのＯＳに関する情報（ＯＳの種類、バージョン情報など）、端末のＣＰＵのクロック周波数、端末のメモリサイズを使用する。冒頭で述べたとおり、ウェブの機能における画像表示の制限は、ＯＳの種類や端末性能、特にメモリサイズに依存する。そのため、分割条件を決定するために、端末情報をネイティブの機能を使用して携帯端末から取得する。ここで取得される端末情報は、例えば、図１５（ｂ）に示したプリンタ情報として取得でき、図１５（ｂ）では、５行目にてメモリサイズを取得している。

例えば、図１３に示すようなＯＳ種類およびバージョン情報、メモリサイズ、ＣＰＵクロック周波数などに対応したテーブルをアプリケーションのネイティブ層２２０に保持しておく。そして、ＯＳの種類やバージョン、メモリサイズ、ＣＰＵクロック周波数によって分割条件を変えることが考えられる。これらの情報は、全て使用してもよいし、一部のみ使用してもよい。また、バージョン情報から選択される分割条件とメモリサイズから選択される条件が必ずしも一致するとは限らない。この場合は、分割条件が厳しい方（画像分割をする分割上限画素数はより小さい方）を採用する。例えば、Ａ ＯＳのバージョン９で、メモリサイズが１０２４である場合、分割の条件として、以下のように決定される。
画像分割：する
分割上限画素数：５００万

なお、表に示す条件および数値は一例であり、これらに限定されるものではない。また、テーブルに無い値のＣＰＵクロック数やメモリサイズであった場合は、補間により条件を決定してもよいし、より数値が近いテーブルの値を使用してもよい。メモリサイズやＣＰＵクロック周波数は、ＯＳ共通としたが、ＯＳにより異なるものを用いてもよい。また、本実施形態ではテーブルを使用したが、メモリサイズやクロック周波数、バージョン情報に関する所定の閾値以上か否かによって分割条件を決定する方法でもよい。

以上により、第一の実施形態の効果に加え、端末に付属する属性情報から、携帯端末の性能に応じて分割条件を決定することができる。

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

１１２…プリンタ、１１５…情報処理装置、２１０…スクリプト層、２２０…ネイティブ層、２３０…ＯＳ層

Claims (11)

1. プロセッサで翻訳され実行されるための命令セットを含む第１のプログラム層と、予め翻訳され前記プロセッサで実行されるための命令セットを含む第２のプログラム層とを包含するアプリケーションが動作可能な情報処理装置であって、
   前記第１および第２のプログラム層の少なくとも一方が動作することにより、印刷コンテンツに配置される画像の情報および前記情報処理装置の情報のうちの少なくとも一つに基づいて前記画像の分割条件を決定する決定手段と、
   前記第２のプログラム層が動作することにより、前記決定手段で決定した分割条件に従って前記画像を分割して分割画像を作成する分割手段と、
   前記第１のプログラム層および前記第２のプログラム層の少なくとも一方が動作することにより、前記分割画像を配置した印刷コンテンツを構築する構築手段と、
   前記第２のプログラム層が動作することにより、前記分割画像を配置した印刷コンテンツをレンダリングしてレンダリング画像を生成するレンダリング手段と、
   前記第２のプログラム層が動作することにより、前記レンダリング画像を用いて印刷データを生成する生成手段と
   を備えることを特徴とする情報処理装置。
2. 前記印刷コンテンツは、ウェブ標準言語を用いて記述されることを特徴とする請求項１に記載の情報処理装置。
3. 前記印刷コンテンツは、ＳＶＧ（Ｓｃａｌａｂｌｅ Ｖｅｃｔｏｒ Ｇｒａｐｈｉｃｓ）またはＣａｎｖａｓを用いて記述されることを特徴とする請求項１または２に記載の情報処理装置。
4. 前記画像の情報は、画像の縦および横の画素数の情報を含むことを特徴とする請求項１乃至３のいずれか一項に記載の情報処理装置。
5. 前記情報処理装置の情報は、オペレーティングシステムに関する情報、プロセッサのクロック数、メモリサイズの少なくとも１つを含むことを特徴とする請求項１乃至４のいずれか一項に記載の情報処理装置。
6. 前記分割条件は、画像の分割数および分割のパターンであることを特徴とする請求項１乃至５のいずれか一項に記載の情報処理装置。
7. 前記分割条件は、前記情報処理装置が備えるオペレーティングシステムにより制限されたリソースの上限を超えないサイズに前記画像を分割するように決定されることを特徴とする請求項１乃至６のいずれか一項に記載の情報処理装置。
8. プロセッサで翻訳され実行されるための命令セットを含む第１のプログラム層と、予め翻訳され前記プロセッサで実行されるための命令セットを含む第２のプログラム層とを包含するアプリケーションが動作可能な情報処理装置の制御方法であって、
   前記第１および第２のプログラム層の少なくとも一方により、印刷コンテンツに配置される画像の情報および前記情報処理装置の情報のうちの少なくとも一つに基づいて前記画像の分割条件を決定する決定工程と、
   前記第２のプログラム層により、前記決定工程にて決定した分割条件に従って前記画像を分割して分割画像を作成する分割工程と、
   前記第１のプログラム層および前記第２のプログラム層の少なくとも一方により、前記分割画像を配置した印刷コンテンツを構築する構築工程と、
   前記第２のプログラム層により、前記分割画像を配置した印刷コンテンツをレンダリングしてレンダリング画像を生成するレンダリング工程と、
   前記第２のプログラム層により、前記レンダリング画像を用いて印刷データを生成する生成工程と
   を有することを特徴とする制御方法。
9. プロセッサで翻訳され実行されるための命令セットを含む第１のプログラム層と、予め翻訳され前記プロセッサで実行されるための命令セットを含む第２のプログラム層とを包含するプログラムであって、
   コンピュータを、
   前記第１のおよび第２のプログラム層の少なくとも一方により、印刷コンテンツに配置される画像の情報および前記コンピュータの情報のうちの少なくとも一つに基づいて前記画像の分割条件を決定する決定手段として機能させ、
   前記第２のプログラム層により、前記決定手段で決定した分割条件に従って前記画像を分割して分割画像を作成する分割手段として機能させ、
   前記第１のプログラム層および前記第２のプログラム層の少なくとも一方により、前記分割画像を配置した印刷コンテンツを構築する構築手段として機能させ、
   前記第２のプログラム層により、前記分割画像を配置した印刷コンテンツをレンダリングしてレンダリング画像を生成するレンダリング手段として機能させ、
   前記第２のプログラム層により、前記レンダリング画像を用いて印刷データを生成する生成手段として機能させる
   ことを特徴とするプログラム。
10. 前記第１のプログラム層は、ウェブ標準言語を用いて記述されることを特徴とする請求項９に記載のプログラム。
11. 前記第１のプログラム層は、ＨＴＭＬ５、ＣＳＳ３、またはＪａｖａＳｃｒｉｐｔを用いて記述されることを特徴とする請求項９または１０に記載のプログラム。

Images