JP2014164742A - 画像形成装置、画像形成装置の制御方法、及びプログラム - Google Patents

Abstract

【課題】アプリケーションが保有する画面レイアウト情報のユーザによる解析や、画像形成装置へのユーザによるレイアウト設定等の煩雑な作業を必要とせず、対応する各種画面サイズの端末がなくても、手間無く容易に、アプリケーションがサポートする複数の画面サイズの画面イメージを全て確認可能にすること。
【解決手段】画像形成装置１０１が、画面サイズの異なる複数の端末上で動作可能なアプリケーションの画面サイズごとの画面レイアウトを定義した画面レイアウト情報を複数含むアプリケーションデータを受信し（Ｓ２００２）、前記複数の画面レイアウト情報に基づいて画面サイズの異なる複数のアプリケーション画面の画面イメージをページ上にレイアウトし（Ｓ２００３〜Ｓ２００４）、レイアウトに従って前記画面サイズの異なる複数の画面のイメージを印刷する（Ｓ２００５）。
【選択図】図１２

Description

本発明は、複数種類の携帯端末上で動作するモバイルアプリケーションの画面レイアウトを印刷する技術に関するものである。

近年、携帯端末からの印刷技術の開発が進んでいる。携帯端末からの印刷において、携帯端末の表示内容をユーザの所望するレイアウトに変換して印刷する技術として、特許文献１が知られている。特許文献１では、予めユーザが所望するレイアウト情報を印刷装置内に保持しておき、テレビやデジタルカメラで表示した静止画像を印刷する際に、該レイアウト情報を用いてレイアウト処理を行う。その結果、携帯端末での表示と異なる、ユーザの所望するレイアウトに変換した印刷結果を得ることが出来る。

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

近年、携帯端末の高性能化が進み、パソコンの機能をベースとして作られた多機能携帯電話（スマートフォン）や、タブレット端末が開発され、携帯端末上で様々な機能が利用できるようになってきている。これら様々な機能は、機能単位でモバイルアプリケーション（以下アプリ）として分割され、ユーザに提供される。携帯端末で動作するアプリの中には、複数の携帯端末と連動したサービスを提供するものもあり、複数端末間で同期を行い、通信対戦を可能とするゲームアプリや、各端末上に保持している静止画、ドキュメントを共有するファイル共有アプリなどがある。

しかし、携帯端末には、様々な画面サイズ、解像度を持つものがあるため、このような複数の携帯端末で動作するアプリは、各端末画面に最適化したユーザインタフェースを表示する必要がある。そのため、アプリは様々な端末画面における画面レイアウト情報を複数保持しており、その中から、アプリ起動時に各端末における最適な画面レイアウト情報を読み込むことで、画面サイズの問題を解決している。

基本的に特定の携帯端末においては、その携帯端末用に選択された画面レイアウト情報以外の画面レイアウト情報を、その携帯端末で使用することはできない。よって、コンテンツデザイナー等が、複数の携帯端末で動作するアプリのコンテンツを、特定の携帯端末上で編集した場合、その編集内容をアプリが保有する全ての画面レイアウト情報に反映した結果を、その携帯端末のみで確認することができず、不便であった。特許文献１の技術を用いてこの問題を解決する場合、ユーザがアプリのサポートする画面レイアウト情報を全て解析し、ユーザが印刷装置にレイアウト情報を設定して印刷することで、反映結果を確認する、といった方法が考えられる。

しかし、アプリがサポートする画面レイアウト情報は、アプリにより様々であり、かつ、解析するための分析環境も必要とされるため、一般的なユーザには現実的ではない。また、そのアプリの画面レイアウト情報に応じて印刷装置へ、都度レイアウト情報を設定することも手間が増え、ユーザビリティの観点からも望ましくない、という課題があった。

本発明は、上記の問題点を解決するためになされたものである。本発明の目的は、ユーザによる煩雑な作業を必要とせず、対応する各種画面サイズの端末がなくても、手間無く容易に、アプリケーションがサポートする複数の画面サイズの画面イメージを全て確認することができる仕組みを提供することである。

本発明は、画像形成装置であって、画面サイズの異なる複数の端末上で動作可能なアプリケーションの画面サイズごとの画面レイアウトを定義した画面レイアウト情報を複数含むアプリケーションデータを受信する受信手段と、前記複数の画面レイアウト情報に基づいて画面サイズの異なる複数のアプリケーション画面の画面イメージをページ上にレイアウトするレイアウト手段と、前記レイアウト手段によるレイアウトに従って前記画面サイズの異なる複数の画面のイメージを印刷する印刷手段と、を有することを特徴とする。

本発明によれば、ユーザによる煩雑な作業を必要とせず、対応する各種画面サイズの端末がなくても、手間無く容易に、アプリケーションがサポートする複数の画面サイズの画面イメージを全て確認することができる。

本発明の一実施例を示すシステム構成図。 画像形成装置のハードウェアブロック図。 携帯端末のハードウェアブロック図。 画像形成装置のソフトウェアモジュール図 アプリデータの内部構成図。 使用される修飾子のｄｐと推奨用紙サイズの対応表。 画面レイアウト情報の構成図（ランドスケープ）。 画面レイアウト情報の構成図（ポートレート）。 印刷要求時のＵＩ画面。 レイアウト情報テーブル。 携帯端末での画面レイアウト印刷要求処理のフローチャート。 画像形成装置での画面レイアウト印刷処理のフローチャート。 実施例１の画像形成装置でのアプリデータ受信処理のフローチャート。 画像形成装置でのレイアウト情報解釈処理のフローチャート。 レイアウト遷移図。 レイアウト遷移図。 画像形成装置でのレイアウト処理のフローチャート。 画像形成装置での用紙サイズ設定処理のフローチャート。 実施例２の画像形成装置でのアプリデータ受信処理のフローチャート。

以下、本発明を実施するための形態について図面を用いて説明する。

＜システム構成図＞
図１は、本発明の一実施例を示すシステムの構成を示す図である。
本実施例に係るシステムは、画像形成装置１０１、携帯端末１０２、コンテンツサーバ１０３を有する。画像形成装置１０１、携帯端末１０２、コンテンツサーバ１０３はそれぞれ、ネットワーク１０４で通信可能に接続されている。

画像形成装置１０１は、例えば、スキャン、ＦＡＸ、プリント、コピーなどの様々な機能を有する複合機（ＭＦＰ；Multifunction Peripheral）、またはプリント機能のみを有するプリンタである。

携帯端末１０２は、画像形成装置１０１へ印刷指示を行うことができる。また、携帯端末１０２は、コンテンツサーバ１０３にアクセスして、様々なモバイルアプリケーション（以下アプリ）をダウンロードすることができる。また、携帯端末１０２は、そのアプリで編集したアプリコンテンツをコンテンツサーバ１０３へアップロードすることも可能である。なお、携帯端末１０２は、電子黒板のような画面の大きな端末も含むものとする。

コンテンツサーバ１０３は、様々な携帯端末上で動作するアプリを複数保持しており、所定の携帯端末からダウンロード要求が来た際に、該当するアプリを要求元の携帯端末へ送信する。また、コンテンツサーバ１０３は、所定の携帯端末上のアプリで編集可能な画像、テキストデータ、音楽ファイル、Ｗｅｂページなどのコンテンツも複数保持している。本実施例では、携帯端末上でアプリを動作させる場合は、アプリの画面レイアウト情報を参照して端末の画面レイアウトを構成し、コンテンツサーバ１０３からコンテンツをダウンロードして、該コンテンツを端末の画面を構成する要素として、該当する領域にコンテンツを表示する構成をとる。また、コンテンツサーバ１０３にアップロード前のコンテンツを携帯端末内で管理し、アプリ起動時に参照する構成もとることができる。

なお、コンテンツサーバ１０３は、複数のサーバで構成されていてもよく、例えば、アプリを管理するサーバと、コンテンツを管理するサーバ等が分かれていてもよい。ネットワーク１０４は、ＷＡＮやＬＡＮで構成される無線、または有線のネットワークである。

＜画像形成装置のハードウェアブロック図＞
図２は、画象形成装置１０１の構成の一例を示すハードウェアブロック図である。
画像形成装置１０１において、２００はコントローラユニットで、画像信号やデバイス情報の入出力を制御する。実施例の処理内容が記述されたプログラムが、ＲＯＭ２０３あるいはＨＤＤ２０４に保存され、画像形成装置にインストールされる。

ＣＰＵ２０１は、ＲＯＭ２０３あるいはＨＤＤ２０４に記憶されたプログラムをＲＡＭ２０２に読み出し、実行する。さらに、ＣＰＵ２０１は、システムバス２０５に接続される各デバイスを統括的に制御する。ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークメモリとして機能する。ＲＯＭ２０３には、電源ＯＮ時に実行されるブートプログラムが格納され、ＨＤＤ２０４にはオペレーティングシステムと画像形成装置１０１の制御プログラム本体が格納される。また、ＨＤＤ２０４は、大容量データを一時的あるいは長期的に保持する目的でも使用される。なお、ＲＯＭ２０３は、フラッシュＲＯＭで構成され、データを書き換え可能としてもよい。

Ｎｅｔｗｏｒｋ２０６は、ネットワーク１０４に接続し、画像形成装置１０１の外部とのプリントデータやデバイス情報の入出力を担う。なお、画象形成装置１０１では、Ｎｅｔｗｏｒｋ２０６を介してダウンロードしたプログラムを、ＲＯＭ２０３あるいはＨＤＤ２０４にインストールすることもできる。

操作部Ｉ／Ｆ２０７は、操作部２１１とのインターフェース部で、操作部２１１に表示する画像データを操作部２１１に対して出力する。また、操作部Ｉ／Ｆ２０７は、操作部２１１から本装置の使用者が入力した情報を、ＣＰＵ２０１に伝える役割をする。操作部２１１は、出力器として液晶パネルと音源等を備え、入力器としてタッチパネルとハードキー、マイク等を備えるものである。

コントローラユニット２００は、デバイスＩ／Ｆ２０８を介して、プリンタエンジン２１２に接続される。デバイスＩ／Ｆ２０８は、ＣＰＵ２０１の指示に基づき、プリンタエンジン２１２に対し、画像信号の送出、デバイス動作指示、デバイス情報の受信を行う。プリンタエンジン２１２は、コントローラユニット２００からの画像信号を印刷媒体上に出力する出力機であり、電子写真方式、インクジェット方式の何れの印刷方式でも構わない。

ＲＩＰ２０９は、中間プリントデータをラスタイメージに展開する専用ハードウェアである。ＲＩＰ２０９は、ＣＰＵ２０１によりＲＡＭ２０２上に生成された中間プリントデータを高速かつ、ＣＰＵ２０１の実行と並列に、処理するものである。プリンタ画像処理部２１０は、プリント出力画像データに対して、画像補正、ハーフトーニング等を行う。画像圧伸部２１３は、画像データの圧縮・伸張処理を行う。

画像形成装置におけるプリンタエンジン２１２以外の部分は、ＲＩＰ２０９のように、ＡＳＩＣ(Application Specific Integrated Circuit)等のハードウェア回路として構成してもよい。逆にハードウェア回路の一部ないし全部をソフトウェアで実現してもよい。また、システムバス２０５に対し、ＣＤやＤＶＤなどの可搬型ディスク記録媒体に対するディスクドライブ、フラッシュメモリなどの可搬型の不揮発性記録媒体に対するメモリリーダライタなどが接続されてもよい。また、実施例の処理内容が記述されたプログラムが前記可搬型記憶媒体を経由して、ＲＯＭ２０３あるいはＨＤＤ２０４に保存され、画像形成装置にインストールすることもできる。

＜携帯端末のハードウェアブロック図＞
図３は、携帯端末１０２の構成の一例を示すハードウェアブロック図である。
携帯端末１０２では、本実施例の処理内容を含む各種処理内容が記述されたプログラム（アプリ）が、補助記憶装置３０３に保存され、携帯端末にインストールされる。中央演算装置３０１は、補助記憶装置３０３に記憶されたプログラムを主記憶装置３０２に読み出し、実行する。さらに、中央演算装置３０１は、システムバス３０６に接続される各デバイスを統括的に制御する。

主記憶装置３０２は、中央演算装置３０１の主メモリ、ワークメモリとして機能する。補助記憶装置３０３には、オペレーティングシステムと本装置の制御プログラム本体が格納される。また、補助記憶装置３０３は、大容量データを一時的あるいは長期的に保持する目的でも使用される。

Ｎｅｔｗｏｒｋ３０５は、ネットワーク１０４に接続し、携帯端末１０２外部の携帯端末などの無線ネットワークで接続される端末との通信データの入出力を担う。なお、携帯端末１０２は、Ｎｅｔｗｏｒｋ３０５を介してコンテンツサーバ１０３に接続し、アプリケーションデータをダウンロードした後、補助記憶装置３０３にインストールすることもできる。なお、アプリケーションデータ（以下、アプリデータ）は、画面サイズの異なる複数の端末上で動作可能なアプリケーションの画面サイズごとのアプリケーション画面の画面レイアウトを定義した画面レイアウト情報を複数含むものである。なお、詳細は後述する図５に示す。
操作部３０４は、出力器として液晶パネルと音源等を備え、入力器としてタッチパネルとハードキー、マイク等を備えるものである。

＜画像形成装置のソフトウェアモジュール図＞
図４は、画像形成装置１０１のソフトウェアモジュール構成の一例を示す図である。なお、図４に記載する各ソフトウェアモジュールは、例えば、画像形成装置１０１のＣＰＵ２０１がＲＯＭ２０３やＨＤＤ２０４等にコンピュータ読み取り可能に記録されたプログラムをＲＡＭ２０２にロードして実行することにより実現される機能に対応する。

本実施例では、携帯端末１０２からアプリの画面レイアウトの印刷要求がされた際、画像形成装置１０１がアプリデータを受信する。ジョブ制御部４０２は、データ受信から印刷までのジョブ制御の全般を司る。データ受信部４０１は、アプリデータを受信し、該受信されたデータはジョブ制御部４０２を介してジョブデータ管理部４０８で保持される。なお、アプリデータには、複数の画面レイアウト情報が含まれる。

レイアウト情報解析部４０３は、ジョブ制御部４０２を介してジョブデータ管理部４０８から、アプリデータに含まれる複数の画面レイアウト情報を読み込み、解析した後、プリントデータ（例えばＰＤＬデータ）を生成する。生成されたプリントデータは、ジョブ制御部４０２を介してジョブデータ管理部４０８で保持される。

インタプリタ４０４は、ジョブ制御部４０２を介してジョブデータ管理部４０８からプリントデータを読み込み、該プリントデータを解釈して、中間データであるディスプレイリストを生成する。生成されたディスプレイリストは、ジョブ制御部４０２を介してジョブデータ管理部４０８で保持される。

レンダラ４０５は、ジョブ制御部４０２を介してジョブデータ管理部４０８からディスプレイリストを読み込み、該ディスプレイリストからビットマップイメージを生成するモジュールであり、多くの処理は専用ハードウェアＲＩＰ２０９により実行される。生成されたビットマップイメージは、ジョブ制御部４０２を介してジョブデータ管理部４０８で保持される。

プリンタドライバ４０６は、ジョブ制御部４０２を介してジョブデータ管理部４０８からビットマップイメージを読み込み、プリンタエンジン２１２への印刷指示とビットマップイメージをプリンタエンジン２１２へ送出する。

ユーザインタフェース４０７は、操作部Ｉ／Ｆ２０７を介して、操作部２１１を制御するモジュールである。ユーザインタフェース４０７は、主に操作部２１１の液晶パネルに表示するデータを生成し、タッチパネルからの入力に従い液晶パネルの表示を更新する。また、ユーザインタフェース４０７は、タッチパネルからの入力が何らかのジョブ実行指示であった場合は、ジョブ制御部４０２に指示を伝達する。ジョブデータ管理部４０８は、アプリデータ、プリントデータ、ディスプレイリスト、ビットマップイメージのそれぞれを一時的もしくは長期的にＨＤＤ２０４に保持管理するデータベースである。

＜アプリデータ構造図＞
図５は、コンテンツサーバ１０３に保持されるアプリデータの構造の一例を示す図である。アプリデータは、コンテンツサーバ１０３から携帯端末１０２へダウンロードされ、インストールされることで、様々な機能を使用・拡張することができる。

図５に示すように、アプリデータには、そのアプリの携帯端末上の画面レイアウト情報５００と、そのアプリの動作、振る舞いを定義しているプログラムをコンパイルしたバイナリ形式の実行ファイル５０４が含まれている。

画面レイアウト情報５００は、その中にアプリがサポートする携帯端末の画面サイズ、解像度に応じてレイアウト情報等を複数保持することが可能である。携帯端末１０２の中央演算装置３０１は、アプリ起動時に、画面レイアウト情報５００の中から各端末画面に最適な画面レイアウト情報を読み込むことで、最適化されたユーザインタフェースを提供している。本実施例では、多機能携帯電話（スマートフォン）などの５型画面を持つ端末、７型画面を持つ小さめのタブレット端末、１０型画面を持つ一般的なタブレット端末の３種類の端末用のレイアウト情報を持つアプリを、図５の画面レイアウト情報５００の例としてあげている。以下、画面レイアウト情報５００について詳細に説明する。

５０１は、多機能携帯電話などの５型画面を持つ端末用の画面レイアウト情報である。５０２は、７型画面を持つ小さめのタブレット端末用の画面レイアウト情報である。５０３は、１０型画面を持つ一般的なタブレット端末である。本実施例では、画像形成装置１０１へ、このアプリデータを携帯端末１０２から送信することで、アプリが保有している複数の画面レイアウト情報を印刷する。

＜レイアウト情報で用いられる単位と修飾子＞
アプリデータに含まれる複数のレイアウト情報（５０１、５０２、５０３）では、ｄｐ(density independent pixels)という、独自の単位系が用いられている。携帯端末において画面上の実際のドット（ピクセル）によってオブジェクトのサイズ（長さや面積）を指定すると、解像度の小さなディスプレイではオブジェクトのサイズは大きくなり、解像度の大きなディスプレイではオブジェクトのサイズは小さくなる。つまり、携帯端末の有するディスプレイごとの解像度に応じて、オブジェクトのサイズが変わってしまう。そこで、レイアウト情報を定義する際は、表示されるオブジェクトのサイズがデバイスによって変わらないピクセルの単位であるｄｐが用いられる。なおｄｐは、ｄｉｐとも呼ばれる。

ｄｐとは、仮想的なピクセル単位であり、ｄｐを用いることでディスプレイの密度に依存せずに位置やサイズを定義できる。１ｄｐは、一般的に、１６０ｄｐｉのディスプレイの１ピクセルとなる。つまり１ｄｐ＝１６０ｄｐｉのディスプレイの１ピクセルとなる。このようなｄｐを用いることで、例えば、オブジェクトの幅を１００ｄｐとした場合に、ＨＶＧＡ（１６０ｄｐｉのディスプレイ）では１００ピクセル、ＷＶＧＡ（２４０ｄｐｉのディスプレイ）では１５０ピクセルになり、実際のオブジェクトのサイズは同等になる。

本実施例においても、複数のレイアウト情報（５０１、５０２、５０３）には、このｄｐが使用されており、ｄｐに応じて対応する端末を切り替えている。具体的な切り替えには、各画面レイアウト情報に修飾子を付けることで実現している。この修飾子の付け方には一定のルールがあり、表示領域の横幅がＮ（定数）ｄｐより大きい場合に参照されるもの、表示領域の高さがＮｄｐより大きい場合に参照されるもの、表示領域で最も短い辺の長さがＮｄｐより大きいもの場合に参照されるものなどがある。本実施例では、『表示領域で最も小さい辺の長さがＮｄｐより大きい場合に参照される』とした修飾子の付け方を採用しているが、その他の修飾子を使用することも可能である。即ち、各画面レイアウト情報に、端末の解像度に依存しない単位（例えばｄｐ）の密度非依存ピクセル情報を用いた修飾子情報を付けて、参照する画面レイアウト情報を切り替える構成であればどのような構成であってもよい。

図６は、各レイアウト情報に用いられる修飾子のｄｐとの対応表の一例を示す図である。
修飾子で使用するｄｐの値Ｎは、１ｉｎｃｈ＝１６０ｄｐという換算式で算出される。例えば、５型画面の携帯端末では、一般的にＷＶＧＡ規格が使用され、短辺が３ｉｎｃｈとなるため「１６０×３＝４８０ｄｐ」が採用される。同様に、７型画面のタブレットでは、一般的にＷＳＶＧＡ規格が使用されており、短辺が３．７５ｉｎｃｈとなるため「１６０×３．７５＝６００ｄｐ」が採用される。１０型画面のタブレットでは、一般的にＨＤＴＶ規格が使用され、短辺が４．５ｉｎｃｈとなるため「１６０×４．５＝７２０ｄｐ」がｄｐの情報として採用される。

なお、本実施例において、図６の中の「推奨用紙サイズ」とは、その画面レイアウト情報を用いて定義された携帯端末の表示内容を画像形成装置により印刷する場合、その表示内容を全て含むことができる最小の用紙サイズのことを言っている。

本発明では、上記１ｉｎｃｈ＝１６０ｄｐという換算式を用いて、修飾子のｄｐの情報から推奨用紙サイズを算出し、複数の画面レイアウト情報の集約・拡縮印刷を実現している。上記の修飾子のルールに従うと、４８０ｄｐが修飾子として使用される画面レイアウト情報は、表示領域の短辺が３ｉｎｃｈとなる５型画面の携帯端末が対象となる。５型画面の携帯端末はＷＶＧＡ規格のアスペクト比を持つものが一般的であり、長辺は５ｉｎｃｈとなる。この表示領域を含むことが出来る最小の用紙サイズはＡ６、またはＢ７となるため、これを推奨用紙サイズとしている。６００ｄｐが修飾子として使用される画面レイアウト情報は、表示領域の短辺が３．７５ｉｎｃｈとなる７型画面のタブレットが対象となる。７型画面の携帯端末はＷＳＶＧＡ規格のアスペクト比を持つものが一般的であり、長辺は６．４ｉｎｃｈとなる。この領域を含むことが出来る最小の用紙サイズはＡ５、またはＢ６であるため、これを推奨用紙サイズとしている。７２０ｄｐが修飾子として使用される画面レイアウト情報は、表示領域の短辺が４．５ｉｎｃｈとなる１０型画面のタブレットが対象となる。１０型画面の携帯端末はＨＤＴＶ規格のアスペクト比を持つものが一般的であり、長辺は８ｉｎｃｈとなる。この領域を含むことができる最小の用紙サイズはＡ５、またはＢ６であるため、これを推奨用紙サイズとしている。

また、修飾子は、レイアウト情報の画面向きの情報も持つことができる。その場合、修飾子は、レイアウト情報の画面の向き（長辺の向き）が横向きのものを「Ｌａｎｄｓｃａｐｅ」、レイアウト情報の画面の向き（長辺の向き）が縦向きのものを「Ｐｏｒｔｒａｉｔ」として対応付ける。

＜画面レイアウト情報の構成図＞
図７、図８は、複数の画面レイアウト情報により定義される端末ごとのレイアウトの構成の一例を示す図である。それぞれ、例として、５型の画面を持つ携帯電話用、７型の画面を持つタブレット用、１０型の画面を持つタブレット用のランドスケープ画面（図７）、ポートレート画面（図８）のレイアウト構成を示している。

本実施例では、アプリの実行画面の描画内容は、大きく描画領域Ａ、描画領域Ｂ、描画領域Ｃ、描画領域Ｄの４つの領域から構成されるものとしているが、その他の構成を取ることも出来る。また、描画領域内の描画内容であるコンテンツ情報に関しては、アプリデータに含まれる固定のＢｉｔｍａｐイメージや、テキスト、選択ボタン、時計、カレンダーなどの静的コンテンツを指定することができる。加えて、ユーザが自由に編集可能な静止画、動画、テキスト、音楽、Ｗｅｂページなどの動的コンテンツの指定も可能である。これら、動的コンテンツの振る舞いは、図５のアプリデータに含まれるバイナリ形式の実行ファイル５０４により定義され、ユーザのコンテンツ編集内容により表示内容が変わる。

一般的に、複数の携帯端末間でコンテンツを同期、共有するようなアプリでは、これらユーザによって編集された動的コンテンツの情報を図１の１０３のような端末外部のコンテンツサーバにアップロードし、共有する。その他の手段としては、端末内で動的コンテンツを管理し、アプリが起動した際に、相互に共有、参照するといったものが考えられる。本実施例では、編集したコンテンツはコンテンツサーバ１０３へアップロードしていることを前提としているが、アップロードしていない場合は、端末間で相互に共有、参照して同期をとるものとしている。

動的コンテンツの表示内容が変わると、そのアプリがサポートする画面レイアウト全ての該当領域の表示内容が変わる。その結果、ユーザの編集内容によっては、特定の端末の表示が崩れる、といった問題が発生する可能性がある。本発明では、この端末の表示が崩れてしまう動的コンテンツの編集を防止するため、画像形成装置による、アプリサポートの全ての画面レイアウトの印刷出力を実施している。これにより、ユーザは、アプリがサポートする全ての画面レイアウトを容易に確認することができる。

図７は、画面の向きがランドスケープの時の、画面レイアウト情報の構成図の例を示している。
図７（Ａ）は、５型の画面を持つ携帯電話用の画面レイアウトの構成図を表している。画面は、描画領域Ａ６０１、描画領域Ｂ６０２、描画領域Ｃ６０３、描画領域Ｄ６０４を含んでいるが、５型の画面では、表示領域が狭いため、２画面で構成する形をとっている。

図７（Ｂ）は、７型の画面を持つタブレット用の画面レイアウトの構成図を表している。こちらも、画面は、描画領域Ａ６１１、描画領域Ｂ６１２、描画領域Ｃ６１３、描画領域Ｄ６１４を含んでいるが、図７（Ａ）の５型の画面より広めの７型画面を対象としているため、１画面内に全ての描画領域が収まる構成になっている。

図７（Ｃ）は、１０型の画面を持つタブレット用の画面レイアウトの構成図を表している。こちらも、画面は、描画領域Ａ６２１、描画領域Ｂ６２２、描画領域Ｃ６２３、描画領域Ｄ６２４を含んでいる。１０型画面であるため、表示領域は広く、各描画領域も図７（Ａ）、図７（Ｂ）と比較して、拡大して表示できる構成になっている。

図８は、画面の向きがポートレートの時の、画面レイアウト情報の構成図の例を示している。
図８（Ａ）は、５型の画面を持つ携帯電話用の画面レイアウトの構成図を表している。画面は、描画領域Ａ７０１、描画領域Ｂ７０２、描画領域Ｃ７０３、描画領域Ｄ７０４を含んでいるが、５型の画面では表示領域が狭いため、２画面で構成する形をとっている。

図８（Ｂ）は、７型の画面を持つタブレット用の画面レイアウトの構成図を表している。こちらも、画面は、描画領域Ａ７１１、描画領域Ｂ７１２、描画領域Ｃ７１３、描画領域Ｄ７１４を含んでいるが、図８（Ａ）の５型の画面より広めの７型画面を対象としているため、１画面内に全ての描画領域が収まる構成になっている。

図８（Ｃ）は、１０型の画面を持つタブレット用の画面レイアウトの構成図を表している。こちらも、画面は、描画領域Ａ７２１、描画領域Ｂ７２２、描画領域Ｃ７２３、描画領域Ｄ７２４を含んでいる。１０型画面であるため、表示領域は広く、各描画領域も図８（Ａ）、図８（Ｂ）と比較して、拡大して表示できる構成になっている。また、図８（Ｃ）は、図８（Ｂ）のレイアウト構成と比較すると、描画領域Ａ７２１、描画領域Ｂ７２２、描画領域Ｃ７２３のレイアウト位置が大きく異なる構成になっている。

＜印刷要求時のＵＩ画面＞
図９は、携帯端末１０２から画像形成装置１０１へアプリの画面レイアウトを印刷要求する際の携帯端末１０２の操作部３０４に表示されるユーザインタフェース（以下ＵＩ）の一例を示す図である。

メニューキー９０１は、各種アプリのメニューを表示するための操作ボタンである。図９の例では、メニューキー９０１が押下されると、印刷要求画面９００を表示することが出来る。ボタン９０２が選択されると、画像形成装置１０１への印刷要求処理が開始される。ボタン９０３が選択されると、印刷要求画面９００は非表示になり、画像形成装置１０１への印刷要求処理は行われない。

＜レイアウト情報テーブル＞
図１０は、アプリがサポートする画面レイアウト情報を管理するレイアウト情報テーブルの一例を示す図である。

本実施例では、携帯端末１０２から画像形成装置１０１へアプリデータを送信することで、アプリがサポートする画面レイアウト情報を印刷出力するが、複数ある画面レイアウト情報の解析結果を、このレイアウト情報テーブルを用いて管理する。なお、図１０に示すようなレイアウト情報テーブルは、例えば、ＲＡＭ２０２またはＨＤＤ２０４に記憶される。

レイアウト情報テーブルは、レイアウトＩＤ、修飾子で用いられるｄｐ情報、画面サイズの短辺、推奨用紙サイズ、画面の向き、の項目を持っている。レイアウトＩＤは、レイアウト情報解析部４０３によって一意に決められる、該レイアウト情報の識別情報である。修飾子で用いられるｄｐ情報は、画面レイアウト情報に対応する端末を切り替えている修飾子に使われているｄｐの情報である。画面サイズの短辺は、画面レイアウト情報が対象としている携帯端末の画面サイズの短辺の長さをｉｎｃｈ単位で保持している。推奨用紙サイズは、レイアウト情報解析部４０３により、図６に例示したｄｐと推奨用紙サイズの対応表から対応付けられる、該携帯端末の画面サイズを印字する場合に表示領域を全て含むことができる最小の用紙サイズのことである。画面向きは、該レイアウト情報が対象としている、携帯端末における画面の向きであり、ＰｏｒｔｒａｉｔとＬａｎｄｓｃａｐｅの属性を持つ。ｄｐと修飾子の詳細は図６の説明で述べているためここでは省略する。

＜携帯端末から画像形成装置への印刷要求＞
図１１は、本実施例における携帯端末１０２から画像形成装置１０１へのアプリの画面レイアウト印刷要求処理の一例を示すフローチャートである。なお、このフローチャートの処理は、携帯端末１０２の中央演算装置３０１が補助記憶装置３０３等にコンピュータ読み取り可能に記録されたプログラムを実行することにより実現される。

本実施例では、携帯端末１０２から画像形成装置１０１へアプリデータを印刷データとして送信することで印刷処理を開始する。携帯端末でアプリを起動させるためには、アプリデータをコンテンツサーバ１０３からダウンロードして、インストールする必要がある。コンテンツサーバ１０３からダウンロードしてくる際、アプリデータは、図５の構成を圧縮した形式で携帯端末へ送られる。そしてダウンロード後、圧縮されたアプリデータは、携帯端末上で展開され、携帯端末へインストールされる。そのため、画像形成装置１０１へ携帯端末１０２からアプリデータを印刷データとして送信する際は、展開してインストールされた状態のアプリデータを、コンテンツ情報として再圧縮して送信する必要がある。印刷要求処理では、画像形成装置１０１へ印刷要求を送信した後、このアプリデータの再圧縮処理を行う。携帯端末１０２の操作部３０４に表示されるボタン９０２が選択されると、中央演算装置３０１は、印刷要求処理を開始する。

印刷要求処理が開始されると、Ｓ１００１において、中央演算装置３０１は、画像形成装置１０１に対して印刷要求を送信する。次に、Ｓ１００２において、中央演算装置３０１は、印刷しようとしているアプリに含まれるコンテンツ情報を取得する。中央演算装置３０１は、コンテンツ情報をコンテンツサーバ１０３から取得するが、ユーザが編集したコンテンツで、コンテンツサーバ１０３へアップロードしていないコンテンツに関しては、携帯端末１０２内で保持しているコンテンツ情報を参照する。

次にＳ１００３において、中央演算装置３０１は、上記Ｓ１００２で取得したコンテンツ情報とともにアプリデータを圧縮する。アプリデータは、コンテンツサーバ１０３から図５の構成を圧縮した形式で携帯端末へダウンロードされている。ダウンロード後、圧縮されたデータは、携帯端末上で展開され、携帯端末へインストールされる。Ｓ１００３においては、この展開したアプリデータを、再度圧縮し、画像形成装置１０１へ送信する。本実施例では、Ｓ１００３において、コンテンツ情報とともに、アプリデータに含まれる全ての画面レイアウト情報を含めた形で圧縮処理を行うが、特定の画面レイアウト情報を選択して必要な画面レイアウト情報を圧縮するといった形態もとることが出来る。

次に、Ｓ１００４において、中央演算装置３０１は、上記Ｓ１００３にて圧縮したアプリデータを印刷データとして画像形成装置１０１へ送信する。
以上の処理により、携帯端末１０２から画像形成装置１０１への印刷要求処理が行われる。

＜画像形成装置による印刷処理の基本フロー＞
図１２は、本実施例における画像形成装置１０１でのアプリデータの画面レイアウト印刷処理の一例を示すフローチャートである。なお、図１２〜図１４、図１７、図１８に示すフローチャートの処理は、画像形成装置１０１のＣＰＵ２０１がＲＯＭ２０３又はＨＤＤ２０４等にコンピュータ読み取り可能に記録されたプログラムを実行することにより実現される。携帯端末１０２から、図１１のＳ１００１において、印刷要求が送信されると、印刷処理が開始される。

まず、Ｓ２００１において、ＣＰＵ２０１は、携帯端末１０２から送信された印刷要求（図１１のＳ１００１で送信された印刷要求）を受信する。次に、Ｓ２００２において、ＣＰＵ２０１は、携帯端末１０２からアプリデータ（図１１のＳ１００３で圧縮され、Ｓ１００４で送信されたアプリデータ）を受信する。このアプリデータ受信処理については、図１３を用いて後ほど詳細を説明する。

次に、Ｓ２００３において、ＣＰＵ２０１は、レイアウト情報解析部４０３を用いて、上記Ｓ２００２において取得したアプリデータに含まれるレイアウト情報を解釈する。このレイアウト情報解析処理については、図１４を用いて後ほど詳細を説明する。

次に、Ｓ２００４において、ＣＰＵ２０１は、上記Ｓ２００３において解釈したレイアウト情報を元に、レイアウト処理を行う。レイアウト処理では、上記Ｓ２００３において解釈した複数の画面レイアウト情報に基づいて、画面サイズの異なる複数のアプリケーション画面の画面イメージをページ上にレイアウトする。なお、ここでは、デバイスに給紙されている用紙サイズを参照して、最も少ない枚数で全ての画面レイアウトを印刷できるように、集約・拡縮してレイアウトされる。このレイアウト処理に関しても、図１７を用いて後ほど詳しく説明する。

次に、Ｓ２００５において、ＣＰＵ２０１は、上記Ｓ２００４のレイアウト処理により定義されたレイアウトに従って印刷処理を行う。以上の処理を行うことで、画像形成装置１０１による、アプリデータがサポートする全ての画面レイアウト情報の印刷処理が行われる。

＜アプリデータ受信処理＞
図１３は、図１２のＳ２００２に示した画像形成装置１０１によるアプリデータの受信処理の一例を示すフローチャートである。図１２のＳ２００１にて印刷要求受信の処理が完了すると、図１３に示すアプリデータの受信処理が開始される。

まず、Ｓ３００１にて、ＣＰＵ２０１は、携帯端末１０２にて圧縮されたアプリデータを受信し、ＲＡＭ２０２またはＨＤＤ２０４上に保存する。次に、Ｓ３００２において、ＣＰＵ２０１は、ＲＡＭ２０２またはＨＤＤ２０４上に保存されているアプリデータを展開する。

次に、Ｓ３００３において、ＣＰＵ２０１は、上記Ｓ３００２にて展開して得られるコンテンツ情報、レイアウト情報を取得する。得られたコンテンツ情報、レイアウト情報は、ＲＡＭ２０２またはＨＤＤ２０４上に保存される。以上の処理により、画像形成装置１０１による、アプリデータの受信処理が行われる。

＜レイアウト解析処理＞
図１４は、図１２のＳ２００３で説明した画像形成装置１０１によるレイアウト情報解釈処理の一例を示すフローチャートである。図１２のＳ２００２にてアプリデータ受信の処理が完了すると、図１４に示すレイアウト情報解釈処理が開始される。

レイアウト情報解釈処理が開始されると、Ｓ４００１において、ＣＰＵ２０１は、図１３のＳ３００３にてＲＡＭ２０２またはＨＤＤ２０４上に保存されているレイアウト情報を読み込む。次に、Ｓ４００２において、ＣＰＵ２０１は、図１０に示したレイアウト情報テーブルを初期化する。

次に、ＣＰＵ２０１は、上記Ｓ４００１にて読み込んだレイアウト情報に含まれるレイアウトの数だけ、Ｓ４００３〜Ｓ４００６の処理を繰り返すように制御する。本実施例では、５型の画面のレイアウト情報が２種類、７型、１０型の画面のレイアウト情報がそれぞれ１種類ずつの、合計４種類のレイアウト情報をもつアプリデータを例として用いて説明する。よって、本実施例ではＳ４００３〜Ｓ４００６の処理を４回繰り返すことになる。

Ｓ４００３において、ＣＰＵ２０１は、レイアウト情報に含まれる修飾子のｄｐの情報を取得する。例えば、５型画面のレイアウト情報である場合は、修飾子のｄｐの情報として「４８０」という値が取得できる。

次に、Ｓ４００４において、ＣＰＵ２０１は、推奨用紙サイズの短辺をｄｐの情報から算出する。本実施例では、図６の説明で述べた通り、修飾子の付け方のルールを表示領域で最も小さい辺の長さがＮｄｐより大きい場合としている。「１６０ｄｐ＝１ｉｎｃｈ」であるため、対象とするレイアウト情報の表示領域の短辺は、「表示領域の短辺（ｉｎｃｈ）＝ｄｐの情報／１６０」として算出する事ができる。本実施例では、この表示領域の短辺（ｉｎｃｈ）の値から、表示領域を全て内包することができる最小の用紙サイズを算出する。例えば、ｄｐ情報が４８０であった場合、「４８０／１６０＝３ｉｎｃｈ」が表示領域の短辺であるため、画面アスペクト比を考慮すると、この表示領域を含むことが出来る最小の用紙サイズはＡ６、またはＢ７となる。本実施例では、ここで算出した用紙サイズを推奨用紙サイズとして扱う。本実施例では、その画面レイアウト情報を用いて定義された携帯端末の表示内容を画像形成装置により印字する場合、その表示内容を全て含むことができる最小の用紙サイズを推奨用紙サイズとしている。

次に、Ｓ４００５において、ＣＰＵ２０１は、レイアウト情報に含まれる画面向きの情報を取得する。次に、Ｓ４００６において、ＣＰＵ２０１は、図１０のレイアウト情報テーブルを更新する。ここでは、上記Ｓ４００３〜Ｓ４００５の処理で取得した、修飾子で用いられるｄｐの情報、画像サイズの短辺、推奨用紙サイズ、画像の向きの情報を、レイアウトＩＤと関連付けして、レイアウト情報テーブルへ追記していく。
そして、ＣＰＵ２０１は、上記Ｓ４００３〜Ｓ４００６の処理を、レイアウト情報に含まれるレイアウトの数だけ完了すると、レイアウト情報解釈処理の処理を終了する。

以上の処理により、画像形成装置１０１によるレイアウト情報解釈処理が行われる。このレイアウト情報解釈処理では、レイアウト情報に含まれる修飾子のｄｐの情報から、レイアウト情報が対象としている表示領域の短辺（ｉｎｃｈ）を算出し、該表示領域を内包することができる最小の用紙サイズ（推奨用紙サイズ）を算出している。

＜レイアウト処理の概要＞
本実施例のレイアウト処理では、印刷用紙サイズに対して、複数の画面レイアウトを、集約することで、可能な限り出力枚数が少なくなるようなレイアウト（面付け）を行う。この集約面付けでは、まず、印刷用紙サイズを印字領域として、画面レイアウトの推奨用紙サイズの大きさで、左上を原点として面付けする。次の画面レイアウトを面付けする際は、前の画面レイアウトを面付けした領域は、印字領域から差し引かれる。その結果、次の画面レイアウトが印字領域に収まらなくなる場合は、新しいページを対象として面付けを行う。印刷用紙サイズは、ユーザから指定がある場合は指定された用紙サイズが設定される。一方、ユーザから指定がない場合はデバイスに給紙されている用紙サイズの最大用紙サイズが印刷用紙サイズとして設定される。なお、ユーザからの用紙サイズの指定は、例えば、携帯端末１０２のアプリで予め用紙サイズを設定しておき、携帯端末１０２から送信された印刷要求（図１１のＳ１００１で送信された印刷要求）に含まれるものとする。または、図９のＵＩ画面で、用紙サイズを指定可能としてもよい。なお、設定された用紙サイズに元々収まらないサイズである画面レイアウトは、縮小して印刷用紙サイズに収まるようにレイアウトされる。印刷用紙の向きと、画面レイアウトの画像向きが異なる場合は、印刷用紙の向きに合うように画面レイアウトの画像を回転して面付けする。

＜レイアウト処理のレイアウト遷移図＞
まず、上記レイアウト処理について、図１５、図１６に示すレイアウト遷移図を用いて、詳細に説明する。図１５、図１６は、本実施例におけるレイアウト遷移図の一例を示す図である。

図１５、図１６において、レイアウト対象となるアプリに含まれる画面レイアウト情報は、図１０に示されるレイアウト情報テーブルに含まれる画面レイアウト情報と同じものとする。７２０ｄｐで画像の向きがランドスケープのレイアウト情報と、６００ｄｐで画像の向きがポートレートのレイアウト情報、４８０ｄｐで画像の向きがランドスケープのレイアウト情報が２つの、合計４種類のレイアウト情報（レイアウトＩＤ００１〜００４）が含まれている。また、図１５、図１６では、印刷用紙サイズをＡ４のＬａｎｄｓｃａｐｅとしてレイアウト処理している。

図１５（Ａ）に示す通り、まず印刷用紙サイズのＡ４領域を印字領域として、レイアウトＩＤ００１の画面レイアウトを面付けする。レイアウトＩＤ００１の推奨用紙サイズで面付けされた領域８０１は、次の印字領域からは差し引かれ、斜線で示す領域８０２が次の印字領域として扱われる。

次にレイアウトＩＤ００２を面付けするが、レイアウトＩＤ００１の面付け領域８０１分だけ、印字領域が狭くなるため、レイアウトＩＤ００２の画面レイアウトを面付けするには、領域８０２の領域では印字領域が足りない。よって、図１５（Ｂ）に示す通り、改ページを行い、新しいページの印字領域を面付け対象として、面付け処理を行う。新しいページの印字領域を対象としても印字領域が不足している場合は、面付け対象の画像を縮小して面付けする。図１５（Ｂ）の例では、新しいページの印字領域内に収まっているため、画像の縮小は行わない。また、印刷用紙の印字向きと画面レイアウトの画像の向きが異なるため、画像を右９０度回転して、面付けを行う。面付けされた領域８０３は、次の印字領域からは差し引かれ、斜線で示す領域８０４が次の印字領域として扱われる。

次にレイアウトＩＤ００３を面付けするが、図１６（Ａ）に示すように、レイアウトＩＤ００２の面付け領域を除いた印字領域の中で、面付け処理を行う。ここでは、論理座標のＸ座標が最も小さく、かつＹ座標が最も大きい位置に、レイアウトＩＤ００３の画像の左上の頂点がくるように面付けする。レイアウトＩＤ００３が面付けされた領域８０５は、次の印字領域からは差し引かれ、斜線で示す領域８０６が次の印字領域として扱われる。

次にレイアウトＩＤ００４の画面レイアウトを面付けするが、図１６（Ｂ）に示す通り、この時もレイアウトＩＤ００２、レイアウトＩＤ００３の面付け領域を除いた印字領域の中で面付けを行う。論理座標のＸ座標が最も小さく、かつＹ座標が最も大きい位置に、レイアウトＩＤ００４の画像の左上の頂点がくるように、領域８０７に面付けする。以上の集約面付けにより、本実施例におけるレイアウト処理が行われる。

＜レイアウト処理のフローチャート＞
図１７は、図１２のＳ２００４で示した画像形成装置１０１によるレイアウト処理の一例を示すフローチャートである。なお、図１７において、Ｍは出力ページ番号、Ｎは面付け対象としているページの印字領域、Ｓはレイアウト情報テーブルにおけるレイアウトＩＤへのインデックスとする。図１２のＳ２００３のレイアウト情報解釈処理が完了すると、図１７に示すレイアウト処理が開始される。

処理が開始されると、Ｓ５００１にて、ＣＰＵ２０１は、図１２のＳ２００３のレイアウト情報解釈処理により作成されたレイアウト情報テーブル（例えば図１０に示したようなテーブル）を参照する。次に、Ｓ５００２において、ＣＰＵ２０１は、出力ページ番号であるＭに「１」を代入し、初期化する。次に、Ｓ５００３において、ＣＰＵ２０１は、レイアウト情報テーブルにおけるレイアウトＩＤへのインデックスであるＳに「１」を代入し、初期化する。

次に、Ｓ５００４において、ＣＰＵ２０１は、Ｍページ目の用紙サイズ設定処理を行う。この用紙サイズ設定処理により、印刷する用紙のサイズが設定される。この用紙サイズ設定処理については、後ほど図１８で詳しく説明する。

次に、Ｓ５００５において、ＣＰＵ２０１は、レイアウトＩＤがＳに対応するレイアウト情報の画像（画像レイアウト情報の画像に基づく画面イメージ）の向きが、印刷しようとしている用紙（ページ）の印字向きと同じ向きかを判定する。なお、印刷しようとしている画像の向きが、印刷用紙の印字向きと異なる場合は、画像を回転する必要がある。よって、ここでは画像の向きと印字向きを見ることで、画像を回転する必要があるか、判定している。

そして、上記Ｓ５００５にて、レイアウト情報の画像の向きが印字向きと同じであると判定した場合(Ｓ５００５でＹｅｓの場合)、ＣＰＵ２０１は、Ｓ５００７へ処理を進める。一方、レイアウト情報の画像の向きが印字向きと異なると判定した場合(Ｓ５００５でＮｏの場合)、ＣＰＵ２０１は、Ｓ５００６へ処理を進める。

Ｓ５００６では、画像の向きが印刷用紙の印字向きと異なるため、ＣＰＵ２０１は、画像を右９０度回転し、Ｓ５００７に処理を進める。本実施例では、ここで回転の向きを右９０度回転としているが、左９０度回転してレイアウトしてもよい。図１５のレイアウト遷移図の例では、図１５（Ｂ）において、レイアウトＩＤ２をレイアウトする際に、画像の向きと、印字向きが異なるため、画像を右９０度回転している。

次に、Ｓ５００７において、ＣＰＵ２０１は、レイアウト情報の画像が印字領域Ｎの領域内に収まる（レイアウトできる）か判定する。印字領域Ｎの領域内に収まるかどうかは、レイアウト情報の画像を、論理座標のＸ座標が最も小さく、かつＹ座標が最も大きい位置に、画像の左上の頂点がくるようにレイアウトして判定する。その結果、印字領域内に収まっていない場合、改ページ、または縮小処理を行う必要がある。本実施例では、面付け対象画像が印字領域内に収まっておらず、かつ、同じページ内に他のレイアウト情報の画像が存在している場合は、改ページ処理を行う。面付け対象画像が印字領域内に収まっておらず、かつ、同じページ内に他のレイアウト情報の画像が存在しない場合は、縮小処理を行う。

上記Ｓ５００７にて、面付け対象画像が印字領域Ｎの領域内に収まっていると判定した場合(Ｓ５００７でＹｅｓの場合)、ＣＰＵ２０１は、Ｓ５０１１に処理を進める。一方、面付け対象画像が印字領域Ｎの領域内に収まっていないと判定した場合(Ｓ５００７でＮｏの場合)、ＣＰＵ２０１は、Ｓ５００８に処理を進める。

Ｓ５００８において、ＣＰＵ２０１は、面付け対象のページ内に他のレイアウト情報の画像が存在しないか判定する。即ち、面付け対象のページがＳに対応するレイアウト情報の画像の面付けのみか判定する。

そして、上記Ｓ５００８にて、面付け対象のページ内に他のレイアウト情報の画像が存在する（Ｓの面付けのみでない）と判定した場合(Ｓ５００８でＮｏの場合)、ＣＰＵ２０１は、Ｓ５００９に処理を進める。

Ｓ５００９では、面付け対象のページ内に他のレイアウト情報の画像が存在していることになるので、改ページ処理を行い、次ページに面付けするように制御する。具体的には、Ｓ５００９において、ＣＰＵ２０１は、出力ページ番号であるＭの値に１を加算してページ番号を進め、Ｓ５００４に処理を戻し、処理を繰り返す。

一方、上記Ｓ５００８にて、面付け対象のページ内に他のレイアウト情報の画像が存在しない（Ｓの面付けのみ）と判定した場合(Ｓ５００８でＹｅｓの場合)、ＣＰＵ２０１は、Ｓ５０１０に処理を進める。

Ｓ５０１０では、面付け対象のページ内に他のレイアウト情報の画像が存在しないにも関わらず、面付け対象の画像が印字領域内に収まらないことになる。これは、面付け対象の画像サイズが印刷用紙サイズとして指定している用紙サイズより大きいサイズであることになるため、この場合は面付け対象の画像を縮小して印刷用紙サイズに収まるようにレイアウトする。よって、Ｓ５０１０において、ＣＰＵ２０１は、面付け対象の画像を印刷用紙サイズに縮小し、Ｓ５０１１に処理を進める。

次に、Ｓ５０１１において、ＣＰＵ２０１は、レイアウトＩＤがＳのレイアウトサイズ、位置、向きを確定する。次に、Ｓ５０１２において、ＣＰＵ２０１は、印字領域Ｎの領域から、レイアウトＩＤがＳの推奨用紙サイズ分の領域を差し引く。この処理を図１５、図１６を用いて説明すると、対象としている印字領域から、レイアウトされた面付け領域（８０１、８０３、８０５）を差し引き、図１５（Ａ）では領域８０２を、図１５（Ｂ）では領域８０４を、図１６（Ａ）では領域８０６を求めている。対象とする印字領域から、面付け済みの領域を差し引くことで、次の面付け対象とする印字領域を算出している。

次に、Ｓ５０１３において、ＣＰＵ２０１は、印字領域Ｎに面付けできるだけの空白領域が残されているか判定する。ここでは、面付け処理を行う領域として、現在対象としている印字領域に、ある程度の空白領域（例えば、特定の閾値を超える空白領域）が残っているかどうかを判定している。印字領域として一応の空白領域が残ってはいるが、あまりにも狭い領域である場合は、改ページ処理を行い、面付け対象領域を広げるものとする。

そして、上記Ｓ５０１３にて、まだ面付けできるだけの空白領域（例えば、特定の閾値を超える空白領域）が残っていると判定した場合(Ｓ５０１３でＹｅｓの場合)、ＣＰＵ２０１は、Ｓ５０１６に処理を進める。一方、面付けできるだけの空白領域（例えば、特定の閾値を超える空白領域）が残っていないと判定した場合(Ｓ５０１３でＮｏの場合)、ＣＰＵ２０１は、改ページ処理をする必要があるため、Ｓ５０１４へ処理を進める。

Ｓ５０１４では、改ページ処理のため、ＣＰＵ２０１は、出力ページ番号であるＭの値に１を加算して、ページ番号を進める。次に、Ｓ５０１５において、ＣＰＵ２０１は、Ｍページ目の用紙サイズ設定処理を行う。この用紙サイズ設定処理については、後ほど図１９を用いて詳しく説明する。

次に、Ｓ５０１６において、ＣＰＵ２０１は、レイアウト情報テーブルにおけるレイアウトＩＤであるＳの値に１を加算して、レイアウトＩＤを進める。
次に、Ｓ５０１７においては、ＣＰＵ２０１は、レイアウト情報テーブルに、レイアウトＩＤがＳに対応するレイアウト情報が存在しないかどうか判定する。そして、上記Ｓ５０１７にて、レイアウトＩＤがＳに対応するレイアウト情報が存在すると判定した場合(Ｓ５０１７でＮｏの場合)、ＣＰＵ２０１は、Ｓ５００５に処理を戻し、処理を繰り返す。

一方、上記Ｓ５０１７にて、レイアウトＩＤがＳのレイアウト情報が存在しないと判定した場合(Ｓ５０１７でＹｅｓの場合)、ＣＰＵ２０１は、本レイアウト処理を終了し、図１２のＳ２００５の印刷出力処理を実行する。以上の処理により、画像形成装置１０１によるレイアウト処理が行われる。

＜用紙サイズ設定＞
図１８は、画像形成装置１０１による用紙サイズ設定処理の一例を示すフローチャートである。本実施例では、複数の画面レイアウト情報からレイアウト情報を解析し、集約・拡縮印刷を行うが、対象とする印刷用紙サイズは、ユーザが指定する場合は、ユーザが指定した用紙サイズを印刷用紙サイズとする。ユーザの指定がない場合は、デバイス内に給紙されている用紙の最大用紙サイズを印刷用紙サイズとしている。図１８の用紙サイズ設定処理は、図１７のＳ５００３、Ｓ５００９、又はＳ５０１４の処理が完了すると開始される。なお、図１８において、Ｎは面付け対象としているページの印字領域である。

まず、Ｓ６００１において、ＣＰＵ２０１は、ユーザからの印刷用紙サイズの指定があるか判定する。
そして、上記Ｓ６００１にて、ユーザからの印刷用紙サイズの指定があると判定した場合(Ｓ６００１でＹｅｓの場合)、ＣＰＵ２０１は、Ｓ６００２に処理を進める。Ｓ６００２において、ＣＰＵ２０１は、Ｎにユーザから指定されている用紙サイズを設定し、本用紙サイズ設定処理を終了し、図１７のフローチャートに処理を戻す。

一方、上記Ｓ６００１にて、ユーザからの印刷用紙サイズの指定がないと判定した場合(Ｓ６００１でＮｏの場合)、ＣＰＵ２０１は、Ｓ６００３に処理を進める。Ｓ６００３において、ＣＰＵ２０１は、Ｎに画像形成装置１０１にセットされている用紙の最大用紙サイズを設定し、本用紙サイズ設定処理を終了し、図１７のフローチャートに処理を戻す。

以上の処理により、画像形成装置１０１による、用紙サイズ設定処理が行われる。本実施例では、レイアウト情報の画像をレイアウト（面付け）する毎に、印字領域Ｎから面付け画像の領域を差し引いて、集約面付けを実現している。そのため、改ページを行う際は、この用紙サイズ設定処理を行う必要がある。

以上示したように、本実施例によれば、ユーザによるアプリが保有する画面レイアウト情報の手動解析、印刷装置へのレイアウト手動設定等の煩雑な操作を必要とせず、アプリがサポートする各種サイズの画面レイアウト情報を、対応する各種画面サイズの携帯端末がなくても、手間無く容易に、必要最低限の出力枚数で全て印刷して、確認することができる。また、アプリケーションが対応している各種画面サイズに対応するアプリケーション画面の画面レイアウトを、一度に確認することができる。

＜アプリデータ受信処理＞
図１９は、実施例２において、図１２のＳ２００２で説明した画像形成装置１０１によるアプリデータの受信処理の一例を示すフローチャートである。なお、図１９に示すフローチャートの処理は、画像形成装置１０１のＣＰＵ２０１がＲＯＭ２０３又はＨＤＤ２０４等にコンピュータ読み取り可能に記録されたプログラムを実行することにより実現される。

実施例１では、図１３に示したように、アプリデータは携帯端末１０２においてコンテンツデータとともに圧縮されたものを、携帯端末１０２から受信していた。本実施例では、携帯端末１０２からは印刷要求のみを受信し、圧縮されたアプリデータは受信しない。アプリデータとコンテンツデータは、画像形成装置１０１からコンテンツサーバ１０３へ直接接続し、ダウンロードする形態をとる。図１２のＳ２００１の印刷要求受信処理が完了すると、図１９のアプリデータの受信処理が開始される。

まず、Ｓ７００１において、ＣＰＵ２０１は、コンテンツサーバ１０３へ接続する。次に、Ｓ７００２において、ＣＰＵ２０１は、コンテンツサーバ１０３から圧縮されたアプリデータを受信し、ＲＡＭ２０２またはＨＤＤ２０４上に保存する。

次に、Ｓ７００３において、ＣＰＵ２０１は、上記ＲＡＭ２０２またはＨＤＤ２０４上に保存されているアプリデータを展開する。次に、Ｓ７００４において、ＣＰＵ２０１は、上記Ｓ７００３にて展開して得られるコンテンツ情報、レイアウト情報を取得する。得られたコンテンツ情報、レイアウト情報は、ＲＡＭ２０２、またはＨＤＤ２０４上に保存される。なお、上記Ｓ７００３にて展開した結果に、コンテンツ情報が含まれていなかった場合は、ＣＰＵ２０１は、再度コンテンツサーバ１０３へ接続し、コンテンツデータそのものを受信する。例えば、コンテンツ情報が、ＵＲＩ等のコンテンツデータの在り処を示す情報である場合は、コンテンツデータをＵＲＩの示す場所（例えばコンテンツサーバ１０３の所定のデータ記憶領域）から取得する。

以上の処理により、画像形成装置１０１による、その他の実施例におけるアプリデータの受信処理が行われる。

上記実施例１，２では、アプリがサポートする各種画面サイズの画面レイアウトを、必要最上限の枚数の用紙にまとめて印刷する構成を説明した。この印刷を以下「複合レイアウト印刷」という。

しかし、再現性を重視して、アプリがサポートする各種サイズの画面レイアウトを、各画面レイアウト情報に対応する画面イメージを実画面サイズで、解像度のまま、画面レイアウト情報毎に印刷するようにしてもよい。なお、電子黒板等のように、画像形成装置１０１にセットされている用紙サイズより大きなサイズの画面に対応する画面レイアウトの画面イメージについては、ポスター印刷を行うものとする。なお、ポスター印刷とは、１ページを４枚／９枚／１６枚等に分割印刷して印刷するものであり、例えば、Ａ４の用紙を使用して、１ページを１６分割してポスター印刷した場合には、Ａ０の大きさで印刷することができる。この印刷を以下「再現性重視レイアウト印刷」という。

また、画面サイズ毎に１ページに収めることを重視して、アプリがサポートする各種画面サイズの画面レイアウトを、用紙１枚の片面に（同一ページ内に）印刷するように印刷する。なお、この際、画像形成装置１０１にセットされている用紙サイズより大きなサイズの画面に対応する画面レイアウトについては、縮小して印刷するものとする。また、複数画面あるレイアウトについては、１枚の用紙の片面上（同一ページ内に）に集約印刷（Ｎｕｐ）するものとする。この際、必要に応じて縮小する。また、用紙サイズに比べて画面サイズが小さい場合には、拡大してもよい。この印刷を以下「１ページレイアウト印刷」という。

さらに、上述の「複合レイアウト印刷」を行う印刷モード、「再現性重視印刷」を行う印刷モード、又は「１ページレイアウト印刷」を行う印刷モードをユーザが指定可能に構成してもよい。なお、この印刷モードの指定は、例えば、携帯端末１０２のアプリで予め印刷モードを設定しておき、携帯端末１０２から送信された印刷要求（図１１のＳ１００１で送信された印刷要求）に含まれるものとする。または、図９のＵＩ画面で、印刷モードを指定可能としてもよい。一方、画像形成装置１０１のＣＰＵ２０１は、携帯端末１０２から受信した印刷要求に含まれる印刷モードに従って、「複合レイアウト印刷」、「再現性重視レイアウト印刷」、又は「１ページレイアウト印刷」を行うように制御する。

以上示したように、本実施例によれば、アプリケーションが保有する画面レイアウト情報のユーザによる解析や、画像形成装置へのユーザによるレイアウト設定等の煩雑な作業を必要とせず、対応する各種画面サイズの端末がなくても、手間無く容易に、アプリケーションがサポートする複数の画面サイズの画面イメージを全て確認することができる。

なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
また、上記各実施例を組み合わせた構成も全て本発明に含まれるものである。

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

また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。
本発明は上記実施例に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施例の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。即ち、上述した各実施例及びその変形例を組み合わせた構成も全て本発明に含まれるものである。

１０１ 画像形成装置
１０２ 携帯端末
１０３ コンテンツサーバ
１０４ ネットワーク

Claims (19)

1. 画像形成装置であって、
   画面サイズの異なる複数の端末上で動作可能なアプリケーションの画面サイズごとのアプリケーション画面の画面レイアウトを定義した画面レイアウト情報を複数含むアプリケーションデータを受信する受信手段と、
   前記複数の画面レイアウト情報に基づいて画面サイズの異なる複数のアプリケーション画面の画面イメージをページ上にレイアウトするレイアウト手段と、
   前記レイアウト手段によるレイアウトに従って前記画面サイズの異なる複数の画面のイメージを印刷する印刷手段と、
   を有することを特徴とする画像形成装置。
2. 前記レイアウト手段は、画面イメージの向きとページの印字向きが異なる場合には、該画面イメージを回転してレイアウトすることを特徴とする請求項１に記載の画像形成装置。
3. 前記レイアウト手段は、前記画面サイズの異なる複数の画面イメージを所定の順にページの空き領域にレイアウトし、該ページの空き領域に次の画面イメージをレイアウトできない場合には、該画面イメージを次ページにレイアウトとすることを特徴とする請求項１又は２に記載の画像形成装置。
4. 前記レイアウト手段は、いずれの画面イメージもレイアウトされていないページに次の画面イメージをレイアウトできない場合には、該画面イメージを縮小して該ページにレイアウトとすることを特徴とする請求項３に記載の画像形成装置。
5. 前記レイアウト手段は、前記画面サイズの異なる複数の画面イメージを実画面サイズでレイアウトすることを特徴とする請求項１又は２に記載の画像形成装置。
6. 前記レイアウト手段は、ページのサイズより画面イメージの実画面サイズが大きい場合には、該画面イメージを分割して複数のページにレイアウトとすることを特徴とする請求項５に記載の画像形成装置。
7. 前記レイアウト手段は、前記画面サイズの異なる複数の画面イメージをそれぞれ１ページにレイアウトすることを特徴とする請求項１又は２に記載の画像形成装置。
8. 前記レイアウト手段は、ページのサイズより画面イメージのサイズが大きい場合には、該画面イメージを縮小してレイアウトとすることを特徴とする請求項７に記載の画像形成装置。
9. 前記レイアウト手段は、１つのアプリケーション画面が複数の画面により構成されている場合には、該複数の画面の画面イメージを同一ページ内にレイアウトとすることを特徴とする請求項７又は８に記載の画像形成装置。
10. 前記レイアウト手段は、
    第１のモードが指定されている場合、前記画面サイズの異なる複数の画面イメージを所定の順にページの空き領域にレイアウトし、該ページの空き領域に次の画面イメージをレイアウトできない場合には、該画面イメージを次ページにレイアウトとする第１のレイアウトを行い、
    第２のモードが指定されている場合、前記画面サイズの異なる複数の画面イメージを実画面サイズでレイアウトする第２のレイアウトを行い、
    第３のモードが指定されている場合、前記画面サイズの異なる複数の画面イメージをそれぞれ１ページにレイアウトする第３のレイアウトを行う、
    ことを特徴とする請求項１又は２に記載の画像形成装置。
11. 前記第１のレイアウトでは、いずれの画面イメージもレイアウトされていないページに次の画面イメージをレイアウトできない場合には、該画面イメージを縮小して該ページにレイアウトとし、
    前記第２のレイアウトでは、ページのサイズより画面イメージの実画面サイズが大きい場合には、該画面イメージを分割して複数のページにレイアウトとし、
    前記第３のレイアウトでは、ページのサイズより画面イメージのサイズが大きい場合には、該画面イメージを縮小してレイアウトとし、また、１つのアプリケーション画面が複数の画面により構成されている場合には、該複数の画面の画面イメージを同一ページ内にレイアウトとする、
    ことを特徴とする請求項１０に記載の画像形成装置。
12. 前記受信手段は、前記アプリケーションが動作する端末、又は、所定のサーバから前記アプリケーションデータを受信することを特徴とする請求項１乃至１１のいずれか１項に記載の画像形成装置。
13. 前記受信手段は、前記アプリケーションが動作する端末から送信される印刷要求を受信した場合に、外部のサーバから前記アプリケーションデータを取得することを特徴とする請求項１乃至１２のいずれか１項に記載の画像形成装置。
14. 前記アプリケーションデータは、前記アプリケーションが前記端末で動作する際の画面を構成する要素を含むことを特徴とする請求項１乃至１３のいずれか１項に記載の画像形成装置。
15. 前記各画面レイアウト情報は、対象とする画面サイズを対応付けるための情報として、端末の解像度に依存しない単位の密度非依存ピクセル情報を用いた修飾子情報を有することを特徴とする請求項１乃至１４のいずれか１項に記載の画像形成装置。
16. 前記レイアウト手段は、前記修飾子情報に用いられた前記密度非依存ピクセル情報から、対応する画面イメージのサイズを算出することを特徴とする請求項１５に記載の画像形成装置。
17. 前記各画面レイアウト情報は、対象とする画面の向きを特定するための情報を含むことを特徴とする請求項１乃至１６のいずれか１項に記載の画像形成装置。
18. 画像形成装置の制御方法であって、
    画面サイズの異なる複数の端末上で動作可能なアプリケーションの画面サイズごとのアプリケーション画面の画面レイアウトを定義した画面レイアウト情報を複数含むアプリケーションデータを受信する受信ステップと、
    前記複数の画面レイアウト情報に基づいて画面サイズの異なる複数のアプリケーション画面の画面イメージをページ上にレイアウトするレイアウトステップと、
    前記レイアウトステップによるレイアウトに従って前記画面サイズの異なる複数の画面のイメージを印刷する印刷ステップと、
    を有することを特徴とする画像形成装置の制御方法。
19. コンピュータを、請求項１乃至１７のいずれか１項に記載された手段として機能させるためのプログラム。

Images