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

Description

本発明は、情報処理装置、情報処理方法、プログラムに関する。

元ドキュメント（例えば、PDFのドキュメント）に対し、情報（例えば、「Confidential」という文字列からなるアノテーション）を追加するといった編集を行うことがよくある。特許文献１には、PDFで作成された元ドキュメントを他のフォーマットに変換した上で編集を行なった後、編集箇所をPDFコマンドに再度変換してその編集部分のみPDFの元ドキュメントにマージする技術が開示されている。

特開２００５− １０８４１号公報

上記のような情報を追加する編集を行う際、どのように情報を追加するのが好ましいかは、ケースバイケースである。例えば、「Confidential」という文字列からなるアノテーションを新たに追加する場合には、テキストとして追加するのが好ましい場合もあれば、グラフィックとして追加するのが好ましい場合もあれば、イメージとして追加するのが好ましい場合もある。

例えば、元ドキュメントに含まれる文字列がテキストで表されている場合であれば、新たに追加された文字列も同様にテキストとして追加されるべきである。一方、元ドキュメントに含まれる文字列がグラフィックで表されている場合であれば、新たな追加された文字列も同様にグラフィックとして追加されるべきである。さらに、元ドキュメントに含まれる文字列がイメージで表されている場合であれば、新たな追加された文字列も同様にイメージとして追加されるべきである。そうしないと、編集後のドキュメント（即ち、情報を追加した後のドキュメント）を印刷した際に同種類のオブジェクト間で色味等が異なって違和感が生じてしまうからである。これは、一般に印刷装置では、オブジェクトの属性に応じた画像処理を行うためである。例えば、テキストの印刷時にはテキスト専用の画像処理（例えば、エッジをシャープにする処理）、イメージの印刷時には写真専用の画像処理（例えば、ぼかし処理）がかけられる一方で、グラフィックの印刷時にはそれら画像処理はなされない。

よって、文字列をテキストで表している元ドキュメントに対して新たに文字列をイメージで追加して印刷すると、元ドキュメント内に存在していた文字列と、新たに追加された文字列とでは見た目が印刷結果において異なり、違和感が生じることになる。

本発明に係る情報処理装置は、編集されたドキュメントから、元ドキュメントに対する編集内容を特定する編集内容特定手段と、ドキュメントを作成するアプリケーション毎のオブジェクトの表現形式に関する特徴を示した特徴情報を取得する取得手段と、前記取得手段で取得した特徴情報に基づいて、前記元ドキュメントに含まれるオブジェクトの表現形式を特定する表現形式特定手段と、前記編集内容特定手段で特定した編集内容の表現形式と、前記表現形式特定手段で特定したオブジェクトの表現形式とが合うように、前記編集内容の表現形式を変換する変換手段と、前記変換手段で変換された表現形式の編集内容を、前記元ドキュメントに統合する統合手段と、を有することを特徴とする。

本発明によれば、元ドキュメントに対し編集を行なった場合においても、その印刷時に色味の違いといった違和感を生じさせることがない。

実施例１に係るドキュメント編集システムの構成の一例を示す図である。 サーバのハードウェア構成の一例を示すブロック図である。 サーバのソフトウェア構成の一例を示すブロック図である。 差分抽出の様子を説明する図である。 コマンドリスト作成処理の流れを示すフローチャートである。 コマンドリストの一例を示す図である。 描画コマンド属性決定処理の流れを示すフローチャートである。 アプリ特徴情報の一例を示す図である。 アプリ特徴情報に基づいて編集箇所の描画コマンドが変換される一例を示す図である。 コマンドリストに基づいて編集箇所の描画コマンドが変換される一例を示す図である。 編集箇所の描画コマンド（変換後）が元ドキュメントに統合される様子を説明する図である。 編集個所の描画コマンドがそのまま維持される場合の一例を説明する図である。 フォーマット変換を伴う編集において適用した場合の一例を説明する図である。

以下、添付図面を参照して、本発明を好適な実施例に従って詳細に説明する。なお、以下の実施例において示す構成は一例にすぎず、本発明は図示された構成に限定されるものではない。

図１は、本実施例に係るドキュメント編集システムの構成の一例を示す図である。ドキュメント編集システム１００は、PC１０１、携帯端末１０２、印刷装置１０３、Ｗｅｂアプリケーションサーバ（以下、サーバ）１０４で構成される。

PC１０１はクライアント端末としてのコンピュータ、携帯端末１０２は携帯電話やタブレット端末等である。PC１０１や携帯端末１０２では、サーバ１０４から所定のフォーマットの（例えば、PDF）のドキュメントを受け取り、編集用アプリケーションを使ってドキュメントを編集することができる。印刷装置１０３は、例えばインクジェット方式や電子写真方式のプリンタであり、編集後のドキュメントの印刷に用いられる。PC１０１、携帯端末１０２、印刷装置１０３は、ネットワーク１０６を介して互いに接続されており、ネットワーク１０６はインターネット１０７に繋がっている。

サーバ１０４は、１台のサーバから構成されてもよいし、複数台のサーバから構成されてもよい。

なお、ドキュメント編集システム１００は、アプリケーションサービスとしてのドキュメント編集アプリケーションを提供するサーバ（群）を別途備えていてもよい。

図２は、サーバ１０４のハードウェア構成の一例を示すブロック図である。

サーバ１０４は、CPU２０１、RAM２０２、ROM２０３、HDD２０４およびネットワークＩ／Ｆ２０５、内部バス２０６で構成されている。

ROM２０３或いはHDD２０４には、オペレーティングシステムやアプリケーションなどの制御プログラムが格納されている。CPU ２０１は、当該制御プログラムを必要に応じてROM２０３或いはHDD２０４からRAM ２０２上へ読み出して実行することで、コンピュータとしての機能を発揮する。

ネットワークＩ／Ｆ２０５は、内部バス２０６とインターネット１０６とを繋ぐインタフェースであり、インターネット１０６を介して接続されている他の装置との間でPDF形式のドキュメント等の各種データの送受信を行う。

図３は、サーバ１０４のソフトウェア構成の一例を示すブロック図である。以下に示すソフトウェアモジュールとしての各部は、上述したCPU２０１がROM２０３等に格納されたプログラムをRAM２０２に展開し実行することにより実現される。ただし、これら各部の一部がハードウェアロジックで構成されていてもよい。

ドキュメント管理部３００は、編集処理の対象となる所定のフォーマットで作成されたドキュメントのデータを管理する。具体的には、以下のような処理を行なう。

・データベース（不図示のDBサーバ等、外部に設けてもよい）に格納されている既存のドキュメント（以下、元ドキュメント）のデータをユーザ指示に応じて取得
・編集作業を行なうPC１０１や携帯端末１０２に元ドキュメントのデータを送信
・編集が施されたドキュメント（以下、編集ドキュメント）のデータをPC１０１や携帯端末１０２から受信
なお、ドキュメントのフォーマットとして本実施例ではPDFを例として説明を行なうものとするが、当然のことながら他のフォーマットでも構わない。

編集反映処理部３１０は、受信した編集ドキュメントに係る編集内容を、元ドキュメントに反映させる処理を行なう。元ドキュメントへの編集内容の反映には、以下の４つの処理が含まれる。

１）編集ドキュメントからの編集箇所の抽出（編集内容の特定）
２）元ドキュメント及び編集箇所の解析
３）抽出された編集箇所の表現形式（描画コマンドの属性）の決定
４）表現形式が決定した編集箇所（描画コマンド）の元ドキュメントへの統合

編集箇所抽出部３１１は、上述の１）に記載した、編集ドキュメントから編集箇所を抽出して編集内容を特定する。具体的には、編集ドキュメントと元ドキュメントとの差分（編集箇所）を、既知の方法であるテキスト差分抽出法や画像差分抽出法によって抽出する。図４は、差分抽出の様子を説明する図である。４０１は編集がなされる前の元ドキュメントであり、「あいう」の文字列と三角形の図形が描画されている。４０２は、元ドキュメント４０１における文字列と図形を描画するためのPDF描画コマンドを示している。４０３は、編集がなされた後の編集ドキュメントであり、元から存在した「あいう」の文字列と三角形の図形に、「かきく」の文字列が新たに追加されているのが分かる。４０４は、編集ドキュメント４０３における文字列と図形を描画するためのPDF描画コマンドを示している。４０５は、元ドキュメント４０１と編集ドキュメント４０３との差分（編集箇所）であり、上述の「かきく」の文字列が編集箇所として抽出されることを示している。４０６は、抽出された編集箇所に対応するPDF描画コマンドである。抽出された編集箇所の情報は、RAM２０２に格納される。

ドキュメント解析部３１２は、上述の２）に記載した、元ドキュメント及び編集箇所を解析する処理を行なう。元ドキュメントの解析においては、当該元ドキュメントで描画されるすべてのオブジェクトの描画コマンドの種別を特定した上で、描画コマンド別の個数情報を含むリスト（以下、コマンドリスト）が作成される。編集箇所の解析においては、編集箇所の描画コマンドの種別が特定される。元ドキュメント及び編集箇所の解析処理の詳細については後述する。

描画コマンド属性決定部３１３は、上述の３）に記載した、編集箇所の描画コマンドの属性を決定する処理を行なう。具体的には、編集箇所抽出部３１１で抽出された編集箇所の描画コマンドが元ドキュメントに合ったものとなるよう、当該編集箇所の表現形式（描画コマンドの属性）を適宜変換する処理を行なう。この描画コマンドの属性を決定する処理の詳細についても後述する。

ドキュメント統合部３１４は、上述の４）に記載した、表現形式が決定した編集箇所を元ドキュメントへ統合する処理を行なう。具体的には、描画コマンド属性決定部３１３で決定した編集箇所の描画コマンドを、元ドキュメントの描画コマンドに統合する。

通信部３２０は、ドキュメント管理部３００からの指示に従い、元ドキュメントや編集ドキュメントといった各種データの送受信を行う。例えば、編集内容が反映された元ドキュメントのデータが通信部３２０を介して印刷装置１０３に送られる。

印刷装置１０３では、受け取ったドキュメントの描画コマンドを解釈して２値画像に変換し、当該２値画像に基づく画像をプリントエンジンを用いて記録媒体上に形成する。その際、冒頭で述べたとおり、オブジェクトの属性に応じた画像処理がなされる。例えば、テキストの印刷時にはテキスト専用の画像処理（例えば、エッジをシャープにする処理）、イメージの印刷時には写真専用の画像処理（例えば、ぼかし処理）、グラフィックの印刷時にはいずれの画像処理も行わないといった制御がなされる。

本実施例では、編集によって新たに追加された情報に対応する描画コマンドは、元ドキュメントで用いられている描画コマンドに合わせて変換された上で、元ドキュメントに統合されるので、属性の齟齬が生じない。つまり、編集内容が反映されたドキュメントの印刷処理においては、属性が統一されて同じ画像処理が適用されることになる。したがって、編集内容が反映されたドキュメントを印刷しても、新たに追加されたオブジェクトと元からあるオブジェクトとの間で色味が異なるといった問題が生じない。

次に、ドキュメント解析部３１２における処理の詳細について説明する。ここでは、元ドキュメントの解析処理（コマンドリスト作成処理）の場合を例に説明するものとする。図５は、コマンドリスト作成処理の流れを示すフローチャートである。

ステップ５０１において、ドキュメント解析部３１２は、元ドキュメント内の任意の描画コマンドが、Textコマンドかどうかを判定する。描画コマンドの種別の判定は、予め描画コマンドを“/Type/”以下に続く内容で分類しておくことで識別可能である。例えば、“/Type/Text”で始まる描画コマンドはTextコマンド、“/Type/Image”で始まる描画コマンドはImageコマンド、“/Type/Graphics”で始まる描画コマンドはGraphicsコマンドといった具合に分類しておけばよい。判定の結果、Textコマンドであれば、ステップ５０２に進む。一方、Textコマンドでなければ、ステップ５０５に進む。

ステップ５０２において、ドキュメント解析部３１２は、Textコマンドと判定された描画コマンドがPathで構成されているかどうかを判定する。Textを描画する方法は、点列でアウトラインを描画するやり方と、イメージで描画するやり方とに大別できる。アウトラインを構成する点列をPathといい、TextコマンドがこのPathで構成されている場合は、ステップ５０３に進む。一方、TextコマンドがPathで構成されていない場合は、ステップ５０４に進む。
ステップ５０３において、ドキュメント解析部３１２は、描画コマンドがPathで構成されるTextコマンドであることを示す「PathText」のカウンタをカウントアップする。

ステップ５０４において、ドキュメント解析部３１２は、描画コマンドがPathで構成されない（Imageで構成される）Textコマンドであることを示す「ImageText」のカウンタをカウントアップする。

ステップ５０５において、ドキュメント解析部３１２は、描画コマンドがImageコマンドかどうかを判定する。判定の結果、Imageコマンドであれば、ステップ５０６に進む。一方、Imageコマンドでなければ、ステップ５１１に進む。

ステップ５０６において、ドキュメント解析部３１２は、描画コマンドが全面イメージを指定するImageコマンドかどうかを判定する。具体的には、ページの領域とイメージの領域とを比較し、両者の差分が所定の範囲内（例えば５％以内）である場合に、当該Imageコマンドは全面イメージを指定する描画コマンドであると判定する。判定の結果、全面イメージのImegeコマンドであれば、ステップ５０７に進む。一方、全面イメージのImegeコマンドでなければ、ステップ５０８に進む。

ステップ５０７において、ドキュメント解析部３１２は、描画コマンドが全面イメージのImageコマンドであることを示す「ScanImage」のカウンタをカウントアップする。

ステップ５０８において、ドキュメント解析部３１２は、描画コマンドがグラデーションのイメージを指定するImageコマンドかどうかを判定する。グラデーションイメージかどうかは、当該Imageコマンドで描画されるイメージの内容が、LinerGradiation, RadialGradiation, 3点Gradiation等の所定のパターンに一致するかどうかによって（パターンマッチング）判定することができる。判定の結果、グラデーションイメージのImageコマンドであれば、ステップ５０９に進む。一方、グラデーションイメージのImageコマンドでなければ、ステップ５１０に進む。

ステップ５０９において、ドキュメント解析部３１２は、描画コマンドがグラデーションイメージのImageコマンドであることを示す「GradationImage」のカウンタをカウントアップする。

ステップ５１０において、ドキュメント解析部３１２は、描画コマンドがその他のイメージのImageコマンドであることを示す「Image」のカウンタをカウントアップする。

ステップ５１１において、ドキュメント解析部３１２は、描画コマンドがGraphicsコマンドかどうかを判定する。判定の結果、Graphicsコマンドであれば、ステップ５１２に進む。一方、Graphicsコマンドでなければ、ステップ５１７に進む。

ステップ５１２において、ドキュメント解析部３１２は、描画コマンドが、単位面積当たりのPath数が所定の閾値（例えば100個）以上のGraphicsコマンドであるかどうかを判定する。判定の結果、単位面積当たりのPath数が所定の閾値以上のGraphicsコマンドであれば、ステップ５１３に進む。一方、単位面積当たりのPath数が所定の閾値以上のGraphicsコマンドでなければ、ステップ５１４に進む。

ステップ５１３において、ドキュメント解析部３１２は、描画コマンドが、多数のPathで構成される文字を表すGraphicsコマンドであることを示す「GraphicsText」のカウンタをカウントアップする。

ステップ５１４において、ドキュメント解析部３１２は、描画コマンドがグラデーションのグラフィックを指定するGraphicsコマンドかどうかを判定する。グラデーションのグラフィックかどうかは、例えば、描画コマンド内に“/ShadingType/”があるかどうかで判定することができる。判定の結果、グラデーションのグラフィックを指定するGraphicsコマンドであれば、ステップ５１５に進む。一方、グラデーションのグラフィックを指定するGraphicsコマンドでなければ、ステップ５１６に進む。

ステップ５１５において、ドキュメント解析部３１２は、描画コマンドがグラデーションのグラフィックを指定するGraphicsコマンドであることを示す「GradationGraphics」のカウンタをカウントアップする。

ステップ５１６において、ドキュメント解析部３１２は、描画コマンドがグラデーション以外のグラフィックを指定するGraphicsコマンドであることを示す「Graphics」のカウンタをカウントアップする。

ステップ５１７において、ドキュメント解析部３１２は、描画コマンドがその他の描画を指定することを示す「Other」のカウンタをカウントアップする。

ステップ５１８において、ドキュメント解析部３１２は、処理対象の元ドキュメントについて未処理の描画コマンドがあるかどうかを判定する。未処理の描画コマンドがあればステップ５０１に戻り、次の描画コマンドについての処理を続行する。一方、未処理の描画コマンドがなければ、ステップ５１９に進む。

ステップ５１９において、ドキュメント解析部３１２は、全てのカウンタのカウント結果（カウント値）を集計して、元ドキュメントに含まれる描画コマンドの種別とその個数の情報からなるコマンドリストを生成する。図６は、本ステップで生成されるコマンドリストの一例を示している。６０１は、前述の元ドキュメント４０１に対応するPDF描画コマンド４０２と同じものであり、これを解析した結果、６０２のようなコマンドリストが得られる。コマンドリスト６０２から、元ドキュメント４０１が、３つのGraphicsTextコマンドと１つのGraphicsコマンドという計４つの描画コマンドで構成されていることが分かる。なお、コマンドリスト６０２には、アプリケーションの名称「アプリケーションB」が、元ドキュメントの作成に使用されたアプリケーションを特定するための情報として付されている。

以上が、コマンドリスト作成処理の内容であり、生成されたコマンドリストは、RAM２０２等に格納される。なお、編集箇所の解析処理も基本的には同じである。ただし、編集箇所の解析処理では、描画コマンドの種別毎の個数情報は不要なのでカウント処理は行なわず、編集箇所の描画コマンドの種別がすべて判定された段階で処理は完了する。

続いて、描画コマンド属性決定部３１３における、編集箇所に係る描画コマンドの属性を決定する処理の詳細について説明する。図７は、描画コマンド属性決定処理の流れを示すフローチャートである。

ステップ７０１において、描画コマンド属性決定部３１３は、元ドキュメント及び編集箇所の解析結果（すなわち、元ドキュメントのコマンドリスト、及び編集箇所の描画コマンドのデータ）をRAM２０２等から取得する。

ステップ７０２において、描画コマンド属性決定部３１３は、特定のフォーマット（本実施例ではPDF）のドキュメントを作成可能なアプリケーションにおける表現形式の特徴を示した情報（以下、アプリ特徴情報）を取得する。ここで、アプリ特徴情報について説明する。

同じフォーマットかつ同じ内容の画像を含んだドキュメントであっても、それぞれの作成に使用したアプリケーションが異なれば、その表現の仕方も異なり得る。例えば、PDFのドキュメントを作る際、グラデーションを１つのイメージ（ビットマップデータ）として表現するアプリケーションもあれば、多数のグラフィックス（即ち、図形データ）の集合体として表現するアプリケーションもある。また、文字を文字コードで表現するものもあれば、グラフィックス（即ち、図形データ）で表現するものもある。あるいは矩形を４頂点の座標位置が指定されたグラフィックスとして表現するものもあれば、イメージとして表現するものもある。こういったアプリケーション毎のオブジェクトの表現形式に関する特徴の情報を集めてリスト形式にまとめたものを、本明細書では「アプリ特徴情報」と呼んでいる。そして、このようなアプリ特徴情報を用いることで、各アプリケーションの特徴に沿って、編集箇所に係る描画コマンドを必要に応じて変換することが可能となる。図８は、アプリ特徴情報の一例を示す図である。図８のアプリ特徴情報には、PDFのドキュメントを作成可能な４種類のアプリケーションA〜Dについての特徴が記載されている。アプリケーションAの特徴「Gradation by Image」はグラデーションをイメージで描画するという特徴を表している。アプリケーションBの特徴「Text by Graphics」は、テキストをグラフィックで描画するという特徴を表している。アプリケーションCの特徴「Rectangle by Image」は、矩形をイメージで描画するという特徴を表している。アプリケーションDの特徴「Rectangle by Fill」は、矩形を４頂点の座標位置が指定されたグラフィックスで描画するという特徴を表している。このように、アプリ特徴情報は、各アプリケーションについて、アプリケーションの名称と当該アプリケーションにおけるオブジェクトの表現形式の特徴とを対応付けた情報となっている。

ステップ７０３において、描画コマンド属性決定部３１３は、コマンドリストを参照し、編集の対象となった元ドキュメントの作成に使用したアプリケーションと一致するアプリケーションがアプリ特徴情報に存在するかどうかを判定する。元ドキュメントの作成に使用したアプリケーションと一致するアプリケーションがアプリ特徴情報に存在する場合は、ステップ７０４に進む。一方、元ドキュメントの作成に使用したアプリケーションと一致するアプリケーションがアプリ特徴情報に存在しない場合は、ステップ７０６に進む。

ステップ７０４において、描画コマンド属性決定部３１３は、該当するアプリケーションの特徴情報を参照して、編集箇所の描画コマンドが、当該アプリケーションの特徴に係る描画コマンドに該当するかどうかを判定する。例えば、元ドキュメントがアプリケーションB（図８を参照）で作成されている場合、その特徴は「Text by Graphics」であるので、編集箇所の描画コマンドがTextコマンドであれば「該当」と判定されることになる。判定の結果、編集箇所の描画コマンドが、元ドキュメントの作成アプリケーションの特徴に係る描画コマンドに該当する場合は、ステップ７０５に進む。一方、編集箇所の描画コマンドが、元ドキュメントの作成アプリケーションの特徴に係る描画コマンドに該当しない場合は、ステップ７０６に進む。

ステップ７０５において、描画コマンド属性決定部３１３は、アプリ特徴情報に基づき、必要に応じて、元ドキュメントの特徴に沿うように編集箇所の描画コマンドを変換する。図９は、アプリ特徴情報に基づいて編集箇所の描画コマンドが変換される一例を示す図である。図９において、枠９０１は、編集ドキュメント４０３における文字列と図形を描画するためのPDF描画コマンド４０１における編集箇所の描画コマンド（追加された文字列「かきく」に対応）を示している。枠９０２は、変換後の編集箇所の描画コマンドを示しており、元ドキュメントを作成したアプリケーションBの特徴である「Text by Graphics」に従い、TextコマンドからGraphicsコマンド（GraphicsText）に変換されている。この変換は、不図示のRIPモジュールで行われる。なお、「かきく」に対応する編集箇所の描画コマンドが当初からGraphicsコマンドであった場合には、そのまま維持されることなる。

ステップ７０６において、描画コマンド属性決定部３１３は、編集箇所の描画コマンドに対し、複数の候補が存在するかどうかを判定する。前述の図６で示したコマンドリストから明らかなように、例えばテキストの場合、PathTextなのか、ImageTextなのか、GraphicsTextなのかといった複数の候補が存在する。同様に、例えばグラデーションの場合、GradationImageなのか、GradationGraphicsなのかといった複数の候補が存在する。このように編集箇所の描画コマンドについて複数の候補が存在するかどうかが判定される。判定の結果、複数の候補が存在する場合はステップ７０７に進む。一方、複数の候補が存在しない場合は、変換の必要がないので編集箇所の描画コマンドに手を加えることなくステップ７０８に進む。

ステップ７０７において、描画コマンド属性決定部３１３は、元ドキュメントのコマンドリストに基づき、必要に応じて編集箇所の描画コマンドを変換する。具体的には、複数の候補の内、コマンドリストにおいてカウント数が１以上である描画コマンドに変換（コマンドリスト内にカウント数が１以上の描画コマンドが複数ある場合はカウント数が最多のものに変換）する。図１０は、コマンドリストに基づいて編集箇所の描画コマンドが変換される一例を示す図である。図１０において、１００１は「A」から「Z」までの文字列からなるPDFの元ドキュメント、１００２はその描画コマンド（GraphicsTextで構成）を示している。１００３は描画コマンド１００２から作成されたコマンドリストであり、GraphicsTextのカウント数のみが２６でその他のカウント数はすべて０である。そして、１００４は「１２３」の文字列が追加された編集ドキュメント、１００５は文字列「１２３」に対応する編集箇所の描画コマンド（PathTextで構成）、１００６はコマンドリスト１００３に従って変換された編集箇所の描画コマンド（GraphicsTextで構成）を示している。編集箇所の描画コマンド１００５は“PathText”であったが、コマンドリスト１００３でカウント数が唯一１以上である“GraphicsText”と一致するように変換されているのが分かる。

ステップ７０８において、描画コマンド属性決定部３１３は、未処理の編集箇所の描画コマンドがあるかどうかを判定する。未処理の編集箇所の描画コマンドがあれば、ステップ７０３に戻って次の編集箇所の描画コマンドについて処理を続行する。一方、未処理の編集箇所の描画コマンドがなければ、本処理を終える。

以上が、描画コマンド属性決定処理の内容である。この処理によって必要に応じて変換がなされた編集箇所の描画コマンドのデータはドキュメント統合部３１４に送られ、元ドキュメントに統合される。図１１は、編集箇所の描画コマンド（変換後）が元ドキュメントに統合される様子を説明する図である。図１１において、１１０１は元ドキュメントであり図６で示した元ドキュメント６０１と同じものである。１１０２は統合後の元ドキュメントであり、アプリ特徴情報に従って“Text”から“Graphics（GraphicsText）”へと変換された編集箇所の描画コマンド１１０３（図９で示した変換後の描画コマンド９０２と同じもの）が組み込まれている。

このように、本実施例では、元ドキュメントに編集内容を反映させる際に、編集箇所の描画コマンドが元ドキュメントの特徴に沿ったものへと変換される。

なお、本実施例においては、編集後のドキュメントデータそのものを受け取り、サーバ１０４内の編集箇所抽出部３１１で編集箇所を抽出していた。しかし、このような態様に限定されるものではない。例えば、ドキュメントの編集を行なうPC１０１や携帯端末１０２から編集箇所を抽出し、抽出された編集箇所の情報（編集箇所の描画コマンドのデータ）のみをサーバ１０４に送るようにしてもよい。これにより、サーバ側での処理負担を軽減することができる。

また、PC１０１や携帯端末１０２から編集内容（位置・大きさ・色を指定して「Confidential」のアノテーションを追加する旨の指示等）の情報だけをサーバ１０４に送るようにしてもよい。この場合、サーバ１０４において、元ドキュメントに沿った描画コマンドとなるよう、取得した情報で特定される編集内容の描画コマンドを決定した上で元ドキュメントに反映すればよい。

さらには、本実施例においてWebサービスのサーバ１０４で行った処理を、クラウドコンピューティングでのアプリケーションによって実現してもよい。或いは、本システムで行なったすべての処理（印刷処理を除く）を、サーバ１０４、PC１０１、モバイル端末１０２といった情報処理装置の単体で実現するようにしてもよい。

本実施例によれば、元ドキュメントに追加したい情報に対応する描画コマンドは、元ドキュメントで用いられている描画コマンドに合わせて変換された上で、元ドキュメントに統合される。よって、統合後のドキュメントにおいて属性の不一致が生じることがなく、同種類のオブジェクトには同じ画像処理が適用されることになる。したがって、統合後のドキュメントを印刷しても、オブジェクト間で色味が異なるといった問題が生じるのを防ぐことができる。

実施例１では、編集箇所の描画コマンドの属性が元ドキュメントに沿ったものとなるよう描画コマンドを変換していた。次に、編集箇所の描画コマンドを一定条件下で変換しないようにする態様について、実施例２として説明する。

具体的には、前述の図７のフローチャートのステップ７０５やステップ７０７における処理において、色、フォントサイズ、連続性といった特徴を考慮して、変換するかどうかを決定する。図１２は、編集個所の描画コマンドがそのまま維持される場合の一例を説明する図である。図１２において、１２０１は編集の対象となった元ドキュメントであり、「あいう」の文字列がGraphicsコマンドで描画されている。１２０２は、編集がなされた後の編集ドキュメントであり、「あいう」の文字列に、１回り大きなサイズの「かきく」の文字列が新たにTextコマンドで追加されている。１２０３は、該編集内容が反映された元ドキュメントであり、一定の条件下では新たに追加された文字列「かきく」がGraphicsコマンドに変換されることなくTextコマンドのままで反映されることを示している。

実施例１であれば、追加された文字列「かきく」は、元ドキュメントの特徴に沿ってGraphicsコマンドに変換された上で追加されることになる。本実施例では、追加される文字の色やフォントサイズが元ドキュメントに存在する文字の色やフォントサイズと一致するかどうかを判定し、一致しない場合は、異なる意図の描画と判断してデフォルト（ここではTextコマンド）のままで追加する。

この場合において、例えば追加される文字のフォントサイズが元ドキュメントに存在する文字のフォントサイズと一致するかどうかの判定は、所定の変化率（例えば30％）の範囲内かどうかによって決定すればよい。色についても同様である。したがって、上記１回り大きなサイズの「かきく」の文字列が、所定の変化率の範囲内であればGraphicsコマンドに変換され、所定の変化率の範囲外であればTextコマンドのまま維持されることになる。

また、元ドキュメントにおける文字列「あいう」と追加された文字列「かきく」の距離によって文字列としての連続性があるかどうかを判定し、連続性がないと判定された場合は、違う意図の描画としてデフォルトのままで追加するようにしてもよい。例えば、追加された文字列の所定の範囲（例えば1000pixel内）にある文字列の描画コマンドのみ変換時に参照することでこれを実現することが可能である。

実施例１及び２では、同一フォーマット間での編集を前提にしていた。上記実施例で述べた内容は、フォーマット変換を伴う編集時にも適用可能である。

図１３は、フォーマット変換を伴う編集時に適用した場合の一例を説明する図である。ここでは、図１３（ａ）に示す様に、まずPDFからSVGに変換し、SVGにおいて編集を行ない、その後再度PDFに変換する場合を想定する。

PDFに再度変換する時に、全てのSVGコマンドをPDFコマンドに変換すると、元のPDFドキュメントとは異なる構成のPDFドキュメントとなってしまう。そのため、編集部分のSVGコマンドのみPDFコマンドに変換して元のPDFドキュメントに統合する（図１３（ｂ））。このSVGコマンドからPDFコマンドへの変換の際に、実施例１及び２の手法を適用することで、元のPDFドキュメントの特徴を踏まえたコマンド体系の、編集後のPDFドキュメントを得ることができる。

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

Claims (12)

1. 編集されたドキュメントから、元ドキュメントに対する編集内容を特定する編集内容特定手段と、
   ドキュメントを作成するアプリケーション毎のオブジェクトの表現形式に関する特徴を示した特徴情報を取得する取得手段と、
   前記取得手段で取得した特徴情報に基づいて、前記元ドキュメントに含まれるオブジェクトの表現形式を特定する表現形式特定手段と、
   前記編集内容特定手段で特定した編集内容の表現形式と、前記表現形式特定手段で特定したオブジェクトの表現形式とが合うように、前記編集内容の表現形式を変換する変換手段と、
   前記変換手段で変換された表現形式の編集内容を、前記元ドキュメントに統合する統合手段と、
   を有することを特徴とする情報処理装置。
2. 編集されたドキュメントから、元ドキュメントに対する編集内容を特定する編集内容特定手段と、
   前記元ドキュメントに含まれるオブジェクトの描画コマンドの種別とその個数とに関する情報を含むリストを作成することにより、前記元ドキュメントに含まれるオブジェクトの表現形式を特定する表現形式特定手段と、
   前記編集内容特定手段で特定した編集内容の表現形式と、前記表現形式特定手段で特定したオブジェクトの表現形式とが合うように、前記編集内容の表現形式を変換する変換手段と、
   前記変換手段で変換された表現形式の編集内容を、前記元ドキュメントに統合する統合手段と、
   を有することを特徴とする情報処理装置。
3. 編集されたドキュメントから、元ドキュメントに対する編集内容を特定する編集内容特定手段と、
   前記元ドキュメントに含まれるオブジェクトの表現形式を特定する表現形式特定手段と、
   前記編集内容特定手段で特定した編集内容の表現形式と、前記表現形式特定手段で特定したオブジェクトの表現形式とが合うように、前記編集内容の表現形式を変換する変換手段と、
   前記変換手段で変換された表現形式の編集内容を、前記元ドキュメントに統合する統合手段と、
   を有し、
   前記変換手段は、オブジェクトの色が異なること、オブジェクトのフォントサイズが異なること、オブジェクトに連続性がないことのうち少なくとも１つの条件を満たす場合、前記変換を行わない、
   ことを特徴とする情報処理装置。
4. 前記変換手段は、前記編集内容特定手段で特定した編集内容の表現形式と、前記表現形式特定手段で特定したオブジェクトの表現形式とが合うように、前記編集内容に含まれる属性と描画コマンドとのうちの少なくともいずれかを変換することを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
5. 前記特徴情報は、アプリケーションの名称と当該アプリケーションにおけるオブジェクトの表現形式の特徴とを対応付けた情報であり、
   前記表現形式特定手段は、前記元ドキュメントの作成に使用したアプリケーションの名称と一致する名称のアプリケーションが前記特徴情報に含まれる場合に、当該一致するアプリケーションに対応するオブジェクトの表現形式を、前記元ドキュメントにおけるオブジェクトの表現形式として特定する
   ことを特徴とする請求項１に記載の情報処理装置。
6. 前記変換手段は、前記編集内容を変換する候補が複数ある場合、当該複数の候補のうち、前記編集内容に係る描画コマンドを前記リストにおいて個数が１以上である描画コマンドの表現形式に変換することを特徴とする請求項２に記載の情報処理装置。
7. 前記変換手段は、前記リスト内に、前記個数が１以上の描画コマンドが複数ある場合、前記編集内容に係る描画コマンドを個数が最多の描画コマンドに変換することを特徴とする請求項６に記載の情報処理装置。
8. 前記編集内容特定手段は、前記元ドキュメントと、前記編集されたドキュメントとを比較することによって、前記編集内容を特定することを特徴とする請求項１乃至７のいずれか１項に記載の情報処理装置。
9. 情報処理装置の編集内容特定手段が、編集されたドキュメントから、元ドキュメントに対する編集内容を特定するステップと、
   前記情報処理装置の取得手段が、ドキュメントを作成するアプリケーション毎のオブジェクトの表現形式に関する特徴を示した特徴情報を取得するステップと、
   前記情報処理装置の表現形式特定手段が、前記取得するステップで取得した特徴情報に基づいて、前記元ドキュメントに含まれるオブジェクトの表現形式を特定するステップと、
   前記情報処理装置の変換手段が、前記特定された編集内容の表現形式が、前記特定されたオブジェクトの表現形式と合うように、前記編集内容の表現形式を変換するステップと、
   前記情報処理装置の統合手段が、前記変換された表現形式の編集内容を、前記元ドキュメントに統合するステップと、
   を含むことを特徴とする情報処理方法。
10. 情報処理装置の編集内容特定手段が、編集されたドキュメントから、元ドキュメントに対する編集内容を特定する第１の特定ステップと、
    前記情報処理装置の表現形式特定手段が、前記元ドキュメントに含まれるオブジェクトの描画コマンドの種別とその個数とに関する情報を含むリストを作成することにより、前記元ドキュメントに含まれるオブジェクトの表現形式を特定する第２の特定ステップと、
    前記情報処理装置の変換手段が、前記第１の特定ステップで特定した編集内容の表現形式と、前記第２の特定ステップで特定したオブジェクトの表現形式とが合うように、前記編集内容の表現形式を変換するステップと、
    前記情報処理装置の統合手段が、前記変換するステップで変換された表現形式の編集内容を、前記元ドキュメントに統合するステップと、
    を含むことを特徴とする情報処理方法。
11. 情報処理装置の編集内容特定手段が、編集されたドキュメントから、元ドキュメントに対する編集内容を特定する第１の特定ステップと、
    前記情報処理装置の表現形式特定手段が、前記元ドキュメントに含まれるオブジェクトの表現形式を特定する第２の特定ステップと、
    前記情報処理装置の変換手段が、前記第１の特定ステップで特定した編集内容の表現形式と、前記第２の特定ステップで特定したオブジェクトの表現形式とが合うように、前記編集内容の表現形式を変換するステップと、
    前記情報処理装置の統合手段が、前記変換するステップで変換された表現形式の編集内容を、前記元ドキュメントに統合するステップと、
    を含み、
    前記変換手段は、オブジェクトの色が異なること、オブジェクトのフォントサイズが異なること、オブジェクトに連続性がないことのうち少なくとも１つの条件を満たす場合、前記変換を行わない、
    ことを特徴とする情報処理方法。
12. コンピュータを、請求項１乃至８のいずれか１項に記載の情報処理装置の各手段として機能させるためのプログラム。

Images