JP6478487B2 - 情報処理装置、情報処理方法、及びプログラム - Google Patents

情報処理装置、情報処理方法、及びプログラム Download PDF

Info

Publication number
JP6478487B2
JP6478487B2 JP2014122750A JP2014122750A JP6478487B2 JP 6478487 B2 JP6478487 B2 JP 6478487B2 JP 2014122750 A JP2014122750 A JP 2014122750A JP 2014122750 A JP2014122750 A JP 2014122750A JP 6478487 B2 JP6478487 B2 JP 6478487B2
Authority
JP
Japan
Prior art keywords
data
layer
program
image
information processing
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2014122750A
Other languages
English (en)
Other versions
JP2016004320A (ja
JP2016004320A5 (ja
Inventor
梅田 清
清 梅田
尚紀 鷲見
尚紀 鷲見
鈴木 智博
智博 鈴木
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Inc
Original Assignee
Canon Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Canon Inc filed Critical Canon Inc
Priority to JP2014122750A priority Critical patent/JP6478487B2/ja
Priority to US14/728,265 priority patent/US9769335B2/en
Publication of JP2016004320A publication Critical patent/JP2016004320A/ja
Publication of JP2016004320A5 publication Critical patent/JP2016004320A5/ja
Application granted granted Critical
Publication of JP6478487B2 publication Critical patent/JP6478487B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N1/00Scanning, transmission or reproduction of documents or the like, e.g. facsimile transmission; Details thereof
    • H04N1/00127Connection or combination of a still picture apparatus with another apparatus, e.g. for storage, processing or transmission of still picture signals or of information associated with a still picture
    • H04N1/00278Connection or combination of a still picture apparatus with another apparatus, e.g. for storage, processing or transmission of still picture signals or of information associated with a still picture with a printing apparatus, e.g. a laser beam printer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N2101/00Still video cameras
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N2201/00Indexing scheme relating to scanning, transmission or reproduction of documents or the like, and to details thereof
    • H04N2201/0077Types of the still picture apparatus
    • H04N2201/0084Digital still camera

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Stored Programmes (AREA)
  • Machine Translation (AREA)
  • Document Processing Apparatus (AREA)

Description

本発明は、例えば、プリンタなどの画像出力装置に対して外部デバイスとして動作する移動体端末などの情報処理装置で実行される画像処理に関するものである。
近年、カメラ機能が搭載された可搬型多機能携帯端末(以下、モバイルコンピュータ)が爆発的に普及し、デジタルカメラや従来のパーソナルコンピュータ(以下、PC)の販売台数を遥かに凌ぐ勢いで拡販されている。
このようなモバイルコンピュータは、基本的には3つの要素で成り立っている。即ち、コンピュータ自身であるハードウェアと、該ハードウェア上で動作するオペレーティングシステム(以下、OS)と、そのOS上で動作するアプリケーションである。ユーザは、そのアプリケーションを用いて、地図やメール、インターネット上のウェブサイトの閲覧等の機能を使用することが可能である。
このようなモバイルコンピュータ上で動作するアプリケーションの形態としては、主に二つのものが存在する。即ち、ネイティブアプリケーションとウェブアプリケーションである。以下、それぞれの特徴を説明する。
まず、ネイティブアプリケーションとは、通常、OS毎に用意される開発環境、及び開発言語を用いて開発される。例えば、A社が提供するOS上ではC/C++言語、B社が提供するOS上ではJava(登録商標)言語、C社が提供するOS上では更に異なる開発言語を用いる、という具合である。通常、ネイティブアプリケーションは、各開発環境において予めコンパイルされ、人間が理解可能ないわゆる高水準言語から、コンピュータのCPUが解釈可能なアセンブラ等の命令セット群に変換される。このように、通常のネイティブアプリケーションでは、命令をCPUが直接解釈するために、高速動作が可能である、というメリットがある。
一方、ウェブアプリケーションとは、近年では、各コンピュータ上のOSに標準的に組み込まれているウェブブラウザ上で動作するアプリケーションのことである。そのアプリケーションはウェブブラウザが解釈できるよう、一般的には、HTML5及びCSS、さらにJavaScript(登録商標)等の言語を用いて開発される。これらはウェブ標準言語であるため、これらのウェブ標準言語でウェブアプリケーションを一旦記述すれば、ウェブブラウザが動作する環境であれば、どこでも動作可能というメリットがある。
近年では、このようなモバイルコンピュータの普及とともに、上記OSの種類も多種多様なものとなっている。そのため、それらのOS上で動作するアプリケーションを如何に短期間で開発して、ユーザにスピーディに提供できるかがソフトウェア開発における重要な課題となっている。
このような課題を解決する方法として、クロス開発と呼ばれる手法がある。クロス開発とは、アプリケーションの大部分を、各種OSに横断的に利用できる共通プログラム言語を用いて開発を行うことである。この方法は、共通プログラム言語を用いるため、各OSで個別にアプリケーションを開発する場合と比較し、大幅に開発工数を削減することができ、有効なアプリケーション開発手法として知られている。
従って、ウェブアプリケーションは上記課題を解決する一つの方法であると言える。しかし、ウェブアプリケーションはブラウザ上で動作するため、ネイティブアプリケーションとして各ベンダが運営するアプリケーションストアから配布することができない。このため、多くの開発者は、上記ストアから配布可能なネイティブアプリケーション形式におけるクロス開発手法を求めていた。
そのストア配布可能なクロス開発手法の一つとして、特許文献1に記載されているようなハイブリッドアプリケーションが注目されている。ハイブリッドアプリケーションとは、アプリケーション自身は、前述したネイティブアプリケーションとしてユーザに配布される。しかし、そのユーザインタフェース(UI)の全て、あるいは大部分は、HTML5、CSS、JavaScript(登録商標)といったいわゆるウェブの標準言語で記述されている。即ち、1つのアプリケーション内部に、ウェブ標準言語によるスクリプト層とネイティブ層を双方包含する構成となっている。このような構成を採用することにより、上記ネイティブアプリケーションとウェブアプリケーションの利点の双方を生かしたソフトウェアを開発することができる。
特開2011−080470号公報
しかしながら上述したハイブリッドアプリケーションを、写真や文書を印刷するといったプリントアプリケーションに適用しようとした場合、以下のような課題がある。
通常のハイブリッドアプリケーションでは、UI部はウェブ標準言語で記述され、それがテキストデータとしてアプリケーション内部に保持されている。このテキストデータをスクリプトと呼ぶ。このスクリプトは、アプリケーションが起動した際に、OSが保持するスクリプトを翻訳し実行するためのエンジンに入力される。この結果、モバイルコンピュータの画面上にUIが表示され、ユーザが操作することが可能となる。ここでは、このエンジンのことをインタプリタと呼ぶ。
写真印刷アプリケーションの場合、例えば、UI上で、印刷対象となる写真を描画する。そして、写真に対して撮影日時などの日付情報を重畳し、絵文字などのスタンプを重畳し、その結果をユーザがプリントできるよう、そのソフトウェアを設計開発する必要がある。ハイブリッドアプリケーションの場合、日付情報やスタンプ等の印刷コンテンツの描画も、ウェブ標準言語を用いて記述することになる。
上記印刷コンテンツを印刷するためには、ウェブ標準言語を用いて記述されたスクリプトをプリンタの印刷エンジンが要求する、一般的には高解像度画像データ(いわゆるビットマップ(登録商標)データ)へ変換する必要がある。この処理をレンダリング処理と呼ぶ。このレンダリング処理を、通常のOSが保持するインタプリタを用いて行うと以下のような課題がある。
(1)処理速度の低下
ウェブ標準言語で記述された印刷コンテンツを上記インタプリタ内部で翻訳し、高解像度画像データに変換を行う。この高解像度画像データをプリンタに転送するためには、アプリケーションが、OSのインタプリタ内部から変換後の画像データを取得し、フォーマット変換を加えた上でプリンタに転送することが必要になる。なぜなら、プリンタが解釈可能なデータに変換する機能を、OSが保持するインタプリタ内部に備えていないためである。そのため、アプリケーションは、変換後の画像データをインタプリタ内部から取り出す必要があるが、通常はBase64という文字列データとして取り出すことになる。従って、インタプリタ内部で、レンダリング後の画素値(R,G,B)をBase64というキャラクタ(文字列)データに変換するためには膨大な時間を要する。レンダリングに時間を要することは、ユーザの観点からすれば、UIの印刷ボタンを押下してから実際に印刷が開始されるまでの待ち時間が発生することを意味し、その結果、ユーザの使い勝手を著しく低減させることになってしまう。
(2)印刷用レンダリングに必要なメモリの不足
近年のモバイルコンピュータは、その飛躍的な性能向上から、数GB単位の物理RAMを搭載している。そのため、数百MB程度の高解像度画像データであれば、メモリ内部に保持することが可能である。通常のハイブリッドアプリケーションの場合、この高解像度画像データはOS内部のインタプリタでBase64に変換され、アプリケーションはそれを取得することになる。しかしながら、この時、使用するOSによっては、インタプリタから返却された大量のBase64データを保持するメモリが確保できず、メモリ不足に陥る場合がある。
以上のように、上記2つの理由を解決しない限り、クロス開発手法として有効なハイブリッドアプリケーションでの印刷アプリケーションを構築することができないという課題があった。なお、印刷アプリケーションは、一例であり、対象のコンピュータから外部装置へフォーマットを変換してデータを送信する際にも同様の課題が生じる。
本発明は上記の課題を解決するためになされたものであり、ハイブリッドアプリケーションを実行する場合にも高速に処理することができ、かつ、メモリ不足を発生させない情報処理装置、情報処理方法、及びプログラムを提供することを目的とする。
上記の目的を達成するための本発明の情報処理装置は以下のような構成を備える。
即ち、第1の言語で記述され第1形式のデータに基づき表示処理を行う第1のプログラム層と、前記第1の言語とは異なる第2の言語で記述され前記第1形式のデータとは異なる第2形式のデータに基づく印刷データの生成処理を行う第2のプログラム層とを包含するプログラムおよび前記表示処理に関わる出力コンテンツに対して翻訳処理を行う第1の翻訳手段を含むオペレーティングシステムが動作可能な情報処理装置であって、前記第1のプログラム層において画像データを選択する選択指示を受け付けた場合、前記選択された画像データに対応する前記第2形式のデータを前記第1形式のデータに変換して前記第1のプログラム層に送信する変換制御手段と、前記第1のプログラム層において印刷指示を受け付けた場合、印刷処理に関わる出力コンテンツを解釈して印刷用の画像データを生成する第2の翻訳手段と、前記画像データに基づいて印刷データを生成する生成処理を実行する生成手段とを有し、前記第1の翻訳手段は、前記表示処理に関わる出力コンテンツである前記第1形式のデータを前記第1のプログラム層から受信して、前記第1形式のデータに基づく画像を表示装置に表示させ、前記第1のプログラム層において印刷指示を受け付けた場合、前記変換制御手段により前記画像データが前記第1形式のデータに変換されることなく前記生成処理が実行され、前記変換制御手段と前記第2の翻訳手段と前記生成手段は、前記第2のプログラム層に含まれることを特徴とする。
また本発明を別の側面から見れば、第1の言語で記述され第1形式のデータに基づき表示処理を行う第1のプログラム層と、前記第1の言語とは異なる第2の言語で記述され前記第1形式のデータとは異なる第2形式のデータに基づく印刷データの生成処理を行う第2のプログラム層とを包含するプログラムと前記表示処理に関わる出力コンテンツに対して翻訳処理を行う機能を含むオペレーティングシステムをプロセッサで実行する情報処理方法であって、前記第1のプログラム層において画像データを選択する選択指示を受け付けた場合、前記選択された画像データに対応する前記第2形式のデータを前記第1形式のデータに変換して前記第1のプログラム層に送信する変換工程と、前記第1のプログラム層において印刷指示を受け付けた場合、印刷処理に関わる出力コンテンツを解釈して印刷用の画像データを生成する第1の生成工程と、前記画像データに基づいて印刷データを生成する生成処理を実行する第2の生成工程と有し、前記翻訳処理を行う機能の実行により、前記表示処理に関わる出力コンテンツである前記第1形式のデータを前記第1のプログラム層から受信して、前記第1形式のデータに基づく画像を表示装置に表示させ、前記第1のプログラム層において印刷指示を受け付けた場合、前記変換工程において前記画像データが前記第1形式のデータに変換されることなく前記生成処理が実行され、前記変換工程と前記第1の生成工程と前記第2の生成工程の実行は、前記第2のプログラム層の実行に含まれることを特徴とする情報処理方法を備える。
さらに本発明を別の側面から見れば、コンピュータを、上記構成の情報処理装置の各手段として機能させるためのログラムを備える。
従って、本発明によれば、ハイブリッド構成のプログラムで、例えば、印刷アプリケーションを実行しても、処理速度の速い、メモリ不足が発生しないユーザにとって使い勝手のよい環境を提供することが可能となるという効果がある。
本発明の代表的な実施形態である情報処理装置の構成を示すブロック図である。 図1に示した情報処理装置のソフトウェアの構成を示すブロック図である。 ユーザ操作に伴う処理を示すフローチャートである。 写真画像選択の詳細を示すフローチャートである。 画像処理の詳細を示すフローチャートである。 スタンプ追加の詳細を示すフローチャートである。 スタンプ特定の詳細を示すフローチャートである。 スタンプ操作の詳細を示すフローチャートである。 プリンタ設定の詳細を示すフローチャートである。 レンダリングの詳細を示すフローチャートである。 プリントの詳細を示すフローチャートである。 アプリケーション画面の一例を示す図である。 設定画面の一例を示す図である。 プリンタ選択画面の一例を示す図である。 画像処理機能選択画面の一例を示す図である。 他の実施形態に従うソフトウェアの構成を示すブロック図である。 プリントUIの例を示す図である。 プレビューUIの例を示す図である。
以下、本発明の実施の形態について添付図面を参照して詳細に説明する。特に、以下の実施形態では、情報処理装置上で、後述するハイブリッド型写真印刷アプリケーションを動作させ、ユーザが選択した画像に対して、様々な画像処理を適用した後に、その画像を印刷する構成について説明する。なお、その情報処理装置の代表例としては、携帯電話やスマートフォンやタブレット端末のような携帯型情報端末が含まれる。
<ハードウェア構成の説明>
図1は本発明の代表的な実施形態である情報処理装置115として、例えば、スマートフォンや携帯電話等の携帯型情報端末の構成例を説明するブロック図である。同図において、100はCPU(中央演算装置/プロセッサ)であり、以下で説明する各種処理をプログラムに従って実行する。図中のCPU100は1つであるが、複数のCPUあるいはCPUコアによって構成されていても良い。101はROMであり、CPU100により実行されるプログラムが記憶されている。102はRAMであり、CPU100によるプログラムの実行時に、各種情報を一時的に記憶するためのメモリである。
103はハードディスクやフラッシュメモリ等の2次記憶装置であり、ファイルや画像解析等の処理結果を保持するデータベース等のデータや、各種プログラムを記憶するための記憶媒体である。104はディスプレイであり、各種処理を実現するための操作を受け付けるためのUI(ユーザインタフェース)や、実行された処理による処理結果等の各種情報を表示する。ディスプレイ104は、タッチセンサ105を備えても良い。
情報処理装置115は、内部撮像デバイス110を備えてもよい。内部撮像デバイス110による撮像によって得られた画像データは、所定の画像処理を経た後、2次記憶装置103に保存される。また、画像データは、外部I/F(インタフェース)108を介して接続された外部撮像デバイス111から読み込むこともできる。
情報処理装置115は、外部I/F(インタフェース)109を備え、インターネット等のネットワーク113を介して通信を行うことができる。情報処理装置115は、この通信I/F109を介して、ネットワーク113に接続されたサーバ114より画像データを取得することもできる。
情報処理装置115は、加速度センサ106を備え、情報処理装置115自身の位置姿勢に関する加速度情報を取得することができる。情報処理装置115は、外部I/F107を介し、プリンタ112と接続されており、画像データ等のデータを出力することができる。プリンタ112は、ネットワーク113にも接続されており、通信I/F109経由で、画像データを送受信することができる。
外部I/F107〜109は、有線通信と無線通信の内、少なくともいずれかの通信形態を有するインタフェースであり、利用する通信形態に応じて外部デバイス(プリンタ112あるいはサーバ114)との通信を行う。有線通信には、例えば、USB、イーサネット(登録商標)等があり、無線通信には、無線LAN、NFC、Bluetooth(登録商標)、赤外線通信等がある。また、無線通信として、無線LANを利用する場合には、装置同士が直接接続する形態もあれば、無線LANルータ等の中継装置を介して接続する形態もある。また、外部I/F107〜109は、図では別々に構成されているが、一体となって構成されていても良い。
情報処理装置115の動作に必要な電源は、バッテリ117によって供給される。情報処理装置115が備える各種構成要素は、制御バス/データバス116を介して相互に接続され、CPU100は、この制御バス/データバス116を介して、各種構成要素を制御する。
尚、本実施形態では、情報処理装置115が、その情報処理装置115が備える制御部(CPU100)によって実行されるプログラム等のソフトウェアの実行場所(ソフトウェア実行環境)となる。
<ソフトウェアのブロック図>
図2は情報処理装置115で動作するソフトウェア構成のブロック図である。
情報処理装置115は、スクリプト層217、ネイティブ層218、及びOS層219のプログラムを実行する。これらの各層は、CPU100がROM101あるいは2次記憶装置103に記憶されている対応するプログラムを読み出し実行することにより実現される。
スクリプト層217は、HTML5やCSS3、及びJavaScript等のウェブ標準言語を使って、テキストデータで命令セット(コンテンツの描画や画像の表示、動画の再生等)が記述されているプログラム層である。スクリプト層217では、アプリケーション実行環境上で、そのアプリケーション実行環境に存在するプロセッサ(例えば、CPU100)を用いて、テキストデータの各種命令セットを翻訳して実行することになる。その実行形態としては、実行の度に命令文を一行ずつ動的に翻訳する場合や、アプリケーションを起動したときに翻訳する場合、アプリケーションを情報処理装置115にインストールしたときに翻訳する場合等が考えられる。
以後、スクリプト層217で処理することや内容をスクリプトと呼ぶ。スクリプトの命令を情報処理装置115内で翻訳する形態の例として、ネイティブ層218やOS層219が備えるインタプリタの機能を使用することが挙げられる。尚、この実施形態においては、アプリケーションのUIの大部分が、スクリプト層217で記述されていることを想定している。
ネイティブ層218は、アプリケーション実行環境以外で予め翻訳(コンパイル)された命令セットが記述されているプログラム層である。形態としては、CもしくはC++といった高水準言語で記述されたコードが、予めアプリケーションの開発者のPCやサーバ上でコンパイルされ、CPU100が解釈可能な命令の集合体となっている。以後、ネイティブ層218で処理することや内容、後述するOS層219の機能をネイティブ層218から呼び出すことを含め、ネイティブと呼ぶこととする。尚、ネイティブ層218の別の実装系として、Javaが挙げられる。Javaは、C/C++と類似の高水準言語であり、予めアプリケーション開発時の開発環境上で中間コードに翻訳される。翻訳された中間コードは、各OSが備えるJava仮想環境上で動作する。本実施形態においては、このようなプログラム形態も、ネイティブ層218の一種に含める。
OS層219は、情報処理装置115のオペレーティングシステム(Operating System:OS)に対応する。OS層219は、ハードウェア機能の使用をアプリケーションに提供する役割及び固有の機能を有する。OS層219は、APIを備え、スクリプト層217やネイティブ層218から機能を使用することができる。
この実施形態では、スクリプト層217からネイティブ層218の呼び出しを可能にすることをバインディング、もしくはバインドと呼ぶ。各種ネイティブの機能は、APIを備え、該APIをスクリプトが呼び出すことでネイティブの機能を使用することができる。このようなバインディング機能は、通常、各種OSが標準的に備えている機能である。
尚、この実施形態では、スクリプト層217とネイティブ層218を含むアプリケーションのことをハイブリッド型アプリケーションと呼ぶ。つまり、本願の処理は、ハイブリッド型アプリケーションおよびオペレーティングシステムが動作可能な情報処理装置において実行される。
スクリプト層217の画像取得部201は、ネイティブ層218に対し画像データの取得を依頼する。取得依頼時に、画像取得部201は、一意なIDを生成し、ネイティブ層218に送信する。このIDと、ネイティブ層218の画像読込部202で読み込まれた画像データは、対となって、ネイティブ層218のデータ保持部204に記憶される。これ以外にも、例えば、絶対パスを指定する方法や、ダイアログ表示を促す方法等が挙げられる。
ネイティブ層218の画像読込部202は、画像データ群215から画像データを取得する。画像データ群215からの画像データの取得方法は、スクリプト層217の画像取得部201の依頼に依存する。依頼方法は、UI上に提供されているダイアログボックスから選択する、ファイルのパスから直接画像を選択する等が挙げられる。
ネイティブ層218のデータ変換部203は、ネイティブ層218のデータをスクリプト層217で利用できる形式のデータに変換する。一方で、データ変換部203は、スクリプト層217から送られてきたデータをネイティブ層218で利用できる形式にする変換も行う。
スクリプト層217のデータ変換部207は、スクリプト層217のデータをネイティブ層218で利用できる形式のデータに変換する。一方で、データ変換部207は、ネイティブ層218から送られてきたデータをスクリプト層217で利用できる形式にする変換も行う。
ネイティブ層218のデータ保持部204は、画像読込部202で読み込んだ画像データ、画像処理部208で画像処理が施された画像データを保持する。保持される画像データは、例えば、RGB画像信号に展開されており、すぐに画像処理が実行できる形式になっている。
スクリプト層217のコンテンツ描画部205は、プリントのためのコンテンツをウェブ標準言語を利用して記述する。この記述には、コンテンツ操作部210で操作されたスクリプトも反映される。コンテンツ描画部205で記述されたコンテンツのスクリプトは、OS層219のインタプリタ214で解釈され、ディスプレイ104に表示されることになる。
スクリプト層217の画像処理部208は、画像処理制御部206で指定された画像に対し画像処理を施す。その際、どのような画像処理を施すかは、画像処理制御部206で設定されたパラメータにより決定される。画像の指定については、例えば、スクリプト層から画像のパスを受け取る方法や、画像データごと受け取る方法などが考えられる。
OS層219のタッチイベント209は、ディスプレイ104のタッチに関する情報を取得する。タッチに関する情報とは、ディスプレイ104のタッチ検知、タッチされた位置情報等が挙げられる。取得したタッチに関する情報は、ネイティブ層218経由でスクリプト層217のコンテンツ操作部210に送信される。
スクリプト層217のコンテンツ操作部210は、画像を操作、例えば、画像の拡大、移動、回転などを行い、その操作を反映すべく、スクリプト命令を変更する。
スクリプト層217のプリンタ制御部211は、レンダリング部216へのレンダリング開始依頼、プリンタ検知の依頼、プリンタ設定画面の表示、プリント情報の生成と送信を制御する。プリンタ設定画面では、用紙のサイズ、用紙の種類、カラー・モノクロ等のプリンタ設定がなされる。ここで設定された項目を基に、プリンタデータ生成部212でプリンタデータが生成される。
ネイティブ層218のプリンタデータ生成部212は、プリンタ制御部211からの依頼を基に、プリンタ通信に必要なデータ、コマンドを生成する。プリンタ通信に必要なデータとは、通信プロトコルに則ったデータであり、コマンドとは、印刷やスキャン等、プリンタの動作を決定するためのデータである。
OS層219のプリンタ通信部213は、プリンタデータ生成部212から受信したプリンタデータを接続しているプリンタ112に送信したり、プリンタ112からプリンタ112に関する情報を受信する。OS層219のインタプリタ214は、スクリプト層217で生成されたウェブ標準言語で記述された命令を解釈・実行する。例えば、画像の描画等の命令の翻訳処理は、インタプリタ214により実行され、ディスプレイ104に表示される。
また、ネイティブ層218の中にも別のインタプリタ221が存在する。インタプリタ221は、詳細は後述するが、スクリプト層217で描画された印刷コンテンツに対して翻訳処理を実行し、印刷解像度にレンダリングし、画像データをRGB画素値で出力する。なお、印刷コンテンツとは、記録媒体に印刷される画像に対応する。よって、印刷コンテンツには、印刷対象として選択された画像データ、画像データに付加されるスタンプ、日付情報が含まれる。もちろん、印刷コンテンツには、画像データのみが含まれていても良い。なお、印刷コンテンツは、外部デバイスで表示されても良いので、単に出力コンテンツと呼ばれても良い。
画像データ群215は、画像データを保持している領域である。データ保存部220は、必要に応じて、データ保持部204が保持する画像データを画像データ群215に保存させるために機能する。
レンダリング部216は、コンテンツ描画部205、画像処理制御部206、及びコンテンツ操作部210を制御して、処理対象の画像データのレンダリングを行う。このレンダリングには、例えば、スクリプト層217のインタプリタ221でプリンタ112への出力解像度で画像を生成することが含まれる。また、インタプリタ221による、レンダリング結果、及び、生成途中の画像はディスプレイ104に表示されない。レンダリング結果は、ネイティブ層218のデータ変換部203に送信され、プリンタ112が利用できる形式の画像データに変換される。
<ユーザ操作に伴う処理>
図3はユーザ操作を含む処理を示すフローチャートである。まず、図3を用いて、S21からS28の各処理の概要を説明し、詳細は後述する。なお、本願のフローチャートの各ステップの処理は、情報処理装置115のCPU100が、ROM101あるいは2次記憶装置103に記憶されているプログラムを実行することにより実現される。また、図3に示す各ステップは、UIの1つである図12に示すアプリケーション画面1200に対するユーザ操作に従って遷移する。アプリケーション画面1200は、スクリプト層217によって生成される。アプリケーション画面1200の操作は、例えば、タッチセンサ105を介して実現される。
S21で、CPU100は、アプリケーション画面1200の写真画像選択ボタン1201に対するユーザ操作(タッチ操作も含む。以後も同様)を検知すると、その操作に応じて、任意の画像を選択する。画像を選択すると、CPU100は、アプリケーション画面1200の描画領域1206の全体に選択された画像を表示する。
S22では、CPU100は、表示されている画像の輝度を調整するためのスライドバー1202に対するユーザ操作を検知すると、そのユーザ操作に応じて、画像処理時に利用する補正パラメータを設定する。そして、CPU100は、設定した補正パラメータに従って、表示されている画像に画像処理を施し、その処理内容及び処理結果を描画領域1206に表示する。
S23は、CPU100は、スタンプ追加ボタン1203に対するユーザ操作を検知すると、スタンプ一覧を表示する。スタンプ一覧に対するユーザ操作によってスタンプの選択を検知すると、CPU100は、描画領域1206に選択されたスタンプを追加・表示する。
S24で、CPU100は、アプリケーション画面1200に対するユーザ操作に応じて、スタンプを特定する。スタンプの特定とは、ディスプレイ104にユーザ操作によってタッチされた座標とスタンプの座標より、スタンプがタッチされたか否かを判断するものである。スタンプがタッチされた場合、そのスタンプは操作受付状態となる。ここでは、ユーザ操作に応じて、スタンプが操作受付状態になっているものとする。操作受付状態については後述する。
S25で、CPU100は、操作受付状態になっているスタンプを回転するためのスライドバー1204に対するユーザ操作を検知すると、そのユーザ操作に応じて、スタンプ操作として、操作受付状態にあるスタンプを回転する。
S26で、CPU100は、プリントボタン1205に対するユーザ操作を検知すると、プリントに必要な情報を設定するための設定画面1301(図13)を表示する。プリントに必要な情報とは、例えば、図13の設定画面1301に示されるように、用紙サイズ、用紙種類、印刷品位、縁あり/なしの設定項目がある。これ以外にも、両面/片面、モノクロ・カラー等、使用するプリンタが有する機能に応じて、設定可能な設定項目が構成される。
S27で、CPU100は、設定画面1301の設定完了ボタン1302に対するユーザ操作を検知すると、描画領域に表示されている画像を、プリンタに出力するためのプリント解像度に変換するためのレンダリングを実行する。
S28で、CPU100は、プリントの解像度に変換された画像を、プリンタ制御のコマンドと共にプリンタ112に送信する。以上の処理により、ユーザにより選択された画像がプリンタ112でプリントされる。
尚、図3に示す処理は一例であり、処理内容はこれに限定されず、ステップ群の処理順序もこれに限定されるものではない。また、この実施形態において、プロセッサで翻訳され実行されるための命令セットを含む第1のプログラム層をスクリプト層217、プロセッサ以外で予め翻訳された命令セットを含む第2のプログラム層をネイティブ層218と定義する。そして、これらの第1のプログラム層と第2のプログラム層とを包含するプログラムがハイブリッド型アプリケーションを実現する。文字列データを第1の形式、バイナリデータを第2の形式と定義する。
<プリンタの選択>
最初に、ユーザ操作によって、図3に示す処理を実現するアプリケーションが起動される際には、アプリケーションは、まず、接続可能な外部デバイス(プリンタ112)のディスカバリ処理(不図示)を行う。ディスカバリ処理とは、情報処理装置115が存在するネットワーク113内において、接続可能なプリンタ112のIPアドレスを特定する処理のことである。
情報処理装置115は、ディスカバリ処理によって取得したIPアドレス(場合によっては、複数個)に対して、各種プリンタの属性情報取得の命令を送信して、その返信を取得することができる。
より具体的には、ネイティブ層218において、各プリンタの情報を取得するためのコマンドを生成する。コマンドとは、プリンタの動作を指定する命令であり、下記のようなXMLで表現される。
<?xml version="1.0" encoding="utf-8" ?>
<cmd xmlns:trans="http://www.trans/example/">
<contents>
<operation>GetInformation</operation>
</contents>
</cmd>
生成されたコマンドは、プリンタの通信プロトコルに従った形式で、ネットワーク上のネットワーク機器(例えば、Wi−Fi(登録商標)接続されたルータ)に対しブロードキャストされる。ここで、通信方法は、Wi−Fiダイレクトや電話回線を利用する形態が考えられるが、これに限定されるものではない。コマンドの送信の結果、ネイティブ層218は、プリンタからの応答を受信する。受信する応答の例としては、下記のようなXMLで表現される。
<?xml version="1.0" encoding="utf-8" ?>
<cmd xmlns:trans="http://www.trans/example/">
<contents>
<PrinterName>PrinterA</PrinterName>
<ImageProcGrp>A</ImageProcGrp>
<ResolutionX>400</ResolutionX>
<ResolutionY>400</ResolutionY>
</contents>
</cmd>
上記は、簡単な例であるが、PrinterNameタグによって、それぞれのプリンタ名称を取得することができる。また、ImageProcGrpタグによって、それぞれのプリンタが利用可能な画像処理グループを取得することもできる。この画像処理グループにより、図15の1501に表示される選択肢が決まる。また、ResolutionXおよびResolutionYは、このプリンタのエンジンが必要とする画像の解像度であり、例えば単位はdpiである。
ネイティブ層218で取得された機種名は、スクリプト層217に伝達されて、以下の仮想コードにより、プリンタのリストとして表示される。
<form name=”frmPrinter”>
<select name=”selPrinter”>
</select>
</form>
<script type=”text/javascript”>
Function fAddPrinter(PrinterName, count){
var sObj=document.forms[“frmPrinter”].elements[“selPrinter”];
for (var i=0;i<count;i++){
var idx=sObj.length;
sObj.options[idx]=new Option(PrinterName[i]);
}
}
</script>
上記において、selectタグは、リストを表示するための記述であり、scriptタグ内に記載したJavaScriptコードによって、リストに取得したプリンタの名称(PrinterNameに配列として格納)を追加することができる。
図14は、スクリプト層217において生成した仮想コードがインタプリタ214で解釈され、ディスプレイ104で表示されたプリンタのリストを含むプルダウンメニュー1401を示している。ユーザが所望のプリンタを選択すると、スクリプト層217が何番目のリストを選択したかというIDを取得することができる。プリンタを選択すると、次に、ユーザは、写真画像の選択操作に遷移する。
<写真画像選択の詳細>
ユーザが図12に示した写真画像選択ボタン1201を押下することでS21が開始する。ここで、図3のS21の写真画像選択の詳細について、図4を用いて説明する。なお、S301〜S302、S309〜S311は、CPUがスクリプト層のプログラムを用いて実行する処理であり、S303〜S308はCPUがネイティブ層のプログラムを用いて実行する処理である。
S301で、CPU100は、一意なIDを生成する。このIDは、数値、文字列等、スクリプト層217からネイティブ層218へ送信できる形式であればどのような形でも良い。S302で、CPU100は、写真画像選択ボタン1201に対するユーザ操作に応じて画像選択をネイティブ層218に依頼する。S302ではS301で生成されたIDもネイティブ層218に送信される。その依頼は、バインディング機能によりスクリプト層217からネイティブ層218固有の画像選択APIを呼び出すことによりなされる。しかしながら、直接ネイティブ層固有の画像選択APIを呼び出せないのであれば、ネイティブ層218にスクリプト層217から直接呼び出せる関数を用意し、その関数内にネイティブ層固有の画像選択APIを呼び出す関数を記述しておけばよい。これは、ラッパを予め用意しておく方法である。
S303で、CPU100は、デバイス固有の画像選択UIをディスプレイ104に表示する。表示された画像選択UIに対するユーザ操作に基づいて、CPU100は、任意の画像を1枚選択する。画像の選択は、例えば、情報処理装置115内で管理されるフォルダから画像を1枚選択するものとするが、これに限定されるものではない。例えば、インターネット上の画像や、脱着可能な記憶媒体内の画像を選択しても良いし、情報処理装置115の内部撮像デバイス110を利用して撮影した画像を取得しても良い。
S304で、CPU100は、選択された画像を取得する。例えば、選択した画像が画像ファイルの状態であれば、CPU100は、ファイルを開き、その内容を読み取る。S305で、CPU100は、取得した画像をRGB空間に展開する。S306で、CPU100は、スクリプト層217から取得したIDと展開したRGB画像を関連付けてデータ保持部204に保持する。関連付け方法は、例えば、IDとRGB画像を有するオブジェクトを作成することで、IDによりRGB画像の特定を可能にするという方法が考えられる。この関連付け方法は、これに限らず、IDと選択された画像のアクセス先であるパスや、IDとRGB展開に応じて実行される関数やクラス等も考えられる。
S307で、CPU100は、展開したRGB画像をスクリプト層217で利用可能な形式(サポート可能な形式)の画像データに変換する。この実施形態では、変換するデータ形式をJPEG(Joint Photography Expert Group)とする。S308で、CPU100は、JPEG形式のデータをBASE64データに変換し、スクリプト層217へ送信する。これは、スクリプト層217では、RGB画像のデータ配列をそのまま利用できないため、ネイティブ層218において、スクリプト層217で利用できる形式に変換する必要があるためである。JavaScript(登録商標)では、文字列しか扱えないため、この実施形態では、文字列としてデータを表現するBASE64の形式を利用する。
S309で、CPU100は、ネイティブ層218で変換されたBASE64データを受信するとともに、そのBASE64データを表示するための描画領域をRAM102に確保する。この実施形態では、描画領域の確保の一例としてHTMLのCanvas機能を利用し、画像の描画は、Canvasの有するContextオブジェクトのAPIを利用する。
S310で、CPU100は、補正パラメータを生成し、初期化する。ここで、補正パラメータとは、S22の画像処理の内容を決定するパラメータ群を保持するオブジェクトである。JavaScript(登録商標)で保持する補正パラメータの一例として、下記のような形態が考えられる。
var CorrectionParam = function(){
this.brightness = 0;
}
この補正パラメータは、CorrectionParamオブジェクトの中に、明るさ補正用にbrightnessという名前の変数が設けられており、0という値を格納するということを表している。
この実施形態では、説明の簡略化のために、補正パラメータは明るさ(輝度)補正用のみであるが、その他の補正処理用のパラメータ(ぼかしフィルタの強度、セピア変換のオン・オフ等)を追加しても良いことは言うまでもない。
S311で、CPU100は、描画領域で描画するデータにBASE64データを指定し、それに従って、その描画領域に画像を描画する。具体的には、CPU100は、スクリプト層217で指定されたBASE64データをOS層のインタプリタ214に送信する。そして、インタプリタ214がBASE64データのスクリプトを解釈し、描画領域に画像として表示する。ここで、描画領域に、BASE64データを反映させるサンプルコードの一例を示す。
--------------------------------------------------
var base64Data = ネイティブ層からのBASE64データ
var canvas = document.createElement("canvas"); //画像の描画領域確保
canvas.setAttribute("width", 100); //描画領域の大きさ設定
canvas.setAttribute("height", 100);
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);
//本フローチャートではCanvasが何層にもなるレイヤー構造を想定している}
これらのCanvasは至る所好き勝手に存在するわけではなく、描画、移動、拡大等の操作は、特定の領域内(図12の描画領域1206)で完結するその領域を指定しているものが「div」であり、Canvasはそのdivに追加されてゆく形態をとる。
--------------------------------------------------
<画像処理の詳細>
ユーザが図12に示したスライドバー1202を変化させることでS22が開始する。ここでは、図3のS22の画像処理の詳細について、図5を用いて説明する。なお、S401〜S403、S409、S411は、CPUがスクリプト層のプログラムを用いて実行する処理であり、S404〜S408、S410はCPUがネイティブ層のプログラムを用いて実行する処理である。
S401で、CPU100は、補正パラメータを設定する。ここでは、図3のS310で生成した補正パラメータのbrightnessの値を、スライドバー1202に対するユーザ操作に応じて設定される値に更新する。S402で、CPU100は、インジケータを起動し、ディスプレイ104に表示する。ここで、インジケータとは、ユーザに処理中である旨を伝える表示であり、一般には、プログレスバーや、時計マーク、図形の点滅や回転等の画像で表現する。S403で、CPU100は、スクリプト層217で、設定した補正パラメータをネイティブ層218で利用できるJSON文字列の形式に変換する。ここで、補正パラメータはオブジェクトの形態を取っており、そのままではネイティブ層218で利用できないため、設定した補正パラメータをJSON文字列に変換する。そして、CPU100は、JSON文字列に変換された補正パラメータを、図3のS301で生成したIDと共にネイティブ層218へ送信する。
S404で、CPU100は、JSON文字列に変換された補正パラメータをデコードし、補正パラメータを取得する。より具体的には、補正パラメータをOS層219に備えられているパーサを利用してパースする。パース後に、上記の例の場合、補正パラメータ内のbrightnessが取得されることになる。
S405で、CPU100は、スクリプト層217から取得したIDを基に、図3のS305で展開されたRGB画像を特定する。尚、上述のように、IDと画像の対応付けは、IDとRGB画像と対にすることに限定されるわけではなく、例えば、IDと画像のパスを関連付ける方法を用いてもよい。その他にIDと関連付ける例として、ネイティブ層218のオブジェクト、画像データの先頭アドレス、画像を呼び出す関数等、様々なものが考えられる。
S406で、CPU100は、取得した補正パラメータから施すべき画像処理を判断し、RGB画像に対して画像処理を行う。
S407で、CPU100は、画像処理が施されたRGB画像から、スクリプト層217で利用可能な形式(サポート可能な形式)の画像データに変換する。ここでは、図3のS307と同様に、JPEG形式のデータに変換する。S408で、CPU100は、スクリプト層217にインジケータの停止を依頼する。これは、ネイティブ層218から、スクリプト層217で定義されているインジケータ停止の関数を呼び出すことで実現する。
S409で、CPU100は、インジケータを停止して、ディスプレイ104の表示から消去する。
一方、S410で、CPU100は、変換されたJPEG形式のデータをBASE64データに変換し、スクリプト層217へ送信する。
S411で、CPU100は、ネイティブ層218で変換されたBASE64データを受信し、それに従って、図3のS309で確保した描画領域に画像を描画する。具体的には、CPU100は、スクリプト層で指定されたBASE64データをOS層のインタプリタ214に送信する。そして、インタプリタ214がBASE64データのスクリプトを解釈し、描画領域に表示する。以上の処理により補正パラメータに基づく画像処理が適用された画像データが表示される。また、この実施形態においては、図15に示すように、プルダウンメニュー1501によって、利用可能な画像処理の一覧を表示し、ユーザが所望の処理を選択することができる。
ここで、プルダウンメニュー1501中の「ImageFix」とは、写真画像を、人物顔検出やシーン解析部を用いて自動で解析し、適切な明るさ・ホワイトバランス調整を行う機能(顔検出機能)である(特開2010−278708号公報参照)。また、「RedeyeFix」とは、画像中から自動で赤目画像を検出して補正する機能(赤目検出機能)である(特開2006−350557号公報参照)。また、「SmartSkin」とは、写真画像から人物の顔を検出して、該顔の肌領域を好適に加工する機能である(特開2010−010938号公報参照)。また、「Mono」は、公知のモノクロ変換を行うモノクロ化処理機能である。「Sepia」は公知のセピア色変換を行うセピア化処理機能である。尚、画像処理機能の種類は、図15に示すものに限定されるものではなく、用途や目的に応じて、様々な画像処理を利用することができる。
この時に、この実施形態では、JavaScriptからバインド機能によってOS層219が通常備えているシステム関数を呼び出し、このシステム関数から、情報処理装置115のCPU100のクロック速度Clk[MHz]を取得する。そして、このクロック速度Clkから、予め定められた閾値Th1を用いて、利用できる画像処理機能を含む画像処理グループを特定する。画像処理グループの特定のための仮想コードは、以下のようになる。
If ( Clk > Th1 ) ImageProcGrp = “A”;
Else ImageProcGrp = “B”
尚、この判定は、通常、アプリケーションが起動した際に、スクリプト層217において行われる。画像処理グループを特定できたら、スクリプト層217において、以下のコードによって利用可能な画像処理の表示用スクリプトを制御する。
<form name=”frmIProc”>
<select name=”selIProc”>
</select>
</form>
<script type=”text/javascript”>
Function fAddImageProc(Grp){
var sObj=document.forms[“frmIProc”].elements[“selIProc”];
if( Grp =”A” ){
var idx=sObj.length;
sObj.options[idx]=new Option(“ImageFix”);
var idx=sObj.length;
sObj.options[idx]=new Option(“RedEyeFix”);
var idx=sObj.length;
sObj.options[idx]=new Option(“SmartSkin”);
var idx=sObj.length;
sObj.options[idx]=new Option(“Mono”);
var idx=sObj.length;
sObj.options[idx]=new Option(“Sepia”);
}
Else if (Grp=”B”){
var idx=sObj.length;
sObj.options[idx]=new Option(“Mono”);
var idx=sObj.length;
sObj.options[idx]=new Option(“Sepia”);
}
}
</script>
上記スクリプト操作においては、情報処理装置115のCPU100のクロック数が所定値(閾値)より大きく、複雑な画像処理を実行可能と判断した場合には(Grp=A)、より多くの画像処理機能を選択可能なものとしている。一方、情報処理装置115のCPU100のクロック数が所定値以下の場合には、処理としては負荷の軽いモノクロ変換、セピア変換という処理しか選択できないようになる。
当然のことながら、上記スクリプトは、図2のインタプリタ214で翻訳され、ディスプレイ104上に機能選択画面1600(図15)として表示される。
ユーザが所望の画像処理機能を選択すると、HTMLの機能によって選択された画像処理IDを判別できる。この画像処理IDは、ネイティブ層218に伝達され、図2の画像処理部208において、選択した画像処理機能に相当する画像処理が適用される。
<スタンプ追加の詳細>
ユーザが、図12に示すスタンプ追加ボタン1203を押下し、ハートスタンプ1208を選択すると、S23の処理が開始する。ここでは、図3のS23のスタンプ追加の詳細について、図6を用いて説明する。以下の説明では、ユーザ操作によって、図12のアプリケーション画面1200のスタンプ追加ボタン1203が押下されてスタンプ一覧が表示された後、ハートスタンプ1208が選択された場合を例に挙げる。なお、S501〜S502、S508〜S510は、CPUがスクリプト層のプログラムを用いて実行する処理であり、S503〜S507はCPUがネイティブ層のプログラムを用いて実行する処理である。
S501で、CPU100は、一意なIDを生成する。このIDは、図3のS301で生成するIDと同等の性質を有する。S502で、CPU100は、生成したIDととともに、スタンプとして利用される画像のアクセス先(絶対パス)をネイティブ層218に送信することで、スタンプに対応するスタンプ画像の画像選択を依頼する。
S503で、CPU100は、スクリプト層217から受信したスタンプ画像の絶対パスとデバイス固有の画像選択APIを利用して、スタンプ画像を取得する。S504で、CPU100は、取得したスタンプ画像をRGB展開する。S505で、CPU100は、スクリプト層217から取得したIDと展開したRGB画像を関連付けてデータ保持部204に保持する。その関連付け方法は、図3のS306と同様である。S506で、CPU100は、展開したRGB画像をスクリプト層217で利用可能な形式(サポート可能な形式)の画像データに変換する。ここでの変換は、図3のS307と同様に、JPEG形式のデータに変換する。S507で、CPU100は、JPEG形式のデータをBASE64データに変換し、スクリプト層217へ送信する。
S508で、CPU100は、ネイティブ層218で変換されたBASE64データを受信するとともに、そのBASE64データを表示するための描画領域をRAM102に確保する。S509で、CPU100は、オブジェクトパラメータを生成し、初期化する。ここで、オブジェクトパラメータとは、図3のS27のレンダリング(詳細は後述)の際、レンダリング後のスタンプの回転角度を決定するために用いられるパラメータを保持するオブジェクトである。JavaScript(登録商標)で保持するオブジェクトパラメータの一例としては、下記のような形態が考えられる。
var ObjectParam = function(){
this.theta = 0;
this.posX = 0;
this.posY = 0;
this.width = 100;
this.height = 100;
}
このオブジェクトパラメータは、ObjectParamオブジェクトの中に、回転角度を示すthetaという変数名と、thetaには0という値が格納されているということを表している。同様に、posXは描画領域の左上を基準点とした時のx座標、posYは描画領域の左上を基準点とした時のy座標、widthは描画領域の横幅、heightは描画領域の縦幅を表している。尚、この実施形態では、説明を簡単にするため、オブジェクトパラメータは必要最小限であるが、その他のパラメータ(平行移動量、拡大倍率等)を追加し、描画時やレンダリング時に利用できることは明らかである。
S510で、CPU100は、BASE64データを、生成したオブジェクトパラメータを基に、描画領域1206に画像として表示する。具体的には、CPU100は、選択されたスタンプに対応するBASE64データをOS層のインタプリタ214に送信する。そして、インタプリタ214がBASE64データのスクリプトを解釈し、描画領域にスタンプ画像として表示する。尚、この実施形態では、説明を簡単にするために、スタンプを1つ選択した場合を例に挙げているが、複数個のスタンプを選択できることは言うまでもない。また、この実施形態では、スタンプに予め用意した画像を利用しているが、Contextオブジェクトを利用して描画物をスクリプト層で生成する方法を用いても良い。
<スタンプ特定の詳細>
ユーザが図1に示したディスプレイ104にタッチすることでS24が開始する。ここでは、図3のS24のスタンプ特定の詳細について、図7を用いて説明する。なお、S602〜603は、CPUがスクリプト層のプログラムを用いて実行する処理であり、S601はCPUがネイティブ層のプログラムを用いて実行する処理である。
S601で、CPU100は、ディスプレイ104上でタッチされた座標を取得し、スクリプト層217に送信する。
S602で、CPU100は、ネイティブ層218から受信した座標と、図5のS509で生成したオブジェクトパラメータの情報より、図3のS23で追加したスタンプがタッチされたかどうかを判断する。追加したスタンプにおいて、オブジェクトパラメータは初期値のままである。そのため、上記のオブジェクトパラメータの一例に従えば、スタンプは、描画領域1206の左上端を(0,0)とし、そこからx方向に100、y方向に100の領域に描画されていることになる。これより、受信した座標の座標(x,y)の内、x座標から描画領域1206のx座標分を差し引いた値が0〜100の範囲、かつ、y座標から描画領域1206のy座標分を差し引いた値が0〜100の範囲であれば、スタンプはタッチされたと判断できる。スタンプがタッチされたと判断された場合、そのスタンプは、図3のS25の操作受付状態となる。
以降の説明では、図3のS24において、図3のS23で追加したスタンプがタッチされたものとして説明する。
S603で、CPU100は、判断結果に応じて、スタンプを操作受付状態に設定する。ここで、操作受付状態に設定することは、タッチされたスタンプのIDを注目スタンプIDとして、一時的にスクリプト層217に記憶しておくことである。これは、データ保持部204には、画像とIDが対となって記憶されているため、IDさえ把握しておけば一意な画像を特定できるためである。
<スタンプ操作の詳細>
ユーザがディスプレイ104のスライドバーにタッチすることで図3のS25が開始する。以下、図3のS25のスタンプ操作の詳細について、図8を用いて説明する。なお、図8の各ステップは、CPUがスクリプト層のプログラムを用いて実行する処理である。
S701で、CPU100は、スタンプのオブジェクトパラメータのrotateの値を更新する。例えば、図12のスライドバー1204で設定した値に更新する(図12では180°)。S702で、CPU100は、オブジェクトパラメータを用いて、図7のS603で操作受付状態に設定されたスタンプを描画領域1206に再描画する。例えば、スタンプ画像の描画をHTMLのCanvasで行っている場合、CanvasのContextオブジェクトのrotateメソッドを利用することで、Canvas内の画像を回転することが可能である。
尚、この実施形態では、スタンプの操作は回転のみであるが、当然、拡大・縮小、平行移動等の他の操作も考えられる。また、写真画像に対してオブジェクトパラメータを持たせれば、スタンプ操作と同様の操作が可能となることも、明らかである。
<プリンタ設定の詳細>
ユーザが、図12に示したプリントボタン1205を押下することで図3のS26の処理が開始する。ここでは、図3のS26のプリンタ設定の詳細について、図9を用いて説明する。なお、S801、S807〜S809は、CPUがスクリプト層のプログラムを用いて実行する処理であり、S802〜S806、S810はCPUがネイティブ層のプログラムを用いて実行する処理である。
S801で、CPU100は、スクリプト層217からネイティブ層218へデバイス情報としてのプリンタ情報取得を依頼する。これは、プリンタ112と通信を行うためのスクリプト層217からの要求にあたる。依頼の方法は、画像選択時と同様に、バインディング機能によりスクリプトからネイティブ固有のAPIを呼び出す。ネイティブ層218には、スクリプト層217から直接呼び出せる関数もしくはその関数を間接的に呼び出す、いわゆる、ラッパが予め用意されている。例えば、GetPrinterInfoというネイティブ関数を用意しておき、スクリプト側からその関数を呼び出す。このように、ネイティブ層はスクリプトからの外部デバイスとの通信の要求を取得する。
通常、スクリプト層217からはセキュリティ上の制限で外部デバイスと直接通信することはできない。そのため、上記のように、スクリプト層217から、一旦、ネイティブ層218へ外部デバイス情報の取得を依頼し、ネイティブ層218を介して外部デバイスと通信を行う。ここで、ネイティブ層218は、OS層219を介して、外部デバイス(例えば、プリンタ112)と通信する機能を備えている。
S802で、CPU100は、プリンタ情報取得コマンドを送信する。例えば、Bonjour(登録商標)などのプロトコルにより、ブロードキャストやマルチキャスト等の方法を用いてプリンタ情報取得コマンドが送信される。S802の送信結果に対する応答がプリンタから返信される。S803で、CPU100は、プリンタからの応答を受信することでプリンタを検知する。そして、S804では、CPU100は応答のあったプリンタのIPアドレスを記憶する。例えば、同一無線LANルータで繋がっているプリンタを検出する。
S805で、CPU100は、応答のあったプリンタのIPアドレスへプリンタ情報の提供を要求する。応答のあったプリンタが複数の場合、CPU100は全てのプリンタに対して情報の提供を要求する。そのために、CPU100はネイティブ層で、プリンタの情報を取得するためのコマンドを生成する。そのコマンドとは、プリンタの動作を指定する命令であり、その一例としては、以下のようなXMLで表現される。
----------------------------------------------
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形式のテキストには記載されない。
1行目はヘッダであり、XML形式で記述していることを表している。
2行目のcmdはコマンドの開始を意味する。xmlnsで名前空間を指定し、コマンドの解釈の定義を指定している。尚、6行目の</cmd>でコマンドの終了を示している。
3行目は以後に内容を記載する宣言であり、5行目でその終了を示している。
4行目には要求する命令が記載されており、<operation>と</operation>の間に実際の命令文言が存在する。命令文言であるGetInformationは、外部デバイスであるプリンタの情報を取得する命令である。例えば、プリンタが対応している用紙種類、サイズ、縁なし印刷機能の有無、印刷品位、等のケーパビリティ情報を提供するよう要求する。
尚、プリンタ情報取得コマンドの生成は、例えば、ROM101に予め記憶した固定のテキストを読み込んでも構わない。また、XML等のテキスト形式に限らず、バイナリ形式で記述し、それに沿ったプロトコルで通信しても良い。また、生成したプリンタ情報取得コマンドは、HTTP等のプリンタが対応している通信プロトコルに従った形式で、プリンタ通信部213を介してプリンタ112へ送信される。
また、通信方法はこれに限定されるものではない。Wi−Fi(登録商標)ダイレクトやBluetooth(登録商標)、赤外線通信、電話回線、有線LAN、USBを用いた接続でも良く、その方法に沿ったプロトコルで通信を行えば同様の効果を得ることができる。
図9では、ネイティブ層218で、コマンドを生成する構成としているが、スクリプト層217で、コマンドを生成する構成でも、同様の効果が得られる。その場合、スクリプト層217で、例えば、上記のXML形式の命令文を含むコマンドを作成し、ネイティブ層218へ渡す。それを受けて、ネイティブ層218は、通信プロトコルに従った形式でプリンタ112へそのコマンドを送信する。
プリンタ112は、情報処理装置115からコマンドを受信すると、デバイス情報であるプリンタ情報をXML形式で通信プロトコルに沿って、情報処理装置115へ送信する。そして、S805では、ネイティブ層218がプリンタからプリンタ機能を取得する。以下に、プリンタの情報の一例を示す。
----------------------------------------------
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>
----------------------------------------------
1行目はヘッダであり、XML形式で記述していることを表している。2行目のcmdはコマンドの開始を意味する。xmlnsで名前空間を指定し、コマンドの解釈の定義を指定している。尚、最下行の</cmd>でコマンドの終了を示している。
3行目は以後に内容を記載する宣言であり、下の</contents>までその内容は継続する。4行目でデバイスIDを示している。ここでは、プリンタ112の機種名が「Printer001」であることを表している。5行目以降はプリンタ112が有する各モードについての記述である。<mode>から</mode>までで、1つのモードにおける情報が記述されている。5行目では、モードの番号が1である。以降の<media>は印刷用紙の種類、<size>は用紙サイズ、<quality>は印刷品位、<border>は縁あり/なしの情報をそれぞれ記述している。
11行目以降は他のモードであるモード2についての情報が記述されている。このように、プリンタ112の機種名と、そのプリンタが対応している全てのモードがこのXMLに記述されている。
尚、プリンタ情報の記述方法はこれに限定されることはなく、タグ形式でないテキストや、バイナリ形式等の他の形式であっても構わない。また、上記の例ではプリンタの印刷機能の情報を受け渡ししているが、それに限定される事ではない。例えば、プリンタが処理可能な画像処理や解析処理、静かに印刷するモードの有無、メモリカードの利用有無、インク残量などのステータスなどの情報が受け渡されても良い。画像処理の例としては、モノクロやセピア、彩度強調などの色変換、複数画像のレイアウト、ホワイトバランス補正、ノイズ除去、その他自動で写真を好ましい色や輝度に補正する処理などが挙げられる。
S805で、CPU100は、プリンタ112からプリンタ情報を受信する。CPU100は、ネイティブ層で、受信したプリンタ情報から、例えば、プリンタ112が有する全てのモードにおける印刷用紙の種類、サイズ、印刷品位、縁あり/なしの項目と項目数等を含むプリンタ機能一覧を取得する。
S806で、CPU100は、受信したプリンタ情報をスクリプト層217が解釈可能な形式に変換して、スクリプト層217へ送信する。つまり、CPU100はプリンタ112との通信によって得られた情報をスクリプト層217へ渡す。具体的には、受け取ったXML形式のプリンタ情報で送信したり、タグなしのテキスト形式に変えて送信する等の方法がある。加えて、スクリプト層217から特定のネイティブ関数を呼び出す毎に、その戻り値として情報を取得しても良い。また、ネイティブ関数に取得するモードなどの引数を渡し、その戻り値として情報を得ても良い。さらに、上述のJSON文字列を用いた受け渡しや、データ変換部207及び203を用いてBASE64等の文字列で受け渡しを行ってもよい。
S807で、CPU100は、ネイティブ層218から受信したプリンタ情報に基づいて、プリンタ112で利用できる機能を含む設定画面(図13)を形成し、表示する。これを、この実施形態では、表示制御と呼ぶ。ここで、接続可能なプリンタが複数ある場合は、プリンタ名を表示し、ユーザに印刷するプリンタを選択させるための表示画面を生成する(表示内容を制御する)。尚、プリンタの選択は、上記に限らず、一番早く応答してきたプリンタや、より機能が多いプリンタ、印刷ジョブが混雑していないプリンタを選択する、等の方法も考えられる。
このように、CPU100は、印刷用紙の種類・サイズ、印刷品位、縁あり/なし等のプリンタで利用できる機能を選択させる設定画面1301(図13)を表示する。設定画面の形成方法の一例として、以下に、HTML記述のサンプルを示す。
------------------------------------------------
<!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[i] = new Option(GetMediaTypeT(j), GetMediaTypeV(j));
}

<!-- 印刷品位 -->
var QualityNum = GetQualityNum();
var q = document.getElementById("QualityList");
var k;
for(k=0; k< QualityNum; k++){
q.options[i] = new Option(GetQualityT(k), GetQualityV(k));
}

<!-- 縁あり/なし-->
var BorderNum = GetBorderNum();
var b = document.getElementById("BorderList");
var l;
for(l=0; l<BorderNum; l++){
b.options[i] = new Option(GetBorderT(l), GetBorderV(l));
}

<!-- 印刷関数-->
function printer() {
SetPrint(document.getElementById("PaperList").value,
document.getElementById("MediaList").value,
document.getElementById("QualityList").value,
document.getElementById("BorderList").value);
}
</script>
</head>

<!-- 表示部 -->
<body>
用紙サイズ <select id="PaperList"></select><br />
用紙種類 <select id="MediaList"></select><br />
印刷品位 <select id="QualityList"></select><br />
縁あり/なし <select id="BorderList"></select><br />
<br />

<button id="btn1" onclick="printer()">設定完了</button>
</body>
</html>
------------------------------------------------
上記のGetPaperSizeNum( )、GetMediaTypeNum( )、GetQualityNum( )、GetBorderNum( )はネイティブ関数であり、それぞれの項目数を取得する機能を備える。例えば、プリンタが対応している用紙サイズがA4、A5、B5、L判の4種類である場合、GetPaperSizeNum( )は4を返す。
GetPaperSizeT(n)、GetMediaTypeT(n)、GetQualityT(n)、GetBorderT(n)もネイティブ関数であり、引数nの値番目の文字列を返す。例えば、用紙サイズのテキストを返す関数のGetPaperSize(0)の返り値は「A4」、GetPaperSize(1)の返り値は「A5」となる。これらの値は、プリンタから受信するプリンタ情報からネイティブ関数が取り出す。
また、GetPaperSizeV(n)、GetMediaTypeV(n)、GetQualityV(n)、GetBorderV(n)もネイティブ関数であり、引数nの値番目の値を返す。例えば、用紙種類のテキストを返す関数のGetMediaTypeT(0)の返り値は「光沢紙」のように、表示してユーザに示す文言である。これに対して、GetPaperTypeV(0)の返り値は「GlossyPaper」と、プリンタが解釈できる文言となっている。これらの文言は、プリンタから送られてきた情報と結び付けてネイティブが決定する。例えば、プリンタから送られてきた情報より取り出した値が「GlossyPaper」であった場合、表示するテキストは「光沢紙」と決定する。決定の方法として、ネイティブはこれらの対応表を予め保持しておき、その対応表に沿ってテキストを決定すれば良い。
尚、上記では、例として、用紙サイズ、用紙種類、印刷品位、縁あり/なしの設定を行う仕様であるが、これに限定されるものではない。他の例として、両面/片面、カラー/モノクロ、画像補正のオン/オフ等の他の設定項目が挙げられることは言うまでもない。また、印刷機能のみではなく、プリンタが処理可能な画像処理や解析処理、サイレントモードの有無、メモリカードの利用有無、インク残量等のステータス等の情報を表示しても良い。
S808で、CPU100は、設定画面1301に対するユーザ操作に基づいて、プリンタに設定する機能を選択する。上記の例で示したHTMLを、レンダリング部216を用いてディスプレイ104に表示した例が図13に示す1301である。ネイティブ層218を介してプリンタ情報を要求し、プリンタ情報から上記のネイティブ関数を用いて取得した情報を基に設定画面1301が形成されている。尚、上記HTMLはスクリプト層217、ネイティブ層218のいずれで形成しても良い。
また、図13に示す用紙サイズ等の設定項目はそれぞれプルダウンメニューになっており、ユーザ操作によって項目を選択する事ができる。ここで、設定画面1301は、プルダウンメニューによって、用紙サイズの設定項目として選択可能な項目の一覧が表示されている状態を示しており、ユーザ操作によってA4やA5等の用紙サイズを選択することができる。
S809で、CPU100は、設定完了ボタン1302に対するユーザ操作を検知すると、ユーザ操作によって選択された設定項目を含む設定情報を作成して、ネイティブ層218へ送信する。上記HTML記述の例にあるSetPrint( )もバインディング機能を有するネイティブ関数である。上記の例では、SetPrint( )を用いて、用紙サイズ、用紙種類、印刷品位、縁あり/なしの設定を文字列としてネイティブ層218へ渡している。
S810で、CPU100は、バインディング機能によりスクリプト層217から設定情報を受信する。ネイティブ層218では、後に、受信した設定情報、印刷対象の画像データ、さらにはスタンプの画像データとを基に、プリンタ112の通信プロトコルに従って、プリントコマンドを生成する。そして、プリンタコマンドがプリンタ通信部213を介してプリンタ112へ送信されることになる。
<レンダリングの詳細>
ユーザが、図13に示した設定画面1301の設定完了ボタン1302を押下することで図3のS27のレンダリング処理が開始する。この実施形態では、印刷用のレンダリング処理は図2に示したネイティブ層に設けられたインタプリタ221で実行される。なお、インタプリタ(第2のインタプリタ)221も、OS層219に設けられたインタプリタ(第1のインタプリタ)214と同様、ウェブ標準言語を翻訳し、描画・実行できるプログラムモジュールである。
ここでは、図3のS27のレンダリングの詳細について、図10を用いて説明する。なお、S901〜S903、S908は、CPUがスクリプト層のプログラムを用いて実行する処理であり、S904〜S907はCPUがネイティブ層のプログラムを用いて実行する処理である。さらになお、詳細に説明すると、図10のS904〜S906はインタプリタ221で実行される。
まず、S901では、CPU100は、インジケータを起動する。ここで、インジケータとはアプリケーション内部でなんらかの処理が進行中であることを示すUI(ユーザインタフェース)表示のことである。例えば、プログレスバーなどがそれに相当する。レンダリング処理には通常、数秒から数10秒の時間がかかることが考えられるため、このようなインジケータの表示は必須である。
次に、S902では、ユーザがS808で選択した用紙種別情報と、「GetInformation」で取得した「ResolutionX」の値と「ResolutionY」の値とから、レンダリングに必要な解像度情報を算出する。例えば、このアプリケーションにおいては、スクリプト層217で、以下のような対応表を保持しているものとする。
<表1>
・−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−・
|用紙サイズ| PaperH[mm] | PaperW[mm] |
・−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−・
| 4×6 | 101.6 | 152.4 |
・−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−・
| A4 | 297 | 210 |
・−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−・
| L判 | 89 | 127 |
・−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−・
表1において、PaperHは用紙の高さ、PaperWは用紙幅を示している。レンダリングに必要な解像度情報ResXおよびResY(単位は画素)は、以下の式によって算出することができる。即ち、
ResX=PaperH/25.4×ResolutionX
ResY=PaperW/25.4×ResolutionY
である。
S902で上記値の算出が終了後、S903では、CPU100はネイティブ層218で用意されているインタプリタ221のAPIをバインド機能によって呼び出し、そのAPIに必要な情報を伝達する。必要な情報とは、具体的には、算出した解像度情報と、さらに、印刷コンテンツを描画したスクリプト情報(Canvasによる記述情報)を伝達する。
S904では、CPU100はネイティブ層218のインタプリタ221でのレンダリング処理に必要な画像領域のRAM102に確保する。確保すべきメモリのサイズMは、以下の通りである。即ち、
M=ResX×ResY×要素数[バイト]
である。上式において要素数は、1画素あたりの色成分の数であり、通常はRGB成分を保持するため3となる。
S905では、CPU100は印刷コンテンツの描画情報を必要解像度に変換するための、拡大率(ExpX,ExpY)を次式によって算出する。即ち、
ExpX=ResX/CanX
ExpY=ResY/CanY
を用いて算出する。上式において、CanXおよびCanYは、元々表示のために用意されたCanvasエリアのサイズ(単位は画素)を示している。
拡大率の算出後、その値を用いて、S905では、CPU100は描画情報のスケーリングを行う。具体的には、CanvasのContextに用意されているscale関数を用いてスケーリングを行う。
S906では、CPU100はそのスケーリング処理を実行し、その結果、S904で確保したRAM102の領域内に、描画情報を解釈して拡大レンダリングを行う。このようにして画像情報をRGB各成分の画素値として得ることができる。
レンダリング処理に成功したら、S907では、CPU100は、インジケータの停止依頼をスクリプト層217に発行する。
S908で、CPU100は、スクリプト層217で、インジケータを停止して、ディスプレイ104の表示から消去する。
<プリントの詳細>
図3のS28ではレンダリングした後の画像データを用いてプリント処理を実行する。実際には、図10のS906の処理が終了し次第、S28の処理が開始される。ここでは、図3のS28のプリントの詳細について、図11を用いて説明する。なお、図11の各ステップは、CPUがネイティブ層のプログラムを用いて実行する処理である。
S1001で、CPU100は、S906でレンダリングされた画像情報(RGB値)を基に、そのRGB値をプリンタ112で利用可能な形式に変換する。プリンタが利用可能な形式は、RGBやJPEG、CMYKに加え、PDF等のプリンタベンダーの独自フォーマット等もある。ここではそれらのうち、どのような形式であっても構わない。
S1002で、CPU100は、前記設定情報とS1001で変換された画像データを基に、プリンタ112へ送信するコマンドを生成する。S1003で、CPU100は、プリンタの利用できる通信プロトコルに則り、S1002で生成したコマンドを、S804で記憶したIPアドレスに対応するプリンタ112に対し、プリンタ通信部213を利用して送信する。
S1004で、プリンタ112は、情報処理装置115から受信したコマンドに従って、プリントを実行する。
従って以上説明した実施形態によれば、アプリケーションのUIおよび印刷コンテンツの描画・表示用のレンダリング処理は、通常通りOSが提供する第1のインタプリタを利用する。一方、印刷用レンダリング処理は、OSが提供するものとは別の第2のインタプリタを利用する。第2のインタプリタはネイティブ層で動作し、そこから出力された高解像度画像データ(ビットマップデータ)は、テキストデータに変換されることなくプリンタに送出される。そのため、高解像度画像データ(ビットマップデータ)をBase64データに変換するために必要な時間を節約し高速に処理を行うことが可能となる。
また、その画像データは、ネイティブ層から直接プリンタに送信されるため、OSの構成に起因するメモリ不足を回避することもできる。
なお、加えて、上記実施形態では、コンテンツ(写真画像やスタンプ画像)の描画として、JavaScriptのCanvas機能で例に挙げて説明しているが、コンテンツの描画は、これに限定されるものではない。例えば、SVG(Scalable Vector Graphics)を利用して、コンテンツを描画することも可能である。この場合、インタプリタ221はSVGを解釈するインタプリタとなるが、本発明の目的を同様に実現することが可能である。また、SVGに関する詳細な説明は、先行文献が多数存在するため、ここでは割愛する。
また、以上説明した実施形態では、アプリケーションを起動した最初にプリンタを選択するとして説明したが、本発明はこれに限定されるものではない。例えば、印刷設定を行う過程において、プリンタを設定し、そのプリンタにXMLによる情報取得コマンドを送信するようにしてもよい。
さらに、表1で示したような情報は、アプリケーション内部に予め保持されていてもよいし、プリンタ本体に含まれており、それを「GetInformation」コマンドで取得するようにしてもよい。或いは、その情報が図1で示したようなサーバ114に保持されており、アプリケーションが起動した際に、そのサーバからウェブの標準的な通信プロトコルに従って表1に示したような情報を取得するようにしてもよい。
またさらに、以上説明した実施形態では、スクリプト層の命令を翻訳・実行するためのインタプリタを2つ備えた例を示したが、本発明はこれに限定されるものではない。例えば、UIに使用する言語や、印刷の目的に応じて、ネイティブ層218の内部で複数個のインタプリタを備え、これらを利用するようにしてもよい。
<他の実施形態>
以上説明した実施形態では、情報処理装置に実装されるOSを特定して説明したものではなかったが、ここでは、特定のOS、即ち、Android(登録商標)OSが実装された場合について説明する。
図16は、Android(登録商標)OSが動作する情報処理装置のソフトウェア構成を示すブロック図である。なお、図16において、図2で説明したのと同じ構成要素については同じ参照番号を付し、その説明は省略する。ここでは、AndroidOS特有の構成に関して説明する。
図16に示すように、AndroidOSではスクリプト層217とOS層219との間に、ネイティブ層218に加えて、Java(登録商標)で構成されているプログラム層(以下、Java層)222が設けられる。また、ネイティブ層218はもともとC/C++言語で記述されたプログラムコードを、Native Delevopment Kit(登録商標)(=NDK)により機械語に翻訳された層となる。
このようなソフトウェア構成では、図16に示すように、コンテンツ描画部205で描画されたコンテンツは、Java層222を経由してインタプリタ214に入力され、インタプリタ214により解釈され、描画される。本願の課題の項で指摘したように、印刷用レンダリングをOS層に設けられたインタプリタで行う場合、そのレンダリングにより得られた画像データをBase64形式でJava層222が取得し、これを画像データに変換してプリンタに送信する必要がある。
しかしながら、一般的には、Java層222で取り扱い可能なメモリの総量は、NDKを用いたネイティブ層218に比べ小さく制限されている。このため、OS層のインタプリタ214で印刷用の大容量の高解像度画像データを生成し、Java層222でこれを抽出すると、Java層222でメモリ不足が発生する可能性が高い。
このため、この実施形態では、そのようなコンテンツの印刷に関しては、図16に示すように、コンテンツの描画スクリプトを、ネイティブ層218に備えられたインタプリタ221に入力し、そこで印刷用の高解像度画像データを生成するようにしている。その結果、生成された画像データは前述の実施形態と同様、データ変換部203で所望のデータ形式に変換され、プリンタ通信部213を介してプリンタ112に送信される。
従って、以上説明した実施形態によれば、特定のOS(AndroidOS)を実装した情報処理装置でも、画像データはネイティブ層から直接プリンタに送信されるため、OSの構成に起因した、Java層におけるメモリ不足を回避することができる。
<さらに別の実施形態>
前述の実施形態では、印刷用のレンダリング処理を行う際に、ネイティブ層に設けられたスクリプトを利用する例について説明したが、ここでは、このスクリプトを印刷プレビュー表示に利用する場合について説明する。
図3を参照して説明したように、ユーザは、S21〜S25で印刷コンテンツを描画後、S26で印刷設定を行うが、印刷プレビューの場合、図17に示すようなUIの設定画面から印刷プレビューを行うことができる。図17に示されているように、この設定画面にはプレビューボタン1701が設けられている。この設定画面で、ユーザがそのボタンを押す又はタッチすると、スクリプト層217で描画されている印刷コンテンツ情報とユーザが選択した用紙等の印刷設定情報がスクリプト層217に入力され、印刷用レンダリングが実行される。
その印刷用レンダリングにより得られた結果は、Base64形式のテキストデータに変換されて、スクリプト層217に渡される。その結果、図18に示すようなプレビュー画面に印刷プレビューが表示される。図18に示すプレビュー画面には、レンダリング結果を描画するエリア(プレビューエリア)1801と、その表示内容の拡大を指示できるスライドバー1802とが設けられている。
従って上記のような構成により、印刷用のレンダリングと印刷プレビュー用のレンダリングを、同じインタプリタを用いて行うことができる。このような構成により、印刷用と印刷プレビュー用のレンダリングを実行するインタプリタが別々である場合と比べ、印刷コンテンツの内容によってはインタプリタ間の微小な差異が発生し、印刷結果とプレビューが一致しない問題を回避することができる。なお、本願では出力処理の一例として印刷と表示を記載したが、その他の出力処理として送信処理が実行されても良い。
また、図1で示した情報処理装置の例は、携帯可能なモバイルコンピュータを想定したハードウェアとなっているが、本発明はそれに限定されない。例えば、据え置き型のパーソナルコンピュータやゲーム機等のハードウェア上においても、同様の構成を実現することは可能である。
加えて、上記実施形態のプリンタは、インクジェットプリンタ、レーザープリンタ、昇華型プリンタ、ドットインパクトプリンタ等を利用することができる。これらには、プリンタ機能、スキャナ機能等を有する、単一機能ではない、いわゆる、複合機(マルチファンクションプリンタ)の場合もある。
尚、以上の実施形態の機能は以下の構成によっても実現することができる。つまり、本実施形態の処理を行うためのプログラムコードをシステムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ(またはCPUやMPU)がプログラムコードを実行することによっても達成される。この場合、記憶媒体から読み出されたプログラムコード自体が上述した実施形態の機能を実現することとなり、またそのプログラムコードを記憶した記憶媒体も本実施形態の機能を実現することになる。
また、本実施形態の機能を実現するためのプログラムコードを、1つのコンピュータ(CPU、MPU)で実行する場合であってもよいし、複数のコンピュータが協働することによって実行する場合であってもよい。さらに、プログラムコードをコンピュータが実行する場合であってもよいし、プログラムコードの機能を実現するための回路等のハードウェアを設けてもよい。またはプログラムコードの一部をハードウェアで実現し、残りの部分をコンピュータが実行する場合であってもよい。
201:画像取得部、202:画像読込部、203:データ変換部、
204:データ保持部、205:コンテンツ描画部、206:画像処理制御部、
207:データ変換部、208:画像処理部、210:コンテンツ操作部、
211:プリンタ制御部、212:プリンタデータ生成部、213:プリンタ通信部、
214、221:インタプリタ、215:画像データ群、216:レンダリング部、
217:スクリプト層、218:ネイティブ層、219:OS層、220:データ保存部

Claims (14)

  1. 第1の言語で記述され第1形式のデータに基づき表示処理を行う第1のプログラム層と、前記第1の言語とは異なる第2の言語で記述され前記第1形式のデータとは異なる第2形式のデータに基づく印刷データの生成処理を行う第2のプログラム層とを包含するプログラムおよび前記表示処理に関わる出力コンテンツに対して翻訳処理を行う第1の翻訳手段を含むオペレーティングシステムが動作可能な情報処理装置であって、
    前記第1のプログラム層において画像データを選択する選択指示を受け付けた場合、前記選択された画像データに対応する前記第2形式のデータを前記第1形式のデータに変換して前記第1のプログラム層に送信する変換制御手段と、
    前記第1のプログラム層において印刷指示を受け付けた場合、印刷処理に関わる出力コンテンツを解釈して印刷用の画像データを生成する第2の翻訳手段と、
    前記画像データに基づいて印刷データを生成する生成処理を実行する生成手段とを有し、
    前記第1の翻訳手段は、前記表示処理に関わる出力コンテンツである前記第1形式のデータを前記第1のプログラム層から受信して、前記第1形式のデータに基づく画像を表示装置に表示させ、
    前記第1のプログラム層において印刷指示を受け付けた場合、前記変換制御手段により前記画像データが前記第1形式のデータに変換されることなく前記生成処理が実行され、
    前記変換制御手段と前記第2の翻訳手段と前記生成手段は、前記第2のプログラム層に含まれることを特徴とする情報処理装置。
  2. 前記第1形式のデータはBASE64データであり、前記第2形式のデータはRGB画像であることを特徴とする請求項1に記載の情報処理装置。
  3. 前記第1のプログラム層と印刷装置との通信を、前記第2のプログラム層を介して行う通信手段をさらに有し、
    前記第2の翻訳手段は、前記通信手段を介して接続する前記印刷装置に関する情報に基づいて、前記印刷用の画像データを生成することを特徴とする請求項1又は2に記載の情報処理装置。
  4. 前記第1のプログラム層はインジケータを起動し、
    前記第2のプログラム層は、前記画像データの生成が完了した場合、前記第1のプログラム層にインジケータの停止を依頼することを特徴とする請求項1乃至3のいずれか1項に記載の情報処理装置。
  5. 前記通信手段は、前記印刷装置から解像度情報を取得し、
    前記第2の翻訳手段は、該取得した解像度情報を用いてレンダリングの解像度を算出し、該レンダリングの解像度に応じた画像データを格納するための領域をメモリに確保し、該領域に、前記領域を用いてレンダリング処理を実行することで前記画像データを生成することを特徴とする請求項に記載の情報処理装置。
  6. 表示用の前記出力コンテンツはCanvasを用いて記述されることを特徴とする請求項1乃至5のいずれか1項に記載の情報処理装置。
  7. 表示用の前記出力コンテンツは、Scalable Vector Graphics(SVGを用いて記述されることを特徴とする請求項1乃至5のいずれか1項に記載の情報処理装置。
  8. 前記オペレーティングシステムはAndroidOSであり、
    前記オペレーティングシステムと前記第1のプログラム層との間には、Java層が設けられていることを特徴とする請求項1乃至7のいずれか1項に記載の情報処理装置。
  9. 前記第1の言語は、HTML5、JavaScriptのいずれかを含むことを特徴とする請求項1乃至のいずれか1項に記載の情報処理装置。
  10. 前記第2の言語は、CもしくはC++であることを特徴とする請求項1乃至のいずれか1項に記載の情報処理装置。
  11. 前記第2のプログラム層は、前記第1のプログラム層および前記第2のプログラム層を含むプログラムの実行環境以外で予め翻訳された命令セットが記述されているプログラム層であることを特徴とする請求項1乃至10のいずれか1項に記載の情報処理装置。
  12. 前記第1のプログラム層は、前記第1のプログラム層および前記第2のプログラム層を含むプログラムの実行環境に存在するプロセッサを用いて翻訳および実行される命令セットが記述されているプログラム層であることを特徴とする請求項1乃至11のいずれか1項に記載の情報処理装置。
  13. 第1の言語で記述され第1形式のデータに基づき表示処理を行う第1のプログラム層と、前記第1の言語とは異なる第2の言語で記述され前記第1形式のデータとは異なる第2形式のデータに基づく印刷データの生成処理を行う第2のプログラム層とを包含するプログラムと前記表示処理に関わる出力コンテンツに対して翻訳処理を行う機能を含むオペレーティングシステムをプロセッサで実行する情報処理方法であって、
    前記第1のプログラム層において画像データを選択する選択指示を受け付けた場合、前記選択された画像データに対応する前記第2形式のデータを前記第1形式のデータに変換して前記第1のプログラム層に送信する変換工程と、
    前記第1のプログラム層において印刷指示を受け付けた場合、印刷処理に関わる出力コンテンツを解釈して印刷用の画像データを生成する第1の生成工程と、
    前記画像データに基づいて印刷データを生成する生成処理を実行する第2の生成工程と有し、
    前記翻訳処理を行う機能の実行により、前記表示処理に関わる出力コンテンツである前記第1形式のデータを前記第1のプログラム層から受信して、前記第1形式のデータに基づく画像を表示装置に表示させ、
    前記第1のプログラム層において印刷指示を受け付けた場合、前記変換工程において前記画像データが前記第1形式のデータに変換されることなく前記生成処理が実行され、
    前記変換工程と前記第1の生成工程と前記第2の生成工程の実行は、前記第2のプログラム層の実行に含まれることを特徴とする情報処理方法。
  14. コンピュータを、請求項1乃至12のいずれか1項に記載の情報処理装置の各手段として機能させるためのプログラム。
JP2014122750A 2014-06-13 2014-06-13 情報処理装置、情報処理方法、及びプログラム Active JP6478487B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2014122750A JP6478487B2 (ja) 2014-06-13 2014-06-13 情報処理装置、情報処理方法、及びプログラム
US14/728,265 US9769335B2 (en) 2014-06-13 2015-06-02 Information processing apparatus, information processing method, and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2014122750A JP6478487B2 (ja) 2014-06-13 2014-06-13 情報処理装置、情報処理方法、及びプログラム

Publications (3)

Publication Number Publication Date
JP2016004320A JP2016004320A (ja) 2016-01-12
JP2016004320A5 JP2016004320A5 (ja) 2017-10-26
JP6478487B2 true JP6478487B2 (ja) 2019-03-06

Family

ID=54837207

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014122750A Active JP6478487B2 (ja) 2014-06-13 2014-06-13 情報処理装置、情報処理方法、及びプログラム

Country Status (2)

Country Link
US (1) US9769335B2 (ja)
JP (1) JP6478487B2 (ja)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9325676B2 (en) 2012-05-24 2016-04-26 Ip Ghoster, Inc. Systems and methods for protecting communications between nodes
US10778659B2 (en) 2012-05-24 2020-09-15 Smart Security Systems Llc System and method for protecting communications
JP6378645B2 (ja) 2014-06-13 2018-08-22 キヤノン株式会社 情報処理装置、制御方法、及びプログラム
JP6138088B2 (ja) 2014-06-30 2017-05-31 キヤノン株式会社 情報処理装置、制御方法、及びソフトウェアプログラム
JP6363888B2 (ja) 2014-06-30 2018-07-25 キヤノン株式会社 情報処理装置、およびプログラム
JP6463914B2 (ja) 2014-06-30 2019-02-06 キヤノン株式会社 情報処理装置、処理方法、及びプログラム
JP6649832B2 (ja) 2016-03-30 2020-02-19 キヤノン株式会社 情報処理装置およびその制御方法、並びにプログラム
JP6799396B2 (ja) 2016-07-01 2020-12-16 キヤノン株式会社 情報処理装置、情報処理方法およびプログラム
JP6786342B2 (ja) 2016-10-18 2020-11-18 キヤノン株式会社 情報処理装置、情報処理方法およびプログラム
US11194930B2 (en) 2018-04-27 2021-12-07 Datatrendz, Llc Unobtrusive systems and methods for collecting, processing and securing information transmitted over a network
CN112527374A (zh) 2020-12-11 2021-03-19 北京百度网讯科技有限公司 标注工具生成方法、标注方法、装置、设备以及存储介质

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3855149B2 (ja) * 2000-03-21 2006-12-06 富士写真フイルム株式会社 画像送信装置及びプリントシステム
US8713295B2 (en) * 2004-07-12 2014-04-29 Oracle International Corporation Fabric-backplane enterprise servers with pluggable I/O sub-system
JP4405942B2 (ja) 2005-06-14 2010-01-27 キヤノン株式会社 画像処理装置およびその方法
JP5127592B2 (ja) 2008-06-25 2013-01-23 キヤノン株式会社 画像処理装置および画像処理方法、プログラム並びに、コンピュータ読み取り可能な記録媒体
JP5300595B2 (ja) 2009-05-28 2013-09-25 キヤノン株式会社 画像処理装置及び方法、及びコンピュータプログラム
US20110154026A1 (en) * 2009-12-23 2011-06-23 Christofer Edstrom Systems and methods for parallel processing of ocsp requests during ssl handshake
KR101350661B1 (ko) 2011-09-30 2014-01-10 엔에이치엔엔터테인먼트 주식회사 웹 기술을 이용한 하이브리드 어플리케이션 구동 장치 및 방법
US9325676B2 (en) * 2012-05-24 2016-04-26 Ip Ghoster, Inc. Systems and methods for protecting communications between nodes
JP5312642B2 (ja) * 2012-06-01 2013-10-09 キヤノン株式会社 画像処理装置、画像処理装置の制御方法及びプログラム
US9910833B2 (en) * 2012-11-13 2018-03-06 International Business Machines Corporation Automatically rendering web and/or hybrid applications natively in parallel

Also Published As

Publication number Publication date
US9769335B2 (en) 2017-09-19
US20150365546A1 (en) 2015-12-17
JP2016004320A (ja) 2016-01-12

Similar Documents

Publication Publication Date Title
JP6478487B2 (ja) 情報処理装置、情報処理方法、及びプログラム
JP6378645B2 (ja) 情報処理装置、制御方法、及びプログラム
JP6386803B2 (ja) 装置、方法、及びプログラム
JP6381319B2 (ja) 情報処理装置、処理方法、及びプログラム
JP6138088B2 (ja) 情報処理装置、制御方法、及びソフトウェアプログラム
JP5901704B2 (ja) 情報処理装置、情報処理方法、プログラム
JP6363888B2 (ja) 情報処理装置、およびプログラム
JP6525517B2 (ja) 情報処理装置、制御方法、及びプログラム
JP6463914B2 (ja) 情報処理装置、処理方法、及びプログラム
JP6438218B2 (ja) 装置、方法、及びプログラム
JP6008897B2 (ja) 装置、方法、及びプログラム
JP6360370B2 (ja) 情報処理装置、情報処理方法、およびプログラム
JP6757368B2 (ja) 情報処理装置、処理方法、及びプログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20170613

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170914

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20180412

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180604

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180730

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20190108

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20190205

R151 Written notification of patent or utility model registration

Ref document number: 6478487

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151