JP2023076287A - 情報処理装置とその制御方法、及びプログラム - Google Patents

Abstract

【課題】ホストデバイス上で動的に印刷データの生成処理を変更する構成を有する情報処理装置、その制御方法及びプログラムを提供する。
【解決手段】情報処理装置で動作するときに解釈され実行される第一プログラムと、第一プログラムから利用できる予めコンパイルされた第二プログラムとを用いて印刷データを生成する情報処理装置であって、印刷を実行するプリンタに紐づいた印刷データを生成する、変更可能な第一生成ロジックを取得し、第一生成ロジックの少なくとも一部を変更した第二生成ロジックを生成する。そして、入力された画像データと、第二生成ロジックとを用いてプリンタで印刷するための印刷データを生成し、生成した印刷データをプリンタへ送信する。第一生成ロジックは、第二プログラムを利用して実行される。
【選択図】図３

Description

本発明は、情報処理装置とその制御方法、及びプログラムに関するものである。

近年、スマートフォンの個人所有率は高く、各プリンタベンダーも、スマートフォンの印刷アプリをユーザへ提供することが当然となっている。このような印刷アプリを使用することにより、ユーザはスマートフォンからプリンタにＪＰＥＧなどの画像データを送信し、プリンタは、その受信した画像データから印刷データを生成して印刷できる。

このようなプリンタにおける印刷データの生成処理には、画像データのデコード、色空間変換、インク色分解、量子化等の多くの処理が存在し、プリンタのインク数やインクの特性、内部の演算精度など、プリンタ毎に違いがある個所は個々に最適化されている。これらの制御は、プリンタのＦＷ（ファームウェア）が行い、印刷データの生成処理ではＡＳＩＣ（特定用途向け集積回路）を併用して実行する。このようにＡＳＩＣを用いることで高速な処理を低コストで実施可能となる。

また上記ＡＳＩＣ処理の他に、ホスト側の印刷ドライバで印刷データを生成する方法もある。印刷ドライバは主にＰＣで利用され、スプール機能や細かい印刷設定を指定できるなど、印刷アプリにはないメリットが多く存在する。

上述した印刷アプリや印刷ドライバによる印刷データの生成処理は、従来から、各プリンタベンダーによって提供されてきたが、印刷データの生成処理を個別にカスタマイズしたいという要望は多く存在する。印刷データの生成処理をカスタマイズできれば、ユーザは自身の好みの印刷物が作成可能となり、印刷物を商用的に扱う印刷ベンダーであれば、カスタマイズが商品の独自性、ひいては競争力につながると期待されている。

特開２０１９－２１１８４９号公報

上述の印刷データの生成処理のカスタマイズには、印刷アプリの変更やＦＷ（firmware）／ＡＳＩＣの変更、もしくは印刷ドライバの変更が必要となる。印刷アプリや印刷ドライバは、ビルド済みのプログラムを使う構成であり、ユーザが変更できる類のものではない。また、ＦＷやＡＳＩＣもユーザが書き換えるようには作られておらず、こちらもユーザが手元で変更するのは困難である。そのため印刷データの生成処理のカスタマイズは、プリンタベンダーが行う必要があるが、ユーザ毎にプリンタベンダーがカスタマイズ対応をするのは負荷が大きく現実的でない。

これを解消する手段の一つとして、ホストデバイス上で動的に印刷データの生成処理を変更する構成が考えられる。

上述のような動的な印刷データの生成処理の変更には、ＪａｖａＳｃｒｉｐｔ（登録商標）などのスクリプト言語が好適である。しかしながらスクリプト言語は、予めコンパイルされたプログラムに比べロジックが解析されやすい状況であり、スクリプト言語でのロジックの提供は、技術保護やセキュリティなどの観点から好ましくない。またスクリプト言語は、実行時にインタプリタによる解釈処理が実行されるため、予めコンパイルされたプログラムに比べ処理速度が遅い。この理由より、Ｗｅｂアプリにおいて、ホストデバイスでの処理とサーバでの処理を併用する手法が良く用いられる。

本発明の目的は、上記従来技術の課題の少なくとも一つを解決することにある。

本発明の目的は、プリンタで印刷される印刷データの生成を情報処理装置側で動的に変更でき、かつ、本来の印刷データの生成処理も併用できる状態で印刷データを生成できるようにする技術を提供することにある。

上記目的を達成するために本発明の一態様に係る情報処理装置は以下のような構成を備える。即ち、
情報処理装置で動作するときに解釈され実行される第一プログラムと、前記第一プログラムから利用できる予めコンパイルされた第二プログラムとを用いて印刷データを生成する情報処理装置であって、
印刷データを生成する変更可能な第一生成ロジックであって、印刷を実行するプリンタに紐づいた前記第一生成ロジックを取得する取得手段と、
前記第一生成ロジックの少なくとも一部が変更された第二生成ロジックを生成する変更手段と、
入力された画像データと、前記第二生成ロジックとを用いて前記プリンタで印刷するための印刷データを生成する生成手段と、
前記生成手段で生成された前記印刷データを前記プリンタへ送信する送信手段とを有し、前記第一生成ロジックは、前記第二プログラムを利用して実行されることを特徴とする。

本発明によれば、スクリプト言語での懸念事項を抑えつつ、プリンタで印刷される印刷データの生成を情報処理装置側で動的に変更でき、かつ、本来の印刷データの生成処理も併用できる状態で印刷データを生成できるという効果がある。

本発明のその他の特徴及び利点は、添付図面を参照とした以下の説明により明らかになるであろう。なお、添付図面においては、同じ若しくは同様の構成には、同じ参照番号を付す。

添付図面は明細書に含まれ、その一部を構成し、本発明の実施形態を示し、その記述と共に本発明の原理を説明するために用いられる。
本発明の実施形態に係る情報処理装置のハードウェア構成と外部装置との接続例を示すブロック図。 実施形態に係るプリンタの機能構成を説明するブロック図。 実施形態に係る情報処理装置が印刷データを生成してプリンタへ送信する処理を説明するフローチャート。 実施形態に係る情報処理装置がプリンタ或いはサーバからデータを取得する例を説明する図。 Ｓ３０２のＵＩ表示で表示されるメインフロー画面の一例を示す図（Ａ）と、図５（Ａ）の前処理ブロックがクリックされることにより表示される前処理編集画面の一例を示す図（Ｂ）。 実施形態に係る情報処理装置において印刷データを生成して送信するまでの処理の流れを説明する図。 実施形態における画像データと扱うビット数を説明する図。 ビットシフトによるシアン（Ｃ）データのデータ圧縮を説明する図。 実施形態に係る情報処理装置からプリンタに送信する印刷データのデータフォーマットを説明する図。 実施形態に係る情報処理装置からプリンタに送信する印刷データの他のデータフォーマットを説明する図。

以下、添付図面を参照して本発明の実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る発明を限定するものでない。実施形態には複数の特徴が記載されているが、これら複数の特徴の全てが発明に必須のものとは限らず、また、複数の特徴は任意に組み合わせられてもよい。さらに、添付図面においては、同一もしくは同様の構成に同一の参照番号を付し、重複した説明は省略する。

図１は、本発明の実施形態に係る情報処理装置１００のハードウェア構成と外部装置との接続例を示すブロック図である。

情報処理装置１００は、ＣＰＵ（中央演算装置／プロセッサ）１０１、ＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｃｅｓｉｎｇ Ｕｎｉｔ）１０２、ＲＡＭ１０４、ＲＯＭ１０４、２次記憶装置１０５、外部Ｉ／Ｆ１０６～１０８を有する。情報処理装置１００は、外部Ｉ／Ｆ１０６を介してインターネット１１０に接続され、また外部Ｉ／Ｆ１０８を介してプリンタ１１４に接続されている。またインターネット１１０にはサーバ１１１～１１３が接続されている。

ＣＰＵ１０１は、以下で説明する各種処理をプログラムに従って実行する。尚、図１では、ＣＰＵ１０１の数は１つであるが、複数のＣＰＵ或いはＣＰＵコアによって構成されていても良い。ＧＰＵ１０２は、大量の演算を並列処理できる演算装置である。ＧＰＵ１０２は、一般的に３Ｄグラフィックや画像描画に必要な計算を得意とするが、近年では機械学習にも応用されている。ＲＡＭ１０３は、ＣＰＵ１００によるプログラムの実行時に、ＲＯＭ１０４或いは２次記憶装置１０５に記憶されているプログラムの展開領域を有し、また各種情報を一時的に記憶するワークメモリとしても機能している。ＲＯＭ１０４は、ＣＰＵ１０１がＲＡＭ１０３に展開して実行するプログラムを記憶している。２次記憶装置１０５は、例えばハードディスクやフラッシュメモリ等を有する記憶装置で、ファイルや画像解析等の処理結果を保持するデータベース等のデータや、各種プログラム等を記憶している。外部Ｉ／Ｆ（インターフェース）１０６～１０８は、有線通信と無線通信の内、少なくともいずれかの通信形態を有するインタフェースであり、利用する通信形態に応じて外部デバイス（プリンタ１１４或いはサーバ１１１～１１３）と通信を行う。有線通信には、例えば、ＵＳＢ、イーサネット（登録商標）等があり、無線通信には、無線ＬＡＮ、ＮＦＣ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、赤外線通信等がある。また無線通信として、無線ＬＡＮを利用する場合には、装置同士が直接接続する形態もあれば、無線ＬＡＮルータ等の中継装置を介して接続する形態もある。情報処理装置１００が、例えばデスクトップＰＣなどの表示機能や入力機構を持たない装置の場合は、外部Ｉ／Ｆ１０７へ、キーボード、ディスプレイ、ポインティングデバイスなどを接続して、それらを利用する。情報処理装置１００内の各種構成要素間の相互通信は、制御バス／データバス１０９を介して行われる。

プリンタ１１４は印刷装置であり、情報処理装置１００の外部Ｉ／Ｆ１０８を介して情報処理装置１００とデータの送受信を行う。また情報処理装置１００は、外部Ｉ／Ｆ１０６を介してインターネット１１０と接続されている。

図２は、実施形態に係るプリンタ１１４の機能構成を説明するブロック図である。

実施形態におけるプリンタ１１４は、大別した機能として記録装置２０１と画像処理装置２０２とを有している。情報処理装置１００より供給された画像データは、画像処理装置２０２で所定の画像処理が施された後、記録装置２０１に送られて記録（印刷）される。

記録装置２０１において、記録装置の主制御部２０３は、記録装置２０１全体を制御しており、ＣＰＵ、ＲＯＭ、ＲＡＭ等を有している。記録バッファ２０４は、記録ヘッド２０５に転送する前の画像データをラスタデータとして格納する。記録ヘッド２０５は、インクを滴として吐出可能な複数の記録素子を有するインクジェット方式の記録ヘッドであり、記録バッファ２０４に格納された画像データに従って、各記録素子からインクを吐出する。シアン（Ｃ）、マゼンタ（Ｍ）、イエロー（Ｙ）及びブラック（Ｋ）の４色分の記録素子列が、記録ヘッド２０５上に配列しているが、色数はその限りではない。例えば、上記４色以外に、ライトシアン、ライトマゼンタ、グレー等の記録素子を搭載することがある。また特色系インクとして、レッド、グリーン、ブルーインク、蛍光色系インクの記録素子を搭載することがある。また色以外の機能を有した銀インク、エンボスインク、クリアインク等の記録素子を搭載することもある。更に、ブラック１色の記録素子で構成されることもある。

記録バッファ２０４に蓄積されるデータ量が、記録ヘッド２０５の処理するデータ量に対して不足する場合に、記録ヘッドの動作が停止することでムラが発生する。これを防止するために、記録バッファ２０４にラスタデータを記憶する速度を、記録ヘッド２０５がデータに基づいて記録する速度より速くする必要がある。もう一つの対策としては、記録が終了するまでに記録バッファ２０４からデータが枯渇しない状態までラスタデータを蓄積してから記録を開始することが挙げられる。

給排紙モータ制御部２０６は、シートや用紙等の記録媒体の搬送や給排紙の制御を行い、記録ヘッド２０５から吐出されるインクを紙面の正確な位置に着弾させるよう紙位置を制御する。記録ヘッド２０５がマルチパス構成である場合も考慮して、搬送用モータのスタート・ストップ動作を実施する。

記録装置Ｉ／Ｆ２０７は、画像処理装置２０２との間でデータ信号の授受を行う。Ｉ／Ｆ信号線２１７は、両者を接続する。Ｉ／Ｆ信号線２１７の種類としては、例えばセントロニクス社の仕様のものを適用することができる。データバッファ２０８は、画像処理装置２０２から受信した画像データを一時的に格納する。操作部２０９は、開発者によるコマンド操作を行うための機構を持つ。システムバス２１０は、記録装置２０１の各機能部を接続する。

次に画像処理装置２０２を説明する。

画像処理装置の主制御部２１１は、外部Ｉ／Ｆ２１６から供給された画像データに基づいて、記録装置２０１が記録可能な印刷データを生成するためのもので、ＣＰＵ、ＲＯＭ、ＲＡＭ等を備えている。主制御部２１１は、他に外部Ｉ／Ｆからの要求に対して対応するデータの返却も行う。画像処理装置２０２で使用する画像データの生成に必要な、例えばルックアップテーブルやマトリクスは、画像処理装置の主制御部２１１のＲＯＭに予め記録されている。画像処理装置Ｉ／Ｆ２１２は、記録装置２０１との間でデータ信号の授受を行う。外部Ｉ／Ｆ２１６は、例えばホストデバイスなどの情報処理装置から、画像データなどの授受を行う。表示部２１３は、ユーザに対し様々な情報を表示し、例えば液晶表示部などを適用することができる。操作部２１４は、ユーザがコマンド操作を行うための機構であり、例えばキーボードやポインティングデバイス等を有している。システムバス２１５は、主制御部２１１と各機能部とを結ぶ。

画像処理部２１９は画像処理を行う。外部Ｉ／Ｆ２１６を通して入力される画像データにはＪＰＥＧやＰＮＧなど、記録装置２０１で記録できない画像データも存在する。画像処理部２１９は、これらのデータにデコードやＣＭＹＫ変換などを実行し、記録装置２０１で記録可能な印刷データを生成する。こうして生成された印刷データは、画像処理装置Ｉ／Ｆ２１２を介して記録装置２０１へ送信される。

以下、実施形態に係る情報処理装置１００を説明する。

図３は、実施形態に係る情報処理装置１００が印刷データを生成してプリンタ１１４へ送信する処理を説明するフローチャートである。尚、このフローチャートで示す処理は、ＣＰＵ１０１がＲＡＭ１０３に展開したプログラムを実行することにより達成される。

まずＳ３０１でＣＰＵ１０１は、変更可能なロジックを取得する。このロジックの取得は、情報処理装置１００搭載のブラウザ４０１（図４）を用いて、外部Ｉ／Ｆ１０８を介して接続されたプリンタ１１４からｈｔｔｐプロトコルで取得する。

図４は、実施形態に係る情報処理装置１００がプリンタ１１４或いはサーバからデータを取得する例を説明する図である。

ブラウザ４０１及び専用ソフト４０２は情報処理装置１００で実行されている。プリンタ１１４は、ブラウザ４０１からの問い合わせに対しＨＴＭＬファイル、ＪａｖａＳｃｒｉｐｔファイル、ＷＡＳＭ（ＷｅｂＡｓｓｅｍｂｌｙファイル）を返却する。このＨＴＭＬファイルには、アプリのＵＩに関する記述がなされており、ＪａｖａＳｃｒｉｐｔと共にＵＩを構築するために用いられる。このＪａｖａＳｃｒｉｐｔファイルは、ＪａｖａＳｃｒｉｐｔというスクリプト言語で記載されたプログラムである。そして、ＪａｖａＳｃｒｉｐｔファイルには、動的にファイルを変更するためのロジックが記載されており、このロジックを用いることで部分的な処理の変更を可能とする。なおここで取得されるＪａｖａＳｃｒｉｐｔファイルは、コンパイルされていないものとする。そして、ＪａｖａＳｃｒｉｐｔファイルが実行される場合に、情報処理装置１００においてコンパイルされるものとする。すなわちＪａｖａＳｃｒｉｐｔにより作成されたロジックは情報処理装置１００においてアプリケーションの実行時にコンパイルされＣＰＵ１０１により実行される。なおブラウザ４０１を含め通常のブラウザはＪａｖａＳｃｒｉｐｔエンジンを搭載しており、このＪａｖａＳｃｒｉｐｔエンジンによりＪａｖａＳｃｒｉｐｔは実行時に動的にコンパイルがされる。ＷＡＳＭファイルは、プリンタ１１４内部で実行される印刷データの生成処理のロジックであり、このＷＡＳＭファイルを実行することで、ブラウザ４０１上でプリンタ１１４内部の処理と同等の印刷データの生成処理が実行される。さらに、本発明においては、ＷＡＳＭファイルは、情報処理装置１００が取得する前に予めコンパイルされたプログラムである。具体的には、予めコンパイルされたＷＡＳＭファイルをプリンタ１１４が有しており、そのＷＡＳＭファイルを情報処理装置１００が取得する。なおプリンタ１１４が有するＷＡＳＭファイルは、プリンタ１１４でコンパイルが実行されたファイルであっても良いし、外部のサーバコンパイルが実行されたファイルであっても良い。また本発明においてＷＡＳＭファイルは、ＷｅｂＡｓｓｅｍｂｌｙで記載された命令セットのことである。なおＷＡＳＭファイルはＪａｖａＳｃｒｉｐｔファイルから利用可能である。

プリンタ１１４での通信処理は、画像処理装置の主制御部２１１で制御される。プリンタ１１４から情報処理装置１００に返却されるファイルは、本実施形態ではＨＴＭＬファイル、ＪａｖａＳｃｒｉｐｔファイル、ＷＡＳＭファイルであるが、これに限定されるものではない。また通信プロトコルは、ブラウザ４０１が利用できるものであれば何でもよく、ｈｔｔｐ通信に制限されるものではない。例えば、ｈｔｔｐｓを用いて通信のセキュリティを高めたり、ＷｅｂＳｏｃｋｅｔを用いて通信の高速化を図っても良い。

また実施形態では、ブラウザ４０１からプリンタ１１４に問い合わせをして、そのプリンタ１１４に紐づいた印刷データの生成ロジックを記述したファイルを取得しているが、ファイルの取得はこれに限定されない。例えば、サーバ１１１～１１３から受け取っても良いし、ファイル要求を出すクライアントソフトは専用ソフト４０２でも良い。サーバ１１１～１１３からデータを受け取る場合、手元にプリンタ本体がなくても印刷データの生成処理の変更が行える利点がある。

専用ソフト４０２を用いる場合は、クライアントソフトをＮａｔｉｖｅで記載できるため、ブラウザが利用できない任意の通信プロトコルを利用することが可能となる。加えて、一度通信して取得したファイルを記憶領域４０３（２次記憶装置１０５）に保存しておくことで、２回目以降は、サーバと通信しなくても印刷データの生成処理の変更操作が可能となる。更に、ロジックを変更した後の処理をカスタムファイル４０６として保存し、使い回すことも可能となる。また専用ソフト４０２を用いる場合は、内部のローカルサーバ４０４を実行して、記憶領域４０３からファイルを読み込ませればよい。Ｗｅｂエンジン４０５は、ＪａｖａＳｃｒｉｐｔなどを解釈して処理を実行する。専用ソフト４０２のようにＷｅｂエンジン４０５を抱え込むと、ブラウザ４０１のバージョン変更による影響を受けることがなくなる利点もある。

次にＳ３０２に進みＣＰＵ１０１は、ＵＩを表示する。このＵＩの表示は、外部Ｉ／Ｆ１０６等を介して接続された外部のディスプレイで行ってもよいし、例えば、スマートフォンであれば、そのスマートフォンに搭載されているタッチパネルディスプレイに表示すればよい。

図５（Ａ）は、Ｓ３０２のＵＩ表示で表示されるメインフロー画面の一例を示す図である。

実施形態に係るＵＩ表示では、このメインフロー画面５００が表示される。このメインフロー画面５００には、印刷データの生成処理のフローと各項目を示したブロック５０１～５０６と、最終的に印刷実行を指示する実行ボタン５０７が表示される。ユーザは、メインフロー画面５００から任意の項目を選択して印刷データの生成処理を変更することができる。

次にＳ３０３に進みＣＰＵ１０１は、ユーザからの印刷データの生成処理を変更する指示を受け取ると、ユーザの指示に従って印刷データの生成処理のロジックを変更する。ＵＩブロック５０１～５０６はそれぞれ、図６の印刷データの生成処理６０２～６０６に対応し、以後、６０７～６０８も含めた印刷データの生成処理を「処理ブロック」と記載する。尚、印刷データの生成処理は、これら印刷データの生成処理６０２～６０６に限定されるものではない。

図６は、実施形態に係る情報処理装置１００において印刷データを生成して送信するまでの処理の流れを説明する図である。印刷データの生成処理ブロック６０２～６０６は、図５のブロック５０１～５０６と対応している。

以後、印刷データの生成処理ブロック６０２～６０８、及び、ＵＩを含めたホストデバイス上で動作するシステム全体を「印刷データの生成フレームワーク」６００と記載する。ここで、処理ブロック群６１０（６０２～６０６）はＵＩでユーザに提示され、ユーザが変更などの指示を与えることが可能な処理ブロックである。処理ブロック群６１１（６０７～６０８）は、ユーザには提示せず印刷データの生成フレームワーク６００が処理する処理ブロックである。処理ブロック群６１１の処理もＷＡＳＭでプリンタ１１４から提供されており、各処理は一つのＷＡＳＭファイルにまとまっていても良いし、複数のＷＡＳＭファイルで提供されていても良い。すなわち、予めコンパイルされた利用可能なロジックが提供されていれば、提供の形態はどのようなものであっても良い。

まず入力画像６０１は、印刷データの生成処理の処理対象となる、入力された画像データである。入力画像６０１は、図５（Ａ）のメインフロー画面５００の入力画像選択ブロック５０１をユーザがクリックすることで取得される。画像データの取得は、ＨＴＭＬであれば＜ｉｎｐｕｔ＞タグを用いることでホストデバイスのファイルから画像データを取得できる。他にもＪａｖａＳｃｒｉｐｔのｆｅｔｃｈ関数などを用いて、インターネット１１０経由で外部から画像ファイルを取得することも可能である。こうして入力画像選択ブロック５０１で選択されて入力された画像データはデコードされ、データ解析６０２へ入力される前に、ＲＧＢ各８ビットの２４ビットのデータに展開されているものとし、下記のフォーマットで保持されているものとする。
let image = {
width: 画像の横幅
height: 画像の縦幅
channels: 3 // RGBの3チャネル
depth: 8 // 演算精度。16bitなら16
data: 画像データ
colorSpace: “AdobeRGB”
}
データ解析６０２は、印刷データの生成処理で一番初めに画像データが渡される箇所であり、画像データの解析を行う。

インクジェットプリンタでは、黒い領域を印刷するのにＣＭＹ（シアン、マゼンタ、イエロー）インクを混ぜる方法は使わない。なぜならＣＭＹインクを混ぜる方法では理論的には黒になるが技術的に再現するのは困難であることに加え、インク消費量も３色分と多くなり、黒インク（Ｋ）を利用した方が合理的だからである。そのため、黒い領域には、黒（Ｋ）インクを用いることが一般的である。ここで言う黒い領域は、例えばドキュメントの文字領域がそれにあたる。しかしドキュメントと言っても黒い文字だけのドキュメントもあれば、図が挿入されているドキュメントもある。このようなドキュメントにおいてＣＭＹインクで打つ領域と、Ｋインクで打つ領域を適切に分離することが画質向上やインク（記録材）の消費量の削減につながる。この領域分離を行う部分がデータ解析６０２であり、画像中の文字領域と文字領域以外を解析し、その解析結果をデータとして保存する役目を持つ。データの保持はＲＡＭ１０３に記憶すれば良く、専用アプリを用いる場合は２次記憶装置１０５に保存しても良い。データ解析６０２を実行すると次にエラーチェック６２０を行う。ここでエラーが検出されなければ前処理６０３に進む。

前処理６０３は、ＲＧＢで入力されたデータを変更してＲＧＢデータで出力する。ここで例えば前処理６０３を変更したい場合、ユーザはメインフロー画面５００の前処理ブロック５０３をクリックする。前処理ブロック５０３がクリックされると、図５（Ｂ）に示す前処理編集画面５１０が表示される。

図５（Ｂ）は、図５（Ａ）の前処理ブロック５０３がクリックされることにより表示される前処理編集画面５１０の一例を示す図である。

この前処理編集画面５１０では、３種類の印刷データの生成処理のいずれかを選択して指定でき、ここではプリセットボタン５１１、直接編集ボタン５１２、ファイル選択ボタン５１３のいずれかをクリックすることで選択できる。

プリセットボタン５１１は、複数のプリセット処理の中から処理を選択でき、これらのプリセット処理は、前述のＳ３０１でプリンタ１１４にアクセスしたタイミングで取得されている。前処理の例としては、例えば色空間変換が挙げられる。

一般的に画像のデジタルデータは各ピクセルがＲＧＢで構成され、各８ビットで表現されている。この場合、最小値は０、最大値は２５５となり、例えば（Ｒ，Ｇ，Ｂ）＝（０，０，０）であれば黒を示し、（Ｒ，Ｇ，Ｂ）＝（０，２５５，０）であれば緑を示す。２５５は８ビットの最大値であり、例えば（Ｒ，Ｇ，Ｂ）＝（０，２５５，０）は、緑の最大出力を示す。

一方、画像データを表示するディスプレイには様々な種類があり、色の表現力が異なる。ここで緑色の表現力の高いディスプレイＡと、緑色の表現力が低いディスプレイＢがある場合、（Ｒ，Ｇ，Ｂ）＝（０，２５５，０）を表示すると、デジタルデータは同じあるが、人の目からは同じ色に見えないという状況が発生する。具体的には、ディスプレイＡは、ＡｄｏｂｅＲＧＢモニタであり、ディスプレイＢはｓＲＧＢディスプレイなどの場合がそれに該当する。つまり、ＲＧＢ各８ビットのデータを同一にしただけでは、ディスプレイをまたいだ時に、人の目から見て同じ色を表現することができない。このような表現の差を低減するのが色空間と色空間変換処理である。色空間とは、表現できる色の範囲（色域）を示し、ｓＲＧＢ、ＡｄｏｂｅＲＧＢ、ＤｉｓｐｌａｙＰ３などが存在する。この色空間とＲＧＢデータとを組み合わせて画像データとして保存することで、ディスプレイをまたいでも同じ色に近づけることが可能となる。この変換処理を色空間変換という。

複数のプリセットの中から処理を選択する際、例えばｓＲＧＢからプリンタ色空間（ＤｅｖｉｃｅＲＧＢ）への色空間変換処理、ＡｄｏｂｅＲＧＢからプリンタ色空間への色空間変換処理等がプリセット処理として用意されているものとする。プリセット処理には、これ以外にも、例えば輝度を明るくする処理や、エッジ強調処理、スムージング処理などがあっても良く、上述の色空間変換に限定されるものではなく、また、これらを複数選択できる構成でも良い。

直接編集ボタン５１２は、ＪａｖａＳｃｒｉｐｔにより直接、プログラムを記載できる。直接編集ボタン５１２が押下されると、図５（Ｂ）のように編集領域５１４が表示される。ユーザは、この編集領域５１４を介して、実行したい処理を実装することができる。ＪａｖａＳｒｉｐｔでは動的に処理をコンパイルするため、実施形態のように後から処理を上書きする構成が可能となる。

編集領域５１４には、前処理６０３へ入力されるデータや、各データの説明、出力すべきデータが表示されており、ユーザはこれらの情報を基にプログラムを記述する。また、前処理６０３の変更に際して、全てを置き換える場合もあれば、元の前処理に新しい処理を追加する方法を採用したい状況も想定される。このような状況に対応するために、プリンタ１１４から取得した前処理６０３に関するＷＡＳＭファイルを実行する手段も同時に提供する。処理の変更は、前述のように処理を変更、追加するだけではなく、処理を一切スキップすることも変更の内に入ることとする。

直接編集ボタン５１２による編集では、ＪａｖａＳｃｒｉｐｔで記載可能であり、ＪａｖａＳｃｒｉｐｔが利用できる機能が活用できる。例えばＷｅｂＧＬなどのＡＰＩを用いればＧＰＵでの処理も可能となり、変更後の印刷データの生成処理の高速化が期待できる。

ファイル選択ボタン５１３が押下されると、印刷データの生成処理の変更を外部ファイルの読み込みで実現できる。このとき読み込むファイルは、特定のルールに従った記述を条件とし、そのルールに基づくことで処理ロジックの読み込みを可能とする。例えば印刷データの生成フレームワーク６００に処理ブロックを上書きするための上書き関数を用意しておき、外部ファイルは、必ず、この上書き関数を呼び出すことを条件とする等が特定のルールにあたる。当然、特定のルールがこれに制限されるわけではない。

このように、処理ロジックを規定する外部ファイルを読み込んで印刷データの生成処理を変更できるようにすることで、一度生成した処理を使い回したり、第三者が用意したファイルを利用するなどの利便性の向上が図れる。また外部ファイルの生成は、直接編集ボタン５１２による編集で生成したものを、エクスポートボタン５１５の押下に応じてエクスポートして生成しても良い。ブラウザ４０１では、ＷＡＳＭが利用できるので、外部ファイルの読み込みはＪａｖａＳｃｒｉｐｔとＷＡＳＭを読み込み、読み込ませたＷＡＳＭを利用させても良い。ＷＡＳＭを生成可能なプログラミング言語であるＣ／Ｃ＋＋やＲＵＳＴは、並列処理の記載が可能であり、これを用いることで並列処理による高速化が期待できる。

以上が本実施形態に係る前処理６０３の変換方法である。ここでは、前処理で８ビット精度のＲＧＢデータ入力を、１０ビット精度のＲＧＢデータへ拡張するものとする。またユーザは、直接編集ボタン５１２による編集により、ＡｄｏｂｅＲＧＢ色空間をプリンタ１１４の色空間であるＤｅｖｉｃｅＲＧＢに独自処理で変換し、同時に８ビットから１０ビットへの拡張処理も行うものとする。ここで画像データのビット数を増やす理由は、演算精度を高めるためであり、実際のプリンタでは８ビット以上の精度で演算していることが多い。ビット数を増やす方法は、前述のように決め打ちのビット精度にしても良いし、プリンタ固有の情報であるため、プリンタ１１４へ内部の演算精度を問い合わせて決定しても良い。このように８ビットから１０ビットへ演算精度を上げることにより、ユーザは画素値を０～２５５の範囲ではなく０～１０２３の範囲で扱うこととなる。上記の画像フォーマットに従えば、前処理６０３から後段処理６０４へ渡される画像データは、下記のフォーマットとなる。
image = {
width: 画像の横幅
height: 画像の縦幅
channels: 3
depth: 10 // 10ビットの演算精度
data: 画像データ // Uint16Array
colorSpace: “DeviceRGB”
}
ここで前処理６０３から後段処理６０４へ画像データを渡すときに印刷データの生成フレームワーク６００は、前処理のエラーチェック６２１を行う。実施形態では、後段処理６０４へ１０ビットの画像データが渡されるが、これ以上のビット数のデータは、印刷データの生成フレームワーク６００からすれば想定外である。そのためエラーチェック６２１では、前処理６０３から後段処理６０４へ渡される画像データが１０ビット以下に適応しているかどうか確認する。ここで画像フォーマットのｄａｔａの型は、１６ビットの型（Ｕｉｎｔ１６Ａｒｒａｙ）で定義されているものとする。

図７は、実施形態における画像データと扱うビット数を説明する図である。

図７において、１画素７０４のＲ７０１、Ｇ７０２、Ｂ７０３はそれぞれ１６ビット（２バイト）を扱える領域７０５を保持している。実施形態では、参照番号７０６で示す６ビットは使用しない。１０ビットのデータを取り得る値が０～１０２３であり、その最大値は１０２３である。しかし実施形態では、ＪａｖａＳｃｒｉｐｔはデータを１６ビットの型で処理しているため、実際には１０２４以上の値を入れることが可能である。これに着目すればエラーチェック６２１ですべきことは、前処理６０３から渡される画像データの中に１０２３を超える値が入っていないかをチェックすることである。その他のエラーチェックとしては、画像フォーマットのｃｈａｎｎｅｌｓは３、ｄｅｐｔｈは１０、ｃｏｌｏｒＳｐａｃｅはＤｅｖｉｃｅＲＧＢであることを確認することも考えられる。

このように画像データの値だけではなく、画像フォーマットの中身も確認することで、印刷データの生成フレームワーク６００が意図する各処理ブロックでの出力をユーザに意識させることができる。図６のエラーチェック６２０～６２４のそれぞれでエラーが発覚した場合の通知は、ＪａｖａＳｃｒｉｐｔの機能でエラーをｔｈｒｏｗし、ログにエラーを表示しても良いし、ＵＩでエラーダイアログを表示しても良い。

尚、実施形態では、ＪａｖａＳｃｒｉｐｔのＵｉｎｔ１６Ａｒｒａｙを例に挙げたが、当然これに限定されず、負の値や小数点の値を用いても良く、その場合はそれに応じた値域のチェックを行う。

図６の後段処理６０４からハーフトーニング６０６も前処理６０３と同様に、ユーザが変更可能である。前処理６０３以降、ユーザによるロジックの変更はないものとした上で、各処理ブロックについて説明を続ける。

後段処理６０４は、ＲＧＢデータをＣＭＹＫデータに変換する処理ブロックである。ＰＣやスマートフォンなどでは画像データはＲＧＢで扱われる。これらの画面は発光能力があるため、ＲＧＢの加法混色で色を表現する。それに対しプリンタによる印刷物は発光しないため減法混色によって色を表現する。減法混色では、色を表現するのにＣＭＹデータが必要となる。プリンタ１１４では、このＣＭＹインクに黒（Ｋ）インクを追加し、ＣＭＹＫで印刷を行う。つまり最終的に印刷に必要なデータは、ＣＭＹＫに関するデータであるため、どこかのタイミングでＲＧＢデータをＣＭＹＫデータに変換する必要がある。実施形態では、それが後段処理６０４で行われる。例えば、ＲＧＢデータをＣＭＹＫデータに変換する式の例として下記の式が挙げられる。
K = 1023 - max(R, G, B);
C = (1023 - R - K) / (1023 - K);
M = (1023 - G - K) / (1023 - K);
Y = (1023 - B - K) / (1023 - K);
ここでｍａｘは、与えられた引数から最大値を取得する関数である。

しかしながら上述の処理を実際に使うことはない。なぜなら印刷される色はＣＭＹＫデータだけではなく、プリンタ１１４に搭載されているインク特性や、プリンタ１１４自身のメカ精度、ハーフトーニングによるインクの打ち込み場所によって大きく異なるためである。よって後段処理６０４におけるＲＧＢデータをＣＭＹＫデータに変換する処理は、プリンタベンダー各社が独自に作り込む箇所である。

しかしながら、ここでもユーザがカスタマイズする余地はある。例えば後段処理６０４は、プリンタ１１４から取得した、変更可能な印刷データの生成ロジックに基づく処理を実行してＣＭＹＫデータに変更した後、ＣＭＹＫデータの量を半分にするということも可能である。ＣＭＹＫデータを半分にするということは、単純にインクの吐出量が減らされるため、薄くても良いからインクの消費量を減らしたいユーザによっては好適である。また、例えばプリンタ１１４に問い合わせた結果、Ｃインクの残量が少ないのであれば、ＣＭＹＫデータの内、Ｃのデータ量を減少することで、シアンのインク切れを先延ばしすることもできる。

一体型インクカートリッジと呼ばれるインクと記録ヘッドとが一体型のタイプでは、一つのカートリッジにＣＭＹインクが含まれており、いずれか一つの色がなくなったタイミングでカートリッジを変更しないといけない。ＣＭＹデータの値をカスタマイズすることで、インクの使用量を均一化して、カートリッジの交換サイクルを伸ばすことが期待できる。

ここで後段処理６０４からガンマ補正６０５に渡される画像フォーマットは、以下の通りとなる。
image = {
width: 画像の横幅
height: 画像の縦幅
channels: 4 // CMYK
depth: 10 // 10ビットの演算精度。
data: 画像データ // Uint16Array
colorSpace: “DeviceCMYK”
}
ガンマ補正６０５では、ＣＭＹＫデータに対するガンマ補正を実行する。

後段処理６０４でＣＭＹＫデータに変換され、それぞれ０～１０２３の値が記憶されている。ここで０はインクを全く打たない値であり、１０２３はインクを最大まで吐出する値となる。ここで０～１０２３の値に対応して吐出するインク量を制御しても、色の濃さが吐出量に比例して濃くなってゆくわけではない。何もない白い紙にインクを打ち込んでゆけば徐々に濃くなってゆくのが視認できるが、ある程度色が飽和してくると同じ量のインク打ち込んでも濃くなる度合が弱くなってくる。これは人間の視覚特性やインクの特性、プリンタのＤＰＩ（Ｄｏｔｓ Ｐｅｒ Ｉｎｃｈ）など様々な要因は考えられるが、それらを加味して調整するのがガンマ補正６０５の処理である。例えばＣＭＫＹデータを下記のように変更する。

γ = 2.2;
C = 1023 * pow(1.0 - (C/1023), γ);
M = 1023 * pow(1.0 - (M/1023), γ);
Y = 1023 * pow(1.0 - (Y/1023), γ);
K = 1023 * pow(1.0 - (K/1023), γ);
ここで、ｐｏｗ（ａ，ｂ）はａをｂ乗する関数である。

後段処理６０４を変更したユーザであれば、ガンマ補正６０５も編集することで、より人間の視覚特性を加味したＣＭＹＫデータを生成することができる。また、一般的にガンマ補正は、画像の暗部や明部の強調に使うことがあり、ガンマ補正６０５をそのような用途に用いることも可能である。

ガンマ補正６０４までは、ＣＭＹＫデータはデジタルデータとして０～１０２３の値で管理されていた。しかし実際にプリンタ１１４で印刷するとなると「インクを打つ」「インクを打たない」の２種類しか選択できない。上記２種類の他に「少しだけ打つ」、「多めに打つ」などのバリエーションがあるプリンタも存在するが、デジタルデータで示される１０２４段階に比べたら断然少ない。そこでプリンタは人間の目に知覚出来ないレベルでの極小領域に対して「インクを打つ領域」「インクを打たない領域」の疎密を形成することで濃淡を表現している。この「インクを打つ領域」「インクを打たない領域」をデジタルデータ的に生成するのがハーフトーニング６０６で、本実施形態では「打つ」「打たない」の２値のみを扱うものとする。ハーフトーニング処理は広く知られている技術であり、ディザ法や、誤差拡散法などが存在する。

ハーフトーニング処理で問題となるのは、例えば「細線処理」であり、ユーザはハーフトーニング６０６を変更することで、独自に細線処理を記載することが可能となる。細線とは細い線であり、建築物の設計図を印刷する際によく登場する。ハーフトーニング６０６は、「打つ」「打たない」領域を２分するため、細い線の途中が「打たない」と判定されると線が欠けてしまう問題がある。これを防止するために、細い線がある場合は途中を分断しないように調整する必要がある。

ここで、印刷データの生成フレームワーク６００は、データ解析６０２において入力画像６０１を解析しており、その結果がＲＡＭ１０３に保存されている。またデータ解析６０２では細線の検知も行われていたものとする。細線の検知は、例えばエッジ検出などの技術を用いれば良い。前述のようにエッジが検出されていれば、エッジの部分に関して途中で断絶が起きないように「打つ」という判定に書き換えてしまえば良い。

このようにデータ解析６０２の解析結果を後の処理ブロックにつなげることも可能であり、当然、解析結果を利用できる処理はハーフトーニング処理に限定されない。

上記のようにユーザは、メインフロー画面５００のブロック５０１～５０６で任意の処理を変更した後、実行ボタン５０７を押下する。これにより図３のＳ３０４の印刷データの生成処理が開始される。こうして印刷データの生成フレームワーク６００は、印刷データを生成する。次に印刷データの生成フレームワーク６００が実行する、処理ブロック群６１１の処理ブロック６０７，６０８について説明する。

ハーフトーニング６０６で生成された結果は、ＣＭＹＫデータのそれぞれで「打つ」「打たない」の２値情報であり、下記の画像フォーマットになっている。
image = {
width: 画像の横幅
height: 画像の縦幅
channels: 4 // CMYK
depth: 1 // 「打つ」「打たない」の１ビット
data: 画像データ // uint8Array()
colorSpace: “none”
}
ここで、ｄａｔａに関しては圧縮がかけられる。今までは１６ビットの領域を確保し１０ビットの演算精度で処理していたが、ハーフトーニング６０６の後は１ビットで表現できる情報になっている。

図８は、ビットシフトによるシアン（Ｃ）データのデータ圧縮を説明する図である。

図中の８０１は、シアンのｘ、ｙ座標が（０，０）のハーフトーニング処理後のデータを示している。同様に８０２は、シアンのｘ、ｙ座標が（１５，０）のハーフトーニング処理後のデータを示している。これらのデータは、参照番号８０３で示すように１ビットで表現でき、１６ビットの領域を使うのはリソースの無駄遣いである。このようにデータを詰めて再生成することでデータの圧縮になる。

また、画像データは近くの画素と似た画素値を持つ場合が多いという特性を持つ。つまり同じ値が連続する場合が多く、上記の圧縮の他にもランレングス圧縮や、ハフマン符号などの圧縮アルゴリズムを併用することで、更なるデータ圧縮が期待できる。参照番号８０４は、シフト演算によってビットを詰める処理がなされた「シフト圧縮」結果を示している。尚、上記圧縮処理は画像フォーマットをＣＭＹＫそれぞれに分離してから実行されるものとし、圧縮後の下記つの画像がエンディアン処理６０８に送信される。
imageC = {
width: 画像の横幅
height: 画像の縦幅
channels: 1 // C
depth: 1 //１ビット。
data: 画像データ // uint16Array()
colorSpace: “none”
}
imageM = {
width: 画像の横幅
height: 画像の縦幅
channels: 1 // M
depth: 1 //１ビット。
data: 画像データ // uint16Array()
colorSpace: “none”
}

imageY = {
width: 画像の横幅
height: 画像の縦幅
channels: 1 // Y
depth: 1 //１ビット。
data: 画像データ // uint16Array()
colorSpace: “none”
}

imageK = {
width: 画像の横幅
height: 画像の縦幅
channels: 1 // K
depth: 1 //１ビット。
data: 画像データ // uint16Array()
colorSpace: “none”
}
エンディアン処理６０８において、エンディアンとは８ビット（１バイト）単位でみた時のデータの並び順であり、ビッグエンディアン、リトルエンディアンなどが存在する。どの方式が採用されているかはＣＰＵにより異なり、エンディアンが異なる場合はデータの整合性を保つためにバイトの並びを変更する必要がある。これを行うのがエンディアン処理６０８である。

エンディアン処理６０８に必要な情報は、情報処理装置１００のエンディアン方式と、印刷データの送信対象であるプリンタ１１４のエンディアン方式である。従って、情報処理装置１００は、プリンタ１１４に対してエンディアン方式に関する情報の問い合わせを行う。これにより受信したエンディアン方式が情報処理装置１００のエンディアン方式と異なる場合は、このエンディアン処理６０８を実施する。但し、エンディアンの方式が同じである場合は、このエンディアン処理６０８はスキップして良い。

次に図３に戻り、Ｓ３０４で印刷デーを生成するとＳ３０５に進み、印刷データをプリンタ１１４に送信する。これは図６の印刷データの送信６０９に対応する。

実施形態では、情報処理装置１００は、プリンタ１１４へプリンタ固有の情報をリクエストしていたが、これらはどのようなリクエストであるかを送信データに含めていたためプリンタ１１４が正しく応答できた。本実施形態におけるプリンタ１１４への印刷開始指示はｈｔｔｐ通信のＰＯＳＴメソッドを用い、印刷データの実体はデータフォーマット９００を用いることで、プリンタ１１４が印刷処理を開始できるものとする。

図９は、実施形態に係る情報処理装置１００からプリンタ１１４に送信する印刷データのデータフォーマットを説明する図である。

ここで参照番号９０１は、データフォーマットにおけるアドレスを示しており、参照番号９０２は、アドレス９０１に格納されるバイト数を示している。参照番号９０３は、圧縮の種類を示している。ここで「シフト圧縮」は、図８の参照番号８０４で示すようなシフト演算によってビットを詰める処理を意味している。

プリンタ１１４は、ｈｔｔｐ通信のＰＯＳＴメソッドで送られてきたデータの実体の先頭の値が「０ｘａ」であることをトリガーにして印刷を開始する。

実際の運用では、情報処理装置１００はプリンタ１１４に印刷可能な状態かを問い合わせて、印刷可能な場合にデータを送信することが好ましい。プリンタ１１４が何かしらの印刷を実行中で、新たなデータを受け付けられない場合は、ＵＩでその旨を通知する。もしくは、プリンタ１１４がデータ受付可能な状態になるまで、情報処理装置１００はＲＡＭ１０３や２次記憶装置１０５にデータを保持しておき、受付可能となったタイミングで自動的にデータ送信を開始するなどが考えられる。

また、データフォーマット９００は、参照番号９０６～９０９で示すように、ＣＭＹＫデータをそれぞれ一面分ずつ保持しているが、ＣＭＹＫデータを一行ずつ保持しても良い。

図１０は、実施形態に係る情報処理装置１００からプリンタ１１４に送信する印刷データの他のデータフォーマットを説明する図である。

ここでは、情報処理装置１００からプリンタ１１４に、１行ずつデータを送信するときのデータフォーマットを示している。

このように一行ずつデータを送信できるフォーマット９１０であれば、プリンタ１１４は全データの受信を待たずとも印刷を開始できるメリットがある。また、プリンタ１１４でデータを保持しておくためのバッファが低容量で済むため、プリンタのコストダウンも期待できる。

以上が情報処理装置１００の動作である。

情報処理装置１００がプリンタ１１４にデータを送信した後、プリンタ１１４は外部Ｉ／Ｆ２１６を介して画像処理装置の主制御部２１１がデータを受信する。受信したデータが記録装置２０１へ直接送信して印刷できるデータの場合は、画像処理部２１９での画像処理を実行せずに画像処理装置Ｉ／Ｆ２１２を介して記録装置２０１へ送信する。例えばデータ復号など何かしらの処理が必要な場合は、画像処理部２１９で画像処理を実行してから記録装置２０１へ処理したデータを送信する。

また、印刷データの生成フレームワーク６００は処理ロジック変更の他に、メモリ確保とメモリ解放の手段を提供する。プログラムは、通常、予め確保した領域とは別に、Ｃ言語でいうｍａｌｌｏｃ関数などで動的にメモリを確保して利用することが多い。印刷データの生成フレームワーク６００においてもプログラム実行中の動的なメモリの確保や解放が存在するが、ＷＡＳＭを利用してメモリを確保する場合、その解放が必要となる。

ＪａｖａＳｃｒｉｐｔであれば、ガベージコレクションが実装されているためメモリ解放は不要であるが、ＷＡＳＭの場合は手動で解放する必要がある。しかしながらＪａｖａＳｃｒｉｐｔに慣れ親しんだユーザは、メモリの解放を意識することが少ないため、メモリ解放のし忘れることも容易に想定でき、それが思わぬバグの原因となる。よって、印刷データの生成フレームワーク６００は、メモリの確保、及び、メモリの解放を担保する手段を提供する必要がある。

印刷データの生成フレームワーク６００は、印刷送信データ送信６０９の後に、メモリの確保はされたが、解放されていないメモリが存在する場合、ユーザに代わってメモリの解放を行う。メモリの確保とメモリの解放の手段は、例えば、ユーザもＷＡＳＭを利用してロジックを記載し、それをＪａｖａＳｃｒｉｐｔから実行する状況などにおいて利用される。

以上説明したように実施形態によれば、印刷を実行するプリンタに紐づいた印刷データを生成する印刷データの生成ロジックの少なくとも一部を、ユーザが意図する仕様に変更して印刷データを生成することができる。こうしてスクリプト言語での懸念事項を抑えつつ、プリンタで印刷される印刷データの生成を情報処理装置側で動的に変更でき、かつ、本来の印刷データの生成処理も併用できる状態で印刷データを生成できる。

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

本発明は上記実施形態に制限されるものではなく、本発明の精神及び範囲から逸脱することなく、様々な変更及び変形が可能である。従って、本発明の範囲を公にするために、以下の請求項を添付する。

１００…情報処理装置、１０１…ＣＰＵ、１０３…ＲＡＭ、１０４…ＲＯＭ、１１４…プリンタ、２０１…記録装置、２０２…画像処理装置、２０３…記録装置の主制御部、２０４…記録バッファ、２０５…記録ヘッド、２１１…画像処理装置の主制御部、２１９…画像処理部

Claims (17)

1. 情報処理装置で動作するときに解釈され実行される第一プログラムと、前記第一プログラムから利用できる予めコンパイルされた第二プログラムとを用いて印刷データを生成する情報処理装置であって、
   印刷データを生成する変更可能な第一生成ロジックであって、印刷を実行するプリンタに紐づいた前記第一生成ロジックを取得する取得手段と、
   前記第一生成ロジックの少なくとも一部が変更された第二生成ロジックを生成する変更手段と、
   入力された画像データと、前記第二生成ロジックとを用いて前記プリンタで印刷するための印刷データを生成する生成手段と、
   前記生成手段で生成された前記印刷データを前記プリンタへ送信する送信手段とを有し、
   前記第一生成ロジックは、前記第二プログラムを利用して実行されることを特徴とする情報処理装置。
2. 前記変更手段は、前記第一生成ロジックに含まれる処理ブロックを表示し、表示された処理ブロックからユーザに選択された処理ブロックを変更することを特徴とする請求項１に記載の情報処理装置。
3. 前記変更手段は、前記第一生成ロジックの選択された処理ブロックを直接編集する、又はプリセットされている生成ロジックを利用して前記選択された処理ブロックを変更する、もしくは、処理ロジックを規定する外部ファイルを入力して前記選択された処理ブロックを変更することにより前記第二生成ロジックを生成することを特徴とする請求項２に記載の情報処理装置。
4. 前記変更手段により変更された前記選択された処理ブロックが適応できるかを確認する手段を、更に有することを特徴とする請求項２又は３に記載の情報処理装置。
5. 前記変更手段による変更は、前記画像データの画素値の演算精度、或いは前記プリンタにおける記録材の消費量の変更を含むことを特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
6. 前記取得手段は、前記プリンタから、或いは、サーバから前記第一生成ロジックを取得することを特徴とする請求項１乃至５のいずれか１項に記載の情報処理装置。
7. 前記生成手段は、前記画像データのデータ圧縮を含むことを特徴とする請求項１乃至６のいずれか１項に記載の情報処理装置。
8. 前記データ圧縮は、前記第二プログラムを用いて実行されることを特徴とする請求項７に記載の情報処理装置。
9. 前記生成手段は、前記プリンタに応じたエンディアン処理を実行して前記印刷データを生成することを特徴とする請求項１乃至８のいずれか１項に記載の情報処理装置。
10. 前記生成手段は、前記プリンタから前記エンディアン処理の方式を取得し、当該取得した方式に基づいて前記プリンタに応じたエンディアン処理を実行することを特徴とする請求項９に記載の情報処理装置。
11. 前記生成手段は、前記印刷データの生成のために使用するメモリの確保と、当該メモリを解放する手段を有することを特徴とする請求項１乃至１０のいずれか１項に記載の情報処理装置。
12. 前記第一プログラムは、スクリプト言語で記述されていることを特徴とする請求項１乃至１１のいずれか１項に記載の情報処理装置。
13. 前記スクリプト言語は、ＪａｖａＳｃｒｉｐｔであることを特徴とする請求項１２に記載の情報処理装置。
14. 前記第二プログラムは、前記第一プログラムとは異なるプログラミング言語から生成されることを特徴とする請求項１乃至１３のいずれか１項に記載の情報処理装置。
15. 前記第二プログラムは、ＷｅｂＡｓｓｅｍｂｌｙであることを特徴とする請求項１４に記載の情報処理装置。
16. 情報処理装置で動作するときに解釈され実行される第一プログラムと、前記第一プログラムから利用できる予めコンパイルされた第二プログラムとを用いて印刷データを生成する情報処理装置を制御する制御方法であって、
    印刷データを生成する変更可能な第一生成ロジックであって、印刷を実行するプリンタに紐づいた前記第一生成ロジックを取得する取得工程と、
    前記第一生成ロジックの少なくとも一部が変更された第二生成ロジックを生成する変更工程と、
    入力された画像データと、前記第二生成ロジックとを用いて前記プリンタで印刷するための印刷データを生成する生成工程と、
    前記生成工程で生成された前記印刷データを前記プリンタへ送信する送信工程とを有し、
    前記第一生成ロジックは、前記第二プログラムを利用して実行されることを特徴とする制御方法。
17. コンピュータに、請求項１６に記載の制御方法の各工程を実行させるプログラム。

Images