JP2006107033A - フォント情報の埋め込み機能を備える情報処理装置及び情報処理方法及びプログラム並びに記憶媒体 - Google Patents

Abstract

【課題】 電子文書への、グリフを含むフォント情報の埋め込みの有無を切り分けたい場合に、必要なフォント情報が埋め込まれている否かなどを随時確認する必要が生じ、煩雑な作業をユーザに強いる事となる。
【解決手段】 フォント情報を埋め込み可能な電子文書を編集可能な情報処理装置において、電子文書に編集が反映されたことに基づき、フォント情報の埋め込むか否かの問い合わせを行わせる手段を備える仕組みを提供することを目的とする。
【選択図】 図３３

Description

本発明は、フォント情報の埋め込みの仕組みに関する。

従来から、ＰＤＦファイルを生成してフォント情報を埋め込む技術が知られている。この技術によれば、生成した文書自体にフォント情報を保持させることにより、出力側の端末にないフォントでも確実に出力することができ、再現性に優れてた文書を実現することができる。

一方、プリンタと接続されたパーソナルコンピュータ等の情報処理装置からなるシステムであって、さらに、情報処理装置上で、プリンタに送信される印刷データを生成する前に、最終的に前記プリンタに送付する印刷データとは異なる形式のデータ形式（いわゆる中間コード）の電子文書を一時保存し、この電子文書から改めて最終的に所望のプリンタに対して送付する印刷データを生成し送付する印刷システムが存在する。

そして、この中間コードを含む電子文書に、上述のようなグリフを含むフォント情報を埋め込むようにすれば、より一層電子文書に基づく印刷出力物の再現性を向上できることが期待される。
特開２００２−３３４０５９号公報 特開２００２−３３０２７４号公報

しかしながら、電子文書へのグリフを含むフォント情報の埋め込みの有無を切り分けたい場合に、必要なフォント情報が埋め込まれている否かなどを随時確認する必要が生じてくる。例えば、ユーザの気づくごとに、電子文書中のテキストオブジェクトのプロパティーを確認するような形態が想定されるが、ユーザに非常に煩雑な作業を強いることとなり且つ確実性が非常に低下するという問題点がある。

本願発明は上記問題を鑑みてなされたものであり、フォント情報を埋め込み可能な電子文書を編集可能な情報処理装置において、電子文書に編集が反映されたことに基づき、フォント情報の埋め込むか否かの問い合わせを行わせる手段を備える仕組みを提供することを目的とする。

本発明によれば、電子文書に編集が反映されたことに基づいて、適切に、フォント情報を埋め込むか否かの問い合わせを行うことができる。

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

［第１の実施形態］
＜システム概要＞
まず、本発明に係る文書処理システムの概要について、図１乃至図１２を参照して以下に説明する。尚、この文書処理システムは、一般のアプリケーションによって作成されたデータファイルを電子原稿ファイルに変換する電子原稿ライタと、その電子原稿ファイルを編集する機能を提供する製本アプリケーションとを含み、作成されたデータを一まとめにした文書の作成及び編集を可能とし、その操作性を向上させて文書編集を効率的に行えるものである。

＜システム構成及び動作＞
図１は、本実施形態の文書処理システムのソフトウェア構成を示す図である。文書処理システムは、本発明の情報処理装置に好適な実施形態であるデジタルコンピュータ１０１（以下、ホストコンピュータとも呼ぶ）によって実現されている。図１に示す一般アプリケーション１０１は、ワードプロセシングやスプレッドシート、フォトレタッチ、ドロー、あるいはペイント、プレゼンテーション、テキスト編集などの機能を提供するアプリケーションプログラムであり、ＯＳに対する印刷機能を有している。これらのアプリケーションは、作成された文書データや画像データなどのアプリケーションデータを印刷する際に、オペレーティングシステム（ＯＳ）によって提供される所定のインタフェース（一般に、ＧＤＩと呼ばれる）を利用する。即ち、アプリケーション１０１は、作成したデータを印刷するために、上述のインタフェースを提供するＯＳの出力モジュールに対して、あらかじめ定められる、ＯＳに依存する形式の出力コマンド（ＧＤＩ関数と呼ばれる）を送信する。一方、出力コマンドを受けた出力モジュールは、その出力コマンドをプリンタ等の出力デバイスが処理可能な形式に変換して、変換されたコマンド（ＤＤＩ関数と呼ばれる）を出力する。出力デバイスが処理可能な形式はデバイスの種類やメーカ、機種などによって異なるため、デバイスごとにデバイスドライバが提供されており、ＯＳではそのデバイスドライバを利用してコマンドの変換を行い、印刷データを生成し、ＪＬ（Ｊｏｂ Ｌａｎｇｕａｇｅ）でくくることにより印刷ジョブが生成されるう。ＯＳとしてマイクロソフト社のウインドウズを利用する場合には、前述した出力モジュールとしてはＧＤＩ（Ｇｒａｐｈｉｃ Ｄｅｖｉｃｅ Ｉｎｔｅｒｆａｃｅ）と呼ばれるモジュールが相当する。

電子原稿ライタ１０２は、上述のデバイスドライバを改良したものであり、本文書処理システム実現のために提供されるソフトウェアモジュールである。但し、電子原稿ライタ１０２は特定の出力デバイスを目的としておらず、詳細は後述する製本アプリケーション１０４やプリンタドライバ１０６により処理可能な形式に出力コマンドを変換する。この電子原稿ライタ１０２による変換後の形式（以後電子原稿形式と呼ぶ）は、ページ単位の原稿を詳細な書式をもって表現可能であれば特に問わない。実質的な標準形式のうち、例えばアドビシステムズによるＰＤＦ形式やＳＶＧ形式などが電子原稿形式として採用できる。

一般アプリケーション１０１から電子原稿ライタ１０２を利用させる場合には、出力に使用するデバイスドライバとして電子原稿ライタ１０２を指定してから印刷を実行させる。但し、電子原稿ライタ１０２によって作成されたままの電子原稿ファイルは、電子原稿ファイルとして完全な形式を備えていない。そのため、デバイスドライバとして電子原稿ライタ１０２を指定するのは製本アプリケーション１０４であり、その管理下でアプリケーションデータの電子原稿ファイルへの変換が実行される。そして、製本アプリケーション１０４は電子原稿ライタ１０２が生成した新規の不完全な電子原稿ファイルを後述する形式を備えた電子原稿ファイルとして完成させる。以下、この点を明瞭に識別する必要がある場合、電子原稿ライタ１０２によって作成されたファイルを「電子原稿ファイル」と呼び、製本アプリケーション１０４によって構造を与えられた電子原稿ファイルを「ブックファイル」と呼ぶ。また、特に区別する必要がない場合は、アプリケーションにより生成されるドキュメントファイル、電子原稿ファイル、及びブックファイルをいずれも文書ファイル（または文書データ）と呼ぶ。

このようにデバイスドライバとして電子原稿ライタ１０２を指定し、一般アプリケーション１０１によりデータを印刷させることで、アプリケーションデータはアプリケーション１０１によって定義されたページ（以後論理ページあるいは原稿ページと呼ぶ）を単位とする電子原稿形式に変換され、電子原稿ファイル１０３としてハードディスクなどの記憶媒体に格納される。尚、ハードディスクは、本実施形態の文書処理システムを実現するコンピュータが備えているローカルドライブであっても良く、ネットワークに接続されている場合にはネットワーク上に提供されるドライブであっても良い。

製本アプリケーション１０４は電子原稿ファイル（あるいはブックファイル）１０３を読み込み、それを編集するための機能を利用者に提供する。但し、製本アプリケーション１０４は、各ページの内容を編集する機能は提供しておらず、ページを最小単位として構成される、後述する章やブックの構造を編集するための機能を提供している。

製本アプリケーション１０４によって編集されたブックファイル１０３を印刷する際には、製本アプリケーション１０４によって電子原稿デスプーラ１０５が起動される。電子原稿デスプーラ１０５は、製本アプリケーションと共にコンピュータ内にインストールされるプログラムモジュールであり、製本アプリケーションで利用するドキュメント（ブックファイル）を印刷する際に、プリンタドライバへ描画データを出力するために使用されるモジュールである。電子原稿デスプーラ１０５は、指定されたブックファイルをハードディスクから読み出し、ブックファイルに記述された形式で各ページを印刷するために、前述したＯＳの出力モジュールに適合する出力コマンドを生成し、不図示の出力モジュールに出力する。その際に、出力デバイスとして使用されるプリンタ１０７用のプリンタドライバ１０６がデバイスドライバとして指定される。上述の出力モジュールは、受信した出力コマンドをデバイスコマンドに変換して指定されたプリンタ１０７用のプリンタドライバ１０６に出力し、そのプリンタドライバ１０６がプリンタ１０７で解釈実行可能なページ記述言語等のコマンドに変換する。そして、変換されたコマンドはプリンタドライバ１０６から不図示のシステムスプーラを介してプリンタ１０７に送信され、プリンタ１０７によってコマンドに応じた画像が印刷される。

図２は、コンピュータ１００のハードウェアブロック図である。図２において、ＣＰＵ２０１は、ＲＯＭ２０３のプログラム用ＲＯＭに記憶された、あるいはハードディスク２１１からＲＡＭ２０２にロードされたＯＳや一般アプリケーション、製本アプリケーションなどのプログラムを実行し、図１のソフトウェア構成や、後述するフローチャートの手順を実現する。ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。キーボードコントローラ（ＫＢＣ）２０５は、キーボード２０９や不図示のポインティングデバイスからのキー入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）２０６は、ＣＲＴディスプレイ２１０の表示を制御する。ディスクコントローラ（ＤＫＣ）２０７は、ブートプログラム、種々のアプリケーション、フォントデータ、ユーザファイル、後述する編集ファイル等を記憶するハードディスク（ＨＤ）２１１やフロッピー（登録商標）ディスク（ＦＤ）等とのアクセスを制御する。ＰＲＴＣ２０８は、接続されたプリンタ１０７との間の信号の交換を制御する。ＮＣ２１２はネットワークに接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。

＜電子原稿データの形式＞
編集アプリケーション１０４の詳細を言及する前に、ブックファイルのデータ形式について説明する。ブックファイルは紙媒体の書物を模倣した３層の層構造を有する。まず、上位層は「ブック」と呼ばれ、１冊の本を模倣しており、その本全般に係る属性が定義されている。その下の中間層は、本でいう章に相当し、やはり「章」と呼ばれる。各章についても、章毎の属性が定義できる。そして、下位層は「ページ」であり、アプリケーションプログラムで定義された各ページに相当する。尚、各ページについてもページ毎の属性が定義できる。更に、一つのブックは複数の章を含んでいてよく、また一つの章は複数のページを含むこともできる。

図３に示す（Ａ）は、ブックファイルの形式の一例を模式的に示す図である。図示するように、この例では、ブックファイルにおけるブック，章，ページは、それぞれに相当するノードにより示されている。一つのブックファイルは一つのブックを含む。ブック，章は、ブックとしての構造を定義するための概念であるから、定義された属性値と下位層へのリンクとをその実体として含む。ページは、アプリケーションプログラムによって出力されたページ毎のデータを実体として有する。そのため、ページは、その属性値のほかに、原稿ページの実体（原稿ページデータ）と各原稿ページデータへのリンクを含む。

尚、紙媒体等に出力する際の印刷ページは複数の原稿ページを含む場合がある。この構造に関してはリンクによって表示されず、ブック、章、ページ各階層における属性として表示される。

図３において、ブック３０１には、ブック属性が定義されていると共に、２つの章３０２Ａ，３０２Ｂがリンクされている。このリンクにより、章３０２Ａ，３０２Ｂがブック３０１に包含されていることが表示される。章３０２Ａには、ページ３０３Ａ，３０３Ｂがリンクされ、これらページが含まれることが示されている。各ページ３０３Ａ，３０３Ｂにはそれぞれ属性値が定義され、その実体である原稿ページデータ（１）、（２）へのリンクが含まれる。これらリンクは、図３に示す（Ｂ）のように原稿ページデータ３０４のデータ（１），（２）を指し示し、ページ３０３Ａ、３０３Ｂの実体が原稿ページデータ（１）、（２）であることを表示している。

図４は、ブック属性のリストである。下位層と重複して定義可能な項目に関しては、下位層の属性値が優先採用される。そのため、ブック属性にのみ含まれる項目に関しては、ブック属性に定義された値はブック全体を通して有効な値となる。しかし、下位層と重複する項目については、下位層において定義されていない場合における既定値としての意味を有する。尚、図示された各項目は具体的に１項目に対応するのではなく、関連する複数の項目を含むものもある。

図５は章属性の、図６はページ属性のリストである。章属性とページ属性との関係もブック属性と下位層の属性との関係と同様である。

図４〜図６から明らかなように、ブック属性に固有の項目は、印刷方法、製本詳細、表紙／裏表紙、インデックス紙、合紙、章区切りの６項目である。これらはブックを通して定義される項目である。印刷方法の属性としては、片面印刷、両面印刷、製本印刷の３つの値を指定できる。ここで、製本印刷とは、別途指定する枚数の用紙を束にして２つ折りにし、その束をつづり合わせることで製本が可能となる形式で印刷する方法である。製本詳細属性としては、製本印刷が指定されている場合に、見開き方向や、束になる枚数等が指定できる。

表紙／裏表紙属性は、ブックとしてまとめられる電子原稿ファイルを印刷する際に、表紙及び裏表紙となる用紙を付加することの指定、及び付加した用紙への印刷内容の指定を含む。インデックス紙属性は、章の区切りとして、印刷装置に別途用意される耳付きのインデックス紙の挿入の指定及びインデックス（耳）部分への印刷内容の指定を含む。この属性は、印刷用紙とは別に用意された用紙を所望の位置に挿入するインサート機能を持ったインサータが使用する印刷装置に備えられている場合か、あるいは、複数の給紙カセットを使用可能である場合に有効となる。これは合紙属性についても同様である。

合紙属性は、章の区切りとして、インサータから、あるいは給紙カセットから供給される用紙の挿入の指定、及び合紙を挿入する場合には、給紙元の指定などを含む。

章区切り属性は、章の区切り目において、新たな用紙を使用するか、新たな印刷ページを使用するか、特に何もしないか等の指定を含む。片面印刷時には、新たな用紙の使用と新たな印刷ページの使用とは同じ意味を持つ。両面印刷時には、「新たな用紙の使用」を指定すれば連続する章が１枚の用紙に印刷されることは無いが、「新たな印刷ページの使用」を指定すれば、連続する章が１枚の用紙の表裏に印刷されることがあり得る。

章属性に関しては、章に固有の項目はなく、全てブック属性と重複する。従って、章属性における定義とブック属性における定義とが異なれば、章属性で定義された値が優先する。ブック属性と章属性とにのみ共通する項目は、用紙サイズ、用紙方向、Ｎ−ｕｐ印刷指定、拡大縮小、排紙方法の５項目である。これらのうち、Ｎ−ｕｐ印刷指定属性は１印刷ページに含まれる原稿ページ数を指定するための項目である。指定可能な配置としては、１×１、１×２、２×２、３×３、４×４などがある。排紙方法属性は、排出した用紙にステイプル処理を施すか否かを指定するための項目であり、この属性の有効性は使用する印刷装置がステイプル機能を有するか否かに依存する。

ページ属性に固有の項目には、ページ回転属性、ズーム、配置指定、アノテーション、ページ分割などがある。ページ回転属性は、原稿ページを印刷ページに配置する際の回転角度を指定するための項目である。ズーム属性は、原稿ページの変倍率を指定するための項目である。変倍率は、仮想論理ページ領域のサイズを１００％として指定される。仮想論理ページ領域とは、原稿ページを、Ｎｕｐ等の指定に応じて配置した場合に、１原稿ページが占める領域である。例えば、１×１であれば、仮想論理ページ領域は１印刷ページに相当する領域となり、１×２であれば、１印刷ページの各辺を約７０パーセントに縮小した領域となる。

ブック、章、ページについて共通な属性としては、ウォーターマーク属性及びヘッダ・フッタ属性がある。ここで、ウォーターマークとは、アプリケーションで作成されたデータに重ねて印刷される、別途指定される画像や文字列などである。ヘッダ・フッタは、それぞれ各ページの上余白及び下余白に印刷されるウォーターマークである。但し、ヘッダ・フッタには、ページ番号や日時など変数により指定可能な項目が用意されている。尚、ウォーターマーク属性およびヘッダ・フッタ属性において指定可能な内容は、章とページとは共通であるが、ブックはそれらと異なっている。ブックにおいてはウォーターマークやヘッダ・フッタの内容を設定できるし、また、ブック全体を通してどのようにウォーターマークやヘッダ・フッタを印刷するかを指定することができる。一方、章やページでは、その章やページにおいて、ブックで設定されたウォーターマークやヘッダ・フッタを印刷するか否かを指定できる。

＜ブックファイルの生成手順＞
ブックファイルは上述したような構造及び内容を有している。次に、製本アプリケーション１０４及び電子原稿ライタ１０２によるブックファイルの作成手順について説明する。ブックファイルの作成手順は、製本アプリケーション１０４によるブックファイルの編集操作の一環として実現される。

図７は、製本アプリケーション１０４によりブックファイルを開く際の手順である。まず、開こうとするブックファイルが、新規作成すべきものであるか、それとも既存のものであるか判定する（ステップＳ７０１）。新規作成の場合には、章を含まないブックファイルを新規に作成する（ステップＳ７０２）。新規に作成されるブックファイルは、図３の例で示せば、ブックノード３０１のみ有し、章のノードに対するリンクが存在しないブックのノードとなる。ブック属性は、新規作成用としてあらかじめ用意された属性のセットが適用される。そして、新規ブックファイルを編集するためのユーザインタフェース（ＵＩ）画面を表示する（ステップＳ７０３）。図１１は、新規にブックファイルが作成された際のＵＩ画面の一例である。この場合は、ブックファイルは実質的な内容を持たないため、ＵＩ画面１１００には何も表示されない。

一方、既存のブックファイルがあれば、指定されたブックファイルを開き（ステップＳ７０３）、そのブックファイルの構造、属性、内容に従ってユーザインタフェース（ＵＩ）画面を表示する。図１０は、既存のブックファイルから指定されたブックファイルを表示するＵＩ画面の一例である。ＵＩ画面１１００は、ブックの構造を示すツリー部１１０１と、印刷された状態を表示するプレビュー部１１０２とを含む。ツリー部１１０１には、ブックに含まれる章、各章に含まれるページが図３に示す（Ａ）のような木構造で表示される。ツリー部１１０１に表示されるページは原稿ページである。またプレビュー部１１０２には、印刷ページの内容が縮小されて表示される。その表示順序はブックの構造を反映したものとなっている。

さて、開かれたブックファイルには、電子原稿ライタ１０２によって電子原稿ファイルに変換されたアプリケーションデータを、新たな章として追加することができる。この機能を電子原稿インポート機能と呼ぶ。図７に示す手順によって新規に作成されたブックファイルに電子原稿インポートすることで、そのブックファイルには実体が与えられる。この機能は、図１０の画面にアプリケーションデータをドラッグアンドドロップ操作することで起動される。

図８に電子原稿インポートの手順を示す。まず、指定されたアプリケーションデータを生成したアプリケーションプログラムを起動し、デバイスドライバとして電子原稿ライタ１０２を指定してアプリケーションデータを印刷出力させることで、電子原稿データに変換する（ステップＳ８０１）。変換を終えたなら、変換されたデータが画像データであるか否かを判定する（ステップＳ８０２）。この判定は、ウインドウズＯＳの下であれば、アプリケーションデータのファイル拡張子に基づいて行われる。例えば、拡張子が「ｂｍｐ」であればウインドウズビットマップデータであり、「ｊｐｇ」であればｊｐｅｇ圧縮された画像データ、「ｔｉｆｆ」であればｔｉｆｆ形式の画像データであると判定できる。また、このような画像データの場合はＳ８０１０のようにアプリケーションを起動せずに、画像データから直接電子原稿ファイルを生成することが可能であるため、Ｓ８０１０の処理を省略することも可能である。

ここで、画像データでなかった場合には、ステップＳ８０１で生成された電子原稿ファイルを、現在開かれているブックファイルのブックに、新たな章として追加する（ステップＳ８０３）。章属性としては、ブック属性と共通するものについてはブック属性の値がコピーされ、そうでないものについては、予め用意された規定値に設定される。

また、ステップＳ８０２で画像データである場合には、原則として新たな章は追加されず、指定されている章に、ステップＳ８０１で生成された電子原稿ファイルに含まれる各原稿ページが追加される（ステップＳ８０４）。但し、ブックファイルが新規作成されたファイルであれば、新たな章が作成されて、その章に属するページとして電子原稿ファイルの各ページが追加される。ページ属性は、上位層の属性と共通のものについてはその属性値が与えられ、アプリケーションデータにおいて定義された属性を電子原稿ファイルに引き継いでいるものについてはその値が与えられる。例えば、Ｎｕｐ指定などがアプリケーションデータにおいて指定されていた場合には、その属性値が引き継がれる。このようにして、新規なブックファイルが作成され、あるいは、新規な章が追加される。

図９は、図８に示すステップＳ８０１において、電子原稿ライタ１０２により電子原稿ファイルを生成させる手順のフローチャートである。まず、新たな電子原稿ファイルを作成してそれを開く（ステップＳ９０１）。指定したアプリケーションデータに対応するアプリケーションを起動し、電子原稿ライタをデバイスドライバとしてＯＳの出力モジュールに対して出力コマンドを送信させる。出力モジュールは、受信した出力コマンドを電子原稿ライタ１０２によって電子原稿形式のデータに変換し、出力する（ステップＳ９０２）。その出力先はステップＳ９０１で開いた電子原稿ファイルである。指定されたデータ全てについて変換が終了したか判定し（ステップＳ９０３）、終了していれば電子原稿ファイルを閉じる（ステップＳ９０４）。電子原稿ライタ１０２によって生成される電子原稿ファイルは、図３の（Ｂ）に示される原稿ページデータの実体を含むファイルである。

＜ブックファイルの編集＞
以上のようにして、アプリケーションデータからブックファイルを作成することができる。生成されたブックファイルについては、章及びページに対して次のような編集操作が可能である。（１）新規追加（２）削除（３）コピー（４）切り取り（５）貼り付け（６）移動（７）章名称変更（８）ページ番号名称振り直し（９）表紙挿入（１０）合紙挿入（１１）インデックス紙挿入（１２）各原稿ページに対するページレイアウト。

このほか、一旦行った編集操作を取り消す操作や、更に取り消した操作をやり直す操作が可能である。これら編集機能により、例えば複数のブックファイルの統合、ブックファイル内で章やページの再配置、ブックファイル内で章やページの削除、原稿ページのレイアウト変更、合紙やインデックス紙の挿入などの編集操作が可能となる。これらの操作を行うと、図４、図５に示す属性に操作結果が反映されたり、あるいはブックファイルの構造に反映される。例えば、ブランクページの新規追加操作を行えば、指定された箇所にブランクページが挿入される。このブランクページは原稿ページとして扱われる。また、原稿ページに対するレイアウトを変更すれば、その変更内容は、印刷方法やＮ−ｕｐ印刷、表紙／裏表紙、インデックス紙、合紙、章区切りといった属性に反映される。

＜ブックファイルの出力＞
以上のように作成・編集されるブックファイルは、印刷出力を最終目的とするものである。ここで、利用者が図１０に示した製本アプリケーションのＵＩ画面１１００からファイルメニューを選択し、そこから印刷を選択すると、指定した出力デバイスにより印刷出力される。この際、まず製本アプリケーション１０４は、現在開かれているブックファイルからジョブチケットを作成し、そのジョブチケットを電子原稿デスプーラ１０５に渡す。一方、電子原稿デスプーラ１０５は、ジョブチケットをＯＳの出力コマンド、例えばウインドウズのＧＤＩ関数に変換し、それを出力モジュール、例えばＧＤＩに送信する。出力モジュールは、指定されたプリンタドライバ１０６によってデバイスに適したコマンドを生成し、そのデバイスに送信する。

ここで、ジョブチケットは原稿ページを最小単位とする構造を有するデータである。ジョブチケットにおける構造は、用紙上における原稿ページのレイアウトを定義している。ジョブチケットは１ジョブにつき１つ発行される。そのため、まず最上位にドキュメントというノードがあり、文書全体の属性、例えば両面印刷／片面印刷などが定義されている。その下には、用紙ノードが属し、用いるべき用紙の識別子やプリンタにおける給紙口の指定などの属性が含まれる。各用紙ノードには、その用紙で印刷されるシートのノードが属する。１シートは１枚の用紙に相当する。各シートには、印刷ページ（物理ページ）が属する。片面印刷ならば１シートには１物理ページが属し、両面印刷ならば１シートに２物理ページが属する。各物理ページには、その上に配置される原稿ページが属する。また物理ページの属性として、原稿ページのレイアウトが含まれる。

電子原稿デスプーラ１０５は、上述のジョブチケットを、出力モジュールへの出力コマンドに変換する。

＜そのほかのシステム構成＞
本実施形態の文書処理システムの概要は以上のようなものである。これはスタンドアロン型のシステムであるが、これを拡張したサーバクライアントシステムでもほぼ同様の構成・手順でブックファイルを作成・編集できる。但し、ブックファイルや印刷処理はサーバによって管理される。

図１２は、サーバクライアント型文書処理システムの構成を示すブロック図である。クライアント文書処理システムは、スタンドアロン型システムに、クライアントモジュールであるＤＯＭＳ（Ｄｏｃｕｍｅｎｔ Ｏｕｔｐｕｔ Ｍａｎａｇｅｍｅｎｔ Ｓｅｒｖｉｃｅ：文書出力管理サービス）ドライバ１０９及びＤＯＭＳプリントサービスモジュール１１０、ＤＳ（文書サービス）クライアントモジュール１０８を加えた構成を有する。このクライアント文書処理システム１２００に文書管理サーバ１２０１、印刷集中管理サーバ１２０２及びプリントサーバ１２０３が接続されている。これらサーバは、通常ネットワークによってクライアント文書処理システムと接続されるが、サーバが同時にクライアントとしても機能する場合には、ネットワーク間の通信をシミュレートするプロセス間通信によって接続される。

尚、図１２に示す例では、文書管理サーバ１２０１と印刷集中管理サーバ１２０２の両方のサーバがクライアントに接続されているが、何れか一方のみネットワーク上に存在する場合もあり得る。例えば、接続されているサーバが文書管理サーバであれば、そのクライアントモジュール１０８を含む文書管理サーバクライアントシステム１２０１ＳＣが、また印刷集中管理サーバ１２０２であれば、そのクライアントモジュールを含む印刷管理サーバクライアントシステム１２０２ＳＣが、スタンドアロン型文書管理システムに追加される。

文書管理サーバ１２０１は、製本アプリケーション１０４により作成・編集されたブックファイルを格納するサーバである。文書管理サーバ１２０１によってブックファイルを管理する場合、ブックファイルはクライアントＰＣのローカルＨＤに代わって、あるいはそれに加えて、文書管理サーバ１２０１のデータベース１２１１に保存される。製本アプリケーション１０４と文書管理サーバ１２０１との間のブックファイルの保存及び読み出しは、ＤＳクライアント１０８及びＤＳコア１２１２を介して行われる。

印刷集中管理サーバ１２０２は、クライアント文書管理システム１２００に格納された、あるいは文書管理サーバ１２０１に格納されたブックファイルの印刷を管理するサーバである。クライアントにおける印刷要求は、ＤＯＭＳドライバ１０９およびＤＯＭＳプリントサービスモジュール１１０を介して印刷集中管理サーバ１２０２のＤＯＭＳＷＧサーバモジュール１２２１に送信される。集中印刷管理サーバ１２０２は、クライアントのプリンタで印刷する場合にはクライアントのＤＯＭＳプリントサービスモジュール１１０を介して電子原稿デスプーラ１０５に電子原稿データを渡し、プリントサーバ１２０３により印刷する場合には、プリントサーバ１２０３のＤＯＭＳプリントサービスモジュール１２０３に送信する。集中印刷管理サーバは、例えば保存されているブックファイルに対して印刷要求を発行した利用者の資格などについてセキュリティチェックを行ったり、印刷処理のログを保存したりする。このように、文書処理システムは、スタンドアロンとしても、クライアントサーバシステムとしても実現できる。

＜プレビュー表示の内容＞
既に説明した通り、ブックファイルが製本アプリケーションによって開かれると、図１０に示したユーザインタフェース画面１１００が表示される。ツリー部１１０１には、開いているブック（以下、「注目ブック」と呼ぶ）の構造を示すツリーが表示される。プレビュー部には、利用者の指定に応じて、３通りの表示方法が用意されている。まず、第１は原稿ページをそのまま表示する原稿ビューと呼ばれるモードである。この原稿ビューモードでは、注目ブックに属する原稿ページの内容が縮小されて表示される。尚、プレビュー部１１０２の表示にレイアウトは反映されない。次に、第２は印刷ビューモードである。この印刷ビューモードでは、プレビュー部１１０２には原稿ページのレイアウトが反映された形で原稿ページが表示される。そして、第３は簡易印刷ビューモードである。この簡易印刷ビューモードでは、各原稿ページの内容はプレビュー部の表示には反映されず、レイアウトのみが反映される。

＜ステイプル制御＞
次に、ステイプル機能を有するプリンタと接続するコンピュータ１００の製本アプリケーション１０４によって行われるステイプル制御について説明する。

図１３は、ステイプル制御システムの構成を示すブロック図である。図示するように、ステイプル制御システムは、図２に示したホストコンピュータ１００とステイプル機能を有するプリンタ１０７とで構成される。

以下、プリンタ１０７の構成について説明する。尚、本発明の機能が実現されるのであれば、単体の機器であっても、複数の機器からなるシステムであっても、ＬＡＮ，ＷＡＮ等のネットワークを介して接続がなされ、処理が行われるシステムであっても本発明を適用できる。

図示するように、プリンタ１０７において、１３０１はプリンタＣＰＵであり、ＲＯＭ１３０２内のプログラム用ＲＯＭに記憶された制御プログラム等や外部メモリ１３０３に記憶された制御プログラム等に基づいてシステムバス１３０４に接続される印刷部Ｉ／Ｆ１３０５を介して、印刷部（プリンタエンジン）１３０６に出力情報としての画像信号を出力する。また、このＲＯＭ１３０２内のプログラムＲＯＭには、ＣＰＵ１３０１の制御プログラム等が記憶され、ＲＯＭ１３０２内のフォント用ＲＯＭには、出力情報を生成する際に使用するフォントデータ等が記憶され、ＲＯＭ１３０２内のデータ用ＲＯＭには、ハードディスク等の外部メモリ１３０３がないプリンタの場合、ホストコンピュータ１００上で利用される情報等が記憶されている。

また、ＣＰＵ１３０１は、入力部１３０７を介してホストコンピュータ１００との通信処理が可能となっており、プリンタ１０７内の情報等をホストコンピュータ１００に通知できる。ＲＡＭ１３０８は、ＣＰＵ１３０１の主メモリや、ワークエリア等として機能するＲＡＭであり、図示しない増設ポートに接続されるオプションＲＡＭによりメモリ容量を拡張することができるように構成されている。

尚、ＲＡＭ１３０８は、出力情報展開領域、環境データ格納領域、ＮＶＲＡＭ等に用いられる。上述したハードディスク（ＨＤ）、ＩＣカード等の外部メモリ１３０３は、メモリコントローラ（ＭＣ）１３０９によりアクセスを制御される。外部メモリ１３０３は、オプションとして接続され、フォントデータ、エミュレーションプログラム、フォームデータ等を記憶する。また、操作パネル１３１１は操作のためのスイッチ及びＬＥＤ表示器等で構成されている。

また、上述の外部メモリ１３０３は１個に限らず、複数個備えられ、内蔵フォントに加えてオプションカード、言語系の異なるプリンタ制御言語を解釈するプログラムを格納した外部メモリを複数接続できるように構成されていても良い。更に、図示しないＮＶＲＡＭを有し、操作パネル１３１１からのプリンタモード設定情報を記憶するようにしても良い。

＜ブックファイル編集機能＞
製本アプリケーション１０４にて生成されたブックファイルに対して、文章・画像の編集を行うことを可能とする原稿エディタを備える。原稿エディタは、製本アプリケーションから起動し、ブックファイルを論理ページ毎に編集することが可能である。

図１５はエディタの起動フローを示している。まず製本アプリケーションにて、選択された原稿ファイルに対してメニューを表示させる（ステップＳ１５０１）。メニューなどの操作部を介して“原稿エディタ”が選択されたことを認識する（ステップＳ１５０２）。原稿エディタを起動し、メイン画面を表示する（ステップＳ１５０３）。

図１４は製本アプリケーションから、原稿エディタを起動する際にユーザにより操作されるＵＩの一例を示す。

１４０１は製本アプリケーションの表示、１４０２はインポートされた原稿ファイルの各頁を示す。１４０３は原稿ファイル選択時のポップアップメニューを示す。図１４では１頁目が選択されボップアップメニューが示されている。１４０４はマウスポインタを示している。原稿エディタの起動は、インポートされた原稿ファイルをマウスポインタで選択し、ポップアップメニューを表示させ、メニュー内の“原稿エディタ”を選択することで実行される。図１４のように原稿エディタの起動が指示された場合には、後述にて説明する図１６のような原稿画面が表示される。また、ここの説明ではポップアップメニューからの起動であったが、その他（たとえばツールボタン、メニューアイテム）を利用した起動方法であっても良い。

次に、原稿エディタで行える編集機能について説明をする。図１６は原稿エディタの全体ＵＩ１６０１を示している。１６０２、１６０３は各種処理を指示するためのメニューバー、ツールボタン、１６０４はページ移動ボタン、１６０５はズーム指定ボックス、１６０６は編集対象の原稿ファイルの内容表示、１６０７はテキストオブジェクト、１６０８・１６０９は図形オブジェクト、１６１０は直線オブジェクトを示している。これらを元に各編集機能について説明を行う。そして、この原稿エディタを介して、図形及び文字の夫々に対して、後述する、テキスト編集、テキストボックス編集、イメージ編集、オブジェクト編集、などの各種指示を行うことができ、これら各種編集指示を反映した電子文章が作成或いは生成されることとなる。

［テキスト編集機能］
図１７はテキストオブジェクトが選択されている様子の表示例を示すものであり、図１６で示した１６０６を詳細に示す。１７０１はテキストオブジェクト、１７０２はオブジェクトのコントロールハンドル、１７０３はマウスポインタを示している。

マウスポインタで原稿ファイル内のテキスト上（テキストボックスの矩形以内）を選択すると、選択されたテキストがオブジェクトとしてマッチングされ、選択状態となる。選択状態になったオブジェクトには１７０２で示した、コントロールハンドルが表示され、選択されたことをユーザに示す。この例では、コントロールハンドルが表示されたが、テキストオブジェクトの外接矩形を表示するようにしても良い。テキストオブジェクトに対しては、選択して移動・削除・テキスト属性の変更・テキストの追加・削除などの操作を行うことができる。

図１８は図１７に示されたテキストオブジェクトに対するテキスト編集のフローを示している。まずマウスポインタで選択された原稿ファイル内のテキストを、テキストオブジェクトとして抽出する（ステップＳ１８０１）。

抽出されたテキストオブジェクトに対して、テキストの追加、テキストの削除、テキスト属性の変更、テキストオブジェクトの移動・削除などの編集を施し（ステップＳ１８０２乃至ステップ１８０６）、編集の終了指示が識別された場合に編集処理を終了する。

図１９はテキスト追加の例を示している。図１９では図１７のテキストオブジェクト１７０１についてテキストの追加が行われている様子を示す。選択状態になっているテキストオブジェクトを再度マウスポインタ１９０３（１７０３）で選択すると、テキストオブジェクトが矩形１９０１で囲まれ、編集カーソル１９０２が表示される。テキストを追加する位置にカーソルを移動させ、キーボードなどを介して文字が入力されると、テキストオブジェクト内に文字が追加される。図１９では、“日本語のテスト”のテストの前に“テスト”が追加された場合を示している。

図２０はテキスト削除の例を示している。図１７のテキストオブジェクト１７０１についてテキストの削除を行う。テキスト追加と同様の方法でテキストオブジェクトが矩形で囲まれ、編集カーソル２００１が表示されている状態にする。その状態で、バックスペースキーや削除を実行すると、編集カーソルの前の文字が削除される。図２０では、“日本語のテスト”の“テスト”を削除したときの例が示されている。

テキスト属性の編集について、各テキストオブジェクト内のテキストは属性を持っており、その属性についても編集することが可能である。テキスト属性には、フォント・スタイル・サイズ・色・文字装飾・文字間隔・水平スケーリング率・単語間隔などがある。それぞれの意味、設定方法については、公知であるため説明は省略する。

［テキストボックス編集機能］
前述したテキストオブジェクトは１行に限定された編集であったが、原稿エディタは複数行のテキストを新規に作成する機能を有する。複数行のテキストを作成する際には、テキストボックスを用いる。

図２２はテキストボックス編集のフローを示している。まずテキストボックス作成モードへ遷移し（ステップＳ２２０１）、マウスドラッグの矩形でテキストボックスを生成する（ステップＳ２２０２）。次に、作成したテキストボックスに対して、テキストオブジェクトの編集（この編集は前述した１行テキストの編集操作と同じ）、テキストボックス属性の編集、テキストボックスの移動・削除などの編集を施し（ステップＳ２２０３−２２０６）、編集が終了したら終了する。

図２１はテキストボックス作成の例を示している。原稿ファイル１６０６上にテキストボックス作成モードで、マウスポインタ１９０３を用いて矩形を描画すると、テキストボックス２１０１が作成される。また、さらにテキストボックスを追加することも可能であり、複数のテキストボックスの追加が可能となっている。作成されたテキストボックスには、新規作成時およびボックスを選択時に、コントロールハンドル２１０２が表示される。コントロールハンドルをマウスポインタでドラッグすることにより、ボックスのリサイズが可能である。

図２３は前述したテキストボックス内にテキストを追加する例を示している。選択状態のテキストボックスを再度マウスポインタで選択すると、テキストオブジェクト編集の時と同様に、ボックス内に編集カーソルが表示される。その状態で、テキストを入力することにより、テキストボックスにテキストを追加することが可能である。また、テキストの削除についてもテキストオブジェクトの時と同様の方法で、行うことが可能である。図２３はテキストボックス２１０１に“テキストボックステスト。複数行”というテキストを追加した例を示している。前述したとおり、テキストボックスは複数行のテキストをサポートする。右端までに収まらないテキストは改行されて表示される（２３０１）。

テキストボックスおよびテキストボックス内のテキストについてもテキストオブジェクトと同様に属性を編集することが可能である。テキストボックスの属性には、線種・線幅・線の色・塗りつぶし・不透明度などがある。テキストボックス内のテキストの属性は、手テキストオブジェクトと同様である。それぞれの意味、設定方法については、公知であるため説明は省略する。

［イメージ編集機能］
次に、原稿エディタにおけるイメージの編集機能について説明をする。イメージの編集機能には、“イメージの挿入”と“イメージの書き出し”がある。

イメージの挿入について説明をする。図２７はイメージ挿入および回転・移動・削除の全体フローを示している。まず、イメージ挿入モードに遷移し、イメージ選択ダイアログを表示する（ステップＳ２７０１）。前記ダイアログで選択されたイメージをエディタ上に表示する（ステップＳ２７０２）。表示されたイメージに対して、回転や移動・削除などの編集を施し（ステップＳ２７０３−２７０５）、編集が終了したら終了。

図２４はイメージの挿入モードへ遷移するためのＵＩ例を示している。２４０１は原稿エディタ、２４０２はメニュー、２４０３はイメージ挿入モードメニューを示している。原稿エディタのメニューバーより、イメージの挿入が選択されると、イメージの挿入ダイアログが表示される。イメージ挿入ダイアログで挿入するイメージファイルを選択することで、原稿上にイメージオブジェクトとして挿入する。

図２５はイメージ挿入が挿入された例を示している。前述した方法でイメージを挿入すると、原稿ファイル１６０６にイメージ２５０１が挿入される。イメージの挿入される位置については、原稿ファイルの中心となる。ただし、位置については、中心に限定せずに原稿ファイルの左上基準、左下基準などユーザビリティを考慮して変更できるようにしても良い。また、挿入の方法についても、メニューからの挿入だけでなく、ツールボタンなどで行えるようにしても良い。

挿入したイメージ、もしくは原稿ファイルに配置されたイメージオブジェクトに対しては、回転、移動・削除と言った編集を行うことができる。図２６はイメージを回転した例を示している。２６０１はイメージを時計回りに９０度回転されたものを示している。移動・削除については、公知であるため説明は省略する。

次にイメージの書き出しについて説明する。図２９はイメージの書き出しの全体フローを示している。まず書き出す対象のイメージを選択することにより抽出する（２９０１）。次に、ポップアップメニューなどからイメージ書き出しダイアログを表示させる（２９０２）。そして、書き出し先（場所）や書き出すイメージのファイル名などを入力して、入力を確定させることで、指定された場所にイメージを保存する（２９０３−２９０４）。図２８はイメージの書き出しの例を示している。書き出すイメージを選択し、ポップアップメニュー２８０１を表示させ、イメージの書き出しを指定する。イメージの書き出しを指定すると、イメージの書き出しダイアログを表示する。表示したダイアログ内で設定した書き出し場所・イメージファイル名を適用させイメージの書き出しを行う。

［オブジェクト編集機能］
次に、原稿エディタにおけるオブジェクトの編集機能について説明をする。オブジェクトの種類には、四角形・楕円・角丸四角形・直線・オートシェイプ・その他任意図形が存在する。それらのオブジェクトの新規作成および編集を行うことが可能である。原稿ファイルの描画されているオブジェクトに対しても選択すること、および編集を加えることができる。新規作成、および編集操作については、移動・削除や各属性（色・線種など）の変更など公知の技術であるため、個々の説明は省略する。図３２は、オブジェクトの編集フローを示している。まずオブジェクト作成フローに遷移し（ステップＳ３２０１）、マウスドラッグで描画された矩形により、オブジェクトを作成する（ステップＳ３２０２）。オブジェクトの編集（属性の編集や移動・削除など）を施し（ステップＳ３２０３−Ｓ３２０５）、編集が終了したら終了する。次に一例として楕円の新規作成について説明をする。

図３０は楕円オブジェクトの新規作成モードに遷移するためのＵＩ例を示している。３００１は原稿エディタ、３００２はメニュー、３００３は楕円作成モード遷移メニューを示している。３００３の楕円作成モード遷移メニューを選択し、原稿エディタ上でマウス矩形を描画することで楕円オブジェクトを作成することができる。図３１は楕円オブジェクトが作成された例を示している。作成された楕円オブジェクト３１０１は、選択状態になるとコントロールハンドル３１０２を表示し、選択されたことをユーザに認識させる。

図３３〜３９はフォント情報の埋め込みに関する処理を示すフローチャートであり、図３３のフローチャートについては、電子文書が複数ページからなる場合には、テキストの編集が反映された全ての部分（ページ）について行われ、図３５のフローチャートについては電子文書全体について行われる。

図３３は、ＰＤＦ文書などのフォント情報を埋めこみ可能な電子文書を編集可能な情報処理装置において実行される処理で、特に、文字への編集指示を反映した電子文書が作成されたことに基づいて、フォント情報を埋め込むか否かの問い合わせを行わせを切り替え、問い合わせに応じてフォント情報を電子文書に新たに埋め込む処理について説明を行う。なお、フォント情報を埋め込むか否かの問い合わせとは、後述の図３９に示されるように、新たなフォント情報の埋め込み指示を最終的に行える画面であれば良い。

まず、ステップＳ３３０１で、ユーザが原稿エディタを介して編集を行っている時、編集終了の指示、或いは、編集された電子文書の保存指示が行われたか否かの判定処理が行われる。これは、ユーザが編集を終了する場合に、［ファイル］メニューの［閉じる］を選択するか、図３７右上の閉じるボタン３７０１が押下され、終了を示す入力がなされた場合に終了であると判定される。

ステップＳ３３０１でＹＥＳと判定されると、内容保存の確認ダイアログ表示処理３３０２が行われる。これは上記判定においてＹＥＳと判定されたことに連動し、ユーザに電子文書の内容保存を促すためにダイアログを表示する処理である。図３６はそのそのダイアログを例示したものである。図３６においては、［はい］、［いいえ］、［キャンセル］などの指示入力を行う為のボタンが含まれている。

そして、ユーザの選択に従い、文書を保存する入力が行われたか否かの判定がステップＳ３３０３が行われる。例えば、上記ダイアログの［はい］の押下に連動した入力がなされたか否かの判定が行われ、ここでは文書の保存が指示されたとする。

次にステップＳ３３０４では、ＴＥＸＴ（文字）の編集があったかの判定処理が行われる。これは先にユーザが行った編集作業の中にテキストに関する編集があったかを判定する処理である。前記したように、例えば図形のように編集操作の中にはテキスト以外のものも編集可能である。テキストに関連した編集がない場合、以下のフォントデータの埋め込み判定処理等は行わない。

尚、ステップＳ３３０４の判定処理は、原稿エディタを介しての文字や図形の各種編集に処理に伴いリアルタイムにテキストに関連した編集が行われたか否かを識別し、その識別結果を一時的に履歴として記憶手段に記憶保存し、ステップＳ３３０４の処理のタイミングで保存結果を参照するようにしても良いし、或いは、ステップＳ３３０４の処理のタイミングで、前回保存時の原稿と今回の保存前の原稿のテキストに関する差分を調べることによりフォント情報を新たに埋め込むべきテキストに関連した編集が行われたか否かを判定するようにしても良い。

ここで、フォント、フォント情報について定義する。フォントとは、例えばゴシック体や明朝体のようにフォント名を指すものであったり、後述するフォント情報を含むものであったり、つまり、ある種類のフォントに係わる情報の全体を概念的に指すものであったり、フォントを総合的に表現するものを指す。

一方、フォント情報とは、フォントの具体的な命令及び／又は字形情報を指し、例えば、フォント名、グリフ（ｇｌｙｐｈ：字形パターン）、ヒント情報、前後の文字のフォントが異なる場合に埋め込まれるフォントの切り替え識別子などが挙げられる。

また、ここでのテキストの編集とは既存文字列への文字の追加、削除、フォントの変更、新規テキストの追加等を指すものとする。ここでは、図３７が編集前の図で、図３８が編集後の図とし、“追加”の文字の追加がされているものとし、テキストの編集があったと判定されたとする。

その後、ステップＳ３３０５で、編集した文書に埋め込むべきフォントがあるかの判定処理が行われる。この判定処理詳細を例示したフローチャートを図３４に示す。この図３４を用いてステップＳ３３０５についての詳細を説明する。

まず、ステップＳ３４０１で編集テキストに追加文字があったかの判定処理が行われる。これは先の例のように新たにフォント情報を埋め込むべき文字列に追加するような編集があったかの判定処理に相当する。より具体的には、編集対象のテキストに、サブセットフォントに既に埋め込まれているフォント情報で、他の文字コードと重複しない文字コードがあるか否かの判定が行われる。無論追加対象のテキストに関連付けられた種類のフォントについての判定処理が行われる。

例えば、図３７から図３８に示されるようなテキストの編集がなされ、「追加」も文字コードに対応するフォント情報が未だサブセットフォントに未埋め込みであった場合には、追加文字があったと判定され、追加テキストに使用しているフォントの列挙処理が行（Ｓ３４０２）われる。例えば、使用されているフォントがフォントＡだとすると、フォントＡが列挙される。

次に、ステップＳ３４０３で編集テキストにフォントの変更があったかの判定処理３４０３が行われる。これは既存のテキストに対する編集によってフォント種（例えばフォントＡからフォントＢ）が変えられているを判定する処理である。より具体的には、フォントの変更が指示された場合に、編集対象のテキストボックス中のテキスト（文字コード）に、変更後のフォント種類に対応するサブセットフォントに既に含まれているテキスト（文字コード）と重複しないものがあるか否かが判定される。

ステップＳ３４０３でＹＥＳと判定されれば、ステップＳ３４０２と同様の変更後のフォントの列挙処理がステップＳ３４０４で行われる。

次に、新規テキストの追加があったかの判定処理がステップＳ３４０５で行われる。原稿エディタでは既存のテキストの編集の他、新規にテキストオブジェクト（例えば上に説明した２１０２）を追加し、該追加されたテキストオブジェクトに新たなテキストを追加することが可能である。このようなテキストの追加があったかの判定を行う処理である。さらに具体的には、ステップＳ３４０５では、各々のフォント種類において、サブセットフォントとして既に埋め込み済みのテキスト（文字コード）と重複しないテキスト（文字コード）が新たに作成されたテキストオブジェクトに新規に追加されたか否かの判定が行われる。

ステップＳ３４０５の判定で、あるフォントにおける新規のテキスト（文字コード）あったと判定された場合、ステップＳ３４０６で、ステップＳ３４０２と同様に追加フォントの列挙処理が行われる。

そして最後に、ステップＳ３４０７で、列挙したフォントが既に埋め込まれていないかの判定処理が行われる。これは、先の判定処理によって列挙されたフォントが既に埋め込まれていないかを判定する処理である。

ここではフォントＡが“元々のテキスト”のサブセットとして埋め込まれており、編集によって追加された“追加”の文字はこの文書内で元々使用されていない（ステップＳ３４０１でＹＥＳ）ため、この”追加”の文字に対するフォント情報は埋め込まれていない。すると、ここではフォントＡは埋め込まれていないと判定され、次の埋め込むべきフォントの列挙処理が行われる（ステップＳ３４０８）。つまり、ステップＳ３４０８では、この場合には、フォントＡが列挙されることになる。

尚、フォントの埋め込みにはそのフォントの文字セット全てが埋め込まれている場合と、使用している文字のサブセットを埋め込む場合の２種類がある。例えば、英数字のように、文字コードの総数が少ない場合には、全ての文字コードに対応するフォント情報を埋め込む形態が適しており、一方、日本語のように文字コードの総数が非常に多いような場合には、サブセットフォントとして、フォント情報を埋め込む形態が容量の面から適している。以下では、フォント情報の埋め込み方法としてサブセットフォントを採用した場合の説明を行う。

図３３の説明に戻ると、上記したように、編集した文書に埋め込むべきフォントがあるかの判定処理（ステップＳ３３０５）が、ステップＳ３４０８での列挙処理に基づき行われ、埋め込みフォントの追加ダイアログ表示処理（ステップＳ３３０６）が行われる。

これは上記判定により列挙されたフォントを元にその埋め込みをユーザに促すため、図３９のような、新たなフォント情報の埋め込みを指示できるダイアログ（フォント追加指示画面）を表示部に表示させる処理である。尚、図３９はあくまで例であり、新たなフォント情報の埋め込みをユーザに促すことができる問い合わせであれば、例えば、単に埋め込むべきと自動的に判定されたフォントを埋め込むか否かをＹＥＳ、ＮＯで指定させる表示画面を表示させても良いし、或いは、音声で新たなフォント情報の埋め込みを確認させるようにしても良い。

図３９では「埋め込み可能フォントの選択」として、先に判定されたフォントＡが列挙される。ここでユーザがこのフォントを追加しようと思えば、フォントＡを［追加］ボタン３９０１を押すことにより、「埋め込まれているフォント一覧」に追加することが可能である。

また、ステップＳ３３０６の処理は、ステップＳ３４０１、Ｓ３４０３、Ｓ３４０５の判定処理に基づくフォント列挙処理に基づくものであるが、一方、図形（イメージを含む）の編集指示が反映されたか否かには係わらない、即ち、文字の編集指示の反映が識別されないと、図３９のような問い合わせは行われず、文字に対する編集指示が反映されたと判定された場合には図３９の問い合わせが行われることとなる。

そして、ステップＳ３３０７で追加フォントの埋め込みを行うかの判定処理が行われる。これは図３９で示すダイアログの［ＯＫ］ボタンが押されたかを判定する処理で、ここでは［ＯＫ］ボタンが押され、フォントの埋め込みを行うと判定されたとする。

次に、追加フォントの選択があったかの判定処理がステップＳ３３０８で行われる。これは上記［ＯＫ］ボタンによりフォントの埋め込みを行うと判定された場合に、図３９の「埋め込み可能フォントの選択」一覧から「埋め込まれているフォント一覧」へのフォントの移動があったかを判定する処理である。ここでは上記したようにフォントＡを選択し、３９０１の［追加］ボタンの押下に応じて移動が行われたと仮定し、追加フォントの選択があったと判定される（ダイアログの表示上は「埋め込まれているフォント一覧」となっているが、この時点ではまだフォントＡは埋め込まれていない）。

すると、追加されたフォントの埋め込み処理３３０９が行われる。これは選択されたフォントの実際の文書内への埋め込み処理を行う処理である。これにより、フォントＡのフォント情報が原稿エディタが稼動される情報処理装置の記憶部から読み出され、文書内に埋め込まれることになる。

このとき埋め込まれる情報は、フォントＡに関連付けられている電子文書内に含まれる文字に関するフォント情報の全であっても良いし、或いは、上に説明したように新たにフォント情報を埋め込むよう識別された文字コード（上の説明では「追加」の文字コード）に対応するフォント情報のみであっても良い。

そして最後にステップＳ３３１０で、文書の保存処理が行われ、フォント情報が埋め込まれた文書全体の保存が終了することになる。

尚、さらに、図３３のフローチャートに図示はされていないが、Ｓ３３０９のフォントの埋め込み処理の前後において、サブセットフォント中で不要となったフォント情報が電子文書から削除される処理が行われる。つまり、原稿エディタを介してテキストが削除された場合には、削除されたテキスト（文字コード）と同様のテキストが電子文書中に他に存在しないと判定されれば、削除されたテキストのフォント情報は不要となる。また、フォントが変更された場合などに、他のテキストについて変更前のフォントが関連付けられていなければ、変更前のフォントに対応するフォント情報は不要となる。本実施形態における情報処理装置は、テキストへの編集指示が反映された電子文書が作成されたことに基づき、不要なフォント情報を判定し、不要と判定されたフォント情報を電子文書におけるサブセットフォントから削除する手段を備える。これにより電子文書の容量を不要に大きくすることを防止できる。

次に、図３５を用いて、図３３に関連したフォント情報の埋め込み処理について更に詳しく説明をする。これは、文書保存時に、元々文書にあるテキストの未埋め込みフォントをも埋め込む処理に対応する。例えば、別のユーザにより作成された電子文書を原稿エディタで読み込み、その開いた電子文書におけるテキストにもともとフォント情報が埋め込まれておらず、且つ、前記テキストに編集を行わない場合にも、図３５のフローチャートにより、適切にフォント情報の埋め込みを促進することができる。

また、図３５のフローチャートに例示される判定処理は、上に説明した図３３のステップＳ３３０５に対応する。つまり、図３５にフローチャートに示される各ステップの処理は、図３４にフローチャートと置き換えて実行されたり、図３４に示されるフローチャートと連動或いは非連動で実行される。以下、図３４と異なる部分についての説明を中心に行う。

ステップＳ３５０７では、電子文書の保存時或いは編集終了時に元々のテキストに埋め込まれていないフォントがあるかの判定処理を行う。これは先の編集したテキストの判定に加え、編集の対象にはなっていないテキストに関連付けられたフォントにおけるフォント情報が未埋め込みであるか否かを判定する処理である。

例えば、もともと存在するテキストに関連付けられたフォントＣのサブセットフォント中の、少なくとも一部の文字コードについて、フォントＣのフォント情報が埋め込まれていなければ、ステップＳ３５０６ではＹＥＳと判定される。

ここで、ＹＥＳ判定されたとすると、次に、ステップＳ３５０８で、未埋め込みフォントの列挙処理が行われる。これにより文書全体でまだ埋め込まれていない処理が列挙され、この結果、図３３と同様に、ステップＳ３５０９でＹＥＳと判定され、ステップＳ３５１０で埋め込むべきフォントの列挙処理が行われ、結果として、図３９に示されるような追加ダイアログ（追加フォントを指定可能なフォント追加指示画面）が表示部に表示され、ユーザに対して元々埋め込まれていないフォントに対しての埋め込みを促すことができる。フォント情報を実際に埋め込むか否かは、図３３で説明した通りなので詳しい説明は省略する。

［変形例］
また、上に説明した図３３のステップＳ３３０６では、ある文字への編集（追加や関連付けられるフォント変更など）が行われたことに応じて、ある文字とは別の文字に対するサブセットフォントが既に電子文書の中に埋め込まれているか否かに係わらず、ある文字に対応するフォントを「埋め込み可能フォントの選択」欄に選択肢として、図３９の例のように表示させるよう説明した。

しかし、これに限定されるものではなく、例えば、図４０のような埋め込みフォントの追加ダイアログ表示を適用することもできる。

図４０における、埋め込みフォントの追加ダイアログにおいて、４００３では、フォントＡについてのグリフを含むフォント情報が全く電子文書に埋め込まれておらず新規であることを示している。４００４も同様に新規にグリフを含むフォント情報が埋め込まれるフォントであることを示している。

一方、４００５は、フォントＣについて、既に他の文字コードに対応してサブセットフォントが埋め込まれており、文字の追加などにより、新たにグリフを埋め込む必要が生じたフォントであることを示している。既に一部の文字コードについて、サブセットフォントが埋め込まれていることが４００４に示されている。

図４０のように、一部の文字に対応して埋め込み済みのフォントを識別可能に表示させるので、ダイアログに表示される埋め込み可能フォントの選択に表示されるものが、全く新規に埋め込むフォントでないことを、ユーザに知らしめることができる。例えば、以前に埋め込んだはずのフォントが、全く新規に追加されるフォントであると思わせるような混乱を防止することができる。また、上の説明では、電子文書に対してテキストの編集が行われた場合に、図３９のように新たなフォント情報の埋め込みを行うか否かを指定できる問い合わせ表示を表示部に表示させるように説明したが、これには限定さない。例えば、Ｓ３３０２で表示部に表示される確認ダイアログに、新たなフォント情報の埋め込みを行うか否かの問い合わせを含ませ、この問い合わせ画面を介して新たなフォント情報を埋め込む指示が入力された場合に、上に説明したステップＳ３３０４以降の処理を行うようにしても良い。

更に、上に説明した図３４のステップＳ３４０１、Ｓ３４０３、Ｓ３４０５、Ｓ３５０１、Ｓ３５０３、Ｓ３５０５、Ｓ３５０７では、テキスト（文字コード）に対する編集が反映されたことに応じて、文字コード及びフォントが一致するフォント情報が既に電子文書内のサブセットフォントに含まれているか否かを判定するようにしてきた。しかしながら、新たにフォント情報をサブセットフォントに含めるか否かの判定処理については別の仕組みを採用することによっても実現される。

例えば、編集が反映されたことに応じて、文字コード及びフォントが一致するフォント情報が既に電子文書内のサブセットフォントに含まれているか否かに係わらず、Ｓ３４０２、Ｓ３４０４、Ｓ３４０６、Ｓ３５０２、Ｓ３５０４、Ｓ３５０６、Ｓ３５０８の各々でフォントを列挙し、Ｓ３４０７、Ｓ３５０９で、列挙されたフォントにおいて編集されたテキストに対応するフォント情報が何れかのサブセットフォントに含まれていないか否かを判定するようにしても、新たにフォント情報をサブセットフォントに含めるか否かを的確に判断することができる。

更に、上の図３３のステップＳ３３０９では、電子文書のサブセットフォントとして、新たに追加しようとするフォント情報を、原稿エディタが稼動される情報処理装置の記憶部から読み出すようにして説明してきたが、これに限定はされない。

例えば、ネットワークを介して通信可能な外部の情報処理装置（例えばフォントサーバ）に対して新たに必要とするフォント情報を要求し、外部の情報処理装置から応答として得られたフォント情報を電子文書内に新たに埋め込むようにしても良い。

さらに、上の実施形態における説明においては、フォント情報の埋め込み方法としてサブセットフォントを採用した場合の説明を行ってきたが、あるフォントにおける文字セットの全てのフォント情報を埋め込むようにしても良い。情報処理装置の記憶容量や処理速度やネットワーク伝送スピードなどが高機能化された場合には有用なフォント埋め込め方式となる。この場合には、図３４の処理において、文字コードの重複を加味することなく、編集対処となったテキストに関連付けられたフォントが新たなものか否かを判定し、新たな種類のフォントが採用された場合には、フォント情報を埋め込むようにすれば良い。

［他の実施形態］
なお、本発明は、上記形態における何れかの装置において実現される機能の一部或いは全部を他の装置に行わせることにより実行させるようにしても良い。例えば、ホストコンピュータにおいてなされる機能の一部をプリンタやサーバなどの他の情報処理装置に実行さえることにより特徴的な機能を実現するようにしても良い。

また、本発明は、上記形態の機能を実現するソフトウェアのプログラムコードを記憶した記憶媒体（又は記録媒体）を、システム又は装置に供給し、そのシステム又は装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出して実行することによっても達成されることは云うまでもない。

この場合、記憶媒体から読み出されたプログラムコード自体が上記実施の形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。また、コンピュータが読み出したプログラムコードを実行することにより、上記実施の形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（ＯＳ）などが実際の処理の一部又は全部を行い、その処理によって上記実施の形態の機能が実現される場合も含まれることは云うまでもない。

さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わる記憶媒体に書込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは云うまでもない。

また、本発明は、上記実施の形態の機能を実現するソフトウェアのプログラムコードがネットワークを介して配信されることにより、システム又は装置のハードディスクやメモリ等の記憶手段又はＣＤ−ＲＷ、ＣＤ−Ｒ等の記憶媒体に格納され、そのシステム又は装置のコンピュータ（又はＣＰＵやＭＰＵ）が当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行することによっても、達成されることは云うまでもない。

以上のように各実施形態を説明してきたが、上述の各実施形態によれば、以下のような効果を例としてあげることができる。

例えば、新規に必要になったフォント情報を自動的に判別し、且つ、電子文書内に自動的に埋め込むような形態が想定されるが、場合によっては、わざわざ、電子文書内にフォント情報を埋め込む必要もなく、ユーザの意図に反する事態を招くという問題がある。しかしながら、上記各実施形態によれば、このような事態を、抑制することができる。

また、何らかの設定画面で、フォント情報の埋め込みを自動的に行うという設定を設けることも想定されるが、この形態では、設定のし忘れ、もしくは、設定の解除のし忘れをした為に、必要なフォント情報が埋め込まれなかったり、不要なフォントが埋め込まれてしまったりするという問題がある。しかし、上記各実施形態によれば、このような事態を、抑制することができる。

さらに、上記各実施形態によれば、新たなフォント情報或いはフォントの埋め込みを電子文書の保存時或いは編集終了時にユーザに問い合わせるよう制御を行うので、例えば新たなテキスト（文字コード）が追加される度に、新たなフォント情報の埋め込みを問い合わせる場合に比べ、ユーザにとって煩わしくない。上記実施形態では、新規なフォント情報の埋め込みを保存時にまとめて行うようにするので、結果として、得られる電子文書には、その都度問い合わせを行う場合に同様のフォント情報の埋め込みを行うことができる。

一方、原稿エディタ或いは製本アプリケーションで取り込んだ電子文書にもともとフォント情報が埋め込まれてなかった場合にもフォントを埋め込むことを可能とし、元々原稿にフォントが埋め込まれておらず再現性高い印刷が保証されていなかった電子文書を、再現性が高く保証された電子文書にすることができる。

本実施形態のスタンドアロン型の文書処理システムのソフトウェア構成例を示すブロック図である。 本実施形態の文書処理システムを実現するハードウェア構成例を示すブロック図である。 ブックファイルの構造の一例を示す図である。 ブック属性の一覧を示す図である。 章属性の一覧を示す図である。 ページ属性の一覧を示す図である。 ブックファイルを開く手順例を示すフローチャートである。 電子原稿ファイルをブックファイルにインポートする手順例を示すフローチャートである。 図８のステップ８０１に示すアプリケーションデータを電子原稿ファイルに変換する手順例を示すフローチャートである。 製本アプリケーションのＵＩ画面例である。 新規にブックファイルが作成された際のＵＩ画面例である。 クライアントサーバ型の文書処理システムのソフトウェア構成例を示すブロック図である。 ステイプル制御システムの構成を示すブロック図の一例である。 本発明の原稿エディタの起動の例を示すＵＩ画面例である。 原稿エディタの起動手順例を示すフローチャートである。 原稿エディタのメインＵＩ画面例を示している。 テキスト編集におけるテキストオブジェクトの選択様子の一例を示す図である。 テキスト編集を実行する手順例を示すフローチャートである。 テキスト編集におけるテキストの追加様子の一例を示す図である。 テキスト編集におけるテキストの削除様子の一例を示す図である。 テキスト編集におけるテキストボックス作成様子の一例を示す図である。 テキストボックスの編集手順例を示すフローチャートである。 テキストボックスへのテキスト追加様子の一例を示す図である。 イメージ編集におけるイメージ挿入メニューの一例を示す図である。 イメージ編集におけるイメージの挿入の一例を示す図である。 イメージ編集におけるイメージの回転の一例を示す図である。 イメージの挿入手順例を示すフローチャートである。 イメージ編集におけるイメージ書き出しメニューの一例を示す図である。 イメージの書き出し手順例を示すフローチャートである。 オブジェクト編集における楕円作成メニューの一例を示す図である。 オブジェクト編集における楕円作成の一例を示す図である。 オブジェクト編集における新規作成順例を示すフローチャートである。 フォント情報の埋め込み処理に関するフローチャートである。 本実施形態におけるフォント情報の埋め込み処理に関するフローチャートである。 本実施形態におけるフォント情報の埋め込み処理に関するフローチャートである。 本実施形態における内容保存を促すためにダイアログ例である。 本実施形態における編集前の原稿エディタを例示した図である。 本実施形態における編集後の原稿エディタを例示した図である。 本実施形態における埋め込みフォントの追加ダイアログの例である。 本実施形態における埋め込みフォントの追加ダイアログの例である。

Claims (24)

1. フォント情報を埋めこみ可能な電子文書を編集可能な情報処理装置であって、
   図形及び文字の夫々への編集指示を反映した電子文書を作成する作成手段と、
   前記作成手段により文字の編集指示が反映された電子文書が作成されたことに基づいて、フォント情報を埋め込むか否かの問い合わせを行わせる制御手段とを有することを特徴とする情報処理装置。
2. 前記作成手段により文字の編集指示が反映されたか否かの判定を行う第１判定手段を有し、前記制御手段は、図形の編集指示が反映されたか否かに係わらず、前記第１判定手段により文字の編集指示の反映が識別されない場合には前記問い合わせを行わせることなく、前記第１判定手段により文字の編集指示が反映されたと判定された場合に前記問い合わせを行わせることを特徴とする請求項１に記載の情報処理装置。
3. 前記制御手段は、前記問い合わせとして、追加フォントを指定可能なフォント追加指示画面を表示部に表示させ、前記フォント追加指示画面を介して指定されたフォントに基づくフォント情報を前記電子文書に埋め込む埋込処理手段を有することを特徴とする請求項１又は２に記載の情報処理装置。
4. 前記第１判定手段は、編集指示が反映された文字のフォント情報が前記電子文書のサブセットフォントに含まれているか否かを判定し、さらに、該判定により含まれていないと判定されたことに応じて前記編集指示が反映された文字に対応するフォントの列挙を行う列挙処理手段を有し、前記制御手段は、列挙されたフォントに基づき前記追加フォント指示画面を表示部に表示させることを特徴とする請求項２又は３に記載の情報処理装置。
5. 前記第１判定手段は、前記編集指示が反映された文字に対応するフォント情報が、前記電子文書に既登録のサブセットフォントに含まれるか否かを判定することを特徴とする請求項２乃至４の情報処理装置。
6. 前記電子文書の保存指示或いは編集終了指示がなされたか否かを判定する第２判定手段を有し、前記制御手段は、前記第２判定手段により前記保存指示或いは編集終了指示がなされたと判定されたことに応じて前記問い合わせを行わせることを特徴とする請求項１乃至５の何れかに記載の情報処理装置。
7. 編集指示が反映されていない文字に対応するフォントの未埋め込みを判別する第３判別手段を有し、前記制御手段は、前記第３判別手段により、未埋め込みのフォントがあると判別された場合に、前記未埋め込みのフォント情報の埋め込みを指定可能な問い合わせを行わせることを有することを特徴とする請求項１乃至６の何れかに記載の情報処理装置。
8. 前記制御手段は、或いは、前記第２制御手段は、一部の文字に対応して埋め込み済みのフォントを識別可能に表示させることを特徴とする請求項１乃至７の何れかに記載の情報処理装置。
9. 前記作成手段により文字の編集指示が反映された電子文書が作成されたことに応じて不要なフォント情報を判定する第４判定手段を有し、前記第４判定手段により不要とされたフォント情報を電子文書から削除させる削除手段を有することを特徴とする請求項１乃至９の何れかに記載の情報処理装置。
10. 前記フォント情報を埋め込むか否かの問い合わせは、新たなフォント情報の埋め込みを指示可能な表示であることを特徴とする請求項１乃至９の何れかに記載の情報処理装置。
11. 前記編集指示には、文字の追加、或いは、文字に対応するフォントの変更、が含まれることを特徴とする請求項１乃至１０の何れかに記載の情報処理装置。
12. フォント情報を埋めこみ可能な電子文書を編集可能な情報処理装置における情報処理方法であって、
    図形及び文字の夫々への編集指示を反映した電子文書を作成する作成ステップと、
    前記作成ステップにおいて文字の編集指示が反映された電子文書が作成されたことに基づいて、フォント情報を埋め込むか否かの問い合わせを行わせる制御ステップとを有することを特徴とする情報処理方法。
13. 前記作成ステップにおいて文字の編集指示が反映されたか否かの判定を行う第１判定ステップを有し、前記制御ステップは、図形の編集指示が反映されたか否かに係わらず、前記第１判定ステップにおいて文字の編集指示の反映が識別されない場合には前記問い合わせを行わせることなく、前記第１判定ステップにおいて文字の編集指示が反映されたと判定された場合に前記問い合わせを行わせることを特徴とする請求項１２に記載の情報処理方法。
14. 前記制御ステップは、前記問い合わせとして、追加フォントを指定可能なフォント追加指示画面を表示部に表示させるステップを含み、前記フォント追加指示画面を介して指定されたフォントに基づくフォント情報を前記電子文書に埋め込む埋込処理ステップを有することを特徴とする請求項１２又は１３に記載の情報処理方法。
15. 前記第１判定ステップは、編集指示が反映された文字のフォント情報が前記電子文書のサブセットフォントに含まれているか否かを判定することを特徴とし、更に、該判定で含まれていないと判定されたことに応じて前記編集指示が反映された文字に対応するフォントの列挙を行う列挙処理ステップを有し、前記制御ステップは、列挙されたフォントに基づき前記追加フォント指示画面を表示部に表示させることを特徴とする請求項１３又は１４に記載の情報処理方法。
16. 前記第１判定ステップは、前記編集指示が反映された文字に対応するフォント情報が、前記電子文書に既登録のサブセットフォントに含まれるか否かを判定することを特徴とする請求項１３乃至１５の情報処理方法。
17. 前記電子文書の保存指示或いは編集終了指示がなされたか否かを判定する第２判定ステップを有し、前記制御ステップは、前記第２判定ステップにおいて前記保存指示或いは編集終了指示がなされたと判定されたことに応じて前記問い合わせを行わせることを特徴とする請求項１２乃至１６の何れかに記載の情報処理方法。
18. 編集指示が反映されていない文字に対応するフォントの未埋め込みを判別する第３判別ステップを有し、前記制御ステップは、前記第３判別ステップにおいて、未埋め込みのフォントがあると判別された場合に、前記未埋め込みのフォント情報の埋め込みを指定可能な問い合わせを行わせることを有することを特徴とする請求項１２乃至１７の何れかに記載の情報処理方法。
19. 前記制御ステップは、或いは、前記第２制御ステップは、一部の文字に対応して埋め込み済みのフォントを識別可能に表示させることを特徴とする請求項１２乃至１８の何れかに記載の情報処理方法。
20. 前記作成ステップにおいて文字の編集指示が反映された電子文書が作成されたことに応じて不要なフォント情報を判定する第４判定ステップを有し、前記第４判定ステップにおいて不要とされたフォント情報を電子文書から削除させる削除ステップを有することを特徴とする請求項１２乃至１９の何れかに記載の情報処理方法。
21. 前記フォント情報を埋め込むか否かの問い合わせは、新たなフォント情報の埋め込みを指示可能な表示であることを特徴とする請求項１２乃至２０の何れかに記載の情報処理方法。
22. 前記編集指示には、文字の追加、或いは、文字に対応するフォントの変更、が含まれることを特徴とする請求項１２乃至２１の何れかに記載の情報処理方法。
23. 請求項１２乃至２２の何れかに記載の情報処理方法をコンピュータに実行させるためのプログラム。
24. 請求項２３に記載のプログラムを格納したコンピュータ可読の記憶媒体。

Images