(57)【要約】【課題】  生成済みのPDF等の電子文書に対して操作することを前提とした技術であるため、動的にPDF等の電子文書を生成しながら従来技術の操作を行うことは困難であり、一旦PDF等の電子文書を生成した後に、従来技術の操作を行うことになるため、効率が悪かった。また、デバイス側で、従来技術に対応した仕組みを備えている必要があり、汎用的な電子文書の直接印刷用デバイスでの利用には不向きであった。【解決手段】  ＰＤＦ等の電子文書を直接デバイスに送信して印刷する場合において、デバイス側の電子文書の受信サイズ制限を回避するために、動的にＰＤＦを生成しながら、１ページ毎に送信可能なサイズであるかをチェックし、その結果を元に、電子文書を分割生成し、全分割電子文書をまとめてデバイスに送信することを特徴とする電子文書処理システム。【選択図】  図１
2007272339.tif 000002
【特許請求の範囲】
【請求項１】
電子文書を直接デバイスに送信して印刷する場合において、デバイス側の電子文書の受信サイズ制限を回避するために、動的にPDFを生成しながら、１ページ毎に送信可能なサイズであるかをチェックし、その結果を元に、電子文書を分割生成し、全分割電子文書をまとめてデバイスに送信することを特徴とする電子文書処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、PDF等の電子文書を直接デバイスに送信して印刷する場合において、デバイス側の電子文書の受信サイズ制限を回避する電子文書処理システムに関するものである。
【背景技術】
【０００２】
従来、PDF等の電子文書を直接デバイスに送信して印刷する場合において、デバイス側の電子文書の受信サイズ制限を回避する方法としては、相互参照表およびトレーラなどの、電子文書内のコンテンツの位置を保持する情報を先にデバイスへ送信し、デバイス側でプリントの際に印刷に必要な情報を送信側に要求し、要求されたデータを送信する技術等が一般的であった（例えば、特許文献１参照。）。
【特許文献１】特開２００４−１７１２０４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、上述した従来の技術は、生成済みのPDF等の電子文書に対して操作することを前提とした技術であるため、動的にPDF等の電子文書を生成しながら従来技術の操作を行うことは困難であり、一旦PDF等の電子文書を生成した後に、従来技術の操作を行うことになるため、効率が悪かった。
【０００４】
また、デバイス側で、従来技術に対応した仕組みを備えている必要があり、汎用的な電子文書の直接印刷用デバイスでの利用には不向きであった。
【課題を解決するための手段】
【０００５】
上述した課題を解決するために、本発明は、PDF等の電子文書を直接デバイスに送信して印刷する場合において、デバイス側の電子文書の受信サイズ制限を回避するために、動的にPDFを生成しながら、１ページ毎に送信可能なサイズであるかをチェックし、PDF受信サイズ制限内に収まるようにPDFを分割することを特徴とする。
【発明の効果】
【０００６】
本発明によって、動的にPDF等の電子文書を生成しながら、デバイス側の電子文書の受信サイズ制限内に収まるように電子文書を分割するため、電子文書を一旦生成し終えてから、相互参照表およびトレーラなどの、電子文書内のコンテンツの位置を保持する情報を抽出したり、送信先デバイスの受信サイズ制限に合わせて電子文書を分割する等の処理時間を省くことが可能となる。
【発明を実施するための最良の形態】
【０００７】
（実施例１）
図３は、本発明における電子文書処理システムの構成を示すブロック図である。図３においては、１はシステムデバイスであり、後述の各構成要素はこのシステムバス１に接続される。２はCPUである。３はプログラムメモリ（以下、PMEMと称す）で、編集処理のためのプログラムを適宜ハードディスク１５から選択して読み込み、CPU２で実行する。
【０００８】
また、キーボード９から入力されたデータはテキストメモリでもあるPMEM３にコード情報として格納される。８は入力制御部であり、９のキーボード、１０のマウス等の入力装置が接続される。操作者はこのキーボード９を操作することによりシステムの動作指令等を行う。１０は、１３のCRT上で画像情報を加工支持するためのポインティング・デバイス（以下、PDと称す）で本実施例ではマウスを使用している。これによりCRT１３上のカーソルをX（横方向）、Y方向（縦方向）任意に移動してコマンドメニュー上のコマンド・アイコンを選択して処理の指示や、編集対象の指示、描画位置の指示等を行う。
【０００９】
１１はビデオイメージメモリ（以下、VRAMと称す）、１２は表示出力制御部、１３はCRTである。CRT１３に表示されるデータは、VRAM１１上にビットマップデータとして展開されている。例えば、文字データであれば、そのコードに対応した文字パターンがVRAMに展開される。また、ソフト制御によりVRAMの表示エリアに直接カーソルを発生して表示することも可能である。１４は外部記憶装置制御部、１５、１６はデータファイル用の外部記憶媒体（ディスクなど）で、たとえば１５はハードディスク（以下、HDと称す）であり、１６はフレキシブルディスク（以下、FDと称す）である。
【００１０】
また、本実施例の文書処理システムは、通信制御部４より通信ポート５、通信回線６を経由して送出される書体/文字サイズ指示情報、印字位置、文字コード列等を受信し、自機内に持つ文字フォント等により印刷ビットマップイメージを展開し印刷出力する複数台のプリンタ７を接続している。
【００１１】
次に本発明に係る実施例１を図面に基づいて説明する。
【００１２】
図１は、本発明に係る電子文書処理システムを説明する代表的なフローチャート図である。
【００１３】
図２は、現在のファイルサイズを取得する処理を説明するフローチャート図である。
【００１４】
[電子文書処理システム]
図１、図２において、本発明に係る実施例１を実施する電子文書処理システムは、ローカルなPC上で使用される。
【００１５】
以下、面付けされたPDFを動的に生成しながら、閾値を元にPDFファイルを分割する方法について、図１、図２を用いて説明する。
【００１６】
S101において、面付けPDFの生成に先立って、１物理ページに面付けをする論理ページ数を設定する。例えば、１物理ページに４つの論理ページを指定する場合は、４となる。
【００１７】
S102において、面付けを行うオリジナルPDFのページ数を、S101で設定した論理ページ数で除算し、その結果の小数部分を切り上げることで、最終的な物理ページ数を計算する。例えば、面付けを行うオリジナルPDFのページ数が15ページであり、設定した論理ページ数が4ページであった場合、14÷4 = 3.5となり、小数部分を切り上げることで、最終的な物理ページ数は4ページとなる。
【００１８】
S103において、PDFを生成する。ここでは、PDFを構成するための必要最小限の情報のみを生成するため、ページに関する情報は存在していない。
【００１９】
S104において、１物理ページ（DSTページ）の面付けを実行する。例えば、４ in １の場合は、１物理ページに対して４論理ページが面付けされることになる。
【００２０】
S105において、生成した物理ページ数の総数を１つカウントアップする。
【００２１】
S106において、現在のPDFファイルサイズを取得するAPIを呼び出す。具体的なPDFファイルサイズの取得方法については後述する。
【００２２】
S107において、S106の結果、現在のPDFファイルサイズを取得できる。
【００２３】
S108において、あらかじめ設定しておいた閾値と、S107で取得した現在のPDFファイルサイズの比較を行う。閾値は、固定的にデバイスの受信ファイルサイズの上限を指定しておいてもよいし、一連の処理を行う前に、あらかじめデバイスから受信ファイルサイズの上限を取得し、閾値として設定しておいてもよい。
【００２４】
S109において、S108の判断の結果、閾値が現在のPDFファイルサイズよりも大きい場合、生成した物理ページの総数が最終的な物理ページ数と等しいかを判断する。
【００２５】
S110において、S109の判断の結果、生成した物理ページの総数が最終的な物理ページ数と等しくない場合、まだ面付けするページが残っているため、次の物理ページの面付け処理を行うために、S104の処理に戻る。
【００２６】
S111において、S108の判断の結果、閾値が現在のPDFファイルサイズよりも小さい場合、または、S109の判断の結果、生成した物理ページの総数が最終的な物理ページ数と等しい場合は、PDFをセーブし、一旦ローカルな記憶装置に保持する。
【００２７】
S112において、閾値が現在のPDFファイルサイズよりも大きい場合、生成した物理ページの総数が最終的な物理ページ数と等しいかを判断する。等しくない場合は、まだ面付けするページが残っているため、次の面付け用新規PDF生成処理を行うため、S103の処理に戻る。等しい場合は、今までローカルな記憶装置に一旦保持していたPDF全てを元に、JDF（Job Definition Format（電子伝票標準書式）)を生成し、MIME（Multipurpose Internet Mail Extensions）でパッケージ化してデバイスに送信する。
【００２８】
S114において、S112で無事データがデバイスに送信されれば終了となる。
【００２９】
[現在のPDFファイルサイズの取得]
以下、現在のPDFファイルサイズをファイルに出力せずに取得する方法について図２を元に説明する。
【００３０】
S201において、現在のPDFファイルサイズを取得するAPIを呼び出す。
【００３１】
S202において、前回のAPI呼び出し以降に登録された新規間接オブジェクトを検出する。
【００３２】
S203において、S202の結果、新規間接オブジェクトが存在するかどうかを判断する。
【００３３】
S204において、新規間接オブジェクトが存在しない場合は、カレントファイルサイズをそのまま返却し、処理を終了する。
【００３４】
S205において、S203の結果、新規間接オブジェクトが存在した場合、新規間接オブジェクトをPDFファイルに書き出した場合のサイズを求め、カレントファイルサイズにその結果を加算する。具体的には、FILE奇術師を空にセットして、fwrite()を行うことでサイズを求める。よって、実際にデータをファイルとして書き出すわけではない。
【００３５】
S206において、新規間接オブジェクトが増加したことにより、クロスリファレンスエントリが増加するため、その分をカレントファイルサイズに加算することで、精度を上げる。
【００３６】
S207において、全ての処理が終了した後、API呼び出し側にカレントファイルサイズを返却し、処理を終了する。
【００３７】
なお、上記はPDFを例に説明したが、構造化電子文書であれば同様の処理が行えることは言うまでもない。
【図面の簡単な説明】
【００３８】
【図１】本発明に係る電子文書処理システムを説明する代表的なフローチャート図である。
【図２】現在のファイルサイズを取得する処理を説明するフローチャート図である。
【図３】本発明における電子文書処理システムの構成を示すブロック図である。
【図１】
2007272339.tif 000003
【図２】
2007272339.tif 000004
【図３】
2007272339.tif 000005