画像処理装置
【課題】 電子文書内にフォントデータを格納するようにした場合、ファイルサイズが増加してしまうという問題があった。
【解決手段】 本発明では、紙文書をスキャンすることにより生成した文書画像内の複数の文字画像を文字認識する。そして、当該文書画像と、該文字認識結果の複数の文字コードと、前記複数の文字コードに対応する文字を描画する際に当該複数の文字コードで共通利用させるための字形データとを格納した電子文書を生成し、指定された送信先へ送信する。これにより、送信先で検索を行う際に、文書画像上で検索キーワードに対応する部分を特定することが可能な電子文書となる。更に、字形データを複数の文字コードで共通利用するので、電子文書内にフォントデータを保存しなければならない場合であっても、ファイルサイズの増加が小さくてすむ。また、単純な字形で描画することによってフォントデータ自体のデータ容量も少なくて済む。
【解決手段】 本発明では、紙文書をスキャンすることにより生成した文書画像内の複数の文字画像を文字認識する。そして、当該文書画像と、該文字認識結果の複数の文字コードと、前記複数の文字コードに対応する文字を描画する際に当該複数の文字コードで共通利用させるための字形データとを格納した電子文書を生成し、指定された送信先へ送信する。これにより、送信先で検索を行う際に、文書画像上で検索キーワードに対応する部分を特定することが可能な電子文書となる。更に、字形データを複数の文字コードで共通利用するので、電子文書内にフォントデータを保存しなければならない場合であっても、ファイルサイズの増加が小さくてすむ。また、単純な字形で描画することによってフォントデータ自体のデータ容量も少なくて済む。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、紙文書のスキャン画像を電子的に検索可能なデータへ変換する技術に関する。
【背景技術】
【0002】
近年、スキャナおよびハードディスク等大容量記憶装置の普及により、これまで紙で保存されていた文書をスキャンし、電子文書として保存されるようになっている。その際、紙文書をスキャンして得た画像データに対して文字認識処理を実行することにより、文書に記載されている文字情報を読みとり、画像にその文字情報を関連付けて保存しておくことも行われている。ユーザは、このようにして文字情報が関連付けられた電子文書を、検索キーワードを用いて検索できる。このように、大量の保存文書群の中から所望の文書を高速に検索するためには、スキャン画像に対してもキーワード検索できるようにすることが重要である。
【0003】
例えば、特許文献1では、このような文字情報が関連づけられた電子文書に対して、ユーザが検索キーワードを用いて検索した際、その文書画像上で当該検索キーワードが記載されている部分をユーザが識別できるように強調表示することが記載されている。このように、検索キーワードに対応する文字部分が強調された状態で表示されるので、文書内に同じキーワードの記載箇所が複数ある場合でも、ページ画像を切り替えていくことにより、ユーザは効率よく記載部分を識別することができる。
【0004】
また一方、文字認識処理した結果を透明テキスト(描画色として透明色が指定された文字コード)として画像ファイル中に埋め込み、PDF(Portable Document Format)形式で保存する技術もある。このように作成されたPDFファイルを表示させると、文書画像内の文字画像上に透明なテキストが描画されることになる。したがって、キーワード検索を行うと、透明テキストが検索されるが、ユーザにとって透明テキスト自体は見えていないので、あたかも画像が検索されているかのように見えることになる。このようにすれば、画像と文字の描画が可能なページ記述言語で記述されたフォーマットのファイルにもとづき、検索キーワードで検索可能な画像を描画することができる。
【先行技術文献】
【特許文献】
【0005】
【特許文献1】特開2000−322417
【発明の概要】
【発明が解決しようとする課題】
【0006】
PDFやSVGなどのページ記述言語を用いた電子文書における文字の描画には、各文字の字形情報、すなわちフォントデータが必要である。しかしながら、フォントデータは一般にサイズが大きいため、電子文書のサイズを小さくするためには、電子文書内にフォントデータを格納せずに、電子文書内には、フォントの種類の指定をおこなっておくことが一般に行われている。このようにすれば、アプリケーションで描画する際に、パソコンにインストールされているフォントを利用して描画することができる。
【0007】
一方、電子文書内にフォントデータを格納しておくことが望まれる場合もある。例えば、文書作成アプリケーションで作成した電子文書を他のパソコンで開く場合、当該電子文書で使用されているフォントデータがそのパソコンにインストールされていなければ、その電子文書を正確に開くことはできない。言い換えると、指定のフォントデータをインストールしていないパソコンやアプリケーションで電子文書を再生する場合であっても、フォントデータ自体が電子文書内に格納されていれば、該電子文書を正確に再生することができる。
【0008】
また、用途によっては、文字の描画に使用するフォントデータを電子文書内に格納しておくのを必須条件にした方がいい場合もある。例えば、長期保存対象のファイルなどは、長期間経過後、OSが変更されるなどして、デフォルトでインストールされているフォントが変更になることも考えられるので、フォントデータを格納する形式を必須にしておくのがよいと考えられる。
【0009】
また、フォーマットの形式によっては、フォントデータを電子文書内に格納しておくことが必須条件になっているフォーマットも存在する。例えば、XPS(XML Paper Specification)のフォーマットでは、テキストデータを保存する場合、フォントデータも一緒に格納しておく必要がある。
【0010】
しかしながら、電子文書内にフォントデータを格納すると、電子文書のサイズ自体が増加してしまう。ファイルサイズが増加すると、電子文書をネットワークで送信する際の時間が多くかかってしまったり、保存する場合の記憶容量が多く必要になったりしてしまうという問題がある。
【0011】
このように電子文書内に格納されているフォントデータを用いて描画するファイル形式の電子文書において、ファイルサイズの増加を防ぐことが望まれることになる。特に、スキャン画像と、文字認識処理した結果のテキストデータと、テキスト描画用のフォントデータとを一緒に電子文書内に格納する場合に、ファイルサイズの増加を防ぐことが望まれる。フォーマットの制約やシステム上の制約などにより電子文書内にフォントデータを格納しなければならないようなとき、ファイルサイズの増加は問題になりやすい。
【課題を解決するための手段】
【0012】
上記課題を解決するために、本発明の画像処理装置は、紙文書をスキャンして文書画像を生成するスキャナと、前記スキャナで生成した文書画像内の複数の文字画像に対して文字認識処理を行うことにより、それぞれの文字画像に対応する文字コードを得る文字認識手段と、前記文書画像と、前記文字認識手段で得た複数の文字コードと、前記複数の文字コードに対応する文字を描画する際に当該複数の文字コードで共通利用させるための字形データとを格納した電子文書を生成する生成手段と、前記生成手段で生成した電子文書を、指定された送信先へ送信する送信手段と、を有する。
【発明の効果】
【0013】
本発明によれば、紙文書をスキャンすることにより生成した文書画像内の複数の文字画像を文字認識する。そして、当該文書画像と、該文字認識結果の複数の文字コードと、前記複数の文字コードに対応する文字を描画する際に当該複数の文字コードで共通利用させるための字形データとを格納した電子文書を生成し、指定された送信先へ送信する。これにより、送信先で検索を行う際に、文書画像上で検索キーワードに対応する部分を特定することが可能な電子文書となる。更に、字形データを複数の文字コードで共通利用するので、電子文書内にフォントデータを保存しなければならない場合であっても、ファイルサイズの増加が小さくてすむ。また、単純な字形で描画することによってフォントデータ自体のデータ容量も少なくて済む。
【図面の簡単な説明】
【0014】
【図1】実施形態1の構成例を表すブロック図
【図2】実施形態1の電子文書生成処理の例を表すフローチャート
【図3】実施形態1の電子文書検索・閲覧処理の例を表すフローチャート
【図4】図2のステップS208でおこなわれる電子文書データ生成処理の詳細を表すフローチャート
【図5】図3のステップS306でおこなわれるページの描画処理の詳細を表すフローチャート
【図6】実施形態1により生成される電子文書の例
【図7】処理対象のページ画像の例
【図8】領域分割処理結果の例
【図9】生成される領域データの例
【図10】文字認識処理時に文字画像を抽出する際の処理を示す例
【図11】文字認識結果で生成される文字コード列データの例
【図12】文字コード配列テーブルの例
【図13】検索結果が強調表示されたページ表示の例
【図14】別の強調表示処理で検索結果が強調表示されたページ表示の例
【図15】実施形態2により生成される電子文書の例
【図16】検索結果が強調表示されたページ表示の例
【発明を実施するための形態】
【0015】
<実施形態1>
図1は画像処理装置の構成を示すブロック図の一例である。
【0016】
画像処理装置100は本実施形態を実現するための装置であり、文書画像データを検索可能な電子文書に変換する。画像処理装置100は、スキャナ101、中央処理ユニット(CPU)102、メモリ103、ハードディスク104、ネットワークインタフェース105、ユーザインタフェース(UI)106で構成される。スキャナ101は紙文書の紙面情報を読み取り、文書画像データに変換を行う。CPU102は、画像データを解析して検索可能な電子文書へ変換するためのコンピュータプログラムなどを実行する処理部である。メモリ103は、該プログラムや処理中のデータを保持したり、CPUのワークスペースとして使用したりするための記憶媒体である。ハードディスク104は、該コンピュータプログラムや電子文書などのデータを格納するための大容量記憶媒体である。ネットワークインタフェース105は、ネットワーク120と接続するためのインタフェースであり、スキャン画像や前記変換された検索可能な電子文書などのデータを外部装置へ送信したり、外部装置からデータを受信したりするために使用される。ユーザインタフェース106は、ユーザからの指示を受け取るためのインタフェースであり、入力キーやタッチパネルなどの入力デバイスと、液晶などの表示デバイスから構成される。なお、本発明の装置の構成は、これに限るものではない。
【0017】
画像処理装置110は、画像処理装置100で作成された電子文書の検索や閲覧をおこなうことができる。CPU111は、電子文書を検索したり閲覧したりするための処理をおこなうためのコンピュータプログラムを実行する。メモリ112は、該プログラムを実行するためのワークスペースとして使用したり、データを一時保存したりするための記憶媒体である。ハードディスク113は、コンピュータプログラムや電子文書などのデータを格納するための大容量記憶媒体である。ネットワークインタフェース114は、外部装置から電子文書などのデータを受信したり、外部装置へデータを送信したりするためのインタフェースである。ユーザインタフェース115は、ユーザからの指示を受け取るためのインタフェースであり、入力キーやタッチパネルなどの入力デバイスと、液晶などの表示デバイスから構成される。
【0018】
次に、本実施形態1における処理を図2および図3のフローチャートを用いて説明する。
【0019】
図2は、画像処理装置100が、紙文書をスキャンするなどして取得した画像データから検索可能な電子文書を生成し、画像処理装置110へ当該電子文書を送信する処理の例を示すフローチャートである。
【0020】
ステップS201では、ユーザからの指示操作にしたがって、生成される電子文書の送信先と送信方法を決定する。ユーザからの指示はユーザインタフェース106を介して行われる。また、送信方法は、例えば、電子メール、FTPを用いたファイル転送、などの選択肢から選択される。
【0021】
ユーザが紙文書をセットしてスタートキーを押下すると、ステップS202では、スキャナ101を用いて当該セットされた紙文書をスキャンして文書画像データを生成してメモリに保存する。なお、オートドキュメントフィーダなどを用いて、複数ページで構成される文書が入力された場合は、1ページ毎に1つのページ画像データへと変換され、入力順にメモリ103に保存されるものとする。
【0022】
図7にページ画像の例を示す。図7中のページ画像701には、「あいう」という文字列702と「かきく」という文字列703、および写真704が存在する。なお、説明のために、写真704を黒の矩形で簡略的に示しているが、実際には自然画である。また、図7の例では、文字列702,703と、写真704の例しか示していないが、その他に、図形等の領域があっても構わない。
【0023】
なお、ページ画像データの形式は、例えば、紙文書がカラーであれば、RGB各々8bitで階調を表現するカラー画像で扱い、紙文書が白黒であれば8bitで輝度を表現するグレー画像もしくは1bitで白黒を表現する二値画像で扱うものとする。
【0024】
ステップS203では、メモリ103に保存された未処理のページ画像データを、処理対象画像として選択する。なお、複数ページの画像がある場合は、入力順にしたがって1ページの画像を処理対象として選択する。
【0025】
ステップS204では、処理対象の画像を解析して、テキスト領域、図領域、写真領域、表領域などといった性質の異なる領域ごとに領域識別する領域解析処理を行い、識別された各領域に関する領域データを生成してメモリ103に保存する。ここで領域データには、各領域の外接矩形の左上位置座標(x,y座標値)と、該外接矩形のサイズ(幅と高さ)を表わす画素数の値と、当該判別された領域の種別とが含まれるものとする。なお、前記領域解析処理には、公知の技術(領域識別処理、領域判別処理、領域抽出処理などとも言う)を用いるものとする。例えば、特開平6−68301号公報に開示される技術を用いれば、二値化した文書画像データから、似たような大きさの黒画素塊が縦または横に連なる範囲をテキスト領域として抽出することができる。
【0026】
図7のページ画像701に対して領域解析処理を行った結果、図8のように、テキスト領域801、写真領域802とが識別される。図9は、その領域解析処理で得られた領域データの例である。
【0027】
ステップS205では、領域解析処理で識別された各テキスト領域内の文字画像に対して文字認識処理をおこなうことにより、各テキスト領域についての文字コード列のデータを得て、メモリ103に保存する。ここで、文字コード列のデータには、テキスト領域内に含まれる各文字画像に対する認識結果である文字コード情報と、各文字画像の外接矩形の情報(外接矩形の左上座標と幅高さの情報)とが含まれるものとする。
【0028】
文字認識処理の一例を簡単に説明する。なお、文字画像を文字認識する処理は、公知の技術を利用することが可能である。
【0029】
まず、文書画像が二値画像でない場合はテキスト領域内を二値化するなどして、テキスト領域内の二値画像を得る。当該二値化された各テキスト領域内について、縦横のライン毎の黒画素数を計数してヒストグラムを作成する。縦横のヒストグラムに基づいて、周期的なヒストグラムになっている方向を行方向とし、ヒストグラムの黒画素数が所定の閾値以上になる部分を文字行を構成する部分として、短冊状の行画像を得る。次に、各行画像に対して、行方向と垂直な方向でヒストグラムをとり、ヒストグラムの結果に基づいて1文字ずつの画像を切り出す。この切り出された範囲が1文字の外接矩形情報となる。なお、ここでは、黒画素数を計数したヒストグラムを用いて判別を行ったが、各ラインに黒画素があるかないかを示す射影を用いて文字領域の判別を行うようにしてもよい。
【0030】
次に、各文字画像の外接矩形内の画像から、エッジ成分などを取り出して特徴ベクトルを得て、あらかじめ登録された文字認識用辞書内の特徴ベクトルと比較し、類似度を求める。そして、最も類似度の高い字種(文字種)のコードを、当該矩形内の文字画像に対する文字コードとする。このようにして、テキスト領域内に存在する全ての文字の外接矩形に対して、文字コードを割り当てたデータが得られる。そして、各テキスト領域から得た文字コード群が文字コード列となる。
【0031】
また、英文の文字領域に対しては、文字間に単語間スペースが存在するか否かの判定も行うこととする。例えば、文字間の距離が広いかどうかや、文字画像の文字認識結果の文字列と単語辞書とのマッチングを行って単語の切れ目であるかどうかなどを判別することにより、単語間スペースが存在するかどうか判定することができる。単語間スペースが存在すると判定した場合は、当該スペースの文字コードを文字コード列に挿入することになる。
【0032】
図10及び図11は、図8のテキスト領域801に対して文字認識処理を行った例を示す。図10中のテキスト領域1000から文字行1001と1002が先ず切り出される。そして、文字行1001内から1011,1012,1013の3文字が切り出されて、それぞれ認識処理が行われる。その結果、各文字に対応する文字コードが得られて、図11の1101に示したような文字コード列データが生成される。同様に、文字行1002内から切り出された1021,1022,1023の3文字にも文字認識処理が実行され、図11の1102に示したような文字コード列データが生成される。
【0033】
なお、上記説明は一例であって、他の公知の文字認識技術を利用した処理方法を用いて、文字コード列を取得してもよい。
【0034】
ステップS206では、当該処理対象となっているページ画像データと領域データと文字コード列データとを関連付けて、メモリ103もしくはハードディスク104に一時保存する。
【0035】
ステップS207では、未処理の画像データがあるかどうかを判定し、あればステップS203に戻り、次のページ画像データの処理を行う。なければ、ステップS208に進む。
【0036】
ステップS208では、メモリ103あるいはハードディスク104に保存された全ページ分のデータをページ順に合成して、複数ページからなる検索可能な電子文書を生成する。
【0037】
このステップS208で生成される電子文書のデータは、各ページ画像をディスプレイ等に電子的に表示あるいはプリンタにより印刷する為の描画情報と、検索キーワードで検索できるようにするための内容情報の両方を保持可能なデータである。そのような条件を満たすデータフォーマットとしては、PDF、SVGなどがあるが、本実施形態では、このとき生成される電子文書のフォーマットとして、フォントデータを埋め込むことが指定されていたとする。なお、フォントデータを埋め込むことが必須条件になっているフォーマット形式としては、例えば、XPSなどがある。以下では、XML表現を用いたページ記述フォーマットの仕様を仮定しながら説明するが、本発明はこのフォーマットに限るものではない。
【0038】
図6は、2ページ分のページ画像で構成される文書が入力された場合に、本説明で用いるページ記述フォーマットの仕様に基づいて生成された電子文書のページ記述例である。なお、ここでは、ページ記述フォーマットの例として、図6に示したように、1つのファイル内にまとめて記述するものとするが、これに限るものではない。例えば、フォントデータの部分を別ファイルにして、本体のファイルからフォントデータファイルを参照するようにし、それらをZIP圧縮等で1つの電子文書にまとめるようなフォーマット(例えば、XPS)でもよい。
【0039】
以下に、ステップS208にて行われる電子文書データ生成処理の例を、図4のフローチャートを用いて説明する。
【0040】
ステップS401では、電子文書の開始タグの記述を行う。本説明のページデータ記述フォーマット仕様では、<Document>という要素が電子文書の開始タグを表すものとする。なお、その<Document>の終了を示す</Document>までに挟まれた範囲のXML記述が、当該文書に含まれる各ページに関する記述データとなる。図6の例では601が電子文書の開始タグ、612が終了タグを表す。
【0041】
ステップS402では、未記述のページのうち、先頭ページに関するデータを特定して処理対象とする。
【0042】
ステップS403では、処理対象ページデータの開始を表わすタグを生成して記述する。本例では<Page>という要素タグがページデータの開始を表わし、その終了タグとなる</Page>までに挟まれた範囲のXML記述が、当該ページ内の描画データおよび内容データとなる。また、<Page>タグには、当該ページの画素幅と高さを示す属性WidthとHeight、ならびに解像度を示す属性Dpiを用いてページの物理的な大きさが記述され、また、ページ番号を示す属性Numberを用いてページ番号が記述される。
【0043】
図6の記述例では、<Page>要素の開始タグ602に、当該ページの幅Widthが“1680”、高さHeightが“2376”、解像度Dpiが“200”であり、ページ番号Numberが“1”であることが記述されている。また、当該1ページ目のデータは、終了タグ606までの間(603〜606)に記述されている。
【0044】
ステップS404では、ページを構成するデータのうち、画像の描画データを表わすタグを生成して記述する。
【0045】
本説明のページデータ記述フォーマット仕様では、1つの<Image>要素が1つの画像の描画データを表わすものとする。また、画像データの内容を属性Data内に記述し、その画像がページ内に描画される位置を属性X,Y,Width,Heightの座標情報で記述するものとする。ページ内に画像が複数ある場合は、各画像データを登場順に上へ重ね書きしていくことを意味する。なお、属性Data内には圧縮された画像データ形式で記述されるものとし、ここでは、圧縮方式として、カラー・グレーの場合はJPEG圧縮、二値の場合はMMR圧縮したコード列を用いるものとする。
【0046】
図6の記述例603では、文書の1ページ目のスキャン画像が全面にわたって描画されるようにしている。図6のタグ603では、画像の位置とサイズを「X=“0”、Y=“0”、Width=“1680”、Height=“2376”」として記述している。また、画像をJPEG圧縮して生成されたコード列の文字列を、属性Dataの値として記述している(なお、図6では、図を単純に示すため、Data属性の文字列を一部省略して示している)。このようにして、<Image>要素603が記述されている。なお、スキャン画像をJPEG圧縮して保存する前に、必要に応じて、解像度を変更して保存するようにしてもよい(例えば600dpiでスキャンした画像を300dpiに変更して保存してもよい)。
【0047】
ステップS405では、ページを構成するデータのうち、文字の描画データを表わす記述を生成する。
【0048】
本説明のページ記述フォーマット仕様では、1つの<Text>要素が1行分の文字の描画データを表わしている。また、<Text>要素内に記述される属性データは、Direction、X,Y、Font、Size、Color、String、CWidth、CGlyphIdなどがある。ここで、属性Directionは、文字列が縦書きか横書きかを示す。また、属性X,Yは、文字の開始位置の座標を指定する。属性Fontは、文字コードを描画するためのフォントデータのIDを指定する。属性Sizeは、フォントサイズを指定する。また、属性Colorは、描画時の文字色を、R成分値,G成分値,B成分値、透過度を表すアルファチャネル値の4値組で指定する。また、属性Stringは、文字列の内容(文字コード列)を指定する。属性CWidthは、String内の各文字より次の文字までの送り幅を指定する。また、属性CGlyphIdは、String内の各文字が描画の際に使用する字形データすなわちグリフのIDを指定する。なお、Directionが指定されていない場合は、デフォルトで横書きとする。
【0049】
<Text>要素を構成する文字コード列は、図2のステップS205で生成された文字コード列のデータを、文字行毎、すなわち縦または横に連なる文字の集合に更に分割したものが使用される。
【0050】
図6の記述例では、2つの<Text>604および605は、1ページ目の文字描画記述に関するものであり、図11の文字コード列データ1101および1102それぞれに対応する記述である。例えば、図11の1101の3文字の横書き文字列「あいう」に対応する<Text>要素604では、下記のような属性が指定されている。
【0051】
属性X,Yには、3文字分の外接矩形の左上座標としてX=“236”、Y=“272”が指定されている。属性Directionには、横書きを示す“Horizontal”が指定されている。
【0052】
フォントの種類を示す属性Fontには、“Font01”が指定されている。また、フォントサイズを示す属性Sizeには、当該文字行内の文字の高さから類推して“97”ピクセルが指定されている。描画時の文字色を示す属性Colorには、R成分値=G成分値=B成分値=0とアルファチャネル=255とが指定されている(つまり、透明色が指定されている)。
【0053】
また、文字列の内容(各文字に対応する文字コードの列)を示す属性Stringには、“0x2422,0x2424,0x2426”とが指定されている。また、各文字の送り幅を示す属性CWidthには、最初の2文字については右隣文字との左端の座標差、最後の1文字については自分の文字幅に相当する値“104,96,59”とが指定されている。
【0054】
属性CGlyphIdには、通常、各文字の字形データに合わせたグリフのIDが指定される。しかしながら、本実施形態では、スキャン画像上に透明色の文字の字形を描画するようにしているので、字形がいかなるものであっても、ユーザの視覚には見えていない。そこで、本実施形態では、異なる文字であっても、同一のグリフIDを指定することにより字形データ(フォントデータ)が少なくて済むようにしている。したがって、図6の例では、属性CGlyphIdには、“0,0,0”の同じ属性値が記述されている。また、このグリフIDで指定される字形は、簡単な形状(例えば矩形)でよい。なお、グリフの形状の詳細については、後述する。
【0055】
なお、上記の属性値は一例であって、同様な意味を持つ別の値で記述してもよい。例えば、フォントサイズの属性サイズは、ピクセル高さと画像解像度に基づき、画素数ではなくポイント数等の値で記述されてもよい。
【0056】
また、上記例では、文字行の外接矩形の左上座標位置を基準として指定し、且つフォントサイズは文字行の高さに合うように指定することで、描画される文字列がスキャン画像上の文字画像の位置にほぼ重なるようにしているが、これに限るものではない。特に、本実施形態で描画される文字は透明色が指定され、ユーザには見えていないので、描画される文字列が、対応する文字画像の真上に重ならなくても構わない。例えば、対応する文字画像の下端部に、透明な文字列が描画されるようにしてもよい。例えば、図6の604の例であれば、X=“236”、Y=“368”、Size=“10”とすれば、文字画像の下端に高さの低い透明な文字列が描画されることになる。このとき、この描画される透明文字列のサイズ(高さ)は、文字画像よりも小さい所定のサイズ(例えば10)としている。
【0057】
描画される透明文字列は、後に、検索キーワードで検索を行う際に用いられ、検索キーワードに一致する文字列は強調表示(例えば、色が変えられて表示)される。透明文字列は、対応する文字画像の位置にほぼ対応する位置に描画されているので、検索時には透明文字列を使って検索しているのであるが、ユーザにとっては、あたかも文字画像が検索されているかのように見えることになる。したがって、このような検索時の文字の強調の用途に用いるのであれば、透明文字列を対応する文字画像の下端部に描画したとしても、検索時には、対応する文字画像にアンダーラインが引かれたかのように強調表示されて特定できるので問題ない。なお、透明文字列の描画位置は、下端に限るものではなく、文字画像の下半分や上半分というような位置に描画されるよう記述しても構わない。
【0058】
ステップS406では、当該ページの終了を示す</Page>を記述する。
【0059】
ステップS407では、未記述のページが他に有るか否かを判定し、未記述のページがある場合は、次のページを処理対象のページ画像としてステップS403に戻る。一方、未記述のページがない場合は、ステップS408に進む。
【0060】
図6の記述例では、2ページ目の画像に対してもステップS404〜S406の処理が行われ、607〜610の部分が記述されることになる。
【0061】
ステップS408では、この電子文書で文字列の描画に使用される全グリフを含むフォントデータの内容を記述する。
【0062】
本説明のページデータ記述フォーマット仕様では、<Font>と</Font>に挟まれる範囲に、フォントデータに含まれるグリフデータが<Glyph>要素として記述される。<Font>要素には、当該フォントの種類を示す属性IDが含まれる。また、<Glyph>要素には、グリフの種類を示す属性IDと、そのIDに対応するグリフ(字形)を示す属性Pathとが含まれる。ここで、属性Pathは、左下を原点とする1024×1024描画矩形単位内で、直線や曲線関数を用いてグリフを表現するように記述される。
【0063】
図6の記述例では、<Font>要素611において、Id=“Font01”のフォントが定義され、その中に、グリフId=“0”のグリフが一種類定義されている。このグリフの字形を表わすPath属性“M0,0 V−1024 H1024 V1024 f”は、「原点(0,0)にMOVE,上方向に1024単位縦線を描画、右方向に1024単位横線描画、下方向に1024単位縦線描画、現在の点から開始点まで線を描画して囲まれた範囲を塗りつぶす」というグリフを記述している。すなわち、1024×1024の矩形を塗りつぶした正方形のグリフを表現する記述となっている。
【0064】
なお、図6の<Font>要素611の記述は一例であって、三角や丸、直線などの他の単純な字形を定義してもよいし、空白(スペース形状)を字形として定義してもよい。
【0065】
ステップS409では、電子文書の終了を示す</Document>を記述し、電子文書の生成を終了する。生成された電子文書はファイルとして画像処理装置100内のメモリ103あるいはハードディスク104に保存される。保存の際には公知のテキスト圧縮技術を用いて圧縮を施してもよい。
【0066】
図2に戻ってステップS209では、ステップS208で生成された電子文書を、ステップS201で指定された送信先(例えば画像処理装置110)へ、指定された送信方法で送信する。データ転送処理自体は公知技術を用いるものとして説明は省略する。
【0067】
送信先の装置110では、ネットワークインタフェース114を介して転送されてきた電子文書を受信し、ハードディスク113に蓄積する。データ受信処理は公知技術を用いるものとして説明は省略する。
【0068】
なお、装置内で蓄積される電子文書をハードディスク内部で特定するための識別情報(ファイル名など)は任意のものでよい。例えば、受信時刻に関連する文字列を付与すればよい。その他にも、重複しない番号を選択して自動付与したり、電子文書生成時にユーザが指定するようにしても構わない。
【0069】
次に、電子文書を検索・閲覧する処理の例を図3のフローチャートに従って説明する。ここでは、画像処理装置110で検索を行う例について述べるが、これに限るものではなく、画像処理装置100で検索を行えるようにしても構わない。
【0070】
ステップS301では、画像処理装置110内に蓄積された電子文書群から所望の電子文書の文字列を検索するために、ユーザは当該電子文書のテキストに含まれていると考えた検索キーワードをUI115より入力する。ここで入力された文字列の長さをkとする。
【0071】
ステップS302では、画像処理装置110のハードディスク114内にある全ての電子文書ファイルに対し、未検索の電子文書ファイルがあるか否か判断する。未検索の電子文書ファイルがあれば、その中の1つの電子文書ファイルを特定し、その電子文書ファイルが圧縮されている場合は展開して、ステップS303に進む。未検索の電子文書がなければS312に進み、全ての電子文書に対する検索が終了したことをユーザに報知する。
【0072】
ステップS303では、S302で特定された電子文書内のテキストデータを対象にして検索を行うための準備を行う。ここでは、文書内のテキスト(文字コード)を1列に並べ、探索開始位置nを初期化、すなわちn=0に設定する。
【0073】
ステップS303の処理例を以下に説明する。まず、電子文書データをXMLパーサでパースしていき、<Text>要素が表われたら属性Stringに記述されている文字コード列を取得する。そのString属性中に記載された文字コード列に基づいて、1文字ずつ、当該文字コードとその文字コード値が該電子文書データ中で記述されている位置との組を、文字コード配列テーブルに追加していく。ここで、文字コード値が記述されている位置とは、電子文書データ中で該文字コードが記述されているキャラクタ列の先頭が、該電子文書データの先頭から数えて何キャラクタ目であるかを示す値である。図6の電子文書から生成した文字コード配列テーブルの例を図12に示す。例えば、図6の電子文書内の<Text>要素604の属性Stringに記述された3つの文字コード“0x2422”、“0x2424”、“0x2426”は、それぞれこの電子文書の先頭から数えて1093キャラクタ目、1100キャラクタ目、1107キャラクタ目の位置より記述されているものとする。同様に、605及び609に基づいて、残り6つの文字コードに対しても記述位置を求めて、図12のような文字コード配列テーブルを生成する。なお、図12では、このとき、文字列番号(No.)を0から順に付与している。
【0074】
ステップS304では、文字コード配列テーブルに対して、探索開始位置nを起点として、検索キーワードの文字コード列と一致するか否か判断する。一致する部分を検出した場合、そのときの変数nを一致文字列の先頭位置としてステップS305に進む。
【0075】
一方、ステップS304で一致しないと判断した場合は、ステップS309に進み、当該文字コード配列テーブルの全ての文字を探索したか判断する。文字コード配列テーブルに格納されている文字コード列全ての探索が終了したと判断した場合はステップS311に進み、現在探索対象となっている電子文書の検索が終了したことを報知する。一方、全ての探索が終了していないと判断した場合は、ステップS310に進んで、変数nを1インクリメントして、ステップS304に戻り、次の探索開始位置nで検索キーワードと一致するか判断する。なお、ステップS309では、文字コード配列テーブルに格納されている文字コードの総数をNとした場合、n<(N−k)ならば全ての探索が終了していないと判断し、n>=(N−k)ならば探索終了と判断すればよい。
【0076】
例えば、図12の文字コード配列テーブルの例に対し、検索キーワード「かき」の文字コード列“0x242b”,“0x242d”を先頭から走査して一致する部分を探した場合、S304、S309、S310の処理が繰り返されて、最初の一致文字列の文字列番号としてn=3が抽出される。
【0077】
ステップS305では、文字列番号nに相当する文字列データが、電子文書のどのページに属しているかを特定する。
【0078】
例えば、電子文書データをパースする際に、<Text>要素がどの<Page>要素に記述されているかを判別すれば、Number属性によってページ番号が識別できる。したがって、ステップS305で特定した位置nに対応する文字列の記述位置を図12から求め、当該記述位置がどの<Page>要素の間にあるかによって、当該文字列が属するページが特定できる。なお、ステップS303で電子文書データをパースする際に、各<Text>要素がどの<Page>要素に記述されているかを判別して、図12の文字コード配列テーブルに予め格納しておけば、文字列番号に基づいてページ番号が容易に特定できる。なお、ステップS304の一致文字列の検出方法や、ステップS305のページ番号の特定方法は、上述した例に限るものではない。
【0079】
ステップS306では、ステップS305で決定されたページの描画記述に従って、当該ページの描画をおこなってUI115に表示する。このとき、文字列番号(No.)がn〜n+k−1の範囲にある文字を描画する際には、その文字に対応する個所をユーザが識別しやすいように、該文字に強調効果を付けて描画する。この検索キーワードに一致する部分に強調効果を付けた描画の詳細については下記で説明する。
【0080】
ステップS306で実施されるページの描画処理を、図5のフローチャートに従って説明する。
【0081】
ステップS501では、特定されたページ番号に対応する<Page>要素のWidth,Height属性の値から、描画結果となるページ画像のサイズを決定する。
【0082】
ステップS502では、ページ画像の画素情報が格納できる分のメモリを確保する。
【0083】
ステップS503では、当該<Page>要素の子要素の中で未処理の要素を1つ抽出し、当該未処理要素の種類を判別する。当該未処理要素が<Image>であると判別した場合は、ステップS504に進み、当該未処理要素が<Text>であると判別した場合は、ステップS505に進む。当該<Page>要素の全ての子要素が既に処理されていたら、ステップS517へ進む。
【0084】
ステップS504では、まず、<Image>要素のData属性値として記述されている圧縮画像を展開する。更に、X,Y,Width,Heightの各属性により表されるページ画像内の描画矩形領域いっぱいに収まるように、当該展開されたイメージを変倍して、ステップS502で確保したページ画像メモリの該当領域へと上書きする。その後、ステップS503に戻る。
【0085】
ステップS505では、処理対象の<Text>要素に記述された各属性から、文字開始位置(X,Y)、文字フォントID(F)、文字サイズ(S)、文字色(C)を取得する。また、当該<Text>要素に記述された文字の数(N)も取得する。
【0086】
ステップS506では、グリフ画像生成のためのメモリを確保する。ここでは1024×1024画素分の二値画像用メモリを確保するものとする。
【0087】
ステップS507では、処理中の文字を示すカウンタiを1に初期化する。
【0088】
ステップS508では、i>Nであるか否かの判断を行い、i≦Nの場合はステップS509に進み、i>Nの場合は当該<Text>要素の処理は終了したと判断してステップS503に戻る。
【0089】
ステップS509では、<Text>要素の属性Stringからi文字目の文字コード(P)と、属性CGlyphIdからi文字目のGlyphId(Q)とを取得する。
【0090】
ステップS510では、電子文書から、フォントIdが(F)である<Font>要素記述を探し出し、更に、その<Font>要素記述の子要素の中で、グリフIdが(Q)である<Glyph>要素からPath属性を取得する。
【0091】
ステップS511では、ステップS510で取得したPath属性値にしたがって、ステップS506で確保したグリフ画像生成用メモリにおいてグリフの二値画像を生成する。なお、グリフの二値画像とは、例えば、描画が行われる部分を1、描画が行われない部分を0として表した画像である。なお、本実施例では、描画が行われる部分1は、後に、透明色で描画されることになる。
【0092】
ステップS512では、グリフの二値画像を、文字サイズ属性の値(S)に則した大きさの矩形サイズになるよう変倍する。
【0093】
ステップS513では、ページ画像メモリ中の座標位置(X,Y)を基準とした矩形領域に、ステップS512で変倍されたグリフの二値画像を描画する。ページ画像上に二値画像を重ねて描画したときの各画素の画素値を以下の式で定義する。なお、グリフを描画する前のページ画像の各画素値(r,g,b)に対して、グリフを描画した後の画素値は(r’,g’,b’)になるものとする。
グリフ二値画像の画素値が0に対応する画素:(r’,g’,b’)=(r,g,b)
グリフ二値画像の画素値が1に対応する画素:(r’,g’,b’)=(F(r,Cr),F(g,Cg),F(b,Cb))
【0094】
ここで、F(r,Cr)=(r×A+Cr×(255−A))/255、F(g,Cg)=(g×A+Cg×(255−A))/255、F(b,Cb)=(b×A+Cb×(255−A))/255とする。また、Aは文字色Cに対するアルファチャネル値、Cr,Cg,Cbは文字色Cの各RGB値とする。なお、アルファチャネル値として255が指定されている場合は、当該グリフ二値画像は透明であるので、グリフ二値画像の画素値が1に対応する画素についても、(r’,g’,b’)=(r,g,b)となる。
【0095】
ステップS514では、処理中のi文字目の文字が、文字列番号(No.)がn〜n+k−1の範囲にある文字であるか否かを、例えば、図12の文字コード配列テーブルを用いて判定する。具体的には、範囲n〜n+k−1内の各文字の記述開始位置が文字コード配列テーブルから分かるので、処理中の文字iの開始位置がそのいずれかに一致しているか否かに基づいて判定する。範囲n〜n+k−1内の文字である場合はステップS515、それ以外の場合はステップS516に進む。
【0096】
ステップS515では、処理中の文字が検索文字列として検出された範囲内にあることを示すための強調処理を行う。具体的には、当該文字列を描画した範囲に相当する、ページ画像メモリの位置(X,Y)から始まる矩形領域内の各画素に対して、各画素値(r,g,b)を以下の画素値(r’,g’,b’)へと変更する。
(r’,g’,b’)=(G(r),G(g),G(b))
(ここで、G(r)=255−r,G(g)=255−g,G(b)=255−bであるとする。)
なお、色の反転を行う上記強調処理は一例であり、その他の強調処理でもよい。例えば、グリフ二値画像の画素値が0の画素に対応する画素はそのまま変更せず、グリフ二値画像の画素値が1の画素に対応する画素については、各画素値(r,g,b)を上記(r’,g’,b’)にそれぞれ変更するようにしてもよい。あるいは、強調する矩形領域の幅をグリフ二値画像の幅ではなく、各文字の送り幅を指定する属性CWidthの値を用いることにより、連続する検索文字列が間隔無しに塗りつぶされるようにしてもよい。各文字の送り幅を用いて強調処理をおこなった場合、図16のように文字間も塗りつぶされるようになる。
【0097】
ステップS516では、このi文字目の文字の送り幅(CWidth属性の値)をXに加算するとともに、iを1インクリメント(i=i+1)して、ステップS508に戻る。
【0098】
ステップS517では、1ページ分の描画結果、すなわち<Page>要素内の<Image>および<Text>要素記述を描画したページ画像メモリの内容を、UI115の表示バッファに転送して表示させる。
【0099】
以下では、図6の電子文書の1ページ目の描画記述を例として、図5のフローチャートの処理を実行した場合を説明する。
【0100】
ステップS501の処理により、図6の1ページ目の<Page>要素602の属性値Width=“1680”、Height=“2376”に基づいて、ページの画像サイズを1680×2376ピクセルと決定する。
【0101】
ステップS502の処理により、例えば、ページ画像がRGB24bitカラーで表現される場合、1680×2376×3バイトのメモリが確保される。
【0102】
ステップS504の処理により、図6の<Image>要素603のData属性値に記述された圧縮のコードが展開されて画像になり、ページ画像メモリの全域に上書きされる。なお、本例では画像データは元のページと同サイズの1680×2376のピクセルの大きさを持っているので変倍処理は施されない。
【0103】
次に、ステップS505の処理により、図6の<Text>要素604から、X=“236”,Y=“272”,文字数N=“3”,文字フォントID=“Font01”,文字サイズ=“97”,文字色=“0,0,0,255”が得られる。
【0104】
ステップS509の処理により、まず最初は、<Text>要素604のString属性の1番目の文字コード=0x2422およびGlyphId=“0”が得られる。
【0105】
ステップS511でグリフの二値画像を生成するにあたって、まず、得られた文字フォントID=“Font01”に基づき、当該IDを有するグリフのPathデータをステップS510で取得する。ここでは、図6の例では、<Font>要素611内にある、<Glyph>要素のId=“0”のPath属性を取得する。そして、ステップS511において、当該取得した<Glyph>要素のId=“0”のPath属性のデータに基づいてグリフ画像を生成する。具体的には、Path属性の記述に従って、1024×1024ピクセルのGlyph画像領域すべてを1で塗りつぶした画像となる。
【0106】
なお、図6の電子文書に記載された<Text>要素604および605内の文字のGlyphIdはすべて“0”であるため、結果的にすべての文字に対してステップS511で得られるグリフ画像は等しくなる。したがって、ステップS511で生成したグリフ画像はメモリに一時保存しておき、他の文字を描画する際、その一時保存されているグリフ画像を流用するようにしてもよい。
【0107】
ステップS512では、文字サイズ=“97”に基づいて、グリフの文字画像が97×97ピクセルに変倍される。
【0108】
ステップS513では、ページ画像上の位置(X,Y)=(236,272)から始まる97×97ピクセルの矩形範囲は変倍されたグリフの文字画像による描画対象領域となる。図6の例では文字色=“0,0,0,255”すなわちアルファチャネル値A=255であるため、グリフの二値画像中の対応する画素値が1であっても常に(r’,g’,b’)=(r,g,b)となる。つまり、ステップS513の処理前後でページ画像内の当該矩形領域内の画素値は変化しない。
【0109】
ステップS514では、図6の<Text>要素604内の1番目の文字が、文字列番号の範囲n〜n+k−1内に相当する文字か否かを文字コード配列テーブルに基づいて判定する。
【0110】
ここでは、たとえば図6の電子文書から図12の文字コード配列テーブルが生成されており、図3のステップS304でキーワードと一致すると判断された文字列の範囲が3〜4であったとする。このとき、図6の<Text>要素604内の1番目の文字コードは、範囲3〜4でないので、ステップS516に進む。<Text>要素604内の1番目の文字コード記述の先頭キャラクタ位置は1093であり、文字コード配列テーブルの文字列番号3〜4の範囲の文字の記述位置のいずれとも一致しないことから、<Text>要素604の1番目の文字は範囲3〜4内に相当する文字でないと判定できる。
【0111】
その後、図6の<Text>要素605内の1番目が示す文字の処理を行う際には、ステップS514において、文字コード配列テーブルの範囲3〜4の文字の開始位置と一致すると判断し、ステップS515での強調描画処理が実行される。
【0112】
この文字に対し、ステップS515では、ページ画像メモリの位置(236,472)から始まる92×92の領域内の各画素値(r,g,b)を、(G(r),G(g),G(b))へと変更させる。
【0113】
以上のようにして全<Text>を描画した後、ページ画像は図13のようになる。ステップS304で一致すると判定された範囲の文字に対応する領域に関しては、各矩形内で輝度が反転された状態となり、残りの文字に対応する領域は、<Image>要素が描画した画像データのままとなる。
【0114】
このように、検索した文字列が強調表示されるので、ページ内のどこに検索キーワードが存在するかを、ユーザはステップS306で表示されたページの画像を見るだけで容易に判断することができる。
【0115】
図14は、別の方法で強調表示をおこなうように設定した場合、どのようにページ画像表示がなされるかの例を示している。図14(a)のページ描画記述では、図4のステップS405で<Text>要素の属性データを記述する際、対応する文字画像の下部(下端)に相当する位置に、当該文字画像より小さいサイズ(例えば、Size=“10”)の透明文字が描画されるように記述している。このようなページ描画記述に対し、ステップS515での強調処理において、各文字の送り幅×文字サイズの矩形範囲が反転強調されるようにすれば、図14(b)のように強調表示されたページ画像が生成される。このように、ユーザにとっては、検索した部分が下線を引かれて強調されているかのように見えることになり、ユーザは検索した文字列がページ内のどこに存在するかを容易に判断することができる。
【0116】
図3に戻って、ステップS307では、検索・閲覧処理を終了するか、あるいは更に別の検索箇所を対象に検索を継続するかどうかをユーザに選択させる。ユーザが終了を選択した場合は、図3の処理を終了し、継続を選択した場合はステップS308に進む。
【0117】
ステップS308では、n=n+kとし、ステップS304に戻って、次に検索キーワードと一致する部分を検索する。
【0118】
以上説明したように、本発明の実施形態1によれば、紙の文書が電子文書へと変換される際に、ページ画像上にページから抽出した文字が透明色で描画されるように記述される。この電子文書に対しては、検索キーワードに一致する箇所が強調表示されたページ表示を確認しながら検索を進めていくことが可能である。
【0119】
この電子文書は、ひとつの単純な字形(例えば矩形)からなるフォントデータを内部で持ち、文書内の様々な字種の透明文字を描画する際に、当該ひとつの単純な字形を用いて描画するように記述している。つまり、複数の字種に対して1つの字形を共通して利用するようにしている。したがって、電子文書内で使用されるフォントデータを当該電子文書内に保存しなければならないような場合であっても、電子文書のファイルサイズ(データ容量)を小さく抑えることができる。
【0120】
<実施形態2>
図15は、実施形態2により生成された電子文書の例である。実施形態1と同様に、画像処理装置100が生成・送信し、画像処理装置110が受信・閲覧・検索するものとする。
【0121】
図15の1501および1512は電子文書の開始、終了を表す記述である。1502および1506は、1ページ目の描画の開始、終了を表わす記述である。1503は1ページ目の画像データ描画の記述である。1504および1505は1ページ目の文字描画の記述である。また、1507および1510は2ページ目の描画の開始、終了を表わす記述である。1508は2ページ目の画像データ描画の記述である。1509は2ページ目の文字描画の記述である。1511はこの電子文書で用いられるフォントデータの記述である。
【0122】
実施形態2の電子文書生成処理の説明は、図2および図4を用いた実施形態1の説明、電子文書検索・閲覧処理の説明は、図3および図5を用いた実施形態1の説明とほぼ同等となるので、実施形態1と異なる部分について説明する。
【0123】
図15の文字描画を表わす<Text>要素1504、1505および1509では、各文字のグリフIDを指定する属性CGlyphIDを記述せず、属性CStringに書かれた文字コードそのものをフォントデータ1511のグリフIDの代わりに使用する。
【0124】
また、フォントデータ1511内に定義された6つの字種のグリフのPathデータには同一の字形を定義している。このように記述されたフォントデータは、LZ77などの公知の圧縮技術を用いて高い圧縮率で圧縮することが可能である。
【0125】
本発明の実施形態2によれば、紙の文書が電子文書へと変換される際に、ページ画像上にページから抽出した文字が透明色で描画されるように記述される。この電子文書に対しては、検索キーワードに一致する箇所が強調表示されたページ表示を確認しながら検索を進めていくことが可能である。
【0126】
この電子文書は、文書内で記述した各文字に対して、同種類の字形データで構成されるフォントデータを保存するようにしている。同種類の字形データで構成されるフォントデータは、一般的なテキスト圧縮技術により高い圧縮率で圧縮することができるので、本実施形態2においても、電子文書内で使用されるフォントデータを保持しながら、電子文書のデータ量を小さく抑えることが可能である。また、実施形態2においても、グリフの字形は、単純化されて保存されているので、字形データ自体のデータ量も抑えることができる。
【0127】
<実施形態3>
また、上述した実施形態では、スキャン画像に対してJPEG圧縮等を行った全面イメージを<Image>要素に記述し、透明テキストを<Text>要素に記述した電子文書を生成することとしたが、これに限るものではない。
【0128】
例えば、<Image>要素に、スキャン画像全体をJPEG圧縮したものを記述する代わりに、文字領域や図領域は色別に2値画像を作成してMMR圧縮したもの、それ以外の領域はJPEG圧縮したものを格納するようにしてもよい。このように、文書画像に含まれる領域を解析して適応的に圧縮処理を行う方法は、例えば、特開平07−236062号公報や特開2002−077633号公報などに記載の方法を用いることができる。本発明の透明テキストを描画する際に用いるフォントデータのデータ量を抑える処理と、これらの画像圧縮処理とを組み合わせることで、更に高圧縮された電子文書を生成することが可能になる。
【0129】
また、全面イメージの代わりに、文字領域、図領域、表領域、写真領域などの部分領域だけを位置データとともに保存するようにしても構わない。
【0130】
<実施形態4>
上述した実施形態では、検索した結果に対応する個所を強調表示する際、画像の色(r,g,b)を反転することにより強調表示したが、使用する色はこれに限るものではない。例えば、検索結果を特定させるための予め決めた色(例えば黄色)を、半透明(例えばアルファチャネル128)で描画させるようにしてもよい。また、文字色(Cr,Cg,Cb)を利用して、強調色を決めるようにしてもよい。
【0131】
<実施形態5>
また、上述した実施形態では、図3及び図5で説明したように、検索を行う際は、キーワードに一致する文字列を文書の先頭から順に検索していき、最初に検索された文字列を強調表示した。そして、「次を検索」の指示があれば、順次、次に一致する文字列を検索して強調表示するように構成した。このように、上述した実施形態では、検索キーワードに一致する文字列を先頭から順に検索をおこない、検索キーワードがヒットするごとに順次強調表示を行っていたが、これに限るものではない。例えば、電子文書内に含まれる全ての文字列について、検索キーワードと比較を行い、全ての一致する文字列を特定し、そのキーワードに一致した全ての文字列を同時に強調表示するような構成にしてもよい。
【0132】
<その他の実施形態>
なお、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコード(コンピュータプログラム)を記憶した、コンピュータ読取可能な記憶媒体を、システムあるいは装置に供給することによっても達成される。また、システムあるいは装置のコンピュータ(またはCPUやMPU)が記憶媒体に格納されたプログラムコードを読出し実行することによっても達成される。
【0133】
本発明のコンピュータプログラムは、上述したフローチャートに記載した各ステップを装置に実行させることになる。言い換えると、このコンピュータプログラムは、フローチャートの各ステップに対応する各処理部(各処理手段)として、コンピュータを機能させるためのプログラムである。この場合、コンピュータ可読記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【0134】
プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、CD−ROM、CD−R、不揮発性のメモリカード、ROMなどを用いることができる。
【0135】
また、プログラムコードの指示に基づき、コンピュータ上で稼働しているOS(オペレーティングシステム)などが実際の処理の一部または全部を行い、その処理によって前述した実施形態が実現される場合も本発明に含まれることは言うまでもない。
【0136】
また、一方、上述した実施形態1,2では、CPUがメモリやハードディスク、表示デバイス等と協働して各フローチャートの各ステップを実行する形態について説明した。本発明は、上述した構成に限るものではなく、各フローチャートで説明した各ステップの処理の一部または全部を、CPUの代わりに専用の電子回路で構成するようにしても構わない。
【技術分野】
【0001】
本発明は、紙文書のスキャン画像を電子的に検索可能なデータへ変換する技術に関する。
【背景技術】
【0002】
近年、スキャナおよびハードディスク等大容量記憶装置の普及により、これまで紙で保存されていた文書をスキャンし、電子文書として保存されるようになっている。その際、紙文書をスキャンして得た画像データに対して文字認識処理を実行することにより、文書に記載されている文字情報を読みとり、画像にその文字情報を関連付けて保存しておくことも行われている。ユーザは、このようにして文字情報が関連付けられた電子文書を、検索キーワードを用いて検索できる。このように、大量の保存文書群の中から所望の文書を高速に検索するためには、スキャン画像に対してもキーワード検索できるようにすることが重要である。
【0003】
例えば、特許文献1では、このような文字情報が関連づけられた電子文書に対して、ユーザが検索キーワードを用いて検索した際、その文書画像上で当該検索キーワードが記載されている部分をユーザが識別できるように強調表示することが記載されている。このように、検索キーワードに対応する文字部分が強調された状態で表示されるので、文書内に同じキーワードの記載箇所が複数ある場合でも、ページ画像を切り替えていくことにより、ユーザは効率よく記載部分を識別することができる。
【0004】
また一方、文字認識処理した結果を透明テキスト(描画色として透明色が指定された文字コード)として画像ファイル中に埋め込み、PDF(Portable Document Format)形式で保存する技術もある。このように作成されたPDFファイルを表示させると、文書画像内の文字画像上に透明なテキストが描画されることになる。したがって、キーワード検索を行うと、透明テキストが検索されるが、ユーザにとって透明テキスト自体は見えていないので、あたかも画像が検索されているかのように見えることになる。このようにすれば、画像と文字の描画が可能なページ記述言語で記述されたフォーマットのファイルにもとづき、検索キーワードで検索可能な画像を描画することができる。
【先行技術文献】
【特許文献】
【0005】
【特許文献1】特開2000−322417
【発明の概要】
【発明が解決しようとする課題】
【0006】
PDFやSVGなどのページ記述言語を用いた電子文書における文字の描画には、各文字の字形情報、すなわちフォントデータが必要である。しかしながら、フォントデータは一般にサイズが大きいため、電子文書のサイズを小さくするためには、電子文書内にフォントデータを格納せずに、電子文書内には、フォントの種類の指定をおこなっておくことが一般に行われている。このようにすれば、アプリケーションで描画する際に、パソコンにインストールされているフォントを利用して描画することができる。
【0007】
一方、電子文書内にフォントデータを格納しておくことが望まれる場合もある。例えば、文書作成アプリケーションで作成した電子文書を他のパソコンで開く場合、当該電子文書で使用されているフォントデータがそのパソコンにインストールされていなければ、その電子文書を正確に開くことはできない。言い換えると、指定のフォントデータをインストールしていないパソコンやアプリケーションで電子文書を再生する場合であっても、フォントデータ自体が電子文書内に格納されていれば、該電子文書を正確に再生することができる。
【0008】
また、用途によっては、文字の描画に使用するフォントデータを電子文書内に格納しておくのを必須条件にした方がいい場合もある。例えば、長期保存対象のファイルなどは、長期間経過後、OSが変更されるなどして、デフォルトでインストールされているフォントが変更になることも考えられるので、フォントデータを格納する形式を必須にしておくのがよいと考えられる。
【0009】
また、フォーマットの形式によっては、フォントデータを電子文書内に格納しておくことが必須条件になっているフォーマットも存在する。例えば、XPS(XML Paper Specification)のフォーマットでは、テキストデータを保存する場合、フォントデータも一緒に格納しておく必要がある。
【0010】
しかしながら、電子文書内にフォントデータを格納すると、電子文書のサイズ自体が増加してしまう。ファイルサイズが増加すると、電子文書をネットワークで送信する際の時間が多くかかってしまったり、保存する場合の記憶容量が多く必要になったりしてしまうという問題がある。
【0011】
このように電子文書内に格納されているフォントデータを用いて描画するファイル形式の電子文書において、ファイルサイズの増加を防ぐことが望まれることになる。特に、スキャン画像と、文字認識処理した結果のテキストデータと、テキスト描画用のフォントデータとを一緒に電子文書内に格納する場合に、ファイルサイズの増加を防ぐことが望まれる。フォーマットの制約やシステム上の制約などにより電子文書内にフォントデータを格納しなければならないようなとき、ファイルサイズの増加は問題になりやすい。
【課題を解決するための手段】
【0012】
上記課題を解決するために、本発明の画像処理装置は、紙文書をスキャンして文書画像を生成するスキャナと、前記スキャナで生成した文書画像内の複数の文字画像に対して文字認識処理を行うことにより、それぞれの文字画像に対応する文字コードを得る文字認識手段と、前記文書画像と、前記文字認識手段で得た複数の文字コードと、前記複数の文字コードに対応する文字を描画する際に当該複数の文字コードで共通利用させるための字形データとを格納した電子文書を生成する生成手段と、前記生成手段で生成した電子文書を、指定された送信先へ送信する送信手段と、を有する。
【発明の効果】
【0013】
本発明によれば、紙文書をスキャンすることにより生成した文書画像内の複数の文字画像を文字認識する。そして、当該文書画像と、該文字認識結果の複数の文字コードと、前記複数の文字コードに対応する文字を描画する際に当該複数の文字コードで共通利用させるための字形データとを格納した電子文書を生成し、指定された送信先へ送信する。これにより、送信先で検索を行う際に、文書画像上で検索キーワードに対応する部分を特定することが可能な電子文書となる。更に、字形データを複数の文字コードで共通利用するので、電子文書内にフォントデータを保存しなければならない場合であっても、ファイルサイズの増加が小さくてすむ。また、単純な字形で描画することによってフォントデータ自体のデータ容量も少なくて済む。
【図面の簡単な説明】
【0014】
【図1】実施形態1の構成例を表すブロック図
【図2】実施形態1の電子文書生成処理の例を表すフローチャート
【図3】実施形態1の電子文書検索・閲覧処理の例を表すフローチャート
【図4】図2のステップS208でおこなわれる電子文書データ生成処理の詳細を表すフローチャート
【図5】図3のステップS306でおこなわれるページの描画処理の詳細を表すフローチャート
【図6】実施形態1により生成される電子文書の例
【図7】処理対象のページ画像の例
【図8】領域分割処理結果の例
【図9】生成される領域データの例
【図10】文字認識処理時に文字画像を抽出する際の処理を示す例
【図11】文字認識結果で生成される文字コード列データの例
【図12】文字コード配列テーブルの例
【図13】検索結果が強調表示されたページ表示の例
【図14】別の強調表示処理で検索結果が強調表示されたページ表示の例
【図15】実施形態2により生成される電子文書の例
【図16】検索結果が強調表示されたページ表示の例
【発明を実施するための形態】
【0015】
<実施形態1>
図1は画像処理装置の構成を示すブロック図の一例である。
【0016】
画像処理装置100は本実施形態を実現するための装置であり、文書画像データを検索可能な電子文書に変換する。画像処理装置100は、スキャナ101、中央処理ユニット(CPU)102、メモリ103、ハードディスク104、ネットワークインタフェース105、ユーザインタフェース(UI)106で構成される。スキャナ101は紙文書の紙面情報を読み取り、文書画像データに変換を行う。CPU102は、画像データを解析して検索可能な電子文書へ変換するためのコンピュータプログラムなどを実行する処理部である。メモリ103は、該プログラムや処理中のデータを保持したり、CPUのワークスペースとして使用したりするための記憶媒体である。ハードディスク104は、該コンピュータプログラムや電子文書などのデータを格納するための大容量記憶媒体である。ネットワークインタフェース105は、ネットワーク120と接続するためのインタフェースであり、スキャン画像や前記変換された検索可能な電子文書などのデータを外部装置へ送信したり、外部装置からデータを受信したりするために使用される。ユーザインタフェース106は、ユーザからの指示を受け取るためのインタフェースであり、入力キーやタッチパネルなどの入力デバイスと、液晶などの表示デバイスから構成される。なお、本発明の装置の構成は、これに限るものではない。
【0017】
画像処理装置110は、画像処理装置100で作成された電子文書の検索や閲覧をおこなうことができる。CPU111は、電子文書を検索したり閲覧したりするための処理をおこなうためのコンピュータプログラムを実行する。メモリ112は、該プログラムを実行するためのワークスペースとして使用したり、データを一時保存したりするための記憶媒体である。ハードディスク113は、コンピュータプログラムや電子文書などのデータを格納するための大容量記憶媒体である。ネットワークインタフェース114は、外部装置から電子文書などのデータを受信したり、外部装置へデータを送信したりするためのインタフェースである。ユーザインタフェース115は、ユーザからの指示を受け取るためのインタフェースであり、入力キーやタッチパネルなどの入力デバイスと、液晶などの表示デバイスから構成される。
【0018】
次に、本実施形態1における処理を図2および図3のフローチャートを用いて説明する。
【0019】
図2は、画像処理装置100が、紙文書をスキャンするなどして取得した画像データから検索可能な電子文書を生成し、画像処理装置110へ当該電子文書を送信する処理の例を示すフローチャートである。
【0020】
ステップS201では、ユーザからの指示操作にしたがって、生成される電子文書の送信先と送信方法を決定する。ユーザからの指示はユーザインタフェース106を介して行われる。また、送信方法は、例えば、電子メール、FTPを用いたファイル転送、などの選択肢から選択される。
【0021】
ユーザが紙文書をセットしてスタートキーを押下すると、ステップS202では、スキャナ101を用いて当該セットされた紙文書をスキャンして文書画像データを生成してメモリに保存する。なお、オートドキュメントフィーダなどを用いて、複数ページで構成される文書が入力された場合は、1ページ毎に1つのページ画像データへと変換され、入力順にメモリ103に保存されるものとする。
【0022】
図7にページ画像の例を示す。図7中のページ画像701には、「あいう」という文字列702と「かきく」という文字列703、および写真704が存在する。なお、説明のために、写真704を黒の矩形で簡略的に示しているが、実際には自然画である。また、図7の例では、文字列702,703と、写真704の例しか示していないが、その他に、図形等の領域があっても構わない。
【0023】
なお、ページ画像データの形式は、例えば、紙文書がカラーであれば、RGB各々8bitで階調を表現するカラー画像で扱い、紙文書が白黒であれば8bitで輝度を表現するグレー画像もしくは1bitで白黒を表現する二値画像で扱うものとする。
【0024】
ステップS203では、メモリ103に保存された未処理のページ画像データを、処理対象画像として選択する。なお、複数ページの画像がある場合は、入力順にしたがって1ページの画像を処理対象として選択する。
【0025】
ステップS204では、処理対象の画像を解析して、テキスト領域、図領域、写真領域、表領域などといった性質の異なる領域ごとに領域識別する領域解析処理を行い、識別された各領域に関する領域データを生成してメモリ103に保存する。ここで領域データには、各領域の外接矩形の左上位置座標(x,y座標値)と、該外接矩形のサイズ(幅と高さ)を表わす画素数の値と、当該判別された領域の種別とが含まれるものとする。なお、前記領域解析処理には、公知の技術(領域識別処理、領域判別処理、領域抽出処理などとも言う)を用いるものとする。例えば、特開平6−68301号公報に開示される技術を用いれば、二値化した文書画像データから、似たような大きさの黒画素塊が縦または横に連なる範囲をテキスト領域として抽出することができる。
【0026】
図7のページ画像701に対して領域解析処理を行った結果、図8のように、テキスト領域801、写真領域802とが識別される。図9は、その領域解析処理で得られた領域データの例である。
【0027】
ステップS205では、領域解析処理で識別された各テキスト領域内の文字画像に対して文字認識処理をおこなうことにより、各テキスト領域についての文字コード列のデータを得て、メモリ103に保存する。ここで、文字コード列のデータには、テキスト領域内に含まれる各文字画像に対する認識結果である文字コード情報と、各文字画像の外接矩形の情報(外接矩形の左上座標と幅高さの情報)とが含まれるものとする。
【0028】
文字認識処理の一例を簡単に説明する。なお、文字画像を文字認識する処理は、公知の技術を利用することが可能である。
【0029】
まず、文書画像が二値画像でない場合はテキスト領域内を二値化するなどして、テキスト領域内の二値画像を得る。当該二値化された各テキスト領域内について、縦横のライン毎の黒画素数を計数してヒストグラムを作成する。縦横のヒストグラムに基づいて、周期的なヒストグラムになっている方向を行方向とし、ヒストグラムの黒画素数が所定の閾値以上になる部分を文字行を構成する部分として、短冊状の行画像を得る。次に、各行画像に対して、行方向と垂直な方向でヒストグラムをとり、ヒストグラムの結果に基づいて1文字ずつの画像を切り出す。この切り出された範囲が1文字の外接矩形情報となる。なお、ここでは、黒画素数を計数したヒストグラムを用いて判別を行ったが、各ラインに黒画素があるかないかを示す射影を用いて文字領域の判別を行うようにしてもよい。
【0030】
次に、各文字画像の外接矩形内の画像から、エッジ成分などを取り出して特徴ベクトルを得て、あらかじめ登録された文字認識用辞書内の特徴ベクトルと比較し、類似度を求める。そして、最も類似度の高い字種(文字種)のコードを、当該矩形内の文字画像に対する文字コードとする。このようにして、テキスト領域内に存在する全ての文字の外接矩形に対して、文字コードを割り当てたデータが得られる。そして、各テキスト領域から得た文字コード群が文字コード列となる。
【0031】
また、英文の文字領域に対しては、文字間に単語間スペースが存在するか否かの判定も行うこととする。例えば、文字間の距離が広いかどうかや、文字画像の文字認識結果の文字列と単語辞書とのマッチングを行って単語の切れ目であるかどうかなどを判別することにより、単語間スペースが存在するかどうか判定することができる。単語間スペースが存在すると判定した場合は、当該スペースの文字コードを文字コード列に挿入することになる。
【0032】
図10及び図11は、図8のテキスト領域801に対して文字認識処理を行った例を示す。図10中のテキスト領域1000から文字行1001と1002が先ず切り出される。そして、文字行1001内から1011,1012,1013の3文字が切り出されて、それぞれ認識処理が行われる。その結果、各文字に対応する文字コードが得られて、図11の1101に示したような文字コード列データが生成される。同様に、文字行1002内から切り出された1021,1022,1023の3文字にも文字認識処理が実行され、図11の1102に示したような文字コード列データが生成される。
【0033】
なお、上記説明は一例であって、他の公知の文字認識技術を利用した処理方法を用いて、文字コード列を取得してもよい。
【0034】
ステップS206では、当該処理対象となっているページ画像データと領域データと文字コード列データとを関連付けて、メモリ103もしくはハードディスク104に一時保存する。
【0035】
ステップS207では、未処理の画像データがあるかどうかを判定し、あればステップS203に戻り、次のページ画像データの処理を行う。なければ、ステップS208に進む。
【0036】
ステップS208では、メモリ103あるいはハードディスク104に保存された全ページ分のデータをページ順に合成して、複数ページからなる検索可能な電子文書を生成する。
【0037】
このステップS208で生成される電子文書のデータは、各ページ画像をディスプレイ等に電子的に表示あるいはプリンタにより印刷する為の描画情報と、検索キーワードで検索できるようにするための内容情報の両方を保持可能なデータである。そのような条件を満たすデータフォーマットとしては、PDF、SVGなどがあるが、本実施形態では、このとき生成される電子文書のフォーマットとして、フォントデータを埋め込むことが指定されていたとする。なお、フォントデータを埋め込むことが必須条件になっているフォーマット形式としては、例えば、XPSなどがある。以下では、XML表現を用いたページ記述フォーマットの仕様を仮定しながら説明するが、本発明はこのフォーマットに限るものではない。
【0038】
図6は、2ページ分のページ画像で構成される文書が入力された場合に、本説明で用いるページ記述フォーマットの仕様に基づいて生成された電子文書のページ記述例である。なお、ここでは、ページ記述フォーマットの例として、図6に示したように、1つのファイル内にまとめて記述するものとするが、これに限るものではない。例えば、フォントデータの部分を別ファイルにして、本体のファイルからフォントデータファイルを参照するようにし、それらをZIP圧縮等で1つの電子文書にまとめるようなフォーマット(例えば、XPS)でもよい。
【0039】
以下に、ステップS208にて行われる電子文書データ生成処理の例を、図4のフローチャートを用いて説明する。
【0040】
ステップS401では、電子文書の開始タグの記述を行う。本説明のページデータ記述フォーマット仕様では、<Document>という要素が電子文書の開始タグを表すものとする。なお、その<Document>の終了を示す</Document>までに挟まれた範囲のXML記述が、当該文書に含まれる各ページに関する記述データとなる。図6の例では601が電子文書の開始タグ、612が終了タグを表す。
【0041】
ステップS402では、未記述のページのうち、先頭ページに関するデータを特定して処理対象とする。
【0042】
ステップS403では、処理対象ページデータの開始を表わすタグを生成して記述する。本例では<Page>という要素タグがページデータの開始を表わし、その終了タグとなる</Page>までに挟まれた範囲のXML記述が、当該ページ内の描画データおよび内容データとなる。また、<Page>タグには、当該ページの画素幅と高さを示す属性WidthとHeight、ならびに解像度を示す属性Dpiを用いてページの物理的な大きさが記述され、また、ページ番号を示す属性Numberを用いてページ番号が記述される。
【0043】
図6の記述例では、<Page>要素の開始タグ602に、当該ページの幅Widthが“1680”、高さHeightが“2376”、解像度Dpiが“200”であり、ページ番号Numberが“1”であることが記述されている。また、当該1ページ目のデータは、終了タグ606までの間(603〜606)に記述されている。
【0044】
ステップS404では、ページを構成するデータのうち、画像の描画データを表わすタグを生成して記述する。
【0045】
本説明のページデータ記述フォーマット仕様では、1つの<Image>要素が1つの画像の描画データを表わすものとする。また、画像データの内容を属性Data内に記述し、その画像がページ内に描画される位置を属性X,Y,Width,Heightの座標情報で記述するものとする。ページ内に画像が複数ある場合は、各画像データを登場順に上へ重ね書きしていくことを意味する。なお、属性Data内には圧縮された画像データ形式で記述されるものとし、ここでは、圧縮方式として、カラー・グレーの場合はJPEG圧縮、二値の場合はMMR圧縮したコード列を用いるものとする。
【0046】
図6の記述例603では、文書の1ページ目のスキャン画像が全面にわたって描画されるようにしている。図6のタグ603では、画像の位置とサイズを「X=“0”、Y=“0”、Width=“1680”、Height=“2376”」として記述している。また、画像をJPEG圧縮して生成されたコード列の文字列を、属性Dataの値として記述している(なお、図6では、図を単純に示すため、Data属性の文字列を一部省略して示している)。このようにして、<Image>要素603が記述されている。なお、スキャン画像をJPEG圧縮して保存する前に、必要に応じて、解像度を変更して保存するようにしてもよい(例えば600dpiでスキャンした画像を300dpiに変更して保存してもよい)。
【0047】
ステップS405では、ページを構成するデータのうち、文字の描画データを表わす記述を生成する。
【0048】
本説明のページ記述フォーマット仕様では、1つの<Text>要素が1行分の文字の描画データを表わしている。また、<Text>要素内に記述される属性データは、Direction、X,Y、Font、Size、Color、String、CWidth、CGlyphIdなどがある。ここで、属性Directionは、文字列が縦書きか横書きかを示す。また、属性X,Yは、文字の開始位置の座標を指定する。属性Fontは、文字コードを描画するためのフォントデータのIDを指定する。属性Sizeは、フォントサイズを指定する。また、属性Colorは、描画時の文字色を、R成分値,G成分値,B成分値、透過度を表すアルファチャネル値の4値組で指定する。また、属性Stringは、文字列の内容(文字コード列)を指定する。属性CWidthは、String内の各文字より次の文字までの送り幅を指定する。また、属性CGlyphIdは、String内の各文字が描画の際に使用する字形データすなわちグリフのIDを指定する。なお、Directionが指定されていない場合は、デフォルトで横書きとする。
【0049】
<Text>要素を構成する文字コード列は、図2のステップS205で生成された文字コード列のデータを、文字行毎、すなわち縦または横に連なる文字の集合に更に分割したものが使用される。
【0050】
図6の記述例では、2つの<Text>604および605は、1ページ目の文字描画記述に関するものであり、図11の文字コード列データ1101および1102それぞれに対応する記述である。例えば、図11の1101の3文字の横書き文字列「あいう」に対応する<Text>要素604では、下記のような属性が指定されている。
【0051】
属性X,Yには、3文字分の外接矩形の左上座標としてX=“236”、Y=“272”が指定されている。属性Directionには、横書きを示す“Horizontal”が指定されている。
【0052】
フォントの種類を示す属性Fontには、“Font01”が指定されている。また、フォントサイズを示す属性Sizeには、当該文字行内の文字の高さから類推して“97”ピクセルが指定されている。描画時の文字色を示す属性Colorには、R成分値=G成分値=B成分値=0とアルファチャネル=255とが指定されている(つまり、透明色が指定されている)。
【0053】
また、文字列の内容(各文字に対応する文字コードの列)を示す属性Stringには、“0x2422,0x2424,0x2426”とが指定されている。また、各文字の送り幅を示す属性CWidthには、最初の2文字については右隣文字との左端の座標差、最後の1文字については自分の文字幅に相当する値“104,96,59”とが指定されている。
【0054】
属性CGlyphIdには、通常、各文字の字形データに合わせたグリフのIDが指定される。しかしながら、本実施形態では、スキャン画像上に透明色の文字の字形を描画するようにしているので、字形がいかなるものであっても、ユーザの視覚には見えていない。そこで、本実施形態では、異なる文字であっても、同一のグリフIDを指定することにより字形データ(フォントデータ)が少なくて済むようにしている。したがって、図6の例では、属性CGlyphIdには、“0,0,0”の同じ属性値が記述されている。また、このグリフIDで指定される字形は、簡単な形状(例えば矩形)でよい。なお、グリフの形状の詳細については、後述する。
【0055】
なお、上記の属性値は一例であって、同様な意味を持つ別の値で記述してもよい。例えば、フォントサイズの属性サイズは、ピクセル高さと画像解像度に基づき、画素数ではなくポイント数等の値で記述されてもよい。
【0056】
また、上記例では、文字行の外接矩形の左上座標位置を基準として指定し、且つフォントサイズは文字行の高さに合うように指定することで、描画される文字列がスキャン画像上の文字画像の位置にほぼ重なるようにしているが、これに限るものではない。特に、本実施形態で描画される文字は透明色が指定され、ユーザには見えていないので、描画される文字列が、対応する文字画像の真上に重ならなくても構わない。例えば、対応する文字画像の下端部に、透明な文字列が描画されるようにしてもよい。例えば、図6の604の例であれば、X=“236”、Y=“368”、Size=“10”とすれば、文字画像の下端に高さの低い透明な文字列が描画されることになる。このとき、この描画される透明文字列のサイズ(高さ)は、文字画像よりも小さい所定のサイズ(例えば10)としている。
【0057】
描画される透明文字列は、後に、検索キーワードで検索を行う際に用いられ、検索キーワードに一致する文字列は強調表示(例えば、色が変えられて表示)される。透明文字列は、対応する文字画像の位置にほぼ対応する位置に描画されているので、検索時には透明文字列を使って検索しているのであるが、ユーザにとっては、あたかも文字画像が検索されているかのように見えることになる。したがって、このような検索時の文字の強調の用途に用いるのであれば、透明文字列を対応する文字画像の下端部に描画したとしても、検索時には、対応する文字画像にアンダーラインが引かれたかのように強調表示されて特定できるので問題ない。なお、透明文字列の描画位置は、下端に限るものではなく、文字画像の下半分や上半分というような位置に描画されるよう記述しても構わない。
【0058】
ステップS406では、当該ページの終了を示す</Page>を記述する。
【0059】
ステップS407では、未記述のページが他に有るか否かを判定し、未記述のページがある場合は、次のページを処理対象のページ画像としてステップS403に戻る。一方、未記述のページがない場合は、ステップS408に進む。
【0060】
図6の記述例では、2ページ目の画像に対してもステップS404〜S406の処理が行われ、607〜610の部分が記述されることになる。
【0061】
ステップS408では、この電子文書で文字列の描画に使用される全グリフを含むフォントデータの内容を記述する。
【0062】
本説明のページデータ記述フォーマット仕様では、<Font>と</Font>に挟まれる範囲に、フォントデータに含まれるグリフデータが<Glyph>要素として記述される。<Font>要素には、当該フォントの種類を示す属性IDが含まれる。また、<Glyph>要素には、グリフの種類を示す属性IDと、そのIDに対応するグリフ(字形)を示す属性Pathとが含まれる。ここで、属性Pathは、左下を原点とする1024×1024描画矩形単位内で、直線や曲線関数を用いてグリフを表現するように記述される。
【0063】
図6の記述例では、<Font>要素611において、Id=“Font01”のフォントが定義され、その中に、グリフId=“0”のグリフが一種類定義されている。このグリフの字形を表わすPath属性“M0,0 V−1024 H1024 V1024 f”は、「原点(0,0)にMOVE,上方向に1024単位縦線を描画、右方向に1024単位横線描画、下方向に1024単位縦線描画、現在の点から開始点まで線を描画して囲まれた範囲を塗りつぶす」というグリフを記述している。すなわち、1024×1024の矩形を塗りつぶした正方形のグリフを表現する記述となっている。
【0064】
なお、図6の<Font>要素611の記述は一例であって、三角や丸、直線などの他の単純な字形を定義してもよいし、空白(スペース形状)を字形として定義してもよい。
【0065】
ステップS409では、電子文書の終了を示す</Document>を記述し、電子文書の生成を終了する。生成された電子文書はファイルとして画像処理装置100内のメモリ103あるいはハードディスク104に保存される。保存の際には公知のテキスト圧縮技術を用いて圧縮を施してもよい。
【0066】
図2に戻ってステップS209では、ステップS208で生成された電子文書を、ステップS201で指定された送信先(例えば画像処理装置110)へ、指定された送信方法で送信する。データ転送処理自体は公知技術を用いるものとして説明は省略する。
【0067】
送信先の装置110では、ネットワークインタフェース114を介して転送されてきた電子文書を受信し、ハードディスク113に蓄積する。データ受信処理は公知技術を用いるものとして説明は省略する。
【0068】
なお、装置内で蓄積される電子文書をハードディスク内部で特定するための識別情報(ファイル名など)は任意のものでよい。例えば、受信時刻に関連する文字列を付与すればよい。その他にも、重複しない番号を選択して自動付与したり、電子文書生成時にユーザが指定するようにしても構わない。
【0069】
次に、電子文書を検索・閲覧する処理の例を図3のフローチャートに従って説明する。ここでは、画像処理装置110で検索を行う例について述べるが、これに限るものではなく、画像処理装置100で検索を行えるようにしても構わない。
【0070】
ステップS301では、画像処理装置110内に蓄積された電子文書群から所望の電子文書の文字列を検索するために、ユーザは当該電子文書のテキストに含まれていると考えた検索キーワードをUI115より入力する。ここで入力された文字列の長さをkとする。
【0071】
ステップS302では、画像処理装置110のハードディスク114内にある全ての電子文書ファイルに対し、未検索の電子文書ファイルがあるか否か判断する。未検索の電子文書ファイルがあれば、その中の1つの電子文書ファイルを特定し、その電子文書ファイルが圧縮されている場合は展開して、ステップS303に進む。未検索の電子文書がなければS312に進み、全ての電子文書に対する検索が終了したことをユーザに報知する。
【0072】
ステップS303では、S302で特定された電子文書内のテキストデータを対象にして検索を行うための準備を行う。ここでは、文書内のテキスト(文字コード)を1列に並べ、探索開始位置nを初期化、すなわちn=0に設定する。
【0073】
ステップS303の処理例を以下に説明する。まず、電子文書データをXMLパーサでパースしていき、<Text>要素が表われたら属性Stringに記述されている文字コード列を取得する。そのString属性中に記載された文字コード列に基づいて、1文字ずつ、当該文字コードとその文字コード値が該電子文書データ中で記述されている位置との組を、文字コード配列テーブルに追加していく。ここで、文字コード値が記述されている位置とは、電子文書データ中で該文字コードが記述されているキャラクタ列の先頭が、該電子文書データの先頭から数えて何キャラクタ目であるかを示す値である。図6の電子文書から生成した文字コード配列テーブルの例を図12に示す。例えば、図6の電子文書内の<Text>要素604の属性Stringに記述された3つの文字コード“0x2422”、“0x2424”、“0x2426”は、それぞれこの電子文書の先頭から数えて1093キャラクタ目、1100キャラクタ目、1107キャラクタ目の位置より記述されているものとする。同様に、605及び609に基づいて、残り6つの文字コードに対しても記述位置を求めて、図12のような文字コード配列テーブルを生成する。なお、図12では、このとき、文字列番号(No.)を0から順に付与している。
【0074】
ステップS304では、文字コード配列テーブルに対して、探索開始位置nを起点として、検索キーワードの文字コード列と一致するか否か判断する。一致する部分を検出した場合、そのときの変数nを一致文字列の先頭位置としてステップS305に進む。
【0075】
一方、ステップS304で一致しないと判断した場合は、ステップS309に進み、当該文字コード配列テーブルの全ての文字を探索したか判断する。文字コード配列テーブルに格納されている文字コード列全ての探索が終了したと判断した場合はステップS311に進み、現在探索対象となっている電子文書の検索が終了したことを報知する。一方、全ての探索が終了していないと判断した場合は、ステップS310に進んで、変数nを1インクリメントして、ステップS304に戻り、次の探索開始位置nで検索キーワードと一致するか判断する。なお、ステップS309では、文字コード配列テーブルに格納されている文字コードの総数をNとした場合、n<(N−k)ならば全ての探索が終了していないと判断し、n>=(N−k)ならば探索終了と判断すればよい。
【0076】
例えば、図12の文字コード配列テーブルの例に対し、検索キーワード「かき」の文字コード列“0x242b”,“0x242d”を先頭から走査して一致する部分を探した場合、S304、S309、S310の処理が繰り返されて、最初の一致文字列の文字列番号としてn=3が抽出される。
【0077】
ステップS305では、文字列番号nに相当する文字列データが、電子文書のどのページに属しているかを特定する。
【0078】
例えば、電子文書データをパースする際に、<Text>要素がどの<Page>要素に記述されているかを判別すれば、Number属性によってページ番号が識別できる。したがって、ステップS305で特定した位置nに対応する文字列の記述位置を図12から求め、当該記述位置がどの<Page>要素の間にあるかによって、当該文字列が属するページが特定できる。なお、ステップS303で電子文書データをパースする際に、各<Text>要素がどの<Page>要素に記述されているかを判別して、図12の文字コード配列テーブルに予め格納しておけば、文字列番号に基づいてページ番号が容易に特定できる。なお、ステップS304の一致文字列の検出方法や、ステップS305のページ番号の特定方法は、上述した例に限るものではない。
【0079】
ステップS306では、ステップS305で決定されたページの描画記述に従って、当該ページの描画をおこなってUI115に表示する。このとき、文字列番号(No.)がn〜n+k−1の範囲にある文字を描画する際には、その文字に対応する個所をユーザが識別しやすいように、該文字に強調効果を付けて描画する。この検索キーワードに一致する部分に強調効果を付けた描画の詳細については下記で説明する。
【0080】
ステップS306で実施されるページの描画処理を、図5のフローチャートに従って説明する。
【0081】
ステップS501では、特定されたページ番号に対応する<Page>要素のWidth,Height属性の値から、描画結果となるページ画像のサイズを決定する。
【0082】
ステップS502では、ページ画像の画素情報が格納できる分のメモリを確保する。
【0083】
ステップS503では、当該<Page>要素の子要素の中で未処理の要素を1つ抽出し、当該未処理要素の種類を判別する。当該未処理要素が<Image>であると判別した場合は、ステップS504に進み、当該未処理要素が<Text>であると判別した場合は、ステップS505に進む。当該<Page>要素の全ての子要素が既に処理されていたら、ステップS517へ進む。
【0084】
ステップS504では、まず、<Image>要素のData属性値として記述されている圧縮画像を展開する。更に、X,Y,Width,Heightの各属性により表されるページ画像内の描画矩形領域いっぱいに収まるように、当該展開されたイメージを変倍して、ステップS502で確保したページ画像メモリの該当領域へと上書きする。その後、ステップS503に戻る。
【0085】
ステップS505では、処理対象の<Text>要素に記述された各属性から、文字開始位置(X,Y)、文字フォントID(F)、文字サイズ(S)、文字色(C)を取得する。また、当該<Text>要素に記述された文字の数(N)も取得する。
【0086】
ステップS506では、グリフ画像生成のためのメモリを確保する。ここでは1024×1024画素分の二値画像用メモリを確保するものとする。
【0087】
ステップS507では、処理中の文字を示すカウンタiを1に初期化する。
【0088】
ステップS508では、i>Nであるか否かの判断を行い、i≦Nの場合はステップS509に進み、i>Nの場合は当該<Text>要素の処理は終了したと判断してステップS503に戻る。
【0089】
ステップS509では、<Text>要素の属性Stringからi文字目の文字コード(P)と、属性CGlyphIdからi文字目のGlyphId(Q)とを取得する。
【0090】
ステップS510では、電子文書から、フォントIdが(F)である<Font>要素記述を探し出し、更に、その<Font>要素記述の子要素の中で、グリフIdが(Q)である<Glyph>要素からPath属性を取得する。
【0091】
ステップS511では、ステップS510で取得したPath属性値にしたがって、ステップS506で確保したグリフ画像生成用メモリにおいてグリフの二値画像を生成する。なお、グリフの二値画像とは、例えば、描画が行われる部分を1、描画が行われない部分を0として表した画像である。なお、本実施例では、描画が行われる部分1は、後に、透明色で描画されることになる。
【0092】
ステップS512では、グリフの二値画像を、文字サイズ属性の値(S)に則した大きさの矩形サイズになるよう変倍する。
【0093】
ステップS513では、ページ画像メモリ中の座標位置(X,Y)を基準とした矩形領域に、ステップS512で変倍されたグリフの二値画像を描画する。ページ画像上に二値画像を重ねて描画したときの各画素の画素値を以下の式で定義する。なお、グリフを描画する前のページ画像の各画素値(r,g,b)に対して、グリフを描画した後の画素値は(r’,g’,b’)になるものとする。
グリフ二値画像の画素値が0に対応する画素:(r’,g’,b’)=(r,g,b)
グリフ二値画像の画素値が1に対応する画素:(r’,g’,b’)=(F(r,Cr),F(g,Cg),F(b,Cb))
【0094】
ここで、F(r,Cr)=(r×A+Cr×(255−A))/255、F(g,Cg)=(g×A+Cg×(255−A))/255、F(b,Cb)=(b×A+Cb×(255−A))/255とする。また、Aは文字色Cに対するアルファチャネル値、Cr,Cg,Cbは文字色Cの各RGB値とする。なお、アルファチャネル値として255が指定されている場合は、当該グリフ二値画像は透明であるので、グリフ二値画像の画素値が1に対応する画素についても、(r’,g’,b’)=(r,g,b)となる。
【0095】
ステップS514では、処理中のi文字目の文字が、文字列番号(No.)がn〜n+k−1の範囲にある文字であるか否かを、例えば、図12の文字コード配列テーブルを用いて判定する。具体的には、範囲n〜n+k−1内の各文字の記述開始位置が文字コード配列テーブルから分かるので、処理中の文字iの開始位置がそのいずれかに一致しているか否かに基づいて判定する。範囲n〜n+k−1内の文字である場合はステップS515、それ以外の場合はステップS516に進む。
【0096】
ステップS515では、処理中の文字が検索文字列として検出された範囲内にあることを示すための強調処理を行う。具体的には、当該文字列を描画した範囲に相当する、ページ画像メモリの位置(X,Y)から始まる矩形領域内の各画素に対して、各画素値(r,g,b)を以下の画素値(r’,g’,b’)へと変更する。
(r’,g’,b’)=(G(r),G(g),G(b))
(ここで、G(r)=255−r,G(g)=255−g,G(b)=255−bであるとする。)
なお、色の反転を行う上記強調処理は一例であり、その他の強調処理でもよい。例えば、グリフ二値画像の画素値が0の画素に対応する画素はそのまま変更せず、グリフ二値画像の画素値が1の画素に対応する画素については、各画素値(r,g,b)を上記(r’,g’,b’)にそれぞれ変更するようにしてもよい。あるいは、強調する矩形領域の幅をグリフ二値画像の幅ではなく、各文字の送り幅を指定する属性CWidthの値を用いることにより、連続する検索文字列が間隔無しに塗りつぶされるようにしてもよい。各文字の送り幅を用いて強調処理をおこなった場合、図16のように文字間も塗りつぶされるようになる。
【0097】
ステップS516では、このi文字目の文字の送り幅(CWidth属性の値)をXに加算するとともに、iを1インクリメント(i=i+1)して、ステップS508に戻る。
【0098】
ステップS517では、1ページ分の描画結果、すなわち<Page>要素内の<Image>および<Text>要素記述を描画したページ画像メモリの内容を、UI115の表示バッファに転送して表示させる。
【0099】
以下では、図6の電子文書の1ページ目の描画記述を例として、図5のフローチャートの処理を実行した場合を説明する。
【0100】
ステップS501の処理により、図6の1ページ目の<Page>要素602の属性値Width=“1680”、Height=“2376”に基づいて、ページの画像サイズを1680×2376ピクセルと決定する。
【0101】
ステップS502の処理により、例えば、ページ画像がRGB24bitカラーで表現される場合、1680×2376×3バイトのメモリが確保される。
【0102】
ステップS504の処理により、図6の<Image>要素603のData属性値に記述された圧縮のコードが展開されて画像になり、ページ画像メモリの全域に上書きされる。なお、本例では画像データは元のページと同サイズの1680×2376のピクセルの大きさを持っているので変倍処理は施されない。
【0103】
次に、ステップS505の処理により、図6の<Text>要素604から、X=“236”,Y=“272”,文字数N=“3”,文字フォントID=“Font01”,文字サイズ=“97”,文字色=“0,0,0,255”が得られる。
【0104】
ステップS509の処理により、まず最初は、<Text>要素604のString属性の1番目の文字コード=0x2422およびGlyphId=“0”が得られる。
【0105】
ステップS511でグリフの二値画像を生成するにあたって、まず、得られた文字フォントID=“Font01”に基づき、当該IDを有するグリフのPathデータをステップS510で取得する。ここでは、図6の例では、<Font>要素611内にある、<Glyph>要素のId=“0”のPath属性を取得する。そして、ステップS511において、当該取得した<Glyph>要素のId=“0”のPath属性のデータに基づいてグリフ画像を生成する。具体的には、Path属性の記述に従って、1024×1024ピクセルのGlyph画像領域すべてを1で塗りつぶした画像となる。
【0106】
なお、図6の電子文書に記載された<Text>要素604および605内の文字のGlyphIdはすべて“0”であるため、結果的にすべての文字に対してステップS511で得られるグリフ画像は等しくなる。したがって、ステップS511で生成したグリフ画像はメモリに一時保存しておき、他の文字を描画する際、その一時保存されているグリフ画像を流用するようにしてもよい。
【0107】
ステップS512では、文字サイズ=“97”に基づいて、グリフの文字画像が97×97ピクセルに変倍される。
【0108】
ステップS513では、ページ画像上の位置(X,Y)=(236,272)から始まる97×97ピクセルの矩形範囲は変倍されたグリフの文字画像による描画対象領域となる。図6の例では文字色=“0,0,0,255”すなわちアルファチャネル値A=255であるため、グリフの二値画像中の対応する画素値が1であっても常に(r’,g’,b’)=(r,g,b)となる。つまり、ステップS513の処理前後でページ画像内の当該矩形領域内の画素値は変化しない。
【0109】
ステップS514では、図6の<Text>要素604内の1番目の文字が、文字列番号の範囲n〜n+k−1内に相当する文字か否かを文字コード配列テーブルに基づいて判定する。
【0110】
ここでは、たとえば図6の電子文書から図12の文字コード配列テーブルが生成されており、図3のステップS304でキーワードと一致すると判断された文字列の範囲が3〜4であったとする。このとき、図6の<Text>要素604内の1番目の文字コードは、範囲3〜4でないので、ステップS516に進む。<Text>要素604内の1番目の文字コード記述の先頭キャラクタ位置は1093であり、文字コード配列テーブルの文字列番号3〜4の範囲の文字の記述位置のいずれとも一致しないことから、<Text>要素604の1番目の文字は範囲3〜4内に相当する文字でないと判定できる。
【0111】
その後、図6の<Text>要素605内の1番目が示す文字の処理を行う際には、ステップS514において、文字コード配列テーブルの範囲3〜4の文字の開始位置と一致すると判断し、ステップS515での強調描画処理が実行される。
【0112】
この文字に対し、ステップS515では、ページ画像メモリの位置(236,472)から始まる92×92の領域内の各画素値(r,g,b)を、(G(r),G(g),G(b))へと変更させる。
【0113】
以上のようにして全<Text>を描画した後、ページ画像は図13のようになる。ステップS304で一致すると判定された範囲の文字に対応する領域に関しては、各矩形内で輝度が反転された状態となり、残りの文字に対応する領域は、<Image>要素が描画した画像データのままとなる。
【0114】
このように、検索した文字列が強調表示されるので、ページ内のどこに検索キーワードが存在するかを、ユーザはステップS306で表示されたページの画像を見るだけで容易に判断することができる。
【0115】
図14は、別の方法で強調表示をおこなうように設定した場合、どのようにページ画像表示がなされるかの例を示している。図14(a)のページ描画記述では、図4のステップS405で<Text>要素の属性データを記述する際、対応する文字画像の下部(下端)に相当する位置に、当該文字画像より小さいサイズ(例えば、Size=“10”)の透明文字が描画されるように記述している。このようなページ描画記述に対し、ステップS515での強調処理において、各文字の送り幅×文字サイズの矩形範囲が反転強調されるようにすれば、図14(b)のように強調表示されたページ画像が生成される。このように、ユーザにとっては、検索した部分が下線を引かれて強調されているかのように見えることになり、ユーザは検索した文字列がページ内のどこに存在するかを容易に判断することができる。
【0116】
図3に戻って、ステップS307では、検索・閲覧処理を終了するか、あるいは更に別の検索箇所を対象に検索を継続するかどうかをユーザに選択させる。ユーザが終了を選択した場合は、図3の処理を終了し、継続を選択した場合はステップS308に進む。
【0117】
ステップS308では、n=n+kとし、ステップS304に戻って、次に検索キーワードと一致する部分を検索する。
【0118】
以上説明したように、本発明の実施形態1によれば、紙の文書が電子文書へと変換される際に、ページ画像上にページから抽出した文字が透明色で描画されるように記述される。この電子文書に対しては、検索キーワードに一致する箇所が強調表示されたページ表示を確認しながら検索を進めていくことが可能である。
【0119】
この電子文書は、ひとつの単純な字形(例えば矩形)からなるフォントデータを内部で持ち、文書内の様々な字種の透明文字を描画する際に、当該ひとつの単純な字形を用いて描画するように記述している。つまり、複数の字種に対して1つの字形を共通して利用するようにしている。したがって、電子文書内で使用されるフォントデータを当該電子文書内に保存しなければならないような場合であっても、電子文書のファイルサイズ(データ容量)を小さく抑えることができる。
【0120】
<実施形態2>
図15は、実施形態2により生成された電子文書の例である。実施形態1と同様に、画像処理装置100が生成・送信し、画像処理装置110が受信・閲覧・検索するものとする。
【0121】
図15の1501および1512は電子文書の開始、終了を表す記述である。1502および1506は、1ページ目の描画の開始、終了を表わす記述である。1503は1ページ目の画像データ描画の記述である。1504および1505は1ページ目の文字描画の記述である。また、1507および1510は2ページ目の描画の開始、終了を表わす記述である。1508は2ページ目の画像データ描画の記述である。1509は2ページ目の文字描画の記述である。1511はこの電子文書で用いられるフォントデータの記述である。
【0122】
実施形態2の電子文書生成処理の説明は、図2および図4を用いた実施形態1の説明、電子文書検索・閲覧処理の説明は、図3および図5を用いた実施形態1の説明とほぼ同等となるので、実施形態1と異なる部分について説明する。
【0123】
図15の文字描画を表わす<Text>要素1504、1505および1509では、各文字のグリフIDを指定する属性CGlyphIDを記述せず、属性CStringに書かれた文字コードそのものをフォントデータ1511のグリフIDの代わりに使用する。
【0124】
また、フォントデータ1511内に定義された6つの字種のグリフのPathデータには同一の字形を定義している。このように記述されたフォントデータは、LZ77などの公知の圧縮技術を用いて高い圧縮率で圧縮することが可能である。
【0125】
本発明の実施形態2によれば、紙の文書が電子文書へと変換される際に、ページ画像上にページから抽出した文字が透明色で描画されるように記述される。この電子文書に対しては、検索キーワードに一致する箇所が強調表示されたページ表示を確認しながら検索を進めていくことが可能である。
【0126】
この電子文書は、文書内で記述した各文字に対して、同種類の字形データで構成されるフォントデータを保存するようにしている。同種類の字形データで構成されるフォントデータは、一般的なテキスト圧縮技術により高い圧縮率で圧縮することができるので、本実施形態2においても、電子文書内で使用されるフォントデータを保持しながら、電子文書のデータ量を小さく抑えることが可能である。また、実施形態2においても、グリフの字形は、単純化されて保存されているので、字形データ自体のデータ量も抑えることができる。
【0127】
<実施形態3>
また、上述した実施形態では、スキャン画像に対してJPEG圧縮等を行った全面イメージを<Image>要素に記述し、透明テキストを<Text>要素に記述した電子文書を生成することとしたが、これに限るものではない。
【0128】
例えば、<Image>要素に、スキャン画像全体をJPEG圧縮したものを記述する代わりに、文字領域や図領域は色別に2値画像を作成してMMR圧縮したもの、それ以外の領域はJPEG圧縮したものを格納するようにしてもよい。このように、文書画像に含まれる領域を解析して適応的に圧縮処理を行う方法は、例えば、特開平07−236062号公報や特開2002−077633号公報などに記載の方法を用いることができる。本発明の透明テキストを描画する際に用いるフォントデータのデータ量を抑える処理と、これらの画像圧縮処理とを組み合わせることで、更に高圧縮された電子文書を生成することが可能になる。
【0129】
また、全面イメージの代わりに、文字領域、図領域、表領域、写真領域などの部分領域だけを位置データとともに保存するようにしても構わない。
【0130】
<実施形態4>
上述した実施形態では、検索した結果に対応する個所を強調表示する際、画像の色(r,g,b)を反転することにより強調表示したが、使用する色はこれに限るものではない。例えば、検索結果を特定させるための予め決めた色(例えば黄色)を、半透明(例えばアルファチャネル128)で描画させるようにしてもよい。また、文字色(Cr,Cg,Cb)を利用して、強調色を決めるようにしてもよい。
【0131】
<実施形態5>
また、上述した実施形態では、図3及び図5で説明したように、検索を行う際は、キーワードに一致する文字列を文書の先頭から順に検索していき、最初に検索された文字列を強調表示した。そして、「次を検索」の指示があれば、順次、次に一致する文字列を検索して強調表示するように構成した。このように、上述した実施形態では、検索キーワードに一致する文字列を先頭から順に検索をおこない、検索キーワードがヒットするごとに順次強調表示を行っていたが、これに限るものではない。例えば、電子文書内に含まれる全ての文字列について、検索キーワードと比較を行い、全ての一致する文字列を特定し、そのキーワードに一致した全ての文字列を同時に強調表示するような構成にしてもよい。
【0132】
<その他の実施形態>
なお、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコード(コンピュータプログラム)を記憶した、コンピュータ読取可能な記憶媒体を、システムあるいは装置に供給することによっても達成される。また、システムあるいは装置のコンピュータ(またはCPUやMPU)が記憶媒体に格納されたプログラムコードを読出し実行することによっても達成される。
【0133】
本発明のコンピュータプログラムは、上述したフローチャートに記載した各ステップを装置に実行させることになる。言い換えると、このコンピュータプログラムは、フローチャートの各ステップに対応する各処理部(各処理手段)として、コンピュータを機能させるためのプログラムである。この場合、コンピュータ可読記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【0134】
プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、CD−ROM、CD−R、不揮発性のメモリカード、ROMなどを用いることができる。
【0135】
また、プログラムコードの指示に基づき、コンピュータ上で稼働しているOS(オペレーティングシステム)などが実際の処理の一部または全部を行い、その処理によって前述した実施形態が実現される場合も本発明に含まれることは言うまでもない。
【0136】
また、一方、上述した実施形態1,2では、CPUがメモリやハードディスク、表示デバイス等と協働して各フローチャートの各ステップを実行する形態について説明した。本発明は、上述した構成に限るものではなく、各フローチャートで説明した各ステップの処理の一部または全部を、CPUの代わりに専用の電子回路で構成するようにしても構わない。
【特許請求の範囲】
【請求項1】
紙文書をスキャンして文書画像を生成するスキャナと、
前記スキャナで生成した文書画像内の複数の文字画像に対して文字認識処理を行うことにより、それぞれの文字画像に対応する文字コードを得る文字認識手段と、
前記文書画像と、前記文字認識手段で得た複数の文字コードと、前記複数の文字コードに対応する文字を描画する際に当該複数の文字コードで共通利用させるための字形データとを格納した電子文書を生成する生成手段と、
前記生成手段で生成した電子文書を、指定された送信先へ送信する送信手段と、
を有することを特徴とする画像処理装置。
【請求項2】
前記送信先と送信方法とをユーザに指定させるためのユーザインタフェースを更に有し、
前記送信手段は、前記生成手段で生成した電子文書を、前記ユーザインタフェースで指定された送信先へ当該指定された送信方法で送信することを特徴とする請求項1に記載の画像処理装置。
【請求項3】
前記ユーザインタフェースで前記送信先と前記送信方法とが前記ユーザにより指定された後、更に、前記ユーザによってスタートキーが押下された場合に、前記スキャナと前記文字認識手段と前記生成手段と前記送信手段とによる処理が実行されることを特徴とする請求項2に記載の画像処理装置。
【請求項4】
前記字形データは、矩形または三角または丸または直線のいずれかの形状を有する字形データ、あるいは空白の字形データであることを特徴とする請求項1に記載の画像処理装置。
【請求項5】
前記生成手段で生成された電子文書には、前記複数の文字コードに対応させた字形データを、前記文書画像内の各文字画像に重なる位置に透明色で描画させるための記述が含まれることを特徴とする請求項1に記載の画像処理装置。
【請求項6】
前記生成手段で生成された電子文書には、前記複数の文字コードに対応させた字形データを、前記文書画像内の各文字画像の下端に対応する位置に透明色で描画させるための記述が含まれることを特徴とする請求項1に記載の画像処理装置。
【請求項7】
前記生成手段で生成された電子文書には、前記複数の文字コードに対応させた字形データを、前記文書画像内の各文字画像のサイズよりも小さいサイズで、前記文書画像内の各文字画像の下端に対応する位置に透明色で描画させるための記述が含まれることを特徴とする請求項1に記載の画像処理装置。
【請求項8】
前記電子文書は、XMLフォーマットで記述された電子文書であることを特徴とする請求項1に記載の画像処理装置。
【請求項9】
前記電子文書は、XPSフォーマットで記述された電子文書であることを特徴とする請求項1に記載の画像処理装置。
【請求項10】
前記画像処理装置は、前記文書画像を圧縮する圧縮手段を更に有し、
前記電子文書に格納される文書画像は、前記圧縮手段で圧縮処理が施された文書画像であることを特徴とする請求項1に記載の画像処理装置。
【請求項11】
前記圧縮手段は、前記文書画像内に含まれる領域を解析して適応的に圧縮することを特徴とする請求項10に記載の画像処理装置。
【請求項1】
紙文書をスキャンして文書画像を生成するスキャナと、
前記スキャナで生成した文書画像内の複数の文字画像に対して文字認識処理を行うことにより、それぞれの文字画像に対応する文字コードを得る文字認識手段と、
前記文書画像と、前記文字認識手段で得た複数の文字コードと、前記複数の文字コードに対応する文字を描画する際に当該複数の文字コードで共通利用させるための字形データとを格納した電子文書を生成する生成手段と、
前記生成手段で生成した電子文書を、指定された送信先へ送信する送信手段と、
を有することを特徴とする画像処理装置。
【請求項2】
前記送信先と送信方法とをユーザに指定させるためのユーザインタフェースを更に有し、
前記送信手段は、前記生成手段で生成した電子文書を、前記ユーザインタフェースで指定された送信先へ当該指定された送信方法で送信することを特徴とする請求項1に記載の画像処理装置。
【請求項3】
前記ユーザインタフェースで前記送信先と前記送信方法とが前記ユーザにより指定された後、更に、前記ユーザによってスタートキーが押下された場合に、前記スキャナと前記文字認識手段と前記生成手段と前記送信手段とによる処理が実行されることを特徴とする請求項2に記載の画像処理装置。
【請求項4】
前記字形データは、矩形または三角または丸または直線のいずれかの形状を有する字形データ、あるいは空白の字形データであることを特徴とする請求項1に記載の画像処理装置。
【請求項5】
前記生成手段で生成された電子文書には、前記複数の文字コードに対応させた字形データを、前記文書画像内の各文字画像に重なる位置に透明色で描画させるための記述が含まれることを特徴とする請求項1に記載の画像処理装置。
【請求項6】
前記生成手段で生成された電子文書には、前記複数の文字コードに対応させた字形データを、前記文書画像内の各文字画像の下端に対応する位置に透明色で描画させるための記述が含まれることを特徴とする請求項1に記載の画像処理装置。
【請求項7】
前記生成手段で生成された電子文書には、前記複数の文字コードに対応させた字形データを、前記文書画像内の各文字画像のサイズよりも小さいサイズで、前記文書画像内の各文字画像の下端に対応する位置に透明色で描画させるための記述が含まれることを特徴とする請求項1に記載の画像処理装置。
【請求項8】
前記電子文書は、XMLフォーマットで記述された電子文書であることを特徴とする請求項1に記載の画像処理装置。
【請求項9】
前記電子文書は、XPSフォーマットで記述された電子文書であることを特徴とする請求項1に記載の画像処理装置。
【請求項10】
前記画像処理装置は、前記文書画像を圧縮する圧縮手段を更に有し、
前記電子文書に格納される文書画像は、前記圧縮手段で圧縮処理が施された文書画像であることを特徴とする請求項1に記載の画像処理装置。
【請求項11】
前記圧縮手段は、前記文書画像内に含まれる領域を解析して適応的に圧縮することを特徴とする請求項10に記載の画像処理装置。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【公開番号】特開2010−33589(P2010−33589A)
【公開日】平成22年2月12日(2010.2.12)
【国際特許分類】
【出願番号】特願2009−242632(P2009−242632)
【出願日】平成21年10月21日(2009.10.21)
【分割の表示】特願2007−172736(P2007−172736)の分割
【原出願日】平成19年6月29日(2007.6.29)
【出願人】(000001007)キヤノン株式会社 (59,756)
【Fターム(参考)】
【公開日】平成22年2月12日(2010.2.12)
【国際特許分類】
【出願日】平成21年10月21日(2009.10.21)
【分割の表示】特願2007−172736(P2007−172736)の分割
【原出願日】平成19年6月29日(2007.6.29)
【出願人】(000001007)キヤノン株式会社 (59,756)
【Fターム(参考)】
[ Back to top ]