JP2016014921A

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

Info

Publication number: JP2016014921A
Application number: JP2014135180A
Authority: JP
Inventors: 鈴木　智博; Tomohiro Suzuki; 智博鈴木; 尚紀鷲見; Hisanori Washimi; 梅田　清; Kiyoshi Umeda; 清梅田
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2014-06-30
Filing date: 2014-06-30
Publication date: 2016-01-28
Anticipated expiration: 2034-06-30
Also published as: US20150379380A1; JP6360370B2; US9575702B2

Abstract

【課題】表示画像の印刷において画質の低下を防ぐ情報処理装置を提供する。【解決手段】アプリケーションの機能により表示された画像を印刷する場合、アプリケーションの実行の際にプロセッサで実行可能なように翻訳されてプロセッサにより実行されるスクリプト命令セットで構成された第１の層において、当該画像のオブジェクトの描画位置及びサイズを含む描画情報から、当該オブジェクトをレンダリングするためのレンダリング情報を決定する。そして、プロセッサで実行可能なように予め翻訳されている命令セットで構成された第２の層において、決定されたレンダリング情報に従って、オブジェクトをレンダリングする。【選択図】図６

Description

本発明は、画像処理を行う情報処理装置、情報処理方法、およびプログラムに関する。

近年、カメラ機能が搭載された可搬型多機能携帯電話（以下、モバイルコンピュータ）が普及し、デジタルカメラや従来のパーソナルコンピュータ（以下、ＰＣ）の販売台数を遥かに凌ぐ勢いで拡販されている。このようなモバイルコンピュータのシステムは、基本的には３つの要素で成り立っている。即ち、コンピュータ自身であるハードウェア、ハードウェア上で動作するオペレーティングシステム（以下、ＯＳ）、ＯＳ上で動作するアプリケーションである。ユーザは、アプリケーションを用いて、地図やメール、ブラウザを起動してインターネット上のウェブサイトを閲覧するなどの操作を行うことができる。このようなモバイルコンピュータ上で動作するアプリケーションの形態として、主に２つのものが存在する。ネイティブアプリケーションとウェブアプリケーションである。以下、それぞれの特徴を説明する。

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

ウェブアプリケーションは、コンピュータ上のＯＳに標準的に組み込まれているウェブブラウザ上で動作するアプリケーションである。ウェブアプリケーションは、ウェブブラウザが解釈できるように、一般的には、ＨＴＭＬ５、ＣＳＳ、Ｊａｖａｓｃｒｉｐｔ（登録商標）といった言語を用いて開発される。これらはウェブ標準言語であるため、一度アプリケーションを記述すれば、ウェブブラウザが動作する環境であればどこでも動作可能というメリットがある。特許文献１には、ウェブアプリケーションの形態の一例が記載されている。ＨＴＭＬ５、ＣＳＳ、ＪａｖａＳｃｒｉｐｔで記述されたウェブアプリケーションの本体は、モバイルコンピュータ外部のサーバ上に存在する。ウェブアプリケーションは、利用時にサーバからモバイルコンピュータにインターネット回線を介してダウンロードされるため、ユーザは、ユーザインタフェース（ＵＩ）デザインなどを予めコンパイルすることなく動的に変更することができる。

近年、モバイルコンピュータは高解像度のカメラを保持することが多くなってきている。モバイルコンピュータは日常的に携帯され、かつ写真を数千枚程度記憶可能なメモリを備えているため、ユーザは高い頻度で気軽に写真撮影を楽しむことができる。このような写真画像に対して、例えばモノクロ・セピア調にするフィルタ処理を施したり、写真が暗い、色バランスが崩れている等の不具合を修正するための画像処理は、ユーザにとって極めて重要であり、必要不可欠なアプリケーションとなってきている。このような画像処理をユーザに対して、ストレスなく簡単に提供できることがアプリケーションにおいては重要である。

特開２０１１−２３３０３４号公報

ウェブアプリケーションは、一般的には、ブラウザのセキュリティ上の制約から、ブラウザ上でＪａｖａＳｃｒｉｐｔにより実行されるか、サーバ上で実行される。ＪａｖａＳｃｒｉｐｔは、従来より、人間が視認可能な文字列のスクリプトとして記述され、スクリプトを動作時に随時コンパイルすることで実行することができる。しかしながら、高度で複雑な画像処理をＪａｖａＳｃｒｉｐｔで記述すると動作が遅くなるという問題がある。

引用文献１のように画像処理をサーバで実行するように構築した場合には、モバイルコンピュータ内部に存在する写真などのデータをインターネット回線を介してサーバ上にアップロードし、画像処理後の結果をダウンロードする時間が必要となる。これは、モバイルアプリケーションに対してストレスの少ない、即時的な処理を欲しているユーザにとっては大きな問題となる。それに加え、サーバでの処理はオフラインでは実行できないという問題がある。

上述したように、ネイティブアプリケーションには、処理を高速実行できるというメリットがある。しかしながら、ネイティブアプリケーションはＯＳ毎に異なる開発言語で別々に開発する必要があるため、開発コストと開発時間が増大するという問題がある。また、ネイティブアプリケーションは、予めコンパイルする必要がある。そのため、例えばアプリケーションのＵＩデザインを動作時に変更したり、機能を動的に追加するといったことは難しく、柔軟性に欠けるという問題がある。

ここで、ＵＩの全て若しくは大部分をＨＴＭＬ５、ＣＳＳ３、Ｊａｖａｓｃｒｉｐｔといったいわゆるウェブ標準言語で記述し、ウェブ標準言語で記述された内容から、ネイティブ言語で記述された機能を利用することができるアプリケーションを考える。このようなアプリケーションをモバイルコンピュータ上に実装することで、ウェブアプリケーションとネイティブアプリケーションの双方のメリットを実現するシステムをモバイルコンピュータ上で構築することができる。

そのようなシステム上で、例えば、写真印刷アプリケーションを動作させる場合を考える。そのようなアプリケーションでは、例えば、印刷対象となる写真を描画し、写真上に撮影日時などの日付情報を重畳し、絵文字などのスタンプ画像を重畳し、重畳した結果をプリントすることが行われる。印刷コンテンツの描画は、ウェブ標準言語を用いて記述される。例えば、ＨＴＭＬ５のＣａｎｖａｓにより印刷コンテンツを生成する場合、まずＣａｎｖａｓで描画領域を確保し、drawImage関数を利用して写真やスタンプ画像を重畳してゆくことになる。例えば、写真、日付、スタンプ画像のそれぞれの画像を１枚のＣａｎｖａｓに描画する場合は、下記のようにdrawImage関数でコンテンツを上書きしていく。
＜script＞
var canvas = Canvasの作成
canvas.width = Canvasの横幅
canvas.height = Canvasの縦幅
var ctx = canvasにコンテンツを描画するためのコンテキストオブジェクトを取得
var img = PictureImage; //写真画像
ctx.drawImage(img, 〜); //img以降の引数で、画像のサイズや位置を指定
img = DateImage;//日付画像
ctx.drawImage(img, 〜); //日付画像を同じcanvasに重畳
img = StampImage;//スタンプ画像
ctx.drawImage(img, 〜); //スタンプ画像を同じcanvasに重畳
＜/script＞
上記の印刷コンテンツを印刷するためには、プリンタの印刷エンジンが要求する画像データ（ビットマップデータ）へ変換する必要がある。この処理はレンダリング処理と呼ばれる。レンダリング処理では、上記アプリケーションのＵＩ上で作成された、印刷コンテンツの表示領域からビットマップデータを取得する。

しかしながら、ＵＩ表示されている画像から取得するビットマップデータは一般的に低解像度であり、一方、印刷エンジンが要求する画像データは一般的に高解像度である。従って、表示用画像データから印刷用画像データへの拡大処理において、ジャギーや画像ボケが発生してしまう場合がある。そのような画像は、精鋭さを欠くものであり、印刷物として適切ではない。

本発明の目的は、このような従来の問題点を解決することにある。上記の点に鑑み、本発明は、表示画像の印刷において画質の低下を防ぐ情報処理装置、情報処理方法、プログラム及び記憶媒体を提供することを目的とする。

上記課題を解決するため、本発明に係る情報処理装置は、プロセッサと、アプリケーションの実行の際に前記プロセッサで実行可能なように翻訳され当該プロセッサにより実行されるスクリプト命令セットで構成された第１の層と、前記プロセッサで実行可能なように予め翻訳されている命令セットで構成された第２の層と、を有する階層構造を成し、前記第１の層と前記第２の層との連携により前記アプリケーションを実行するためのプログラムを記憶する記憶手段と、前記アプリケーションの機能により表示された画像を印刷する場合、前記第１の層において、当該画像のオブジェクトの描画位置及びサイズを含む描画情報から、当該オブジェクトをレンダリングするためのレンダリング情報を決定する決定手段と、前記第２の層において、前記決定手段により決定された前記レンダリング情報に従って、前記オブジェクトをレンダリングするレンダリング手段と、を備えることを特徴とする。

本発明によれば、表示画像の印刷において画質の低下を防ぐことができる。

携帯型情報端末のハードウェア構成を示すブロック図である。携帯型情報端末のソフトウェア構成を示すブロック図である。写真印刷処理の全体の手順を示すフローチャートである。Ｓ３０１の写真画像選択の処理を示すフローチャートである。Ｓ３０２の画像処理を示すフローチャートである。Ｓ３０３のスタンプ画像追加の処理を示すフローチャートである。Ｓ３０４のプリンタ設定の処理を示すフローチャートである。Ｓ３０５のレンダリング処理を示すフローチャートである。Ｓ３０６のプリント処理を示すフローチャートである。写真印刷アプリケーション画面の一例を示す図である。プリンタの設定ＵＩの一例を示す図である。写真印刷処理の全体の手順を示す他のフローチャートである。Ｓ１２０４のスタンプ画像の特定の処理を示すフローチャートである。Ｓ１２０５のスタンプ画像の操作処理を示すフローチャートである。

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

［第１の実施形態］
以下、携帯型情報端末上で、ウェブアプリケーションの１つである写真印刷アプリケーションを動作させたときの動作について説明する。写真印刷アプリケーションでは、ユーザが選択した画像に対して様々な画像処理（例えば、輝度補正し、スタンプ画像を追加）を適用した後に、印刷対象のコンテンツを印刷する。なお、本実施形態においては、写真印刷アプリケーションは、後述するハイブリッド型アプリケーションとして提供されている。

［ハードウェア構成］
図１は、情報処理装置、特に、携帯型情報端末１００のハードウェア構成の一例を示すブロック図である。同図において、ＣＰＵ（中央演算装置）１０１は、各実施形態において説明する動作を、プログラムをＲＯＭ１０２からＲＡＭ１０３に読み出して実行することにより実現する。ＲＯＭ１０２は、ＣＰＵ１００により実行されるプログラム等を記憶するコンピュータ読取可能な記憶媒体である。ＲＡＭ１０３は、例えば、ＣＰＵ１００によるプログラムの実行時に、各種データを一時的に記憶するためのワーキングメモリとして用いられる。２次記憶装置１０４は、例えばハードディスクやフラッシュメモリであり、例えば、画像ファイルや画像データ、画像解析などの処理結果を保持するデータベースなどを記憶する。タッチセンサ１０５は、タッチパネル上でのユーザの接触動作を検知するためのセンサである。ディスプレイ１０６は、写真印刷アプリケーション上の印刷設定画面等のユーザインタフェース画面や、画像処理結果などを表示する。ディスプレイ１０６は、タッチセンサ１０５を含んでも良い。

加速度センサ１０７は、加速度を検出するためのセンサであり、携帯型情報端末１００の傾き等を検出する。外部インタフェース（ＩＦ）１０８は、携帯型情報端末１００をプリンタ１１４と接続する。携帯型情報端末１００は、外部ＩＦ１０８により、プリンタ１１５での印刷を行うことができる。また、携帯型情報端末１００は、外部ＩＦ１１０により、インターネット１１６を介してプリンタ１１５での印刷を行うこともできる。外部ＩＦ１０９は、携帯型情報端末１００を外部撮像デバイス（カメラ）１１４と接続する。外部撮像デバイス１１３や内部撮像デバイス１１１により撮像された画像データは、所定の画像処理後、２次記憶装置１０４に格納される。外部ＩＦ１１０は、無線ＬＡＮを備えており、携帯型情報端末１００をインターネット１１６と接続する。携帯型情報端末１００は、外部ＩＦ１１０により、インターネット１１６を介して外部の各種サーバ１１７から画像データ等を取得することができる。携帯型情報端末１００の動作に必要な電源は、バッテリ１１２から供給される。上記のＣＰＵ１０１〜バッテリ１１２は、システムバス（制御バス／データバス）１１３を介して相互に接続されており、ＣＰＵ１０１は各部を統括的に制御する。

携帯型情報端末は、ＵＳＢや、有線ＬＡＮのような有線接続を行うための外部ＩＦを含んでも良い。また、無線ＬＡＮの他に、Ｂｌｕｅｔｏｏｔｈ（登録商標）や赤外線通信のような無線接続を行うための外部ＩＦを含んでも良い。無線ＬＡＮによる接続形態においては、例えば、デバイス同士が直接接続される場合や、不図示の無線ＬＡＮルータを介して通信先のデバイスと接続される場合がある。

［ソフトウェア構成］
図２は、写真印刷アプリケーション（以下、アプリケーション）を実行するための、携帯型情報端末１００上でのソフトウェア構成の一例を示す図である。図２に示すソフトウェアの各ブロックは、ＣＰＵ１０１により実現される。本実施形態においては、携帯型情報端末１００のソフトウェアは、スクリプト層２０１、ネイティブ層２０２、ＯＳ層２０３の３つの階層構造を有する。アプリケーションの機能は、図２に示す各層の連携により実現される。スクリプト層２０１は、ＨＴＭＬ５、ＣＳＳ（ＣａｓｃａｄｉｎｇＳｔｙｌｅＳｈｅｅｔｓ）３、Ｊａｖａｓｃｒｉｐｔといったウェブ標準言語により、テキストデータで各種命令（スクリプト命令セット）が記述されている。各種命令とは、例えば、コンテンツの描画や画像の表示、動画の再生等の命令である。また、スクリプト層２０１は、それらのテキストデータを保持している。記述されたスクリプトは、アプリケーション実行環境上に存在するプロセッサ（ＣＰＵ１０１）によりテキスト命令群が翻訳されて実行される。翻訳は、実行の度に命令文を一行ずつ動的に翻訳する形態や、アプリケーションを起動したときに翻訳する形態、アプリケーションを携帯型情報端末１００にインストールしたときに翻訳する形態などで行われる。以下、スクリプト層２０１で処理することやスクリプト層２０１での内容を単にスクリプトとも呼ぶ。スクリプトの命令をデバイス（携帯型情報端末１００）内で翻訳する際には、例えば、後述するネイティブ層２０２やＯＳ層２０３のインタプリタの機能が使用される。なお、本実施形態においては、アプリケーションのＵＩの大部分がスクリプトで記述される。

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

ＯＳ層２０３は、デバイスのオペレーティングシステム（ＯＳ）に対応する。ＯＳ層２０３は、ハードウェア機能の使用をアプリケーションに提供する役割や、ＯＳ固有の機能を有する。ＯＳ層２０３はＡＰＩを備えており、スクリプト層２０１やネイティブ層２０２からＯＳ層２０３の機能を使用することができる。

本実施形態では、上記のスクリプト層２０１からネイティブの機能の呼び出しを可能にすることをバインディング（又はバインド）と呼ぶ。各種ネイティブ機能はＡＰＩを備えており、スクリプト層２０１は、ＡＰＩを呼び出すことによりネイティブ機能を使用することができる。そのようなバインディング機能は、通常、各種ＯＳが標準的に備えている。本実施形態では、スクリプト層２０１とネイティブ層２０２を両方含むアプリケーションを特にハイブリッド型アプリケーションと呼ぶ。ハイブリッド型アプリケーションでは、ＵＩの全て若しくは大部分をＨＴＭＬ５、ＣＳＳ３、Ｊａｖａｓｃｒｉｐｔといったいわゆるウェブ標準言語で記述し、ウェブ標準言語で記述された内容から、ネイティブ言語で記述された機能を利用することができる。このようなハイブリッド型アプリケーションを携帯型情報端末１００上に実装することで、ウェブアプリケーションとネイティブアプリケーションの双方のメリットを実現するシステムを携帯型情報端末１００上で構築することができる。

以下、図２の各ブロックについて説明する。

●画像データの取得
スクリプト層２０１の画像取得部２０４は、ネイティブ層２０２に対して画像データの取得を依頼する。取得依頼方法は複数可能であり、例えば、ファイルの存在場所そのものを指定する絶対パス指定方法や、ダイアログ表示を促す方法などがある。ネイティブ層２０２の画像読込部２０５は、画像取得部２０４からの取得依頼に基づき、画像データを保持している領域であるネイティブ層２０２の画像群２０６から画像データを取得する。画像群２０６からの画像データの取得方法は、画像取得部２０４の依頼方法によって異なる。画像読込部２０５は、例えば、ファイルの絶対パスに基づき直接に画像データを取得したり、ダイアログ表示での選択に基づき画像データを取得する。

ネイティブ層２０２のデータ変換部２０７は、ネイティブ層２０２のデータをスクリプト層２０１で利用可能なデータ形式に変換する。逆に、データ変換部２０７は、スクリプト層２０１から送られてきたデータをネイティブ層２０２で利用可能なデータ形式に変換する。スクリプト層２０１のデータ変換部２０８は、スクリプト層２０１のデータをネイティブ層２０２で利用可能なデータ形式に変換する。逆に、ネイティブ層２０２から送られてきたデータをスクリプト層２０１で利用可能なデータ形式に変換する。本実施形態では、例えば、ネイティブ層２０２の画像読込部２０５により取得された画像データは、スクリプト層２０１で利用可能なＢＡＳＥ６４データ形式に変換されてスクリプト層２０１に渡される。

●画像データの読込／保存
ネイティブ層２０２のデータ保持部２０９は、画像読込部２０５により読み込まれた画像データや、画像処理部２１０により画像処理が実行された画像データを保持する。ここで、保持される画像データはＲＧＢ展開されている。従って、画像読込部２０５により読み込まれて保持された画像データに対して、直ちに画像処理が実行可能である。ネイティブ層２０２のデータ保存部２１６は、必要に応じて、データ保持部２０９に保持されている画像データを画像群２０６に格納する。

●出力
スクリプト層２０１のレンダリング部２１９は、出力（表示／印刷）対象の画像のレンダリングについてのスクリプトを作成するためのブロックであり、コンテンツ描画部２１１、コンテンツ操作部２１２、画像処理制御部２１３を含む。本実施形態では、レンダリング部２１９でスクリプト作成途中の画像はディスプレイ１０６には表示されない。コンテンツ描画部２１１は、印刷対象のコンテンツを、ウェブ標準言語で記述する。スクリプト層２０１のコンテンツ操作部２１２は、画像の操作をスクリプトに反映する。画像の操作とは、例えば、画像の拡大、移動、回転である。コンテンツ描画部２１１による記述には、コンテンツ操作部２１２で操作された内容も反映される。ここで記述されたコンテンツのスクリプトは、後述するＯＳ層２０３のインタプリタ２１８で解釈され、ディスプレイ１０６に表示される。画像処理制御部２１３は、画像処理に用いる補正パラメータ（例えば、輝度の補正値）と、補正対象となる画像を決定する。それらのデータは、必要に応じてスクリプト層２０１のデータ変換部２０８で、ネイティブ層２０２で利用可能なデータ形式に変換されてネイティブ層２０２に渡される。

ネイティブ層２０２の画像処理部２１０は、スクリプト層２０１の画像処理制御部２１３から指定された画像データに対して画像処理（輝度補正等）を実行する。その際、どのような画像処理を実行するかは、画像処理制御部２１３で設定された補正パラメータに従って決定される。画像データの指定については、例えば、スクリプト層２０１から画像データのパスを受け取る方法がある。

ＯＳ層２０３のタッチイベント部２１６は、ディスプレイ１０６へのユーザによるタッチに関する情報を取得する。タッチに関する情報とは、ディスプレイ上のタッチの検知、タッチされた位置情報などである。取得したデータは、ネイティブ層２０２を介してスクリプト層２０１のコンテンツ操作部２１２に送信される。例えば、ユーザがディスプレイ１０６上で所望のスタンプ画像を選択した情報は、タッチイベント部２１６により、ネイティブ層２０２を介してスクリプト層２０１のコンテンツ操作部２１２に送信される。

ＯＳ層２０３のインタプリタ２１８は、スクリプト層２０１で生成されたウェブ標準言語によるスクリプト命令を解釈・実行するブロックであり、画像の描画命令等はインタプリタ２１８により解釈され、ディスプレイ１０６への表示が実行される。また、インタプリタ２１８は、スクリプト層２０１で描画された印刷コンテンツを翻訳し、印刷解像度にレンダリングし、画像データをＲＧＢ画素値で出力する。図２では、インタプリタ２１８は、ＯＳ層２０３に構成されているが、ネイティブ層２０２に構成されても良い。

●プリンタとの通信
スクリプト層２０１のプリンタ制御部２１４は、レンダリング開始依頼、プリンタ検知の依頼、プリンタ設定画面の表示、プリント情報の生成及び送信を制御する。ここでのレンダリングとは、印刷に必要なビットマップデータを作成することをいう。プリンタ設定画面では、用紙のサイズ、用紙の種類、カラー／モノクロ印刷などの設定が可能である。ここで設定された項目に基づいて、ネイティブ層２０２のプリンタデータ生成部２１５は、プリント情報を生成する。

ネイティブ層２０２のプリンタデータ生成部２１５は、スクリプト層２０１のプリンタ制御部２１４からの依頼に基づき、プリンタ通信に必要なデータやコマンドを生成する。プリンタ通信に必要なデータとは、通信プロトコルに則ったデータであり、コマンドとは、印刷やスキャンなど、プリンタの動作を決定するためのデータである。ＯＳ層２０３のプリンタ通信部２１７は、プリンタデータ生成部２１５から受け取ったデータを、接続されているプリンタ１１５に送信するためのインタフェースである。

［全体フロー］
図３は、本実施形態における写真印刷処理の全体の手順を示すフローチャートである。図３の処理は、例えば、ＣＰＵ１０１がＲＯＭ１０２からプログラムをＲＡＭ１０３に読み出して実行することにより実現される。図１０は、本実施形態におけるスクリプトで記述された写真印刷アプリケーション画面の一例を示す図である。

Ｓ３０１において、ＣＰＵ１０１は、ユーザによる写真画像選択ボタン１００１の押下（タッチ操作も含む。以下同様）を検出し、画像の選択を受け付ける。画像の選択を受け付けると、ＣＰＵ１０１は、描画領域１００６の全体に、選択された画像を表示する。

Ｓ３０２において、ＣＰＵ１０１は、ユーザによる、スライドバー１００２を用いた、画像処理時に利用する補正パラメータ（例えば、輝度補正値）を検出する。ＣＰＵ１０１は、検出した補正パラメータに従って、画像に対して画像処理を実行し、描画領域１００６の全体に画像を表示する。

Ｓ３０３において、ＣＰＵ１０１は、ユーザによる、スタンプ追加ボタン１００３の押下を検出すると、スタンプ画像一覧を表示する。そして、ＣＰＵ１０１は、ユーザによる所望のスタンプ画像の選択を受け付け、描画領域１００６上にスタンプ画像を追加・表示する。

Ｓ３０４において、ＣＰＵ１０１は、ユーザによる、プリントボタン１００５の押下を検出すると、プリントに必要な情報の設定ＵＩをディスプレイ１０６に表示する。ここで、プリントに必要な情報とは、例えば、用紙サイズ、両面、モノクロ・カラー印刷などの情報である。図１１に、プリンタの設定ＵＩの一例を示す。

Ｓ３０５において、ＣＰＵ１０１は、ユーザによる、設定完了ボタン１１０２の押下を検出すると、印刷に必要なビットマップデータを作成するレンダリングを開始する。ＣＰＵ１０１は、描画領域１００６に表示されている画像について、プリント解像度での画像データを作成する。

Ｓ３０６において、ＣＰＵ１０１は、Ｓ３０５でプリント解像度で作成された画像データを、プリンタ制御のコマンドと共にプリンタ１１５に送信し、プリンタ１１５から印刷物を出力させる。

上記では、説明上、必要最小限のフローを記載しているが、特に上記の処理の流れに限定されるものではない。以下、各工程での詳細な動作を説明する。

［写真画像選択］
上述のように、ユーザによる写真画像選択ボタン１００１の押下を検出することにより、Ｓ３０１の処理が開始する。図４は、Ｓ３０１の写真画像選択の処理を示すフローチャートである。図４のＳ４０１、Ｓ４０２、Ｓ４０９〜Ｓ４１１は、スクリプト層２０１により実行される処理であり、Ｓ４０３〜Ｓ４０８は、ネイティブ層２０２により実行される処理である。他のフローチャートにおいても同様に示す。

Ｓ４０１において、スクリプト層２０１の画像取得部２０４は、取得対象の画像データを識別するための一意なＩＤを生成する。ＩＤは、数値や文字列など、スクリプト層２０１からネイティブ層２０２へ送信できる形式であればどのような形式でも良い。

Ｓ４０２において、スクリプト層２０１の画像取得部２０４は、ネイティブ層２０１にＩＤを渡すとともに画像選択を依頼する。その依頼の方法として、スクリプト層２０１からネイティブ層２０２固有の画像選択ＡＰＩを直接呼び出すようにしても良い。ここで、ネイティブ層２０２固有の画像選択ＡＰＩを直接呼び出せない場合には、ネイティブ層２０２にラッパーを用意しておいても良い。ラッパーとは、スクリプト層２０１から呼び出せる関数をネイティブ層２０２に予め用意しておき、ネイティブ関数内でネイティブ層２０２固有の関数を呼び出す方法である。また、画像選択ＡＰＩは、ＩＤを例えば引数として渡す仕組みを備えている。そのような構成により、スクリプト層２０１は、ネイティブ層２０２へＩＤを渡すことができる。

Ｓ４０３において、ネイティブ層２０２では、デバイス固有の画像選択ＵＩがディスプレイ１０６に表示されるよう表示制御が行われる。画像読込部２０５は、ユーザによる、表示された画像選択ＵＩ上での画像の選択を受け付ける。画像の選択は、脱着可能な記憶媒体内の画像の選択でも良いし、携帯型情報端末１００のカメラ機能が用いられて撮影された画像データであっても良い。

Ｓ４０４において、ネイティブ層２０２の画像読込部２０５は、選択された画像に対応する画像データを画像群２０６から取得する。画像データの取得は、例えば、画像ファイルのダウンロードやコピーによって行われる。また、ファイルオープンは、ネイティブ層２０２の使用言語に応じたものにより行われる。

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

Ｓ４０６において、ネイティブ層２０２のデータ保持部２０９は、展開されたＲＧＢデータをＳ４０３で受信したＩＤと関連付けて記憶する。関連付けの方法として、例えば、ＩＤとＲＧＢデータを持つオブジェクトを作成することにより、ＩＤによるＲＧＢデータの特定を可能にしても良い。また、ＩＤとＲＧＢデータとの対応付けは、ＩＤとＲＧＢデータと対にすることに限定されるわけではなく、例えば、ＩＤとＲＧＢデータのパスとを関連付ける方法を用いてもよい。その他にも、ＲＧＢデータの先頭アドレスや、ＲＧＢデータを呼び出す関数と関連付ける方法などが用いられても良い。

Ｓ４０７において、Ｓ４０５で取得したＲＧＢデータに基づいて、スクリプト層２０１で対応している形式に変換可能な画像データが生成される。本実施形態においては、例えばＪＰＥＧ形式の画像データが生成される。ＲＧＢデータからＪＰＥＧデータへの変換には、ＯＳが有するエンコーダが用いられる。

Ｓ４０８において、ネイティブ層２０２のデータ変換部２０７は、ＪＰＥＧデータをＢＡＳＥ６４データに変換する。これは、スクリプト層２０１では、ＲＧＢデータ配列やＪＰＥＧのバイナリデータをそのまま利用できず、スクリプト層２０１が利用可能な形式にデータを変換する必要があるためである。本実施形態では、ＪａｖａＳｃｒｉｐｔ（登録商標）が用いられている場合には、スクリプト層２０１で扱う画像データはＢＡＳＥ６４形式であるとする。ＢＡＳＥ６４とは、バイナリデータを文字列データとして扱うためのエンコード方式である。

Ｓ４０９において、スクリプト層２０１のデータ変換部２０８は、ネイティブ層２０２のデータ変換部２０７から、Ｓ４０８で変換されたＢＡＳＥ６４データを受け取る。そして、ＢＡＳＥ６４データを表示するための領域がＲＡＭ１０３に確保される。本実施形態では、メモリの確保のために、例えば、ＨＴＭＬのＣａｎｖａｓ機能が用いられ、画像の描画は、Ｃａｎｖａｓの持つＣｏｎｔｅｘｔオブジェクトのＡＰＩにより行われる。

Ｓ４１０において、スクリプト層２０１の画像処理制御部２１３は、補正パラメータを生成し、その補正パラメータを初期化する。補正パラメータとは、Ｓ３０２の画像処理の内容を決定するパラメータ群を保持するオブジェクトである。ネイティブ層２０２でどのような画像処理が実行されるかは、補正パラメータに応じて決定される。ＪａｖａＳｃｒｉｐｔでは、例えば、下記のような補正パラメータが生成される。
var CorrectionParam = function(){
this.brightness = 10;
}
上記の補正パラメータは、CorrectionParamオブジェクトの中に、明るさ補正用にbrightnessという変数名と、brightnessには１０という値が格納されているということを表している。説明上、補正パラメータは、明るさ補正用のみとして示しているが、その他の補正処理用のパラメータを追加することにより、画像処理の種類を増やすことができる。

Ｓ４１１において、スクリプト層２０１の画像処理制御部２１３は、描画領域１００６での描画するデータにネイティブ層２０２から受け取ったＢＡＳＥ６４データを指定する。これにより、ＯＳ層２０３のインタプリタ２１８がスクリプトを解釈し、描画領域１００６に画像を表示することができる。下記に、描画領域１００６にＢＡＳＥ６４データを反映させるためのコードの一例を示す。
var base64Data = ネイティブからのBASE64データ
var canvas = document.createElement("canvas");//画像の描画領域確保
canvas.setAttribute("width", 100);//描画領域の大きさ設定
canvas.setAttribute("height", 100);
canvas.setAttribute(“id”, “ImageID”);//canvasにIDをつける
var context = canvas.getContext("2d");//描画領域に描画するAPIを持つオブジェクトの生成
var img = new Image();//Imageオブジェクトの生成
img.src = base64Data;//画像のURIを受け取ったBASE64データとする
img.onload = function(){//画像のロードが終わってから処理を開始する
context.drawImage(img, 0, 0, img.width, img.height, 0, 0, canvas.width, canvas.height);//contextオブジェクトのメソッドを用いて画像を描画領域に描画
document.getElementById("div").appendChild(canvas);｝
本実施形態では、Ｃａｎｖａｓが何層にもなるレイヤ構造を用いている。それらのＣａｎｖａｓは、描画／移動／拡大などの操作が特定されると、divで指定される描画領域１００６に対して順次追加されていく。通常、Ｃａｎｖａｓは１枚の画像として扱われるので、Ｃａｎｖａｓに写真画像を描画した後にスタンプ画像などを追加すると、スタンプ画像と合わせて１枚の画像とされる。それに対して、本実施形態では、レイヤ構造を用いてＣａｎｖａｓを重ねて表示するので、ユーザに対して１枚の画像のように表示するが、実際の描画物はそれぞれ独立したものとなっている。例えば、ＨＴＭＬのＤＯＭ（ＤｏｃｕｍｅｎｔＯｂｊｅｃｔＭｏｄｅｌ）のように、divの領域内にＣａｎｖａｓオブジェクトが複数存在する形態である。以下に一例を示す。
＜div width = 100 height = 100＞
＜canvas id=”ImageID” width=100 height=100 style="position:absolute;left:0px; top:0px;"＞＜/canvas＞
＜canvas id=”Stamp” width=10 height=10 style="position:absolute;left:10px; top:10px;"＞＜/canvas＞
…
＜/div＞
１つ目のＣａｎｖａｓは、縦幅１００、横幅１００のdiv領域に対して、縦幅１００、横幅１００で追加されている。つまり、表示領域全体に対してＣａｎｖａｓが重なっているということであり、写真画像は全体表示される。２つ目のＣａｎｖａｓは、縦幅１０、横幅１０の大きさ、div左上の頂点を基準とした時の（１０，１０）の座標に追加されている。それぞれのＣａｎｖａｓは独立しており、また、それぞれに一意なＩＤが指定されている。スクリプトによる操作や、特定のＣａｎｖａｓの情報を取得する際には、対応するＩＤが用いられる。例えば、２つ目のＣａｎｖａｓの縦幅は、以下の操作で取得することができる。
var width = document.getElementById(“Stamp”).width;
［画像処理］
ユーザによるスライドバー１００２の設定を検出することにより、図３のＳ３０２の処理が開始する。図５は、Ｓ３０２の画像処理を示すフローチャートである。

Ｓ５０１において、スクリプト層２０１の画像処理制御部２１３は、Ｓ４１０で生成された補正パラメータの値（例えば、brightness。以下同様とする。）を、スライドバー１００２で設定された値に更新する。

Ｓ５０２において、スクリプト層２０１の画像処理制御部２１３は、インジケータを起動してディスプレイ１０６に表示するよう処理する。ここで、インジケータとは、データ処理中にディスプレイ１０６に表示される、作業状態を表すアイコンである。

Ｓ５０３において、スクリプト層２０１のデータ変換部２０８は、補正パラメータをネイティブで利用可能なＪＳＯＮ文字列に変換する。これは、補正パラメータは上記のようにオブジェクト形式であり、ネイティブ層２０２では解釈することができないからである。変換されたＪＳＯＮ文字列は、Ｓ４０１で生成された画像データを識別するためのＩＤと共にネイティブ層２０２へ渡される。

Ｓ５０４において、ネイティブ層２０２の画像処理部２１０は、文字列として受け取ったＪＳＯＮデータをパース（解析）する。パースには、ＯＳに備えられているパーサーが用いられる。ネイティブ層２０２の画像処理部２１０は、パースにより、補正パラメータ内のbrightnessの値を取得する。

Ｓ５０５において、ネイティブ層２０２の画像処理部２１０は、スクリプト層２０１から送信されたＩＤに基づいて、Ｓ４０５でＲＧＢ展開された画像データ（ＲＧＢデータ）を特定する。前述のように、ＩＤと画像データとの対応付けは、ＩＤと画像データとを対にすることに限定されるわけではなく、例えば、ＩＤと画像データのパスとを関連付ける方法により行われても良い。また、ＩＤと、画像データの先頭アドレスや画像データを呼び出す関数などを関連付ける方法により行われても良い。

Ｓ５０６において、ネイティブ層２０２の画像処理部２１０は、取得した補正パラメータから実行すべき画像処理を決定し、Ｓ５０５で特定された画像データに対して補正パラメータに対応した画像処理を行う。本実施形態では、輝度補正のパラメータにより、全ての画素のＲＧＢ値に１０が加算されるとする。

ここで、補正パラメータに他の情報を追加することにより、画像処理の種類を増やすようにしても良い。例えば、公知のモノクロ変換、公知のセピア色変換、ImageFix、RedeyeFix、SmartSkinなどの画像処理を追加するようにしても良い。ImageFixとは、写真画像を、人物顔検出やシーン解析を用いて自動で解析し、適切な明るさやホワイトバランス調整を行う処理である。また、RedeyeFixとは、画像中から自動で赤目画像を検出して補正する処理である。また、SmartSkinとは、写真画像から人物の顔を検出して、その顔の肌領域を好適に加工する処理である。また、画像処理は、ＯＳ層２０３が提供する機能により実行されても良い。また、取得した補正パラメータから実行可能な複数の画像処理をプルダウンメニュー表示し、ユーザ選択を受け付けるようにしても良い。

Ｓ５０７において、Ｓ５０６で画像処理が実行された画像データに基づいて、スクリプトで対応しているフォーマットに変換可能な画像データが生成される。本実施形態においては、例えばＪＰＥＧの画像データが生成される。

Ｓ５０８において、ネイティブ層２０２の画像処理部２１０は、スクリプト層２０１にインジケータの停止を依頼する。これは、例えば、ネイティブ層２０２から、スクリプト層２０１で定義されているインジケータ停止の関数を呼び出すことで行われる。

Ｓ５０９において、スクリプト層２０１の画像処理制御部２１３は、インジケータを停止させてディスプレイへの表示を停止する。一方、Ｓ５１０において、ネイティブ層２０２のデータ変換部２０７は、ＪＰＥＧデータをＢＡＳＥ６４データに変換し、スクリプト層２０１に送信する。

Ｓ５１１において、スクリプト層２０１のデータ変換部２０８は、ネイティブ層２０２からＳ５０８で変換されたＢＡＳＥ６４データを受け取る。その後、スクリプト層２０１の画像処理制御部２１３は、描画領域１００６での描画するデータにネイティブ層２０２から受け取ったＢＡＳＥ６４データを指定する。これにより、ＯＳ層２０３のインタプリタ２１８がスクリプトを解釈し、描画領域１００６に画像処理が実行された画像が表示される。

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

［スタンプ画像追加］
ユーザによるスタンプ追加ボタン１００３の押下を検出し、ハートスタンプ画像１００８の選択を検出することにより、Ｓ３０３の処理が開始する。図６は、Ｓ３０３のスタンプ画像追加の処理を示すフローチャートである。

Ｓ６０１において、スクリプト層２０１の画像取得部２０４は、スタンプを識別するための一意なＩＤを生成する。ＩＤは、数値や文字列など、スクリプト層２０１からネイティブ層２０２へ送信できる形式であればどのような形式でも良い。

Ｓ６０２において、スクリプト層２０１の画像取得部２０４は、Ｓ６０１で生成されたＩＤと、スタンプ画像として用いられる画像の絶対パスとをネイティブ層２０２に送信し、画像取得を依頼する。

Ｓ６０３において、ネイティブ層２０２の画像読込部２０５は、スクリプト層２０１から受け取った画像の絶対パスに基づいて、デバイス固有のＡＰＩにより画像データを取得する。

Ｓ６０４において、ネイティブ層２０２のデータ保持部２０９は、取得した画像データをＲＧＢ展開して保持する。

Ｓ６０５において、ネイティブ層２０２のデータ保持部２０９は、Ｓ４０６と同様に、ＲＧＢ展開された画像データと、Ｓ６０２で受信したＩＤとを関連付けて記憶する。

Ｓ６０６において、Ｓ６０４で取得したＲＧＢデータに基づいて、スクリプトで対応しているフォーマットに変換可能な画像データが生成される。本実施形態においては、例えばＪＰＥＧの画像データが生成される。ＲＧＢデータからＪＰＥＧデータへの変換には、ＯＳが有するエンコーダが用いられる。

Ｓ６０７において、ネイティブ層２０２のデータ変換部２０７は、ＪＰＥＧデータをＢＡＳＥ６４データに変換し、スクリプト層２０１に送信する。

Ｓ６０８において、スクリプト層２０１のデータ変換部２０８は、ネイティブ層２０２からＳ６０７で変換されたＢＡＳＥ６４データを受け取る。そして、ＢＡＳＥ６４データを表示するための領域がＲＡＭ１０３に確保される。メモリの確保のためには、例えば、ＨＴＭＬのＣａｎｖａｓ機能が用いられる。

Ｓ６０９において、スクリプト層２０１の画像処理制御部２１３は、オブジェクトパラメータを生成し、そのオブジェクトパラメータを初期化する。オブジェクトパラメータとは、描画の際に用いられるパラメータを保持するオブジェクトである。ＪａｖａＳｃｒｉｐｔでは、例えば、下記のようなオブジェクトパラメータが生成される。
var ObjectParam = function(){
this.posX = 10;
this.posY = 10;
this.width = 100;
this.height = 100;
this.ImageData = BASE64Data;
}
このオブジェクトパラメータは、ObjectParamオブジェクトの中に、基準点からのｘ座標を示すposX変数名が含まれ、posXには１０という値が格納されているということを表している。ここで、基準点とは、描画領域１００６の左上の座標１０１０である。同様に、posYは、描画領域１００６の左上を基準点としたときのｙ座標、widthはスタンプ画像の描画領域１００９の横幅、heightは描画領域１００９の縦幅を表している。また、BASE64Dataは、ネイティブ層２０２から受け取った画像データである。

つまり、本実施形態では、オブジェクトパラメータが描画物オブジェクトに対応する。本実施形態では説明上、オブジェクトパラメータとして、描画物のサイズ、位置、画像データを示している。しかしながら、その他のパラメータ（回転角度、平行移動量、拡大倍率など）を追加して、描画、レンダリング、オブジェクト操作時に利用できるようにしても良い。また、描画オブジェクトに対する情報保持の方法も、本実施形態に限定されるものではない。

Ｓ６１０において、スクリプト２０１の画像処理制御部２１３は、描画領域１００６で描画するデータとして、ネイティブ層２０２から受け取ったＢＡＳＥ６４データを指定する。これにより、ＯＳ層２０３のインタプリタ２１８がスクリプトを解釈し、Ｓ６０９で初期化されたオブジェクトパラメータに基づいて、描画領域１００６に画像を表示することができる。

本実施形態では説明上、スタンプ画像が１つのみであるが、スタンプ画像を複数個扱うようにしても良い。また、本実施形態では、スタンプ画像として予め用意した画像データを用いているが、ＣａｎｖａｓのＣｏｎｔｅｘｔオブジェクトを用いて描画物をスクリプトで生成する方法を用いても良い。その場合には、Ｓ６０２において、Ｃｏｎｔｅｘｔオブジェクトを用いて生成された描画物がネイティブ層２０２に送信され、データ保持部２０９は、その描画物をＲＧＢデータとして保持する。

［プリンタ設定］
ユーザによるプリントボタン１００５の押下を検出することにより、Ｓ３０４の処理が開始する。図７は、Ｓ３０４のプリンタ設定の処理を示すフローチャートである。

Ｓ７０１において、スクリプト層２０１のプリンタ制御部２１４は、ネイティブ層２０２にプリンタ情報の取得を依頼する。依頼の方法として、例えば、バインディング機能によりスクリプト層２０１からネイティブ層２０２固有のＡＰＩを呼び出す。その場合、ネイティブ層２０２には、スクリプト層２０１から直接呼び出せる関数、もしくはその関数を間接的に呼び出すいわゆるラッパーを予め用意しておく。例えば、GetPrinterInfoというネイティブ関数を用意しておき、スクリプト層２０１からその関数を呼び出す。

一般的に、機密情報の保証が難しい等のセキュリティ上の制限のために、スクリプト層２０１から外部の機器と直接通信することはできない。そのため、本実施形態では、スクリプト層２０１は、一旦、ネイティブ層２０２へ依頼することにより、ネイティブ層２０２を介して外部の機器と通信を行う。

Ｓ７０２において、ネイティブ層２０２のプリンタデータ生成部２１５は、対応する関数が呼び出されると、プリンタ１１５の検出、いわゆるディスカバリを行う。ここでは、通信可能なプリンタ１１５の検出を行うために、Ｂｏｎｊｏｕｒなどのプロトコルが用いられる。プリンタ１１５の検出は、例えば、同じ無線ＬＡＮルータで接続されているプリンタにおいて行われる。

Ｓ７０３において、ネイティブ層２０２のプリンタデータ生成部２１５は、ブロードキャストやマルチキャスト等の方法で応答のあったプリンタ１１５のＩＰアドレスを記憶する。

Ｓ７０４において、ネイティブ層２０２のプリンタデータ生成部２１５は、Ｓ７０３で応答のあったプリンタ１１５のＩＰアドレスへプリンタ情報の提供を要求するためのコマンドを生成する。応答のあったプリンタが複数の場合には、プリンタデータ生成部２１５は、全てのプリンタに対して情報の提供を要求する。コマンドとは、プリンタの動作を指定する命令であり、例えば、ＸＭＬ（ＥｘｔｅｎｄａｂｌｅＭａｒｋｕｐＬａｎｇｕａｇｅ）により下記のように記述される。
----------------------------------------------
01: ＜?xml version="1.0" encoding="utf-8" ?＞
02: ＜cmd xmlns:trans="http://www.xxxx/yyyyy/"＞
03: ＜contents＞
04: ＜operation＞GetPrinterInfo＜/operation＞
05: ＜/contents＞
06: ＜/cmd＞
----------------------------------------------
上記各行の左側に書かれている「01：」などの数値は説明を行うために付加した行番号であり、本来のＸＭＬ形式のテキストには記述されない。

１行目はヘッダであり、ＸＭＬ形式で記述していることを表している。

２行目のcmdは、コマンドの開始を意味する。xmlnsで名前空間を指定し、コマンドの解釈の定義を指定している。なお、６行目の＜／cmd＞は、コマンドの終了を示している。

３行目は以降に内容を記述する宣言であり、５行目はその終了を示している。

４行目には要求する命令が記述されており、＜operation＞と＜／operation＞の間に実際の命令文言が存在する。命令文言であるGetPrinterInfoは、外部デバイスであるプリンタ１１５の情報を取得する命令である。例えば、プリンタ１１５が対応している用紙種類、サイズ、縁なし印刷機能の有無、印刷品位、などのプリンタ情報を提供するよう要求する内容が記述されている。

なお、上記のコマンド生成は、予めＲＯＭ１０２などに記憶した固定のテキストを読み込むようにしても良い。また、コマンドは、ＸＭＬなどのテキスト形式に限らず、バイナリ形式で記述され、それに従ったプロトコルで通信されるようにしても良い。生成されたコマンドは、送信先のプリンタが対応しているプロトコルに従った形式で、ＯＳ層２０３のプリンタ通信部２１７を介してプリンタ１１５へ送信される。プリンタ１１５との通信の方法は、上記に限られず、例えば、Ｗｉ−ＦｉダイレクトやＢｌｕｅｔｏｏｔｈ、赤外線通信、電話回線、有線ＬＡＮ、ＵＳＢを用いた接続でも良い。

上記では、ネイティブ層２０２でコマンドの生成が行われると説明したが、スクリプト層２０１でコマンドの生成が行われるようにしても良い。その場合、スクリプト層２０１で上記のＸＭＬ形式の命令文が作成されてネイティブ層２０２へ渡される。その後、上記と同様に、通信プロトコルに従った形式でプリンタ１１５のＩＰアドレスへ送信される。

上記のコマンドを受信したプリンタ１１５は、プリンタ情報を通信プロトコルに従ってＸＭＬ形式でネイティブ層２０２へ送信する。以下、プリンタ情報の一例を示す。
----------------------------------------------
01: ＜?xml version="1.0" encoding="utf-8" ?＞
02: ＜cmd xmlns:trans="http://www.xxxx/yyyyy/"＞
03: ＜contents＞
04: ＜device id=”Printer001” /＞
05: ＜mode = 1＞
06: ＜media＞GlossyPaper＜/media＞
07: ＜size＞A4＜/size＞
08: ＜quality＞1＜/quality＞
09: ＜border＞no＜/border＞
10: ＜/mode＞
11: ＜mode = 2＞
〜中略〜
＜/mode＞
＜mode = 3＞
〜中略〜
＜/mode＞
〜中略〜
＜/contents＞
＜/cmd＞
----------------------------------------------
１行目はヘッダであり、ＸＭＬ形式で記述していることを表している。

２行目のcmdは、コマンドの開始を意味する。xmlnsで名前空間を指定し、コマンドの解釈の定義を指定している。なお、最下行の＜／cmd＞はコマンドの終了を示している。

３行目は以降に内容を記述する宣言であり、下の＜／contents＞までその内容が続く。

４行目はデバイスIDを示し、そのプリンタの機種名が「Printer001」であることを表している。

５行目以降は、各モードについて記述されている。＜mode＞から＜／mode＞まで、対応するモードの情報が記述されている。５行目では、モードの番号は１である。以降の＜media＞は印刷用紙の種類、＜size＞は用紙サイズ、＜quality＞は印刷品位、＜border＞は縁あり／なしの情報がそれぞれ記述されている。

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

Ｓ７０５において、ネイティブ層２０２のプリンタデータ生成部２１５は、ＯＳ層２０３のプリンタ通信部２１７を介してプリンタ１１５からプリンタ情報を受け取る。そして、プリンタデータ生成部２１５は、受け取ったプリンタ情報から、全てのモードにおける印刷用紙の種類、サイズ、印刷品位、縁あり／なしの項目と項目数を取得する。

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

Ｓ７０７において、スクリプト層２０１は、受け取ったプリンタ情報に基づいて、表示画面を形成してディスプレイ１６０に表示するよう処理する。ここで、接続可能なプリンタが複数ある場合には、スクリプト層２０１は、複数のプリンタ名をユーザに選択可能に表示するよう処理する。なお、プリンタの選択は、上記に限られず、例えば、一番早く応答してきたプリンタや、より機能が多いプリンタ、印刷ジョブが混んでいないプリンタ、などに基づいて選択されるようにしても良い。

Ｓ７０８において、スクリプト層２０１は、印刷用紙の種類・サイズ、印刷品位、縁あり／なし、などを選択させる印刷設定画面をディスプレイ１６０に表示するよう処理する。印刷設定画面の形成方法の一例として、以下に、ＨＴＭＬ／ＪａｖａＳｃｒｉｐｔの記述を示す。
------------------------------------------------
＜!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(GetPaperSize(i), GetPaperSize(i));
}
＜!-- 用紙種類--＞
var MediaTypeNum = GetMediaTypeNum();
var m = document.getElementById("MediaList");
var j;
for(j=0; j＜MediaTypeNum; j++){
m.options[i] = new Option(GetMediaType(j),GetMediaType(j));
}
＜!-- 印刷品位 --＞
var QualityNum = GetQualityNum();
var q = document.getElementById("QualityList");
var k
for(k=0; k＜ QualityNum; k++){
q.options[i] = new Option(GetQuality(k), GetQuality(k));
}
＜!-- 縁あり/なし--＞
var BorderNum = GetBorderNum();
var b = document.getElementById("BorderList");
var l;
for(l=0; l＜BorderNum; l++){
b.options[i] = new Option(GetBorder(l),GetBorder(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＞
------------------------------------------------
上記のGetPaperSizeNum（）、GetMediaTypeNum（）、GetQualityNum（）、GetBorderNum（）はネイティブ関数であり、それぞれの項目がいくつあるかを取得する機能を備える。例えば、プリンタが対応している用紙サイズがＡ４、Ａ５、Ｂ５、Ｌ判の４種類の場合、GetPaperSizeNum（）は４を返す。

GetPaperSize（n）、GetMediaType（n）、GetQuality（n）、GetBorder（n）もネイティブ関数であり、引数ｎの値番目の文字列を返す。例えば、用紙サイズを返す関数のGetPaperSize（0）の返り値は「Ａ４」であり、GetPaperSize（1）の返り値は「Ａ５」である。これらの値は、ネイティブ層２０２が、プリンタ１１５からＯＳ層２０３を介して送られてきた情報から取得する。また、これらの文言は、プリンタ１１５から送られてきた情報と結び付けてネイティブ層２０２が決定する。例えば、プリンタ１１５から送られてきた情報より取り出した値が「GlossyPaper」であった場合、表示するテキストは「光沢紙」と決定する。決定の方法として、ネイティブ層２０２は、これらの対応表を予め保持しておき、その対応表に従ってテキストを決定すれば良い。

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

上記の例のように取得した情報に基づきＷｅｂレンダリングエンジンを用いて、例えば、図１１に示す印刷設定画面１１０１のようなユーザインタフェースが実現される。つまり、本実施形態では、スクリプト層２０１は、ネイティブ層２０２を介して外部のプリンタ１１５にプリンタ情報を要求し、ネイティブ関数を用いて取得した情報に基づいて印刷設定画面をディスプレイ１０６に表示する。なお、上記ＨＴＭＬは、スクリプト層２０１とネイティブ層２０２のいずれで作成するようにしても良い。図１１に示すように、用紙サイズなどはプルダウンメニューになっており、ユーザの項目を選択するタッチ操作を受け付けることができる。

設定完了ボタン１１０２の押下を検出すると、Ｓ７０９において、スクリプト層２０１のプリンタ制御部２１４は、Ｓ７０８でユーザが選択した各プリント情報を、ネイティブ層２０２へ送信する。上記ＨＴＭＬの例にあるSetPrint（）は、取得したプリンタ設定情報を引数としてネイティブ関数を呼び出している。上記の例では用紙サイズ、用紙種類、印刷品位、縁あり／なしの各設定を文字列としてネイティブ層２０２へ渡している。

Ｓ７１０において、ネイティブ層２０２のプリンタデータ生成部２１５は、スクリプト層２０１から送信されたプリント情報を取得する。プリンタデータ生成部２１５は、取得したプリント情報に基づいて、プリンタの通信プロトコルに従って印刷コマンドを生成し、ＯＳ層２０３のプリンタ通信部２１７を介してプリンタ１１５へ送信する。

［レンダリング］
ユーザによる印刷設定画面１１０１の設定完了ボタン１１０２の押下を検出することにより、Ｓ３０５の処理が開始する。図８は、Ｓ３０５のレンダリング処理を示すフローチャートである。

Ｓ８０１において、スクリプト層２０１のプリンタ制御部２１４は、インジケータの起動をＯＳ層２０３に依頼する。Ｓ８０２において、ＯＳ層２０３は、インジケータをディスプレイ１０６に表示する。

Ｓ８０３において、スクリプト層２０１のプリンタ制御部２１４は、Ｓ７０９で設定されたプリント情報に基づいて、印刷する用紙サイズに対応する出力サイズを決定し、その出力サイズをＯＳ層２０３に渡す。

Ｓ８０４において、ＯＳ層２０３は、受け取った出力サイズに対応する出力画像領域をＲＡＭ１０３に確保する。ここで、出力画像領域とは、１つのＣａｎｖａｓ領域である。この出力サイズのＣａｎｖａｓに対して、先述の各Ｃａｎｖａｓ（写真画像、追加されるスタンプ画像等）を、サイズ・領域内の位置がディスプレイ１０６への表示画像と印刷画像とで相対的に合うように合成していく。

Ｓ８０５において、スクリプト層２０１のプリンタ制御部２１４は、ＯＳ層２０３に対して写真画像の描画を依頼する。その際、プリンタ制御部２１４は、写真画像がＳ８０４で確保された出力画像領域全体に描画されるように依頼する。画像の描画は、Ｃａｎｖａｓであれば、ＣｏｎｔｅｘｔオブジェクトのdrawImageメソッドを用いて行われる。また、写真画像データは、オブジェクトパラメータのImageDataで表される。

Ｓ８０６において、ＯＳ層２０３のインタプリタ２１８は、描画依頼されたスクリプトを解釈し、写真画像のレンダリングを行う。Ｓ８０７において、ＯＳ層２０３は、Ｓ８０４で確保された出力画像領域に対して、レンダリング後の画像データを格納する。ここで、図８のＳ８０７の「出力画像領域に反映」とは、上記のようにＳ８０４で確保された出力画像領域（メモリ）に変更を加えることであり、ディスプレイ１０６上に画像を表示することではない。

Ｓ８０８において、スクリプト層２０１の画像処理制御部２１３は、スタンプ画像について、オブジェクトパラメータによるレンダリング条件の変更をスクリプトで記述する。レンダリング条件の変更とは、例えば、描画領域１００６をＡ４サイズ等の印刷領域に変倍する際のスタンプ画像の拡大倍率や平行移動量の変更である。

まず、スクリプトは、スタンプ画像の拡大倍率を求める。ここで、スタンプ画像の横の拡大倍率（scaleX）、縦の拡大倍率（scaleY）はそれぞれ式（１）及び（２）から算出される。

scaleX＝出力画像の横サイズ／描画領域１００６の横サイズ・・・（１）
scaleY＝出力画像の縦サイズ／描画領域１００６の縦サイズ・・・（２）
これは、描画領域１００６を拡大する際にはスタンプ画像も拡大しないと、ユーザに対する表示画像と印刷画像とで、スタンプ画像の相対的なサイズや描画位置が異なってしまうからである。ここで求めた拡大倍率によるスタンプ画像の拡大は、例えばＣａｎｖａｓであればＣｏｎｔｅｘｔオブジェクトのscaleメソッドを用いて行われる。

次に、拡大後のスタンプ画像の位置を求める。スタンプ画像の位置も先述のサイズと同様、印刷画像内でスタンプ画像の相対位置が、ユーザがディスプレイ１０６上で見る表示画像とずれないように、位置を変更する必要がある。再配置後のスタンプ画像の位置は、現在の位置に拡大倍率を乗算したものであり、再配置後のｘ座標（posX’）、ｙ座標（posY’）はそれぞれ式（３）及び（４）から算出される。

posX’＝poxX×scaleX ・・・（３）
posY’＝posY×scaleY ・・・（４）
再配置後の位置へのコンテンツの平行移動は、例えばＣａｎｖａｓであればＣｏｎｔｅｘｔオブジェクトのtranslateメソッドを用いて行われる。

本実施形態では、Ｓ８０８で、上記のようなＣａｎｖａｓ機能により拡大倍率と平行移動量とが算出され、表示用の描画情報からＯＳ層２０３でのレンダリングに必要なレンダリング情報（レンダリング条件）が設定される。

Ｓ８０９において、スクリプト層２０１の画像処理部２１３は、Ｓ８０８で設定されたレンダリング条件とともに、スタンプ画像の描画をＯＳ層２０３に依頼する。

Ｓ８１０において、ＯＳ層２０３は、Ｓ８０８で設定されたレンダリング条件に従って、スタンプ画像のレンダリングを行う。つまり、本実施形態では、スタンプ画像の平行移動やリサイズは、ＯＳ層２０３で実行される。

Ｓ８１１において、ＯＳ層２０３は、Ｓ８０４で確保された出力画像領域に対して、レンダリング後のスタンプ画像データを格納する。ここで、図８のＳ８１１の「出力画像領域に反映」とは、Ｓ８０７と同様、Ｓ８０４で確保された出力画像領域（メモリ）に変更を加えることであり、ディスプレイ１０６上に画像を表示することではない。

Ｓ８１２において、スクリプト層２０１の画像処理部２１３は、ネイティブ層２０２に対して印刷用の画像データの取得を依頼する。

Ｓ８１３において、ＯＳ層２０３は、出力画像領域の画像データを、ＢＡＳＥ６４のデータ形式に変換してスクリプト層２０１に送信する。

Ｓ８１４において、スクリプト層２０１のプリンタ制御部２１４は、ネイティブ層２０２に対してＢＡＳＥ６４データを送信し、印刷を依頼する。

Ｓ８１５において、ネイティブ層２０２のプリンタデータ生成部２１５は、スクリプト層２０１から送信されたＢＡＳＥ６４データをデコードする。Ｓ８１６において、ネイティブ層２０２のプリンタデータ生成部２１５は、デコードされたデータからＲＧＢデータに変換し、Ｓ８１７において、ＯＳ層２０３に対してインジケータの停止を依頼する。Ｓ８１８において、ＯＳ層２０３は、インジケータを停止させてディスプレイへの表示を停止する。

［プリント］
Ｓ８１８の処理が終了すると、Ｓ３０６の処理が開始する。図９は、Ｓ３０６のプリント処理を示すフローチャートである。

Ｓ９０１において、ネイティブ層２０２のプリンタデータ生成部２１５は、Ｓ７１０で取得されたプリント情報に基づいて、Ｓ８１６で変換されたＲＧＢデータをプリンタ１１５が処理可能なデータ形式に変換する。プリンタ１１５が処理可能なデータ形式には標準的なフォーマット（ＪＰＥＧ等）もあれば、各社独自のフォーマットの場合もある。ここではそれらのうち、どのようなデータ形式であっても良い。

Ｓ９０２において、ネイティブ層２０２のプリンタデータ生成部２１５は、プリント情報と、Ｓ９０１で生成されたＲＧＢデータとに基づいて、プリンタ１１５へ送信するコマンドを生成する。

Ｓ９０３において、ネイティブ層２０２のプリンタデータ生成部２１５は、プリンタ１１５が対応可能な通信プロトコルに従って、Ｓ９０２で生成されたコマンドをＯＳ層２０３のプリンタ通信部２１７を介して送信する。その際、Ｓ７０３で記憶されたＩＰアドレスを送信宛先とする。

Ｓ９０４において、プリンタ１１５において、印刷が開始されて印刷物が出力される。

以上のように、本実施形態によれば、印刷を行う際には、ディスプレイ１０６上の表示画像から印刷用のデータ（印刷解像度に従ったデータ）を生成するのではなく、表示に使われている元の画像データの情報から印刷用のデータが生成される。例えば、表示画像では、写真画像にスタンプ画像が合成されている場合には、ＯＳ層２０３は、写真画像データとスタンプ画像データそれぞれの情報から、両データが合成された印刷用のデータを生成する。つまり、描画領域１００６から印刷画像への拡大処理等は、ＯＳ層２０３において写真画像データとスタンプ画像データについて別々に行われた上で合成される。その結果、表示用の画像データから印刷用の画像データを生成する際の解像度変換や拡大処理により、画像がぼやけてしまうことを低減し、画質劣化の少ないレンダリングが可能となる。

［第２の実施形態］
本実施形態では、追加したスタンプ画像をスクリプトで操作する方法について記述する。以下、第１の実施形態と異なる点について説明する。

［ユーザ操作フロー］
図１２は、本実施形態における写真印刷処理の全体の手順を示すフローチャートである。本実施形態では、Ｓ１２０３のスタンプ画像追加の処理後に、Ｓ１２０４のスタンプ画像の特定と、Ｓ１２０５のスタンプ画像の操作が行わる点で、図３と異なる。図１２のＳ１２０１〜Ｓ１２０３は図３のＳ３０１〜Ｓ３０３に対応し、図１２のＳ１２０６〜Ｓ１２０８は図３のＳ３０４〜Ｓ３０６に対応する。

［スタンプ画像の特定］
Ｓ１２０３でスタンプ画像が追加された後、ユーザによるディスプレイ１０６上をタップ操作を検出することにより、Ｓ１２０４のスタンプ画像の特定処理が開始する。ここで、タップ操作とは、ユーザがディスプレイ１０６上を指で押すタッチ操作のことをいう。これは、ＰＣで言うところの「クリック」に相当する。

図１３は、スタンプ画像の特定の処理を示すフローチャートである。

Ｓ１３０１において、ネイティブ層２０２の画像処理部２１０は、ＯＳ層２０３のタッチイベント部２１６を介してタップされた座標を取得し、スクリプト層２０１に送信する。

Ｓ１３０２において、スクリプト層２０１のコンテンツ操作部２１２は、ネイティブ層２０２から送られてきた座標と、Ｓ６０９で生成されたオブジェクトパラメータの情報とから、スタンプ画像がタッチされたかを判定する。ここで、スタンプ画像のオブジェクトパラメータは初期値のままであるので、スタンプ画像は、左上の頂点座標を（１０，１０)、右下の頂点座標を（１１０，１１０）とする正方形の領域に描画されていることとなる。つまり、Ｓ１３０１で送られてきたｘ座標及びｙ座標が、その正方形の領域の範囲内であれば、スタンプ画像はタッチされたと判定する。例えば、Ｓ１３０１で送信されたｘ座標から、描画領域１００６のｘ座標分を差し引いた値が０〜１００の範囲、かつ、送信されたｙ座標から、描画領域１００６のｙ座標分を差し引いた値が０〜１００の範囲であれば、タッチされたと判定する。スタンプ画像が複数個ある場合には、より上層に表示されているスタンプ画像から順番に判定を行っていき、スタンプ画像の特定がなされた時点で判定処理を終了する。スタンプ画像がタッチされたと判定された場合、スタンプ画像は、スタンプ画像の操作を受け付ける状態となる。

Ｓ１３０３において、スクリプト層２０１のコンテンツ操作部２１２は、スタンプ画像を操作受付状態にする。ここで、操作受付状態とは、スタンプ画像の操作（スワイプ等）に関する指示がされた場合、スタンプ画像がその指示で動作可能な（スワイプ可能な）状態のことをいう。操作受付状態のスタンプ画像が存在しない場合には、スタンプ画像操作に関する指示がされても何も起こらない。また、操作受付状態とされたスタンプ画像のＩＤは、注目スタンプ画像ＩＤとして、一時的にスクリプト層２０１で記憶しておく。そのことにより、スクリプト層２０１は、ネイティブ層２０２で記憶されているスタンプ画像を一意に特定することができる。

［スタンプ画像の操作］
Ｓ１３０２でスタンプ画像が操作受付状態になると、Ｓ１２０５のスタンプ画像の操作が開始する。図１４は、Ｓ１２０５のスタンプ画像の操作処理を示すフローチャートである。

Ｓ１４０１において、スクリプト層２０１のコンテンツ操作部２１２は、スタンプ画像がスワイプされたか否かを、ＯＳ層２０３のタッチイベント部２１６からネイティブ層２０２を介して取得した情報に基づいて判定する。ここで、スワイプされたと判定された場合にはＳ１４０２へ進み、スワイプされていないと判定された場合にはＳ１４０４へ進む。スワイプとは、ユーザがディスプレイ１０６をタップしたのち、指を画面から離さない状態で移動させる操作のことである。これは、ＰＣで言うところの「ドラッグ」に相当する。

Ｓ１４０２において、スクリプト層２０１のコンテンツ操作部２１２は、スタンプ画像のオブジェクトパラメータのposXとposYの値を、タッチイベント部２１６からネイティブ層２０２を介して取得したｘ座標、ｙ座標に更新する。

Ｓ１４０３において、スクリプト層２０１の画像処理制御部２１３は、更新されたposX、posYの値に基づいて、描画領域１００６内のスタンプ画像１００９をＤＯＭ操作により座標位置（poxX、posY）へ移動させる。例えば、取得した情報からスタンプの座標位置を変更する場合には、以下のようなスクリプトを作成する。
update(x, y){ //座標位置を更新する
//x：描画領域の基準点(図10、1010)からのx座標
//y：描画領域の基準点からのy座標
var stamp = 操作受付状態のスタンプ（スタンプであるCanvasの実体）
var id = stamp.getAttribute(“id”); //スタンプのidを取得
var ObjectParam = ObjectParamArray[id];
//idから、操作受付状態のスタンプのオブジェクトパラメータを取得
ObjectParam.posX = x; //スタンプのObjectParamを更新
ObjectParam.posY = y;
}
reflection(stamp){ //更新した座標位置によってスタンプを操作
//stampは操作受付状態のスタンプ(Canvasの実体)
var id = stamp.getAttribute(“id”); //スタンプのidを取得
var ObjectParam = ObjectParamArray[id];
//idから、操作受付状態スタンプのオブジェクトパラメータを取得
stamp.style.position = “absolute”;
stamp.style.left = ObjectParam.posX + “px”; //スタンプをpoxXへ移動
stamp.style.top = ObjectParam.posY + “px”; //スタンプをpoxYへ移動
}
まず、update関数で、操作受付状態のスタンプ画像に関するObjectParamを特定し、位置に関する情報が更新される。上記では、ObjectParamArrayに、それぞれのスタンプ画像（Ｃａｎｖａｓ）に対するObjectParamが配列として存在しており、スタンプ画像のＩＤを添え字とすることで、一意なObjectParamを特定している。スタンプ画像からObjectParamを特定する方法は他に、スタンプ画像に対応するCanvasとObjectParamとを両方含むオブジェクトを作成しておく方法や、ObjectParamにCanvasの実体を包含するなどの方法でも良い。

次に、reflection関数は、ObjectParamの情報を基にＤＯＭ操作を行い、表示されているスタンプ画像の位置を変更する。stamp.style.leftは、スタンプ画像の左上を原点としたときのｘ座標であり、ＪａｖａＳｃｒｉｐｔによりこの値を操作することで、スタンプ画像（Ｃａｎｖａｓ）の属性情報が変更され、表示されているスタンプ画像の位置が変更される。そのため、stamp.style.leftにObjectParam.posXを代入することで、update関数で更新されたｘ座標の情報をＤＯＭに反映させることができる。ここで、stamp.style.leftのstampはスタンプ画像（Ｃａｎｖａｓ）であり、styleは、ＪａｖａＳｃｒｉｐtでスタンプ画像のＣＳＳ情報を追加（変更）するということを示している。また、leftは、そのＣＳＳ情報に設定されるｘ座標である。ＣＳＳは、ＤＯＭ要素のスタイルを変更できる言語であり、ＨＴＭＬとＣＳＳを組み合わせて利用することで、ＨＴＭＬの表示を変更することが可能である。ＣＳＳは、Ｗｅｂページ作成などのＨＴＭＬを利用する場面では広く利用されており、先述の位置の変更だけではなく、他にも文字のサイズ・フォント、背景色の変更など様々な操作が可能である。前述の例では、ＪａｖａＳｃｉｒｐｔによるＣＳＳの変更を行っている。

同様に、stamp.style.topはスタンプ画像のｙ座標のことであり、ObjectParam.posYを代入することで、スタンプ画像のｙ座標が変更され、表示されているスタンプ画像の位置が変更される。

上記のスクリプト記述は、説明上、位置に関する記述のみであるが、コンテンツの大きさに関する情報など、reflection関数で操作できる内容は、上記に限定されるものではない。

スタンプ画像の操作後、Ｓ１４０１において、スクリプト層２０１のコンテンツ操作部２１２は、ユーザによる画面のタッチが維持されているか否かを、タッチイベント２１６からネイティブ層２０２を介して取得した情報に基づいて判定する。ここで、タッチが維持されていない（タッチが解除されている）と判定された場合には、図１４の本処理を終了する。一方、タッチが維持されている場合には、Ｓ１４０１からの処理を繰り返す。

本実施形態では、スワイプによるＣａｎｖａｓの移動のみを説明したが、本実施形態はこれに限定されるものではない。例えば、ピンチアウトによるスタンプ画像の拡大、ロングタップ（長押し）とスワイプとを組み合わせてＣａｎｖａｓ内で描画物を平行移動させるなど、タッチイベントとコンテンツ操作とが組み合わされた動作においても適用される。ここで、ピンチアウトとは、ユーザが二本の指で画面にタッチした後、二本の指の間隔を開ける操作である。一般的な携帯型情報端末では、画像・画面の拡大などに利用される。

また、先述の平行移動とは、描画領域１００６内をＣａｎａｖｓが移動するのとは異なり、スタンプ画像１００９のＣａｎｖａｓ内で描画されているコンテンツが移動することを意味している。例えば、図１０のスタンプ画像１００９内のハートをwidth/2だけ平行移動したとすると、スタンプ画像１００９の左半分の領域には何も表示されず、スタンプ画像１００９の右半分には、ハートの左半分が映っているような状態になる。

本実施形態では、コンテンツの描画方法にレイヤ構造を用いた。また、レイヤ構造の中で描画される各コンテンツは、各々の描画元データや描画されている位置・サイズを保持している。これらの情報はスクリプトによる変更が可能であり、その情報を用いて表示系へ反映させることもできる。これを利用することで、１枚の表示画像として、独立したコンテンツ同士を適切な位置・サイズへ描画することが可能となる。また、印刷のためのレンダリングには、表示に使用される元の画像データを用いるため、画質劣化の少ないレンダリングが実現できる。

［その他の実施形態］
上記の各実施形態では、携帯型情報端末１００上で、ハイブリッド型アプリケーションを動作させる構成について説明した。しかしながら、本実施形態はこれに限定されるものではない。例えば、ハイブリッド型アプリケーションが動作する環境は、スマートフォンやタブレットＰＣを始めとする携帯型情報端末１００の他に、ＰＣやサーバ、ゲーム機などであっても良い。

上記の各実施形態では、デバイス内の画像フォルダから画像が選択されているが、これに限定されるものではない。他に、画像データの絶対パスを指定する、画像データが格納されているフォルダを指定する、デバイスのカメラ機能により撮影された画像データを用いるなどの構成であっても良い。また、画像データの取得先についても、インターネット上の画像データを選択する、脱着可能な記憶媒体内の画像データを選択する、外部のデバイスとの通信により画像データを取得する、などであっても良い。外部のデバイスとしては、例えば、ＰＣ、携帯型情報端末、カメラである。

また、上記の各実施形態でのプリンタ１１５は、例えば、インクジェットプリンタ、レーザープリンタ、昇華型プリンタ、ドットインパクトプリンタである。また、プリンタ１１５は、スキャナ機能やＦＡＸ機能等を一体的に備えたいわゆる複合機（ＭＦＰ）であっても良い。

本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

１００携帯情報端末：１０１ＣＰＵ：１０２ＲＯＭ：１０３ＲＡＭ

Claims

プロセッサと、
アプリケーションの実行の際に前記プロセッサで実行可能なように翻訳され当該プロセッサにより実行されるスクリプト命令セットで構成された第１の層と、前記プロセッサで実行可能なように予め翻訳されている命令セットで構成された第２の層と、を有する階層構造を成し、前記第１の層と前記第２の層との連携により前記アプリケーションを実行するためのプログラムを記憶する記憶手段と、
前記アプリケーションの機能により表示された画像を印刷する場合、前記第１の層において、当該画像のオブジェクトの描画位置及びサイズを含む描画情報から、当該オブジェクトをレンダリングするためのレンダリング情報を決定する決定手段と、
前記第２の層において、前記決定手段により決定された前記レンダリング情報に従って、前記オブジェクトをレンダリングするレンダリング手段と、
を備えることを特徴とする情報処理装置。
前記第１の層において、前記オブジェクトの描画情報を変更する変更手段をさらに備え、
前記決定手段は、前記変更手段により変更された描画情報から、前記レンダリング情報を決定することを特徴とする請求項１に記載の情報処理装置。
前記画像のオブジェクトが複数のオブジェクトを含む場合、
前記決定手段は、前記複数のオブジェクトそれぞれについて、前記レンダリング情報を決定することを特徴とする請求項１又は２に記載の情報処理装置。
前記レンダリング手段は、前記複数のオブジェクトそれぞれについて、前記レンダリングを行うことを特徴とする請求項３に記載の情報処理装置。
前記レンダリング手段は、印刷解像度に基づいてビットマップデータを生成することを特徴とする請求項３又は４に記載の情報処理装置。
前記レンダリング手段は、さらに、前記複数のオブジェクトそれぞれについて生成されたビットマップデータを合成することを特徴とする請求項５に記載の情報処理装置。
前記第１の層は、ＨＴＭＬ５、ＪａｖａＳｃｒｉｐｔの少なくともいずれかにより記述されていることを特徴とする請求項１乃至６のいずれか１項に記載の情報処理装置。
前記画像のオブジェクトは、前記第１の層がＪａｖａＳｃｒｉｐｔで記述されている場合、Ｃａｎｖａｓを用いて描画されることを特徴とする請求項７に記載の情報処理装置。
プロセッサと、
アプリケーションの実行の際に前記プロセッサで実行可能なように翻訳され当該プロセッサにより実行されるスクリプト命令セットで構成された第１の層と、前記プロセッサで実行可能なように予め翻訳されている命令セットで構成された第２の層と、を有する階層構造を成し、前記第１の層と前記第２の層との連携により前記アプリケーションを実行するためのプログラムを記憶する記憶手段とを有する情報処理装置において実行される情報処理方法であって、
前記アプリケーションの機能により表示された画像を印刷する場合、前記第１の層において、当該画像のオブジェクトの描画位置及びサイズを含む描画情報から、当該オブジェクトをレンダリングするためのレンダリング情報を決定する決定工程と、
前記第２の層において、前記決定工程において決定された前記レンダリング情報に従って、前記オブジェクトをレンダリングするレンダリング工程と、
を有することを特徴とする情報処理方法。
アプリケーションの実行の際にプロセッサが実行可能なように翻訳され当該プロセッサにより実行されるスクリプト命令セットで構成された第１の層と、前記プロセッサで実行可能なように予め翻訳されている命令セットで構成された第２の層と、を有する階層構造を成し、前記第１の層と前記第２の層との連携により前記アプリケーションを実行するためのプログラムであって、
前記アプリケーションの機能により表示された画像を印刷する場合、前記第１の層において、当該画像のオブジェクトの描画位置及びサイズを含む描画情報から、当該オブジェクトをレンダリングするためのレンダリング情報を決定し、
前記第２の層において、当該決定された前記レンダリング情報に従って、前記オブジェクトをレンダリングする、
ようにコンピュータを機能させるためのプログラム。
前記第１の層において、前記オブジェクトの描画情報を変更するようにコンピュータをさらに機能させ、
当該変更された描画情報から、前記レンダリング情報を決定することを特徴とする請求項１０に記載のプログラム。
前記画像のオブジェクトが複数のオブジェクトを含む場合、
前記複数のオブジェクトそれぞれについて、前記レンダリング情報を決定することを特徴とする請求項１０又は１１に記載のプログラム。
前記複数のオブジェクトそれぞれについて、前記レンダリングが行われることを特徴とする請求項１２に記載のプログラム。
前記レンダリングでは、印刷解像度に基づいてビットマップデータが生成されることを特徴とする請求項１２又は１３に記載のプログラム。
前記レンダリングでは、さらに、前記複数のオブジェクトそれぞれについて生成されたビットマップデータが合成されることを特徴とする請求項１４に記載のプログラム。
前記第１の層は、ＨＴＭＬ５、ＪａｖａＳｃｒｉｐｔの少なくともいずれかにより記述されていることを特徴とする請求項１０乃至１５のいずれか１項に記載のプログラム。
前記画像のオブジェクトは、前記第１の層がＪａｖａＳｃｒｉｐｔで記述されている場合、Ｃａｎｖａｓを用いて描画されることを特徴とする請求項１６に記載のプログラム。