JP5376795B2 - 画像処理装置、画像処理方法、そのプログラム及び記憶媒体 - Google Patents

Description

本発明は紙文書を電子的に検索可能なデータへと変換する技術に関する。

近年、スキャナや、ハードディスク等の大容量記憶装置の普及により、これまで紙で保存されていた文書を電子化し、電子文書として保存する作業が進んでいる。特に紙文書をスキャンして画像データに変換するだけではなく、そこに書かれた文字情報を文字認識技術により読みとって、画像の付加情報として保存しておくことも一般に行われている。そのようにして保存された電子文書は、ユーザが元の文書に含まれていた文字列を検索キーワードとして入力することで、大量の保存文書群の中から所望の文書を高速に取り出すことが可能となっている。

また、例えば、特許文献１では、このような文字情報が関連づけられた電子文書に対して、ユーザが検索キーワードを用いて検索した際、その文書画像上で当該検索キーワードが記載されている部分をユーザが識別できるように強調表示することが記載されている。このように、検索キーワードに対応する文字部分が強調された状態で表示されるので、文書内に同じキーワードの記載箇所が複数ある場合でも、ページ画像を切り替えていくことにより、ユーザは効率よく記載部分を識別することができる。

また一方、文字認識処理した結果を透明テキスト（描画色として透明色が指定された文字コード）として画像ファイル中に埋め込み、ＰＤＦ（Portable Document Format）形式で保存する技術もある。このように作成されたＰＤＦファイルを表示させると、文書画像内の文字画像上に透明なテキストが描画されることになる。したがって、キーワード検索を行うと、透明テキストが検索されるが、ユーザにとって透明テキスト自体は見えていないので、あたかも画像が検索されているかのように見えることになる。このようにすれば、画像と文字の描画が可能なページ記述言語で記述されたフォーマットのファイルにもとづき、検索キーワードで検索可能な画像を描画することができる。

特開２０００−３２２４１７号公報

ＰＤＦやＳＶＧなどのページ記述言語を用いた電子文書における文字の描画には、各文字の字形情報、すなわちフォントデータが必要である。しかしながら、フォントデータは一般にサイズが大きいため、電子文書のサイズを小さくするためには、電子文書内にフォントデータを格納せずに、電子文書内には、フォントの種類の指定をおこなっておくことが一般に行われている。このようにすれば、アプリケーションで描画する際に、パソコンにインストールされているフォントを利用して描画することができる。

一方、電子文書内にフォントデータを格納しておくことが望まれる場合もある。例えば、文書作成アプリケーションで作成した電子文書を他のパソコンで開く場合、当該電子文書で使用されているフォントデータがそのパソコンにインストールされていなければ、その電子文書を正確に開くことはできない。言い換えると、指定のフォントデータをインストールしていないパソコンやアプリケーションで電子文書を再生する場合であっても、フォントデータ自体が電子文書内に格納されていれば、該電子文書を正確に再生することができる。

また、用途によっては、文字の描画に使用するフォントデータを電子文書内に格納しておくのを必須条件にした方がいい場合もある。例えば、長期保存対象のファイルなどは、長期間経過後、ＯＳが変更されるなどして、デフォルトでインストールされているフォントが変更になることも考えられるので、フォントデータを格納する形式を必須にしておくのがよいと考えられる。

また、フォーマットの形式によっては、フォントデータを電子文書内に格納しておくことが必須条件になっているフォーマットも存在する。例えば、ＸＰＳ（XML Paper Specification）のフォーマットでは、テキストデータを保存する場合、フォントデータも一緒に格納しておく必要がある。

しかしながら、電子文書内にフォントデータを格納すると、電子文書のサイズ自体が増加してしまう。ファイルサイズが増加すると、電子文書をネットワークで送信する際の時間が多くかかってしまったり、保存する場合の記憶容量が多く必要になったりしてしまうという問題がある。

このように電子文書内に格納されているフォントデータを用いて描画するファイル形式の電子文書において、ファイルサイズの増加を防ぐことが望まれることになる。特に、スキャン画像と、文字認識処理した結果のテキストデータと、テキスト描画用のフォントデータとを一緒に電子文書内に格納する場合に、ファイルサイズの増加を防ぐことが望まれる。フォーマットの制約やシステム上の制約などにより電子文書内にフォントデータを格納しなければならないようなとき、ファイルサイズの増加は問題になりやすい。

また、検索結果の強調表示を行う際に、文書を表示するビューアの特性によっては、検索結果の強調表示の仕方が異なる。すなわち、検索結果の強調表示により画像上の文字画像が見づらくなることがある。

かかる状況では、紙文書を電子的に検索可能な電子文書へと変換する処理において、以下の機能が求められる。すなわち、使用されるフォントデータを電子文書内部に保持するが当該電子文書のサイズは小さく抑えつつ、検索の強調表示時に視認性が確保できるようにすることが望まれる。

上記課題を解決するために本発明の画像処理装置は、 文書画像内の複数の文字画像に対して文字認識処理を行うことにより、それぞれの文字画像に対応する文字コードを得る文字認識手段と、前記文書画像と、前記文字認識手段で得た複数の文字コードと、複数の異なる文字コードの描画において共通で利用する字形データと、どの字形データを使用すべきかを各アプリケーションで判断するための判断基準の情報とを格納した電子文書を生成する生成手段と、を有する画像処理装置であって、前記複数の異なる文字コードの描画において共通で利用する字形データとして、複数種類の字形データが前記電子文書に格納され、前記判断基準の情報は、前記複数種類の字形データそれぞれの属性データとして各字形データの形状の特徴を記述した情報であり、前記電子文書に格納されている前記文書画像と前記文字コードとを描画することによって前記電子文書の閲覧処理を行うアプリケーションは、当該電子文書に格納されている前記複数種類の字形データの中から、前記複数種類の字形データそれぞれの属性データに記述されている各字形データの形状の特徴に基づいて、当該アプリケーションで強調表示するのに適した形状の特徴が前記属性データに記述されている字形データを自動的に１つ選択し、当該選択した１つの字形データを用いて当該電子文書に格納されている前記複数の異なる文字コードの描画を行うことを特徴とする。

本発明によれば、紙文書をスキャンしたページ画像の描画記述と、ページ画像より抽出した文字を（透明色で）描画する記述を有する電子文書へと変換する。その際に、単純な字形からなるフォントデータを複数、内部に格納する。また、各フォントデータにおいて、１つの字形を複数の文字種に対して共通して利用させる。これにより、使用されるフォントデータを電子文書内部に保持するが、字形データは少なくて済むので、当該電子文書のファイルサイズ（データ容量）は小さく抑えることができる。更に、いくつかのフォントデータを格納し、複数の字形を切り換えて描画することを可能としているので、異なるアプリケーションで検索の強調表示を行う場合であっても、視認性や操作性のよい表示が可能となる。

＜実施形態１＞
以下、本発明の一実施形態について図面を用いて説明する。

図１は本発明を実施できる画像処理装置の構成を示すブロック図の一例である。

１００は紙文書を電子文書へと変換する画像処理装置であり、以下の各デバイスにより構成される。

１０１は、読み取った紙文書の紙面情報を画像のデータに変換するスキャナである。１０２は、画像データを解析して検索可能な電子文書へと変換するプログラムなどを実行するＣＰＵである。１０３のメモリおよび１０４のハードディスクは、上記プログラムによる電子文書への変換結果や途中のデータを保存するための記憶装置である。

１０５は、上記プログラムによって生成されたデータを装置外に出力するネットワークＩ／Ｆである。１０６は、ユーザからの指示を受け取るためのインタフェースであり、入力キーやタッチパネルなどの入力デバイスと、液晶などの表示デバイスから構成される。

１１０は１００で作成された電子文書の検索・閲覧を行う画像処理装置であり、以下のデバイスにより構成される。

１１１は、電子文書のデータを解釈し検索や閲覧のための表示データを作成するプログラムや検索動作の制御を行うプログラムなどを実行する。１１２のメモリや１１３のハードディスクは、電子文書データの保存や、上記プログラムにより作成される表示データや処理途中のデータを保存するための記憶装置である。１１４は、装置外で生成された電子文書を装置内に転送するためのネットワークＩ／Ｆである。１１５は、ユーザからの指示を受け取るためのインタフェースであり、入力キーやタッチパネルなどの入力デバイスと、液晶などの表示デバイスから構成される。

１２０は画像処理装置１００と画像処理装置１１０を電子的に接続するネットワークである。

次に、本実施形態１による処理の例を、図２および図３のフローチャートを用いて説明する。

図２は、画像処理装置１００が、紙文書をスキャンするなどして取得した画像データから検索可能な電子文書を生成し、画像処理装置１１０へ当該電子文書を送信する処理の例を示すフローチャートである。

はじめに、ステップＳ２０１では、ユーザからの指示操作にしたがって、生成される電子文書の送信先と送信方法を決定する。ユーザからの指示はユーザインタフェース１０６を介して行われる。また、送信方法は、例えば、電子メール、ＦＴＰを用いたファイル転送、などの選択肢から選択される。

ユーザが紙文書をセットしてスタートキーを押下すると、ステップＳ２０２では、スキャナ１０１が公知の光電変換技術を用いて紙文書をスキャンしてページ画像データ（文書画像）へと変換する。手動、あるいはオートドキュメントフィーダなどを用いて複数ページの文書が入力された場合は、スキャンされた紙文書は１ページ毎に１つのページ画像データへと変換され、入力順にメモリ１０３に保存されるものとする。

図７にページ画像の例を示す。図７中のページ画像７０１には、「あいう」という文字列７０２と「かきく」という文字列７０３からなる文字画像、および写真７０４が存在する。なお、説明のために、写真７０４を黒の矩形で簡略的に示しているが、実際には自然画である。また、図７の例では、文字列７０２，７０３と、写真７０４の例しか示していないが、その他に、図形等の領域があっても構わない。

ページ画像データの形式は、例えば紙文書がカラーであればＲＧＢ各々８ｂｉｔでその階調を表現するカラー画像、白黒であれば８ｂｉｔで輝度を表現するグレースケール画像もしくは１ｂｉｔで白黒を表現する二値画像であるとする。

ステップＳ２０３では、メモリ１０３に保存された未処理のページ画像データを、処理対象画像として選択する。なお、複数ページの画像がある場合は、入力順にしたがって１ページの画像を処理対象として選択する。

ステップＳ２０４では、選択された画像から、テキスト領域、図領域、写真領域、表領域などといった性質の異なる領域ごとに領域識別する領域解析処理を行い、識別された各領域に関する領域データを生成してメモリ１０３に保存する。なお、この領域データには、該当領域の外接矩形の左上位置に対する画像内画素のｘ，ｙ方向の座標値ｘ，ｙ、および該外接矩形のサイズ（幅・高さ）を表わす画素数の値ｗｉｄｔｈ，ｈｅｉｇｈｔ、さらに、テキスト、写真などの領域の種別が含まれるものとする。

上記領域解析処理には公知の技術（領域識別処理、領域判別処理、領域抽出処理などとも言う）を用いるものとする。例えば特開平６−６８３０１号公報に開示される技術を用いれば、二値化した文書画像データから、似たような大きさの黒画素塊が縦または横に連なる範囲をテキスト領域として抽出することができる。

ここで、図８および図９に、図７に示したページ画像７０１にたいする領域解析処理例を示す。図８中の８０１がテキスト領域、８０２が写真領域と判定された領域である。図９がその領域解析処理で得られた領域データの例である。

次に、ステップＳ２０５では、領域解析処理で識別された各テキスト領域内の文字画像に対して文字認識処理をおこなうことにより、各テキスト領域についての文字コード列のデータを得て、メモリ１０３に保存する。ここで文字コード列のデータには、領域内に含まれる各文字画像に対する認識結果である文字コード情報、および当該各文字画像の外接矩形情報（外接矩形の左上座標ｘ，ｙとその幅・高さの情報ｗｉｄｔｈ，ｈｅｉｇｈｔ）が含まれるものとする。

ここで、上記文字認識処理の一例を簡単に説明する。なお、文字画像を文字認識する処理は、公知の技術を利用することが可能である。

まず、文書画像が二値画像でない場合はテキスト領域内を二値化するなどして、テキスト領域内の二値画像を得る。当該二値化された各テキスト領域内について、縦横のライン毎の黒画素数を計数してヒストグラムを作成する。縦横のヒストグラムに基づいて、周期的なヒストグラムになっている方向を行方向とし、ヒストグラムの黒画素数が所定の閾値以上になる部分を文字行を構成する部分として、短冊状の行画像を得る。次に、各行画像に対して、行方向と垂直な方向でヒストグラムをとり、ヒストグラムの結果に基づいて１文字ずつの画像を切り出す。この切り出された範囲が１文字の外接矩形情報となる。なお、ここでは、黒画素数を計数したヒストグラムを用いて判別を行ったが、各ラインに黒画素があるかないかを示す射影を用いて文字領域の判別を行うようにしてもよい。

次に、各文字画像の外接矩形内の画像から、エッジ成分などを取り出して特徴ベクトルを得て、あらかじめ登録された文字認識用辞書内の特徴ベクトルと比較し、類似度を求める。そして、最も類似度の高い字種（文字種）のコードを、当該矩形内の文字画像に対する文字コードとする。このようにして、テキスト領域内に存在する全ての文字の外接矩形に対して、文字コードを割り当てたデータが得られる。そして、各テキスト領域から得た文字コード群が文字コード列となる。

また、英文の文字領域に対しては、文字間に単語間スペースが存在するか否かの判定も行うこととする。例えば、文字間の距離が広いかどうかや、文字画像の文字認識結果の文字列と単語辞書とのマッチングを行って単語の切れ目であるかどうかなどを判別することにより、単語間スペースが存在するかどうか判定することができる。単語間スペースが存在すると判定した場合は、当該スペースの文字コードを文字コード列に挿入することになる。

なお上記説明は一例であって、他の公知技術を利用した処理方法を用いて文字コード列を取得してもよい。

図１０および図１１に、図８で示したテキスト領域８０１に対する文字認識処理例を示している。

図１０中のテキスト領域１０００から文字行１００１と１００２が先ず切り出され、さらに文字行１００１内から１０１１，１０１２，１０１３の３文字が切り出される。そして、それぞれの文字が認識され、その結果、各文字に対応する文字コードが得られて、図１１の１１０１に示したような文字コード列データが生成される。同様に文字行１００２内から切り出された１０２１，１０２２，１０２３の３文字にも文字認識処理が実行され、図１１中の１１０２の文字コード列データが生成される。

次いで、ステップＳ２０６では、処理対象となっているページ画像データ、領域データおよび文字コード列データとを関連付けて、メモリ１０３もしくはハードディスク１０４に保存する。

ステップＳ２０７では、未処理の画像データがあるかどうかを判定し、あればステップＳ２０３に戻り、次のページ画像データの処理を行う。なければステップＳ２０８に進む。

ステップＳ２０８では、メモリ１０３あるいはハードディスク１０４に保存された全ページ分のデータをページ順（処理順）に合成して複数ページからなる検索可能な電子文書を生成する。

上記ステップＳ２０８において生成される電子文書のデータは、各ページ画像をディスプレイ等に電子的に表示あるいはプリンタにより印刷する為の描画情報と、検索キーワードで検索できるようにするための内容情報の両方を保持可能なデータである。そのようなデータ保持条件を満たすデータフォーマットとしてはＰＤＦ形式、ＳＶＧ形式など様々な公知例が存在する。本実施形態では、このとき生成される電子文書のフォーマットとして、フォントデータを埋め込むことが指定されていたとする。なお、フォントデータを埋め込むことが必須条件になっているフォーマット形式としては、例えば、ＸＰＳなどがある。以下では、ＸＭＬ表現を用いたページ記述フォーマットの仕様を仮定しながら説明するが、本発明はこのフォーマットに限るものではない。もちろん、既存の、字形を埋め込む形式のＸＰＳ、ＰＤＦ／Ａなどの電子文書フォーマットを用いてもよい。

図６は、２ページ分のページ画像で構成される文書が入力された場合に、本説明で用いるページ記述フォーマットの仕様に基づいて生成された電子文書のページ記述例である。なお、ここでは、ページ記述フォーマットの例として、図６に示したように、１つのファイル内にまとめて記述するものとするが、これに限るものではない。例えば、フォントデータの部分を別ファイルにして、本体のファイルからフォントデータファイルを参照するようにし、それらをＺＩＰ圧縮等で１つの電子文書にまとめるようなフォーマット（例えば、ＸＰＳ）でもよい。

以下に、ステップＳ２０８にて行われる電子文書データ生成処理の例を、図４のフローチャートを用いて説明する。

はじめに、ステップＳ４０１では電子文書の開始を表わす記述を生成する。

本説明のページデータ記述フォーマット仕様では、＜Ｄｏｃｕｍｅｎｔ＞という要素が電子文書の開始タグを表し、その終了である＜／Ｄｏｃｕｍｅｎｔ＞までに挟まれた範囲のＸＭＬ記述が、当該文書に含まれる各ページに関する記述データとなる。図６の例では６０１が電子文書の開始タグ、６１３が終了タグを表す。

ステップＳ４０２では未記述のページの中から先頭ページ用のデータを特定して処理対象とする。

ステップＳ４０３では処理対象ページデータの開始を表わすタグを生成して記述する。本例では＜Ｐａｇｅ＞という要素タグがページデータの開始を表わし、その終了タグとなる＜／Ｐａｇｅ＞までに挟まれた範囲のＸＭＬ記述が当該ページ内の描画データおよび内容データとなる。また、＜Ｐａｇｅ＞タグには、当該ページの画素幅と高さを示す属性ＷｉｄｔｈとＨｅｉｇｈｔ、ならびに解像度を示す属性Ｄｐｉを用いてページの物理的な大きさが記述され、また、ページ番号を示す属性Ｎｕｍｂｅｒを用いてページ番号が記述される。

図６の記述例では、＜Ｐａｇｅ＞要素の開始タグ６０２に、当該ページの幅Ｗｉｄｔｈ＝“１６８０”、高さＨｅｉｇｈｔ＝“２３７６”および解像度Ｄｐｉ＝“２００”、ページ番号Ｎｕｍｂｅｒ＝“１”であることが記述されている。また、当該１ページ目のデータは、終了タグ６０６までの間（６０３〜６０６）に記述されている。

ステップＳ４０４では、ページを構成するデータのうち、画像の描画データを表わすタグ記述（画像描画記述）を生成する（画像描画記述生成）。

本説明のページデータ記述フォーマット仕様では、１つの＜Ｉｍａｇｅ＞要素が１つの画像の描画データを表わすものとする。また、画像データの内容を属性Ｄａｔａ内に記述し、その画像がページ内に描画される位置を属性Ｘ，Ｙ，Ｗｉｄｔｈ，Ｈｅｉｇｈｔの座標情報で記述するものとする。ページ内に画像が複数ある場合は各画像データを登場順に上へ重ね書きしていくことを意味する。属性Ｄａｔａ内に記述されるのは公知方法で圧縮された画像データ、例えばカラーやグレースケールの画像データの場合はＪＰＥＧ圧縮を、二値の画像データの場合はＭＭＲ圧縮をしたコード列であるとする。

図６の記述例では、図２のステップＳ２０３で選ばれた文書１ページ目のスキャン画像がページ一面にわたって描画されるように、タグ６０３では、Ｘ＝“０”、Ｙ＝“０”、Ｗｉｄｔｈ＝“１６８０”、Ｈｅｉｇｈｔ＝“２３７６”が記述されている。さらに画像をＪＰＥＧ圧縮したコード列をテキスト化した文字列を属性Ｄａｔａの値とした＜Ｉｍａｇｅ＞要素６０３が記述されている（なお、図６では、図を単純に示すため、Ｄａｔａ属性の文字列を一部省略して示している）。

ステップＳ４０５では、ページを構成するデータのうち、文字の描画データを表わす記述（文字描画記述）を生成する（文字描画記述生成）。

本説明のページデータ記述フォーマット仕様では、１つの＜Ｔｅｘｔ＞要素がそれぞれ縦または横の１行分の文字の描画データを表わす。＜Ｔｅｘｔ＞要素内に記述される属性データは以下のとおりである。
・文字列の縦書き／横書きを示す属性Ｄｉｒｅｃｔｉｏｎ（なお、Ｄｉｒｅｃｔｉｏｎが指定されていない場合は、デフォルトで横書きとする）
・文字の開始位置の座標を指定する属性Ｘ，Ｙ
・文字を描画する際に適用されるフォントデータのＩＤを指定する属性Ｆｏｎｔ
・フォントサイズを指定する属性Ｓｉｚｅ
・描画時の文字色を、Ｒ成分値、Ｇ成分値、Ｂ成分値、透過度を表すアルファチャネル値の４値の組で指定する属性Ｃｏｌｏｒ
・文字列の内容（文字コード列）を指定する属性Ｓｔｒｉｎｇ
・Ｓｔｒｉｎｇ内の各文字から次の文字までの送り幅を指定する属性ＣＷｉｄｔｈ
・Ｓｔｒｉｎｇ内の各文字が描画の際に使用する字形データすなわちグリフのＩＤを指定する属性ＣＧｌｙｐｈＩｄ

ここで、＜Ｔｅｘｔ＞要素を構成する文字列は、図２のステップＳ２０５で生成された文字コード列のデータを、文字行毎、すなわち縦または横に連なる文字の集合に更に分割したものである。なお、属性Ｆｏｎｔが未定義である場合、デフォルトのフォントＩＤに対応する字形が、全文字共通の字形として用いられる。

図６の記述例では、２つの＜Ｔｅｘｔ＞タグ６０４および６０５は、１ページ目の文字描画記述に関するものであり、図１１の文字コード列データ１１０１および１１０２それぞれに対応する記述である。

例えば図１１中１１０１の３文字の横書き文字列「あいう」に対応する＜Ｔｅｘｔ＞要素記述６０４においては、以下のとおり、各属性値が記述されている。

・属性Ｘ，Ｙは、３文字分の外接矩形の左上座標としてＸ＝“２３６”、Ｙ＝“２７２” が指定されている。

・フォントデータＩＤの属性Ｆｏｎｔは未定義である。

・フォントサイズの属性Ｓｉｚｅは、行内文字の高さから類推して“９７”ピクセルが指定されている。

・属性Ｄｉｒｅｃｔｉｏｎは横書き“Ｈｏｒｉｚｏｎｔａｌ”が指定されている。

・描画時文字色の属性Ｃｏｌｏｒは、Ｒ成分値＝Ｇ成分値＝Ｂ成分値＝０、アルファチャネル＝２５５を意味する”０，０，０，２５５”が指定されている（つまり、透明色が指定されている）。

・文字列内容（各文字に対応する文字コードの列）を指定する属性Ｓｔｒｉｎｇは、“０ｘ２４２２，０ｘ２４２４，０ｘ２４２６”が指定されている。

・各文字の送り幅を指定する属性ＣＷｉｄｔｈは、左の２文字は右隣文字との左端の座標差、最後の文字は自らの文字幅に相当する、“１０４，９６，５９”が指定されている。

・各文字の字形データであるグリフのＩＤを指定する属性ＣＧｌｙｐｈＩｄには、通常、各文字の字形データに合わせたグリフのＩＤが指定される。しかしながら、本実施形態では、スキャン画像上に透明色の文字の字形を描画するようにしているので、字形がいかなるものであっても、ユーザの視覚には見えていない。そこで、本実施形態では、異なる文字（文字種）であっても、同一のグリフＩＤを指定することにより字形データ（フォントデータ）が少なくて済むようにしている。したがって、図６の例では、属性ＣＧｌｙｐｈＩｄには、“０，０，０”の同じ属性値が記述されている。また、このグリフＩＤで指定される字形は、簡単な形状（例えば矩形）でよい。なお、グリフの形状の詳細については、後述する。

なお上記の属性値は一例であって、同様な意味を持つ別の値で記述してもよい。例えばフォントサイズの属性サイズは、ピクセル高さと画像解像度から、画素数ではなくポイント数等の値で記述されてもよい。あるいは、本記述で描画される文字には透明色が指定され、ユーザには見えていないので、描画される文字列が、対応する文字画像の真上に重ならなくても構わない。例えば、対応する文字画像の下端部に、透明な文字列が描画されるようにしてもよい。例えば、図６の６０４の例であれば、Ｘ＝“２３６”、Ｙ＝“３６８”、Ｓｉｚｅ＝“１０”とすれば、文字画像の下端に高さの低い透明な文字列が描画されることになる。このとき、この描画される透明文字列のサイズ（高さ）は、文字画像よりも小さい所定のサイズ（例えば１０）としている。

描画される透明文字列は、後に、検索キーワードで検索を行う際に用いられ、検索キーワードに一致する文字列は強調表示（例えば、色が変えられて表示）される。透明文字列は、対応する文字画像の位置にほぼ対応する位置に描画されているので、検索時には透明文字列を使って検索しているのであるが、ユーザにとっては、あたかも文字画像が検索されているかのように見えることになる。したがって、このような検索時の文字の強調の用途に用いるのであれば、透明文字列を対応する文字画像の下端部に描画したとしても、検索時には、対応する文字画像にアンダーラインが引かれたかのように強調表示されて特定できるので問題ない。なお、透明文字列の描画位置は、下端に限るものではなく、文字画像の下半分や上半分というような位置に描画されるよう記述しても構わない。

次に、ステップＳ４０６では、ページ記述の終了を示す＜／Ｐａｇｅ＞を記述する。

ステップＳ４０７では未記述のページの有無を判定し、未記述のページがある場合はステップＳ４０３から繰り返し、ない場合はステップＳ４０８に進む。図６の記述例では２ページ目に対してもステップＳ４０４〜Ｓ４０６の処理が行われ、６０７〜６１０の部分が記述されることになる。

ステップＳ４０８では、この電子文書で描画に使用される全グリフを含むフォントデータの内容の記述（字形データ記述）を生成する（字形データ記述生成）。本説明のページデータ記述フォーマット仕様では、＜Ｆｏｎｔ＞と＜／Ｆｏｎｔ＞に挟まれる範囲にフォントデータに含まれるグリフの一つ一つが＜Ｇｌｙｐｈ＞要素として記述される。＜Ｆｏｎｔ＞要素には、当該フォントの種類を示す属性ＩＤが含まれる。また、＜Ｇｌｙｐｈ＞要素には、グリフの種類を示す属性ＩＤと、そのＩＤに対応するグリフ（字形）を示す属性Ｐａｔｈとが含まれる。＜Ｇｌｙｐｈ＞要素の属性Ｐａｔｈは、左下を原点とする１０２４×１０２４描画矩形単位内で、直線あるいは曲線関数を用いてグリフを表現する記述である。

図６の記述例では、６１１および６１２の＜Ｆｏｎｔ＞要素にて、６１１ではフォントＩｄ＝“Ｆｏｎｔ０１”、６１２ではフォントＩｄ＝“Ｆｏｎｔ０２”のフォントがそれぞれ定義されている。それぞれの内容にＩｄ＝“０”を持つグリフが一種類定義されている。６１１の“Ｆｏｎｔ０１”のグリフの字形を表わすＰａｔｈ属性の“Ｍ０，０ Ｖ−１０２４ Ｈ１０２４ Ｖ１０２４ ｆ”の意味は、以下のとおりである。
「原点（０，０）にＭＯＶＥ，上方向に１０２４単位縦線を描画、右方向に１０２４単位横線を描画、下方向に１０２４単位縦線を描画、現在の点から開始点まで線を描画して囲まれた範囲を塗りつぶす。」
すなわち、１０２４×１０２４を塗りつぶす正方形のグリフを表現する記述となっている。

また６１２の“Ｆｏｎｔ０２”のグリフの字形を表わすＰａｔｈ属性の“Ｍ０，０ Ｖ−６４ Ｈ１０２４ Ｖ６４ ｆ”の意味は、以下のとおりである。
「原点（０，０）にＭＯＶＥ，上方向に６４単位縦線を描画、右方向に１０２４単位横線を描画、下方向に６４単位縦線を描画、現在の点から開始点まで線を描画して囲まれた範囲を塗りつぶす。」
すなわち、描画矩形単位内下部の１０２４×６４の領域を塗りつぶす水平方向直線状のグリフを表現する記述となっている。

なお、図６の＜Ｆｏｎｔ＞要素６１１および６１２の記述は一例であって、それぞれ垂直方向直線や波線や点線や三角や丸や四角形などの別の単純な字形を定義してもよい。

次に、ステップＳ４０９では、電子文書の終了を示す＜／Ｄｏｃｕｍｅｎｔ＞を記述し、電子文書の生成を終了する。生成された電子文書はファイルとして画像処理装置１００内のメモリ１０３あるいはハードディスク１０４に保存される。保存の際には公知のテキスト圧縮技術を用いて圧縮を施してもよい。

ここで図２に戻る。ステップＳ２０９では、ステップＳ２０８で生成された電子文書を、ステップＳ２０１で指定された送信方法で、指定された送信先である画像処理装置１１０へと転送する。転送処理は公知技術を用いるものとして説明は省略する。

以上のようにして、転送された電子文書は画像処理装置１１０がネットワークインタフェース１１４を通して受信し、ハードディスク１１４へと蓄積する。

ここで、蓄積する電子文書をハードディスク内部で特定するためのファイル名などのＩＤ情報は任意のものでよく、本説明では例として受信時刻に関連する文字列を付与するものとする。他にも、例えば重複しない番号を選択して自動付与したり、あるいは画像処理装置１００で生成時にユーザが指定する情報としてファイル名を予めユーザが入力しておくなどの方法があるが、本発明の本質とは異なる処理であるため詳細な説明は省略する。

次に、図１の画像処理装置１１０により電子文書を検索・閲覧する処理の例を図３のフローチャートに従って説明する。ここでは、画像処理装置１１０で検索を行う例について述べるが、これに限るものではなく、画像処理装置１００で検索を行えるようにしても構わない。

ステップＳ３０１では、Ｆｏｎｔ属性未定義の場合に使用されるデフォルトのフォントＩＤを電子文書が保持しているフォントＩＤの一覧からＵＩ１１５を用いてユーザに選択させる。図１６は検索対象の電子文書が所持しているフォントの一覧と、選択中のフォントのプレビュー画像（図中、黒四角部分はＦｏｎｔ０１のグリフを示している）を表示した選択画面ＵＩの一例を示したものである。このようなＵＩを用いてユーザはデフォルトのフォントＩＤを選択できる。なお、図３中のステップＳ３０１のフォントＩＤ指定処理を行う順序は一例であり、ステップＳ３０７より前であればどこにあってもよい。

ステップＳ３０２では、画像処理装置１１０内に蓄積された電子文書群から所望の電子文書の文字列を検索するために、当該電子文書のテキストに含まれているとユーザにより考えられた検索キーワードがＵＩ１１５より入力される。ここで入力された文字列の長さをｋとする。

ステップＳ３０３では、画像処理装置１１０のハードディスク１１４内にあるすべての電子文書ファイルに対し、未検索の電子文書ファイルがあるか否か判断する。未検索の電子文書ファイルがあれば、その中の１つの電子文書ファイルを特定し、その電子文書ファイルが圧縮されている場合は展開してステップＳ３０４に進む。未検索の電子文書がなければＳ３１３に進み、全ての電子文書に対する検索が終了したことをユーザに報知する。

ステップＳ３０４では、Ｓ３０３で特定された電子文書内のテキストデータを対象にして、検索キーワード文字列の探索を行う準備を行う。ここでは、文書内のテキスト（文字コード）を１列に並べ、探索開始位置ｎを初期化、すなわちｎ＝０に設定する。

ここで、ステップＳ３０４の処理例の詳細を以下に説明する。

電子文書データをＸＭＬパーサでパースしていく段階で、＜Ｔｅｘｔ＞要素が表われたとき属性Ｓｔｒｉｎｇに記述されている文字コード列を取得する。そして、その中のＳｔｒｉｎｇ属性中に記載された１文字ずつ、その文字コードと、その文字コード値が電子文書データ内で記述されている位置との組を、文字コード並びテーブルに追加していく。ここで、文字コード値が記述されている位置とは、当該文字コードを記述するキャラクタの先頭が、電子文書データの先頭から数えて何キャラクタ目であるかを示す値である。

ここで、理解を容易にするため図６の電子文書から生成した文字コード配列テーブルの例を図１２に示す。この例では、図６中の＜Ｔｅｘｔ＞要素６０４の属性Ｓｔｒｉｎｇには３つの文字コード“０ｘ２４２２”、“０ｘ２４２４”、“０ｘ２４２６”が記述されている。ここでは、それぞれこの電子文書の先頭から数えて１０９３キャラクタ目、１１００キャラクタ目、１１０７キャラクタ目の位置より記述されているものとする。同様に＜Ｔｅｘｔ＞要素６０５及び６０９に基づいて、残り６つの文字コードに対しても記述位置を求めて、図１２のような文字コード配列テーブルを生成する。なお、図１２では、このとき、文字列番号（Ｎｏ．）を０から順に付与している。

次に、ステップＳ３０５では、文字コード配列テーブルに対して、探索開始位置ｎを起点として、検索キーワードの文字コード列と一致するか否か判断する。一致する部分を検出した場合、そのときの変数ｎを一致文字列の先頭位置としてステップＳ３０６に進む。

一方、ステップＳ３０５で一致しないと判断した場合は、ステップＳ３１０に進み、当該文字コード配列テーブルの全ての文字を探索したか判断する。文字コード配列テーブルに格納されている文字コード列全ての探索が終了したと判断した場合はステップＳ３１２に進み、現在探索対象となっている電子文書の検索が終了したことを報知する。一方、全ての探索が終了していないと判断した場合は、ステップＳ３１１に進んで、変数ｎを１インクリメントして、ステップＳ３０５に戻り、次の探索開始位置ｎで検索キーワードと一致するか判断する。なお、ステップＳ３１０では、文字コード配列テーブルに格納されている文字コードの総数をＮとした場合、ｎ＜（Ｎ−ｋ）ならば全ての探索が終了していないと判断し、ｎ＞＝（Ｎ−ｋ）ならば探索終了と判断すればよい。

図１２の文字コード配列テーブルの例に対し、例えばキーワード文字「かき」の文字コード列“０ｘ２４２ｂ，０ｘ２４２ｄ”を先頭から走査して一致する部分を探した場合、最初の一致文字列の文字列番号としてｎ＝３が抽出される。また、後述するＳ３０７で更に検索を継続して次の一致文字列を検索した場合は位置ｎ＝６が抽出される。なお、この文字コードと記述位置を対にした文字コード並びテーブルを用いたステップＳ３０３〜Ｓ３０５の処理はあくまで一例であって、他の方法を用いてもよい。

次いで、ステップＳ３０６では、一致した文字列番号ｎに相当する文字列データが、電子文書のどのページに属しているかを特定する。例えば電子文書データをパースする際に、＜Ｔｅｘｔ＞要素がどの＜Ｐａｇｅ＞要素に記述されているかを判別すれば、Ｎｕｍｂｅｒ属性によってページ番号が識別できる。したがって、ステップＳ３０６で特定した位置ｎに対応する文字列の記述位置を図１２から求め、当該記述位置がどの＜Ｐａｇｅ＞要素の間にあるかによって、当該文字列が属するページが特定できる。なお、ステップＳ３０４で電子文書データをパースする際に、各＜Ｔｅｘｔ＞要素がどの＜Ｐａｇｅ＞要素に記述されているかを判別して、図１２の文字コード配列テーブルに予め格納しておけば、文字列番号に基づいてページ番号が容易に特定できる。なお、ステップＳ３０５の一致文字列の検出方法や、ステップＳ３０６のページ番号の特定方法は、上述した例に限るものではない。

ステップＳ３０７では、ステップＳ３０６で決定されたページ内に含まれる描画記述に従って、ページの描画結果をＵＩ１１５に表示する（電子文書表示）。このとき、文字列番号（Ｎｏ．）がｎ〜ｎ＋ｋ−１の範囲にある文字を描画する際には、その文字に対応する個所をユーザが識別しやすいように、該文字に強調効果を付けて描画する。この検索キーワードに一致する部分に強調効果を付けた描画の詳細については下記で説明する。

ここで、ステップＳ３０７で実施されるページの描画処理の詳細を、図５のフローチャートに従って以下に説明する。

ステップＳ５０１では、＜Ｐａｇｅ＞要素のＷｉｄｔｈ，Ｈｅｉｇｈｔ属性の値から、描画結果となるページ画像のサイズを決定する。

ステップＳ５０２では、ページ画像の画素情報が格納できる量のメモリ領域を確保する。

ステップＳ５０３では、＜Ｐａｇｅ＞要素の子要素の中で未処理の要素を先頭から順に１つ抽出し、当該抽出した未処理要素の種類を判別する。未処理要素が＜Ｉｍａｇｅ＞であると判別した場合ステップＳ５０４に進む。一方、未処理要素が＜Ｔｅｘｔ＞であると判別した場合ステップＳ５０５に進む。当該＜Ｐａｇｅ＞要素の全ての子要素が既にすべての要素が処理されている場合はステップＳ５１７へ進む。

ステップＳ５０４では、＜Ｉｍａｇｅ＞要素のＤａｔａ属性値として記述されている圧縮画像を展開する。更に、Ｘ，Ｙ，Ｗｉｄｔｈ，Ｈｅｉｇｈｔ属性が表わすページ画像内の描画矩形領域いっぱいに収まるように当該展開されたイメージを変倍する。そして、上記ステップＳ５０２で取得したページ画像メモリの該当領域へと上書きする。その後ステップＳ５０３に戻る。

一方、ステップＳ５０５では、処理対象の＜Ｔｅｘｔ＞要素に記述された各属性から、文字開始位置（Ｘ，Ｙ）、フォントＩＤ（Ｆ）、文字サイズ（Ｓ）、文字色（Ｃ）を取得する。また、当該＜Ｔｅｘｔ＞要素に記述された文字の数（Ｎ）も取得する。なお、図６の例のようにフォントＩＤが定義されていない場合は、前述のＳ３０１で指定されたデフォルトのフォントＩＤを用いる。

ステップＳ５０６では、グリフ画像生成のためのメモリ領域を確保する。ここでは１０２４×１０２４画素分の二値画像用メモリを取得するものとする。

ステップＳ５０７では、処理中文字カウンタｉを１に初期化する。

ステップＳ５０８では、ｉ＞Ｎであるか否かの判断を行い、ｉ≦ＮならステップＳ５０９に進み、ｉ＞Ｎなら当該＜ｔｅｘｔ＞要素の処理は終了してステップＳ５０３に戻る。

ステップＳ５０９では、＜ｔｅｘｔ＞要素の属性Ｓｔｒｉｎｇからｉ文字目の文字コード（Ｐ）と、属性ＣＧｌｙｐｈＩｄからｉ文字目のＧｌｙｐｈＩｄ（Ｑ）とを取得する。

ステップＳ５１０では、電子文書の中からフォントＩｄ＝Ｆの＜Ｆｏｎｔ＞要素記述を探し出し、更に、その＜Ｆｏｎｔ＞要素記述の子要素の中でグリフＩｄ＝Ｑの＜Ｇｌｙｐｈ＞要素からＰａｔｈ属性を取得する。

ステップＳ５１１では、ステップＳ５１０で取得したＰａｔｈ属性値にしたがって、ステップＳ５０６で確保したグリフ画像生成用メモリに対してグリフの二値画像を生成する。なお、グリフの二値画像とは、例えば、描画が行われる部分を１、描画が行われない部分を０として表した画像である。なお、本実施例では、描画が行われる部分１は、後に、透明色で描画されることになる。

ステップＳ５１２では、グリフの二値画像を、文字サイズの属性値（Ｓ）に則した大きさの矩形サイズになるよう変倍する。

ステップＳ５１３では、ページ画像メモリの位置（Ｘ，Ｙ）から始まる矩形領域に、変倍されたグリフの二値画像の情報を描画する。ページ画像上に二値画像を重ねて描画したときの各画素の画素値を以下の式で定義する。このとき、ページ画像の対象領域内の各画素値（ｒ，ｇ，ｂ）は、二値画像中の対応する画素の値が０か１かによって以下の（ｒ’，ｇ’，ｂ’）へと各々変化する。
・グリフ二値画像の画素値が０に対応する画素の場合：
（ｒ’，ｇ’，ｂ’）＝（ｒ，ｇ，ｂ）
・グリフ二値画像の画素値が１に対応する画素の場合：
（ｒ’，ｇ’，ｂ’）＝（Ｆ（ｒ，Ｃｒ），Ｆ（ｇ，Ｃｇ），Ｆ（ｂ，Ｃｂ））
ここで、Ｆ（ｒ，Ｃｒ）＝（ｒ×Ａ＋Ｃｒ×（２５５−Ａ））／２５５、Ｆ（ｇ，Ｃｇ）＝（ｇ×Ａ＋Ｃｇ×（２５５−Ａ））／２５５、Ｆ（ｂ，Ｃｂ）＝（ｂ×Ａ＋Ｃｂ×（２５５−Ａ））／２５５とする。また、Ａは文字色Ｃのアルファチャネル値、Ｃｒ，Ｃｇ，Ｃｂは文字色ＣのそれぞれＲＧＢ値である。なお、アルファチャネル値として２５５が指定されている場合は、当該グリフ二値画像は透明であるので、グリフ二値画像の画素値が１に対応する画素についても、（ｒ’，ｇ’，ｂ’）＝（ｒ，ｇ，ｂ）となる。

ステップＳ５１４では、処理中のｉ文字目の文字が、文字列番号（Ｎｏ．）がｎ〜ｎ＋ｋ−１の範囲にある文字であるか否かを、例えば、図１２の文字コード配列テーブルを用いて判定する。具体的には、範囲ｎ〜ｎ＋ｋ−１内の文字の記述開始位置が文字コード配列テーブルから分かるので、処理中の文字ｉの開始位置がそのいずれかに一致しているか否かに基づいて判定する。範囲ｎ〜ｎ＋ｋ−１内の文字である場合はステップＳ５１５、それ以外の場合はステップＳ５１６に進む。
ステップＳ５１５では、処理中の文字が検索文字列として検出された範囲内にあることを示すための強調処理を行う。具体的には、対応するグリフ二値画像の画素値が０である画素はそのままに、対応するグリフ二値画像の画素値が１である画素に対しては各画素値（ｒ，ｇ，ｂ）を以下の（ｒ’，ｇ’，ｂ’）へと各々変化させる
（ｒ’，ｇ’，ｂ’）＝（Ｇ（ｒ），Ｇ（ｇ），Ｇ（ｂ））
ここで、Ｇ（ｒ）＝２５５−ｒ，Ｇ（ｇ）＝２５５−ｇ，Ｇ（ｂ）＝２５５−ｂであるとする。

なお、上記強調処理は一例であり、例えば強調する幅をグリフ二値画像の幅ではなく、各文字の送り幅を指定する属性ＣＷｉｄｔｈの値を用いて、連続する文字が間隔無しに塗りつぶされるようにしてもよい。

一方、ステップＳ５１６ではＣＷｉｄｔｈ属性のｉ番目に記述されたこの文字の送り幅をＸに加算するとともにｉに１を加算して（ｉ＝ｉ＋１）、ステップＳ５０３からの処理を繰り返す。ステップＳ５０３の段階で未処理の子要素がなくなると、ステップＳ５１７へ移る。

ステップＳ５１７では、１ページ分の描画結果、すなわち＜Ｐａｇｅ＞要素内の＜Ｉｍａｇｅ＞および＜Ｔｅｘｔ＞要素記述の描画結果となっているページ画像メモリの内容を、ＵＩ１１５の表示バッファに転送して表示させる。

次いで、図５のフローチャートが示す、図３のステップＳ３０７の処理を、図６の電子文書中１ページ目の描画記述に従って実行した場合の例を説明する。

ステップＳ５０１の処理により、図６中の１ページ目の＜Ｐａｇｅ＞要素６０２の属性値Ｗｉｄｔｈ＝“１６８０”、Ｈｅｉｇｈｔ＝“２３７６”から、ページの画像サイズは１６８０×２３７６ピクセルと決定される。

ステップＳ５０２の処理により、例えばページ画像がＲＧＢ２４ｂｉｔカラーで表現される場合、１６８０×２３７６×３バイトのメモリが確保される。

ステップＳ５０４の処理により、図６中の＜Ｉｍａｇｅ＞要素６０３のＤａｔａ属性値に記述された圧縮コードが展開されて画像データとなり、ページ画像メモリの全域に上書きされる。なお、本例では画像データは元々ページと同サイズの１６８０×２３７６のピクセルの大きさを持っているので変倍処理は施されない。

ステップＳ５０５の処理により、図６中の＜Ｔｅｘｔ＞要素６０４から、Ｘ＝“２３６”，Ｙ＝“２７２”，文字数Ｎ＝３，文字サイズ＝“９７”，文字色＝“０，０，０，２５５”が得られる。＜Ｔｅｘｔ＞要素６０４ではＦｏｎｔ要素が定義されていない為、Ｓ３０１で指定したデフォルトの文字コードが指定される。ここでは、Ｓ３０１でフォントＩＤ＝“Ｆｏｎｔ０１”が指定されていたとする。

ステップＳ５０９の処理により、まず最初は、＜Ｔｅｘｔ＞要素６０４のＳｔｒｉｎｇ属性内の１番目の文字コード＝０ｘ２４２２およびＣＧｌｙｐｈＩｄ＝“０”が得られる。

ステップＳ５１１で生成されるグリフの二値画像は、デフォルトのフォントＩＤ＝“Ｆｏｎｔ０１”が指定されている為、図６中の＜Ｆｏｎｔ＞要素６１１内にある、Ｉｄ＝“０”の＜Ｇｌｙｐｈ＞要素に記述されたＰａｔｈ属性に基づいて作成される。具体的にはＰａｔｈ属性の記述に従って、１０２４×１０２４ピクセルのＧｌｙｐｈ画像領域すべてを１で塗りつぶした画像となる。

なお、図６の電子文書に記載された＜Ｔｅｘｔ＞要素６０４および６０５内の文字のＣＧｌｙｐｈＩｄはすべて“０”であるため、結果的にすべての文字に対してステップＳ５１１の処理結果は等しくなる。したがって、ステップＳ５１１で生成したグリフ画像はメモリに一時保存しておき、他の文字を描画する際、その一時保存されているグリフ画像を流用するようにしてもよい。

ステップＳ５１２では、グリフの文字画像が文字サイズ＝“９７”によって９７×９７ピクセルに変倍される。

ステップＳ５１３では、ページ画像の位置（２３６，２７２）から始まる９７×９７ピクセルの矩形範囲は変倍されたグリフの文字画像による描画対象領域となる。しかし図６の例では文字色＝“０，０，０，２５５”すなわちアルファチャネル値Ａ＝２５５であるため、グリフの二値画像の対応する画素値は１でも常に（ｒ’，ｇ’，ｂ’）＝（ｒ，ｇ，ｂ）となる。つまり、ステップＳ５１３の処理前後でページ画像内の当該矩形領域内の画素値は変化しない。

ステップＳ５１４では、図６中の＜Ｔｅｘｔ＞要素６０４内の１番目の文字が、図３中のステップＳ３０５で得られた位置ｎ〜ｎ＋ｋ−１の範囲に相当する文字か否かを、文字コード配列テーブルに基づいて判定する。

ここでは、例えば図６の電子文書から図１２の文字コード配列テーブルが生成されており、図３中のステップＳ３０５でキーワードと一致すると判断された文字列の位置が３〜４の範囲であったとする。このとき、図６中の＜Ｔｅｘｔ＞要素６０４内の１番目の文字コード記述の先頭キャラクタ位置は図に示すように１０９３である。これは、文字コード配列テーブルの３〜４の範囲内の文字の記述位置のいずれとも一致しないので、ステップＳ５１６を経て次の文字へと処理が進む。

その後、処理が進んで図６中の＜Ｔｅｘｔ＞要素６０５内の１番目が示す文字の処理に於いては、ステップＳ５１４において、文字コード配列テーブルの３〜４の範囲の文字の開始位置と一致すると判断し、ステップＳ５１５での強調描画処理が実行される。

この文字に対し、ステップＳ５１５では、ページ画像メモリの位置（２３６，４７２）から始まる９２×９２の領域内の対応するグリフ二値画像の画素値が１である画素の各画素値（ｒ，ｇ，ｂ）を、（Ｇ（ｒ），Ｇ（ｇ），Ｇ（ｂ））へと変化させる。

以上のようにして、全ての＜Ｔｅｘｔ＞を描画した後のページ画像は図１３に示すようになる。すなわち、ステップＳ３０５で一致すると判定された範囲の文字に対応する領域に関しては、各矩形内で輝度が反転された状態となる。一方、残りの文字に対応する領域は、＜Ｉｍａｇｅ＞要素を描画した画像データのままとなる。

したがって、検索した文字列が強調表示されるので、ページ内のどこに検索キーワードが存在するかを、ユーザはステップＳ３０７で表示されたページの画像を見るだけで容易に判断することができる。

一方、ビューア・アプリケーションの種類によっては、強調表示する際の表示方法が異なる場合がある。すなわち、図５中のステップＳ５１５の文字部の強調処理の方法によっては、記載されている文字をユーザが識別できなくなるなど、適切な強調表示がなされない場合がある。例えば強調処理において、対応するグリフ二値画像の画素値が０である画素はそのままにし、グリフ二値画像の画素値が１である画素に対しては各画素値（ｒ，ｇ，ｂ）を予め決められた色（例えば（０，０，０））に各々変化させるようなビューアがあったとする。この場合、本実施形態のＦｏｎｔ０１は四角で塗りつぶすグリフを使用しているので、強調表示すると図１７のようなページ画像が表示されることになってしまう。図１７のような状態になってしまうと、文字画像が見えなくなってしまい、ユーザの視認性が悪くなってしまう。

そこで、上述したように本実施形態では、このようなビューア・アプリケーションで使用される場合を想定し、ステップＳ２０８で電子文書を生成する際に、異なるグリフを有するフォントデータを複数種類、格納するようにしている。したがって、ユーザは再度図３のステップＳ３０１のフォントＩＤ指定の処理を用いて、別のフォントＩＤを指定すれば強調表示の方法を変更できる。

Ｓ３０１でデフォルトのフォントＩＤに“Ｆｏｎｔ０２”を指定し、強調表示をおこなった場合のページ画像表示の例を図１４に示す。図６中の記述６１２に指定されるグリフ二値画像を用いて各画素値（ｒ，ｇ，ｂ）を（０，０，０）へと変化させた強調表示がそれぞれ描画されると、図１４のようなページ画像が生成される。つまり、“Ｆｏｎｔ０２”で用いるグリフは、描画矩形単位内下部の１０２４×６４の領域を塗潰す水平方向直線状のグリフであるから、この部分の画素値を（０，０，０）にした場合、図１４のように文字に下線が付与されたかのように強調表示されることになる。したがって、ユーザは検索した文字列がページ内のどこに存在するかを容易に判断することができるとともに、文字画像の視認性も確保できる。

ここで図３に戻る。ステップＳ３０８では、ユーザが検索・閲覧処理を終了するか、あるいは更に別の検索箇所を対象に検索を継続するか選択する。ユーザが終了を選択した場合は図３の処理を終了し、継続を選択した場合はステップＳ３０９に進む。

ステップＳ３０９では、ｎ＝ｎ＋ｋとし、ステップＳ３０５に戻って以降の処理を繰り返す。

以上説明したように、本発明の実施形態１によれば、紙の文書が電子文書へと変換される際に、ページ画像上にページから抽出した文字が透明色で描画されるように記述するとともに、異なる字形を有するフォントを複数格納する。この電子文書に対して、ユーザは強調表示時に用いるデフォルトの字形を選択、すなわち字形の切換指示をできるようになる。したがって、各ビューア・アプリケーション或いはその文書画像に最適な字形に切り換えて強調表示させることができる。検索キーワードに一致する箇所が見やすい形で強調表示されたページ表示を、ユーザが確認しながら検索を進めていくことが可能である。

本実施形態の電子文書は、単純な字形からなるフォントデータを一つの文字に対して複数、内部で持ち、文書内の透明文字の描画する際に、上記単純な字形の１つを選択して描画できるようになる。また、各フォントデータにおいて、１つの字形を複数の文字種に対して共通して利用するようにしている。したがって、使用されるフォントデータを電子文書内部に保持するが、字形データは少なくて済むので、当該電子文書のファイルサイズ（データ容量）は小さく抑えることができる。更に、いくつかのフォントデータを格納しているので、検索の強調表示時には視認性や操作性のよい表示が可能となる。

＜実施形態２＞
次に、本発明の第２の実施形態（実施形態２）について図面を用いて説明する。

図１５は、本実施形態２により生成された電子文書の例である。前述の実施形態１と同様に、画像処理装置１００が電子文書を生成・送信し、画像処理装置１１０が受信・閲覧・検索するものとする。

図１５中の１５０１および１５１３は電子文書の開始、終了を表す記述である。１５０２および１５０６は１ページ目の描画の開始、終了を表わす記述である。１５０３は１ページ目の画像データ描画の記述である。１５０４および１５０５は１ページ目の文字描画の記述である。また、１５０７および１５１０は２ページ目の描画の開始、終了を表わす記述である。１５０８は２ページ目の画像データ描画の記述である。１５０９は２ページ目の文字描画の記述である。１５１１および１５１２はこの電子文書で用いられるフォントデータの記述である。

実施形態１では、図３ステップＳ３０１において、デフォルトのフォントＩＤをユーザが選択していたが、本実施形態２では、閲覧処理を行うアプリケーション（ビューア）がその選択のための判断を行えるように、電子文書を生成する。その場合、図４のステップＳ４０８のフォントデータ記述において、＜Ｆｏｎｔ＞要素にアプリケーションが判断する為の属性を追加することになる。本実施形態では、図１５中の＜Ｆｏｎｔ＞要素１５１１および１５１２ではＳｈａｐｅという属性により、フォントデータの形状（フォントデータの特徴）が容易に判別できるようにしている。この場合、このフォントデータのＳｈａｐｅ属性を判断基準として用いることにより、アプリケーションはそのアプリケーションで強調表示を行うときに適した表示用のフォントＩＤを選択できるようになる。なお、上記追加属性は一例であり、フォントデータの特徴以外に、閲覧処理をするアプリケーションの名前や種類などを属性として記述してもよい。この場合、これを判断基準として、例えば、アプリケーションが自らのアプリケーション名が含まれているフォントデータの判断を行い、デフォルト表示用のフォントＩＤを決定する。

本実施形態２によれば、紙の文書が電子文書へと変換される際に、ページ画像上にページから抽出した文字が透明色で描画されるように記述し、異なる字形を有するフォントを複数記述し、アプリケーションがどのフォントを使用すべきか判断する為の属性を持つ。この電子文書に対しては、アプリケーション（ビューアなど）が上記属性を判断して字形を自動的に選択して当該アプリケーションで強調表示するのに適した字形に切り換えて表示することができる。また、検索キーワードに一致する箇所が強調表示され、且つ文字画像の視認性が自動的に確保されたページ表示をユーザが確認しながら検索を進めていくことが可能である。

上述のように、本実施形態２における電子文書は、文書内で記述したすべての透明文字の描画にあたって、アプリケーション（ビューアなど）が属性を判断して複数の字形から一つの字形を選択して描画するように記述されている。また、各フォントデータにおいて、１つの字形を複数の文字種に対して共通して利用するようにしている。そのため、電子文書が当該電子文書内で使用されるフォントデータを保持するが、字形データは少なくて済むので、電子文書のファイルサイズ（データ容量）は小さく抑えることができる。更に、いくつかのフォントデータを格納しているので、検索の強調表示時にはアプリケーションに最適な表示が可能である。

＜実施形態３＞
また、上述した実施形態では、スキャン画像に対してＪＰＥＧ圧縮等を行った全面イメージを＜Ｉｍａｇｅ＞要素に記述し、透明テキストを＜Ｔｅｘｔ＞要素に記述した電子文書を生成することとしたが、これに限るものではない。

例えば、＜Ｉｍａｇｅ＞要素に、スキャン画像全体をＪＰＥＧ圧縮したものを記述する代わりに、文字領域や図領域は色別に２値画像を作成してＭＭＲ圧縮したもの、それ以外の領域はＪＰＥＧ圧縮したものを格納するようにしてもよい。このように、文書画像に含まれる領域を解析して適応的に圧縮処理を行う方法は、例えば、特開平０７−２３６０６２号公報や特開２００２−０７７６３３号公報などに記載の方法を用いることができる。本発明の透明テキストを描画する際に用いるフォントデータのデータ量を抑える処理と、これらの画像圧縮処理とを組み合わせることで、更に高圧縮された電子文書を生成することが可能になる。

また、全面イメージの代わりに、文字領域、図領域、表領域、写真領域などの部分領域だけを位置データとともに保存するようにしても構わない。

＜実施形態４＞
また、上述した実施形態では、図３及び図５で説明したように、検索を行う際は、キーワードに一致する文字列を文書の先頭から順に検索していき、最初に検索された文字列を強調表示した。そして、「次を検索」の指示があれば、順次、次に一致する文字列を検索して強調表示するように構成した。このように、上述した実施形態では、検索キーワードに一致する文字列を先頭から順に検索をおこない、検索キーワードがヒットするごとに順次強調表示を行っていたが、これに限るものではない。例えば、電子文書内に含まれる全ての文字列について、検索キーワードと比較を行い、全ての一致する文字列を特定し、そのキーワードに一致した全ての文字列を同時に強調表示するような構成にしてもよい。

以上、本発明の諸実施形態について説明した。

なお、本発明の目的は、上述した実施形態で示したフローチャートの手順を実現するプログラムコードを記憶した記憶媒体から、システムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）がそのプログラムコードを読出し実行することによっても達成される。
この場合、記憶媒体から読み出されたプログラムコード自体が、コンピュータに、上述した実施形態の機能を実現させることになる。そのため、このプログラムコード及びプログラムコードを記憶／記録したコンピュータ読み取り可能な記憶媒体も本発明の一つを構成することになる。

プログラムコードを供給するための記憶媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。

また、前述した実施形態の機能は、コンピュータが、読み出したプログラムを実行することによって実現される。また、このプログラムの実行とは、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行う場合も含まれる。

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

本発明の実施形態１および２の画像処理装置の構成例を表すブロック図である。 本発明の実施形態１および２の電子文書生成処理の例を表すフローチャートである。 本発明の実施形態１および２の電子文書検索・閲覧処理の例を表すフローチャートである。 図２中ステップＳ２０８にて行われる電子文書データ生成処理の例を表すフローチャートである。 図３中ステップＳ３０７にて行われるページの描画処理の例を表すフローチャートである。 本発明の実施形態１により生成される電子文書の一例である。 本発明の実施形態１および２にて処理されるページ画像の一例である。 本発明の実施形態１および２にて行われる領域解析処理例を表す図である。 本発明の実施形態１および２にて生成される領域データの一例である。 本発明の実施形態１および２にて行われる文字認識処理例を表す図である。 本発明の実施形態１および２にて生成される文字コード列データの例である。 本発明の実施形態１および２にて利用される文字コード配列テーブルの一例である。 本発明の実施形態１および２で実施される検索箇所が強調されたページ表示例である。 本発明の実施形態１で実施される検索箇所が強調されたページ表示例である。 本発明の実施形態２により生成される電子文書の一例である。 本発明の実施形態１にて表示されるＵＩの一例である。 本発明の実施形態１で実施される検索箇所が強調されたページ表示例である。

符号の説明

１００，１１０ 画像処理装置
１０１ スキャナ
１０２，１１１ ＣＰＵ
１０３，１１２ メモリ
１０４，１１３ ハードディスク
１０５，１１４ ネットワークＩ／Ｆ
１０６，１１５ ＵＩ
１２０ ネットワーク

Claims (12)

1. 文書画像内の複数の文字画像に対して文字認識処理を行うことにより、それぞれの文字画像に対応する文字コードを得る文字認識手段と、
   前記文書画像と、前記文字認識手段で得た複数の文字コードと、複数の異なる文字コードの描画において共通で利用する字形データと、どの字形データを使用すべきかを各アプリケーションで判断するための判断基準の情報とを格納した電子文書を生成する生成手段と、
   を有する画像処理装置であって、
   前記複数の異なる文字コードの描画において共通で利用する字形データとして、複数種類の字形データが前記電子文書に格納され、
   前記判断基準の情報は、前記複数種類の字形データそれぞれの属性データとして各字形データの形状の特徴を記述した情報であり、
   前記電子文書に格納されている前記文書画像と前記文字コードとを描画することによって前記電子文書の閲覧処理を行うアプリケーションは、当該電子文書に格納されている前記複数種類の字形データの中から、前記複数種類の字形データそれぞれの属性データに記述されている各字形データの形状の特徴に基づいて、当該アプリケーションで強調表示するのに適した形状の特徴が前記属性データに記述されている字形データを自動的に１つ選択し、当該選択した１つの字形データを用いて当該電子文書に格納されている前記複数の異なる文字コードの描画を行う
   ことを特徴とする画像処理装置。
2. 文書画像内の複数の文字画像に対して文字認識処理を行うことにより、それぞれの文字画像に対応する文字コードを得る文字認識手段と、
   前記文書画像と、前記文字認識手段で得た複数の文字コードと、複数の異なる文字コードの描画において共通で利用する字形データと、どの字形データを使用すべきかを各アプリケーションで判断するための判断基準の情報とを格納した電子文書を生成する生成手段と、
   を有する画像処理装置であって、
   前記複数の異なる文字コードの描画において共通で利用する字形データとして、複数種類の字形データが前記電子文書に格納され、
   前記判断基準の情報は、前記複数種類の字形データそれぞれの属性データとしてアプリケーションの名前または種類を記述した情報であり、
   前記電子文書に格納されている前記文書画像と前記文字コードとを描画することによって前記電子文書の閲覧処理を行うアプリケーションは、当該電子文書に格納されている前記複数種類の字形データの中から、当該閲覧処理を行うアプリケーションの名前または種類が前記属性データに記述されている字形データを自動的に１つ選択し、当該選択した１つの字形データを用いて当該電子文書に格納されている前記複数の異なる文字コードの描画を行う
   ことを特徴とする画像処理装置。
3. 前記電子文書に格納される複数種類の字形データのうちの１つは、矩形の形状を有する字形データであることを特徴とする請求項１または２に記載の画像処理装置。
4. 前記電子文書に格納される複数種類の字形データのうちの１つは、下線の形状を有する字形データであることを特徴とする請求項１または２に記載の画像処理装置。
5. 前記電子文書に格納される複数種類の字形データのうちの１つは、波線、点線、三角、丸、四角形の形状のうちの少なくともいずれかの形状を有する字形データであることを特徴とする請求項１または２に記載の画像処理装置。
6. 前記生成手段で生成された電子文書には、前記複数の文字コードに対応させた字形データを、前記文書画像内の各文字画像の位置に対応する位置に透明色で描画させるための記述が含まれることを特徴とする請求項１または２に記載の画像処理装置。
7. 前記電子文書は、ＸＭＬフォーマット或いはＸＰＳフォーマットで記述された電子文書であることを特徴とする請求項１または２に記載の画像処理装置。
8. 前記画像処理装置は、前記文書画像を圧縮する圧縮手段を更に有し、
   前記電子文書に格納される文書画像は、前記圧縮手段で圧縮処理が施された文書画像であることを特徴とする請求項１または２に記載の画像処理装置。
9. 前記圧縮手段は、前記文書画像内に含まれる領域を解析して適応的に圧縮することを特徴とする請求項８に記載の画像処理装置。
10. 前記アプリケーションは、前記生成された電子文書に格納されている複数の文字コードに対して、入力された検索キーワードに一致する部分を前記選択した１つの字形データを用いて強調表示させることを特徴とする請求項１乃至９のいずれか１項に記載の画像処理装置。
11. 文字認識手段が、文書画像内の複数の文字画像に対して文字認識処理を行うことにより、それぞれの文字画像に対応する文字コードを得る文字認識ステップと、
    生成手段が、前記文書画像と、前記文字認識手段で得た複数の文字コードと、複数の異なる文字コードの描画において共通で利用する字形データと、どの字形データを使用すべきかを各アプリケーションで判断するための判断基準の情報とを格納した電子文書を生成する生成ステップと、を有する画像処理方法であって、
    前記複数の異なる文字コードの描画において共通で利用する字形データとして、複数種類の字形データが前記電子文書に格納され、
    前記判断基準の情報は、前記複数種類の字形データそれぞれの属性データとして各字形データの形状の特徴を記述した情報であり、
    前記電子文書に格納されている前記文書画像と前記文字コードとを描画することによって前記電子文書の閲覧処理を行うアプリケーションは、当該電子文書に格納されている前記複数種類の字形データの中から、前記複数種類の字形データそれぞれの属性データに記述されている各字形データの形状の特徴に基づいて、当該アプリケーションで強調表示するのに適した形状の特徴が前記属性データに記述されている字形データを自動的に１つ選択し、当該選択した１つの字形データを用いて当該電子文書に格納されている前記複数の異なる文字コードの描画を行う
    ことを特徴とする画像処理方法。
12. コンピュータを、請求項１乃至１０のいずれか１項に記載の画像処理装置として機能させるためのプログラム。

Images