画像処理装置、画像処理方法、コンピュータプログラム
【課題】 電子文書内にフォントデータを格納するようにした場合、ファイルサイズが増加してしまうという問題があった。また、描画するテキストの位置が、文書画像中の各文字画像の位置と合うようにしたい。
【解決手段】 本発明では、文書画像内の複数の文字画像に対して文字認識処理を行い、各文字画像に対応する文字コードを得る。幅の異なる複数種類の字形データの中から、各文字画像の文字の幅(或いは文字送り幅)に適合する字形データの種類を選択する。次に、文書画像と、文字認識して得た複数の文字コードと、複数の異なる文字コードで共通利用させるための複数種類の字形データと、複数の文字コードの描画の際に使用する前記選択した字形データの種類を示すデータとを格納した電子文書を生成し、指定された送信先へ送信する。
【解決手段】 本発明では、文書画像内の複数の文字画像に対して文字認識処理を行い、各文字画像に対応する文字コードを得る。幅の異なる複数種類の字形データの中から、各文字画像の文字の幅(或いは文字送り幅)に適合する字形データの種類を選択する。次に、文書画像と、文字認識して得た複数の文字コードと、複数の異なる文字コードで共通利用させるための複数種類の字形データと、複数の文字コードの描画の際に使用する前記選択した字形データの種類を示すデータとを格納した電子文書を生成し、指定された送信先へ送信する。
【発明の詳細な説明】
【技術分野】
【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】
上記課題を解決するために、本発明の画像処理装置は、文書画像内の複数の文字画像に対して文字認識処理を行うことにより、それぞれの文字画像に対応する文字コードを得る文字認識手段と、幅の異なる複数種類の字形データの中から、前記文書画像内の各文字画像の文字の幅に適合する字形データの種類を選択する選択手段と、前記文書画像と、前記文字認識手段で得た複数の文字コードと、前記複数の文字コードに対応する文字を描画する際に複数の異なる文字コードで共通利用させるための前記複数種類の字形データと、前記複数の文字コードの描画の際に使用する字形データの種類を示すデータとを格納した電子文書を生成する生成手段と、前記生成手段で生成した電子文書を、指定された送信先へ送信する送信手段と、を有し、前記電子文書に格納される、前記複数の文字コードの描画の際に使用する字形データの種類を示すデータは、前記文書画像内の各文字画像に対して前記選択手段で選択された字形データの種類に基づいて記述されることを特徴とする。
【0015】
または、上記課題を解決するために、本発明の画像処理装置は、文書画像内の複数の文字画像に対して文字認識処理を行うことにより、それぞれの文字画像に対応する文字コードを得る文字認識手段と、幅の異なる複数種類の字形データの中から、前記文書画像内の各文字画像の文字送り幅に適合する字形データの種類を選択する選択手段と、前記文書画像と、前記文字認識手段で得た複数の文字コードと、前記複数の文字コードに対応する文字を描画する際に複数の異なる文字コードで共通利用させるための前記複数種類の字形データと、前記複数の文字コードの描画の際に使用する字形データの種類を示すデータとを格納した電子文書を生成する生成手段と、前記生成手段で生成した電子文書を、指定された送信先へ送信する送信手段と、を有し、前記電子文書に格納される、前記複数の文字コードの描画の際に使用する字形データの種類を示すデータは、前記文書画像内の各文字画像に対して前記選択手段で選択された字形データの種類に基づいて記述されることを特徴とする。
【発明の効果】
【0016】
本発明によれば、幅の異なる複数の字形データの中から、文書画像内の各文字画像の文字の幅(あるいは文字送り幅)に適合する字形データの種類を選択しておくことで、テキストの描画位置と文書画像内の各文字画像の位置とが合うようにできる。また複数種類の字形データとして、幅の異なる単純な字形(例えば矩形)をいくつか用意しておき、様々な字種を描画する際、共通して利用するようにしている。よって、記述するデータの量が少なくて済む。ゆえに、フォントデータを電子文書内に保存しなければならないような場合であっても、電子文書のファイルサイズを小さく抑えることができる。
【図面の簡単な説明】
【0017】
【図1】実施形態1の構成例を表すブロック図
【図2】実施形態1の電子文書生成処理の例を表すフローチャート
【図3】実施形態1の電子文書検索・閲覧処理の例を表すフローチャート
【図4】図2のステップS208でおこなわれる電子文書データ生成処理の詳細を表すフローチャート
【図5】図3のステップS306でおこなわれるページの描画処理の詳細を表すフローチャート
【図6】実施形態1により生成される電子文書の例
【図7】処理対象のページ画像の例
【図8】領域分割処理結果の例
【図9】生成される領域データの例
【図10】文字認識処理時に文字画像を抽出する際の処理を示す例
【図11】文字認識結果で生成される文字コード列データの例
【図12】文字コード配列テーブルの例
【図13】検索結果が強調表示されたページ表示の例
【図14】別の強調表示処理で検索結果が強調表示されたページ表示の例
【図15】グリフID決定処理を示すフローチャートの例
【図16】実施形態2において、検索結果が強調表示されたページ表示の例
【発明を実施するための形態】
【0018】
<実施形態1>
図1は画像処理装置の構成を示すブロック図の一例である。
【0019】
画像処理装置100は本実施形態を実現するための装置であり、文書画像データを検索可能な電子文書に変換する。画像処理装置100は、スキャナ101、中央処理ユニット(CPU)102、メモリ103、ハードディスク104、ネットワークインタフェース105、ユーザインタフェース(UI)106で構成される。スキャナ101は紙文書の紙面情報を読み取り、文書画像データに変換を行う。CPU102は、画像データを解析して検索可能な電子文書へ変換するためのコンピュータプログラムなどを実行する処理部である。メモリ103は、該プログラムや処理中のデータを保持したり、CPUのワークスペースとして使用したりするための記憶媒体である。ハードディスク104は、該コンピュータプログラムや電子文書などのデータを格納するための大容量記憶媒体である。ネットワークインタフェース105は、ネットワーク120と接続するためのインタフェースであり、スキャン画像や前記変換された検索可能な電子文書などのデータを外部装置へ送信したり、外部装置からデータを受信したりするために使用される。ユーザインタフェース106は、ユーザからの指示を受け取るためのインタフェースであり、入力キーやタッチパネルなどの入力デバイスと、液晶などの表示デバイスから構成される。なお、本発明の装置の構成は、これに限るものではない。
【0020】
画像処理装置110は、画像処理装置100で作成された電子文書の検索や閲覧をおこなうことができる。CPU111は、電子文書を検索したり閲覧したりするための処理をおこなうためのコンピュータプログラムを実行する。メモリ112は、該プログラムを実行するためのワークスペースとして使用したり、データを一時保存したりするための記憶媒体である。ハードディスク113は、コンピュータプログラムや電子文書などのデータを格納するための大容量記憶媒体である。ネットワークインタフェース114は、外部装置から電子文書などのデータを受信したり、外部装置へデータを送信したりするためのインタフェースである。ユーザインタフェース115は、ユーザからの指示を受け取るためのインタフェースであり、入力キーやタッチパネルなどの入力デバイスと、液晶などの表示デバイスから構成される。
【0021】
次に、本実施形態1における処理を図2および図3のフローチャートを用いて説明する。
図2は、画像処理装置100が、紙文書をスキャンするなどして取得した画像データから検索可能な電子文書を生成し、画像処理装置110へ当該電子文書を送信する処理の例を示すフローチャートである。
【0022】
ステップS201では、ユーザからの指示操作にしたがって、生成される電子文書の送信先と送信方法を決定する。ユーザからの指示はユーザインタフェース106を介して行われる。また、送信方法は、例えば、電子メール、FTPを用いたファイル転送、などの選択肢から選択される。
【0023】
ユーザが紙文書をセットしてスタートキーを押下すると、ステップS202では、スキャナ101を用いて当該セットされた紙文書をスキャンして文書画像データを生成してメモリに保存する。なお、オートドキュメントフィーダなどを用いて、複数ページで構成される文書が入力された場合は、1ページ毎に1つのページ画像データへと変換され、入力順にメモリ103に保存されるものとする。
【0024】
図7にページ画像の例を示す。図7中のページ画像701には、「あ1A」という文字列702と、「かBc」という文字列703、および写真704が存在する。なお、説明のために、写真704を黒の矩形で簡略的に示しているが、実際には自然画である。また、図7の例では、文字列702,703と、写真704の例しか示していないが、その他に、図形等の領域があっても構わない。
【0025】
なお、ページ画像データの形式は、例えば、紙文書がカラーであれば、RGB各々8bitで階調を表現するカラー画像で扱い、紙文書が白黒であれば8bitで輝度を表現するグレー画像もしくは1bitで白黒を表現する二値画像で扱うものとする。
【0026】
ステップS203では、メモリ103に保存された未処理のページ画像データを、処理対象画像として選択する。なお、複数ページの画像がある場合は、入力順にしたがって1ページの画像を処理対象として選択する。
【0027】
ステップS204では、処理対象の画像を解析して、テキスト領域、図領域、写真領域、表領域などといった性質の異なる領域ごとに領域識別する領域解析処理を行い、識別された各領域に関する領域データを生成してメモリ103に保存する。ここで領域データには、各領域の外接矩形の左上位置座標(x,y座標値)と、該外接矩形のサイズ(幅と高さ)を表わす画素数の値と、当該判別された領域の種別とが含まれるものとする。なお、前記領域解析処理には、公知の技術(領域識別処理、領域判別処理、領域抽出処理などとも言う)を用いるものとする。例えば、特開平6−68301号公報に開示される技術を用いれば、二値化した文書画像データから、似たような大きさの黒画素塊が縦または横に連なる範囲をテキスト領域として抽出することができる。
【0028】
図7のページ画像701に対して領域解析処理を行った結果、図8のように、テキスト領域801、写真領域802とが識別される。図9は、その領域解析処理で得られた領域データの例である。
【0029】
ステップS205では、領域解析処理で識別された各テキスト領域内の文字画像に対して文字認識処理をおこなうことにより、各テキスト領域についての文字コード列のデータを得て、メモリ103に保存する。ここで、文字コード列のデータには、テキスト領域内に含まれる各文字画像に対する認識結果である文字コード情報と、各文字画像の外接矩形の情報(外接矩形の左上座標と幅と高さの情報、ならびに該文字が含まれる行の高さの情報)とが含まれるものとする。
【0030】
文字認識処理の一例を簡単に説明する。なお、文字画像を文字認識する処理は、公知の技術を利用することが可能である。
【0031】
まず、文書画像が二値画像でない場合はテキスト領域内を二値化するなどして、テキスト領域内の二値画像を得る。当該二値化された各テキスト領域内について、縦横のライン毎の黒画素数を計数してヒストグラムを作成する。縦横のヒストグラムに基づいて、周期的なヒストグラムになっている方向を行方向とし、ヒストグラムの黒画素数が所定の閾値以上になる部分を文字行を構成する部分として、短冊状の行画像を得る。次に、各行画像に対して、行方向と垂直な方向でヒストグラムをとり、ヒストグラムの結果に基づいて1文字ずつの画像を切り出す。この切り出された範囲が1文字の外接矩形情報となる。なお、ここでは、黒画素数を計数したヒストグラムを用いて判別を行ったが、各ラインに黒画素があるかないかを示す射影を用いて文字領域の判別を行うようにしてもよい。
【0032】
次に、各文字画像の外接矩形内の画像から、エッジ成分などを取り出して特徴ベクトルを得て、あらかじめ登録された文字認識用辞書内の特徴ベクトルと比較し、類似度を求める。そして、最も類似度の高い字種(文字種)のコードを、当該矩形内の文字画像に対する文字コードとする。このようにして、テキスト領域内に存在する全ての文字の外接矩形に対して、文字コードを割り当てたデータが得られる。そして、各テキスト領域から得た文字コード群が文字コード列となる。
【0033】
また、英文の文字領域に対しては、文字間に単語間スペースが存在するか否かの判定も行うこととする。例えば、文字間の距離が広いかどうかや、文字画像の文字認識結果の文字列と単語辞書とのマッチングを行って単語の切れ目であるかどうかなどを判別することにより、単語間スペースが存在するかどうか判定することができる。単語間スペースが存在すると判定した場合は、当該スペースの文字コードを文字コード列に挿入することになる。
【0034】
図10及び図11は、図8のテキスト領域801に対して文字認識処理を行った例を示す。図10中のテキスト領域1000から文字行1001と1002が先ず切り出される。そして、文字行1001内から1011,1012,1013の3文字が切り出されて、それぞれ認識処理が行われる。その結果、各文字に対応する文字コードが得られて、図11の1101に示したような文字コード列データが生成される。同様に、文字行1002内から切り出された1021,1022,1023の3文字にも文字認識処理が実行され、図11の1102に示したような文字コード列データが生成される。
【0035】
なお、上記説明は一例であって、他の公知の文字認識技術を利用した処理方法を用いて、文字コード列を取得してもよい。
【0036】
ステップS206では、当該処理対象となっているページ画像データと領域データと文字コード列データとを関連付けて、メモリ103もしくはハードディスク104に一時保存する。
【0037】
ステップS207では、未処理の画像データがあるかどうかを判定し、あればステップS203に戻り、次のページ画像データの処理を行う。なければ、ステップS208に進む。
【0038】
ステップS208では、メモリ103あるいはハードディスク104に保存された全ページ分のデータをページ順に合成して、複数ページからなる検索可能な電子文書を生成する。
【0039】
このステップS208で生成される電子文書のデータは、各ページ画像をディスプレイ等に電子的に表示あるいはプリンタにより印刷する為の描画情報と、検索キーワードで検索できるようにするための内容情報の両方を保持可能なデータである。そのような条件を満たすデータフォーマットとしては、PDF、SVGなどがあるが、本実施形態では、このとき生成される電子文書のフォーマットとして、フォントデータを埋め込むことが指定されていたとする。なお、フォントデータを埋め込むことが必須条件になっているフォーマット形式としては、例えば、XPSなどがある。以下では、XML表現を用いたページ記述フォーマットの仕様を仮定しながら説明するが、本発明はこのフォーマットに限るものではない。
【0040】
図6は、2ページ分のページ画像で構成される文書が入力された場合に、本説明で用いるページ記述フォーマットの仕様に基づいて生成された電子文書のページ記述例である。なお、ここでは、ページ記述フォーマットの例として、図6に示したように、1つのファイル内にまとめて記述するものとするが、これに限るものではない。例えば、フォントデータの部分を別ファイルにして、本体のファイルからフォントデータファイルを参照するようにし、それらをZIP圧縮等で1つの電子文書にまとめるようなフォーマット(例えば、XPS)でもよい。
【0041】
以下に、ステップS208にて行われる電子文書データ生成処理の例を、図4のフローチャートを用いて説明する。
【0042】
ステップS401では、電子文書の開始タグの記述を行う。本説明のページデータ記述フォーマット仕様では、<Document>という要素が電子文書の開始タグを表すものとする。なお、その<Document>の終了を示す</Document>までに挟まれた範囲のXML記述が、当該文書に含まれる各ページに関する記述データとなる。図6の例では601が電子文書の開始タグ、612が終了タグを表す。
【0043】
ステップS402では、未記述のページのうち、先頭ページに関するデータを特定して処理対象とする。
【0044】
ステップS403では、処理対象ページデータの開始を表わすタグを生成して記述する。本例では<Page>という要素タグがページデータの開始を表わし、その終了タグとなる</Page>までに挟まれた範囲のXML記述が、当該ページ内の描画データおよび内容データとなる。また、<Page>タグには、当該ページの画素幅と高さを示す属性WidthとHeight、ならびに解像度を示す属性Dpiを用いてページの物理的な大きさが記述され、また、ページ番号を示す属性Numberを用いてページ番号が記述される。
【0045】
図6の記述例では、<Page>要素の開始タグ602に、当該ページの幅Widthが“1680”、高さHeightが“2376”、解像度Dpiが“200”であり、ページ番号Numberが“1”であることが記述されている。また、当該1ページ目のデータは、終了タグ606までの間(603〜606)に記述されている。
【0046】
ステップS404では、ページを構成するデータのうち、画像の描画データを表わすタグを生成して記述する。
【0047】
本説明のページデータ記述フォーマット仕様では、1つの<Image>要素が1つの画像の描画データを表わすものとする。また、画像データの内容を属性Data内に記述し、その画像がページ内に描画される位置を属性X,Y,Width,Heightの座標情報で記述するものとする。ページ内に画像が複数ある場合は、各画像データを登場順に上へ重ね書きしていくことを意味する。なお、属性Data内には圧縮された画像データ形式で記述されるものとし、ここでは、圧縮方式として、カラー・グレーの場合はJPEG圧縮、二値の場合はMMR圧縮したコード列を用いるものとする。
【0048】
図6の記述例603では、文書の1ページ目のスキャン画像が全面にわたって描画されるようにしている。図6のタグ603では、画像の位置とサイズを「X=“0”、Y=“0”、Width=“1680”、Height=“2376”」として記述している。また、画像をJPEG圧縮して生成されたコード列の文字列を、属性Dataの値として記述している(なお、図6では、図を単純に示すため、Data属性の文字列を一部省略して示している)。このようにして、<Image>要素603が記述されている。なお、スキャン画像をJPEG圧縮して保存する前に、必要に応じて、解像度を変更して保存するようにしてもよい(例えば600dpiでスキャンした画像を300dpiに変更して保存してもよい)。
【0049】
ステップS405では、ページを構成するデータのうち、文字の描画データを表わす記述を生成する。
【0050】
本説明のページ記述フォーマット仕様では、1つの<Text>要素が1行分の文字の描画データを表わしている。また、<Text>要素内に記述される属性データは、Direction、X,Y、Font、Size、Color、String、CGlyphIdなどがある。ここで、属性Directionは、文字列が縦書きか横書きかを示し、Direction属性が記述されていない場合はデフォルトの方向(例えば、左から右に向かう水平方向)が使用される。また、属性X,Yは、文字の開始位置の座標を指定する。属性Fontは、文字コードを描画するためのフォントデータのIDを指定する。属性Sizeは、フォントサイズを指定する。また、属性Colorは、描画時の文字色を、R成分値,G成分値,B成分値、透過度を表すアルファチャネル値の4値組で指定する。また、属性Stringは、文字列の内容(文字コード列)を指定する。また、属性CGlyphIdは、String内の各文字が描画の際に使用する字形データすなわちグリフのIDを指定する。なお、Directionが指定されていない場合は、デフォルトで横書きとする。
【0051】
<Text>要素を構成する文字コード列は、図2のステップS205で生成された文字コード列のデータを、文字行毎、すなわち縦または横に連なる文字の集合に更に分割したものが使用される。
【0052】
図6の記述例では、2つの<Text>604および605は、1ページ目の文字描画記述に関するものであり、図11の文字コード列データ1101および1102それぞれに対応する記述である。例えば、図11の1101の3文字の横書き文字列「あ1A」に対応する<Text>要素604では、下記のような属性が指定されている。
【0053】
属性X,Yには、3文字分の外接矩形の左上座標としてX=“236”、Y=“272”が指定されている。
【0054】
フォントの種類を示す属性Fontには、“Font01”が指定されている。また、フォントサイズを示す属性Sizeには、当該文字行内の文字の高さから類推して“97”ピクセルが指定されている。描画時の文字色を示す属性Colorには、R成分値=G成分値=B成分値=0とアルファチャネル=255とが指定されている(つまり、透明色が指定されている)。
【0055】
また、文字列の内容(各文字に対応する文字コードの列)を示す属性Stringには、“0x2422,0x2332,0x2341”とが指定されている。
【0056】
属性CGlyphIdには、各文字の字形データとして用いるグリフのIDが指定される。ここでは、ステップS205で得た各文字の幅情報に基づきグリフのIDが指定されるものとする。なお、本実施形態では、スキャン画像上に透明色の文字の字形を描画するようにしているので、ユーザの視覚には見えていない。そこで、本実施形態では、字形データとして、文字画像の形状そのままの字形を用いるのではなく、単純な形状(例えば矩形)の字形データをいくつか(例えば8種類)用意しておき、その中から使用する字形データ(グリフのID)を選択して用いることとする。つまり、グリフとして、矩形幅のサイズが異なるグリフ(縦横比の異なるグリフ)を複数用意しておき、その中から文字毎に適したグリフを選択するように制御する。したがって、本実施形態では、文字が含まれている行の高さと各文字の文字幅との比に基づいて、グリフのIDが選択されるものとする。図15は、画像処理装置100が、各文字画像に対するグリフのIDを選択するためのフローチャートの例である。ステップS1501〜S1507では、(文字幅/行高さ)を、(7/8)、(6/8)、(5/8)、(4/8)、(3/8)、(2/8)、(1/8)と比較する。その比較結果に応じて、ステップS1508〜S1515のいずれかに進んで、グリフのID(0〜7)を選択する。すなわち、(文字幅/行高さ)>(7/8)であると判断された場合は、グリフID=0と選択される。(7/8)>=(文字幅/行高さ)>(6/8)であると判断された場合は、グリフID=1と選択される。(6/8)>=(文字幅/行高さ)>(5/8)であると判断された場合は、グリフID=2と選択される。(5/8)>=(文字幅/行高さ)>(4/8)であると判断された場合は、グリフID=3と選択される。(4/8)>=(文字幅/行高さ)>(3/8)であると判断された場合は、グリフID=4と選択される。(3/8)>=(文字幅/行高さ)>(2/8)であると判断された場合は、グリフID=5と選択される。(2/8)>=(文字幅/行高さ)>(1/8)であると判断された場合は、グリフID=6と選択される。(文字幅/行高さ)<=(1/8)であると判断された場合は、グリフID=7と選択される。なお、この例では、グリフIDの番号が小さい方が、より矩形幅が広いグリフになっている。例えば、図11の1101の文字列では、(文字幅/行高さ)がそれぞれ「0.82」、「0.14」、「0.57」であるので、図15の選択処理により、グリフのIDは、“1,6,3”と指定されることになる。なお、英文の単語間スペースに関しても同様に、スペースの幅を文字幅として扱うことにより、当該スペースが含まれている文字行の高さと当該スペースの幅との比に基づいて、グリフIDが選択される。なお、グリフの形状の詳細については、後述する。
【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は、左下を原点とする描画矩形単位内で、直線や曲線関数を用いてグリフを表現するように記述される。
【0063】
図6の記述例では、<Font>要素611において、Id=“Font01”のフォントが定義され、その中に、グリフId=“0”〜“7”のグリフが8種類定義されている。例えば、Id=“7”のグリフの字形を表わすPath属性“M0,0 V−1024 H128 V1024 f”は、「原点(0,0)にMOVE,上方向に1024単位縦線を描画、右方向に128単位横線描画、下方向に1024単位縦線描画、現在の点から開始点まで線を描画して囲まれた範囲を塗りつぶす」というグリフを記述している。すなわち、1024×128の矩形を塗りつぶした矩形のグリフを表現する記述となっている。そのほかのIDはそれぞれID=“7”を横方向に段階的に整数倍した長方形のグリフであり、例えば、ID=“0”は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”、“0x2332”、“0x2341”は、それぞれこの電子文書の先頭から数えて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の文字コード配列テーブルの例に対し、検索キーワード「かB」の文字コード列“0x242b”,“0x2342”を先頭から走査して一致する部分を探した場合、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)に則した大きさの矩形サイズになるよう変倍する。このとき、変倍後のグリフ二値画像の描画が行われる部分1の幅を、変倍グリフ幅Wiとして取得する。
【0093】
ステップS513では、ページ画像メモリ中の座標位置(X,Y)を基準とした矩形領域に、ステップS512で変倍されたグリフの二値画像を描画する。ページ画像上に二値画像を重ねて描画したときの各画素の画素値を以下の式で定義する。なお、グリフを描画する前のページ画像の各画素値(r,g,b)に対して、グリフを描画した後の画素値は(r’,g’,b’)になるものとする。
【0094】
グリフ二値画像の画素値が0に対応する画素:(r’,g’,b’)=(r,g,b)
グリフ二値画像の画素値が1に対応する画素:(r’,g’,b’)=(F(r,Cr),F(g,Cg),F(b,Cb))
ここで、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’)へと変更する。
【0097】
(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’)にそれぞれ変更するようにしてもよい。
【0098】
ステップS516では、次の文字の描画開始位置Xを決定し、nを1インクリメント(n=n+1)して、ステップS508に戻る。次の文字の描画開始位置Xは、現在の文字の描画開始位置に、変形グリフ幅Wiと文字間の距離とを加算したもので計算される。本実施形態では、データ容量が少なくて済むように、文字送り幅や文字間の距離などのデータを保存していないので、文字間の距離は変形グリフ幅の10%であると仮定して計算を行うこととする。したがって、ここでは、次の文字の描画開始位置は、X=X+1.1Wiで計算することとしている。なお、文字間の距離は、この計算に限るものではない。例えば、文字間の距離として、文字サイズSの10%としてもよいし、予め決めておいた定数であってもよい。
【0099】
ステップS517では、1ページ分の描画結果、すなわち<Page>要素内の<Image>および<Text>要素記述を描画したページ画像メモリの内容を、UI115の表示バッファに転送して表示させる。
【0100】
以下では、図6の電子文書の1ページ目の描画記述を例として、図5のフローチャートの処理を実行した場合を説明する。
【0101】
ステップS501の処理により、図6の1ページ目の<Page>要素602の属性値Width=“1680”、Height=“2376”に基づいて、ページの画像サイズを1680×2376ピクセルと決定する。
【0102】
ステップS502の処理により、例えば、ページ画像がRGB24bitカラーで表現される場合、1680×2376×3バイトのメモリが確保される。
【0103】
ステップS504の処理により、図6の<Image>要素603のData属性値に記述された圧縮のコードが展開されて画像になり、ページ画像メモリの全域に上書きされる。なお、本例では画像データは元のページと同サイズの1680×2376のピクセルの大きさを持っているので変倍処理は施されない。
【0104】
次に、ステップS505の処理により、図6の<Text>要素604から、X=“236”,Y=“272”,文字数N=“3”,文字フォントID=“Font01”,文字サイズ=“97”,文字色=“0,0,0,255”が得られる。
【0105】
ステップS509の処理により、まず最初は、<Text>要素604のString属性の1番目の文字コード=0x2422およびGlyphId=“1”が得られる。
【0106】
ステップS511でグリフの二値画像を生成するにあたって、まず、得られた文字フォントID=“Font01”に基づき、当該IDを有するグリフのPathデータをステップS510で取得する。ここでは、図6の例では、<Font>要素611内にある、<Glyph>要素のId=“1”のPath属性を取得する。そして、ステップS511において、当該取得した<Glyph>要素のId=“1”のPath属性のデータに基づいてグリフ画像を生成する。具体的には、Path属性の記述に従って、1024×896ピクセルの矩形領域すべてを1で塗りつぶした画像となる。つまり、グリフ画像生成用メモリとして確保した1024×1024の領域のうち、縦1024ピクセル、左端から横に896ピクセルで構成される長方形を1で塗りつぶすことにより、グリフ画像を生成する。
【0107】
ステップS512では、文字サイズ=“97”に基づいて、グリフ画像生成用メモリ1024×1024が97×97ピクセルに変倍される。したがって、塗りつぶされる領域は、縦97×横85ピクセル(変倍グリフ幅Wi=85)となる。
【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】
この<Text>要素605内の1番目の文字に対するグリフIDは“0”のため、ページ画像メモリの位置(236,472)から始まる92×92の領域が透明色で塗りつぶされている。そこで、ステップS515では、ページ画像メモリの位置(236,472)から始まる92×92の領域内の各画素値(r,g,b)を、(G(r),G(g),G(b))へと変更させる。
【0113】
また、例えば、図6の<Text>要素604内の1番目の文字コード(描画開始位置は(236,272)である)を描画した場合、ステップS516では、次の文字の描画開始位置Xとして、236+1.1×85=330が計算される。したがって、<Text>要素604内の2番目の文字コードの描画開始位置は、(330,272)となる。
【0114】
以上のようにして全<Text>を描画した後、ページ画像は図13のようになる。ステップS304で一致すると判定された範囲の文字に対応する領域に関しては、各矩形内で輝度が反転された状態となり、残りの文字に対応する領域は、<Image>要素が描画した画像データのままとなる。
【0115】
このように、検索した文字列が強調表示されるので、ページ内のどこに検索キーワードが存在するかを、ユーザはステップS306で表示されたページの画像を見るだけで容易に判断することができる。また、文字幅に合わせたグリフを用いて透明色で描画するため、検索時に強調される文字と文書画像内の当該文字画像との位置が合いやすくなり、ユーザは判別しやすくなる。
【0116】
図14は、別の方法で強調表示をおこなうように設定した場合、どのようにページ画像表示がなされるかの例を示している。図14(a)のページ描画記述では、フォントデータのグリフとして、文字高さ1024の下部の位置に、高さが128で幅が1024〜128の塗りつぶし矩形を描画する8種類のグリフを定義している。図4のステップS405で<Text>要素の属性データを記述する際、対応する文字画像の下部に相当する位置に、各グリフに対応する高さの低い矩形の透明文字が描画される。このようなページ描画記述に対し、ステップS515での強調処理において、各グリフの矩形範囲が反転強調されるようにすれば、図14(b)のように強調表示されたページ画像が生成される。このように、ユーザにとっては、検索した部分が下線(アンダーライン)を引かれて強調されているかのように見えることになり、ユーザは検索した文字列がページ内のどこに存在するかを容易に判断することができる。
【0117】
図3に戻って、ステップS307では、検索・閲覧処理を終了するか、あるいは更に別の検索箇所を対象に検索を継続するかどうかをユーザに選択させる。ユーザが終了を選択した場合は、図3の処理を終了し、継続を選択した場合はステップS308に進む。
【0118】
ステップS308では、n=n+kとし、ステップS304に戻って、次に検索キーワードと一致する部分を検索する。
【0119】
以上説明したように、本発明の実施形態1によれば、紙の文書が電子文書へと変換される際に、ページ画像上にページから抽出した文字が透明色で描画されるように記述される。この電子文書に対しては、検索キーワードに一致する箇所が強調表示されたページ表示を確認しながら検索を進めていくことが可能である。
【0120】
この電子文書は、いくつかの文字幅の異なる単純な字形(例えば矩形)からなるフォントデータを内部で持ち、文書内の様々な字種の透明文字を描画する際に、各字種の幅に適合する単純な字形を選択して描画するように記述している。つまり、多数の字種(例えば数百種類の字種)に対して、数種の字形(例えば8種の幅の異なる字形)を共通して利用するようにしている。また、透明テキストの描画位置を全ての文字に対して文字ごとに(文字の位置座標などを用いて)細かく記述しなくても、透明テキストの描画位置と文書画像内の各文字画像の位置とがほぼ合うようになる。したがって、電子文書内で使用されるフォントデータを当該電子文書内に保存しなければならないような場合であっても、電子文書のファイルサイズ(データ容量)を小さく抑えることができる。
【0121】
<実施形態2>
実施形態1では、図4のステップS405で<Text>要素のグリフIDの属性データを記述する際、各文字の幅情報と行高さとに基づいて、各文字に対応させるグリフを決定していたが、これに限るものではない。
【0122】
例えば、ステップS205の文字認識処理時に取得した各文字画像の位置情報を用いて、注目文字の左端から次の文字の左端までの間隔(文字送り幅)を求め、当該間隔と文字行高さとの比率に基づいて、グリフIDを選択するようにしてもよい。なお、各文字行の最後の文字についてはその文字の文字幅を前記間隔として用いる。なお、このようにした場合、前記間隔の方が文字行高さよりも大きくなるときがあるので、幅が高さよりも大きい矩形のグリフ(例えば、幅が1152や1280などのグリフ)も用意しておけばよい。また、このようにした場合、図5のステップS516では、次の文字の描画開始位置Xは、X=X+Wiで求められることになる。
【0123】
このように文字送り幅を基準としてグリフIDを選択するようにして生成した電子文書に対して、検索処理を行うと、図16のように、キーワードに一致する文字列内の文字間も含めて強調処理されることになる。
【0124】
このように、実施形態2においても、透明テキストの描画位置(文字の位置座標など)を全ての文字に対して文字ごとに細かくしなくても、透明テキストの描画位置と文書画像内の各文字画像の位置とがほぼ合うようになる。また、格納するグリフの総数は限られた数(例えば、10個)になるので、フォントデータのデータ量を抑えることができる。また、グリフの字形自体も単純化されて保存されているので、字形データ自体のデータ量も抑えることができる。
【0125】
<実施形態3>
上述した実施形態の図5のステップS516における次の文字の描画開始位置Xを決定するための別実施形態について述べる。
【0126】
上述した実施形態の図2のステップS205の文字認識処理で識別した各文字画像の位置の情報に基づいて、文字間距離の平均値を算出する。そして、図4のステップS405で<Text>要素を記述する際に、当該文字領域における文字間距離の平均値を属性データ(AvC)として記述しておく。そして、ステップS516では、その記述しておいた文字間距離平均値(AvC)を用いて、次の文字の描画開始位置を決定するようにしてもよい。この場合、次の文字の描画開始位置は、X=X+Wi+AvCとなる。
【0127】
<実施形態4>
また、上述した実施形態では、スキャン画像に対してJPEG圧縮等を行った全面イメージを<Image>要素に記述し、透明テキストを<Text>要素に記述した電子文書を生成することとしたが、これに限るものではない。
【0128】
例えば、<Image>要素に、スキャン画像全体をJPEG圧縮したものを記述する代わりに、文字領域や図領域は色別に2値画像を作成してMMR圧縮したもの、それ以外の領域はJPEG圧縮したものを格納するようにしてもよい。このように、文書画像に含まれる領域を解析して適応的に圧縮処理を行う方法は、例えば、特開平07−236062号公報や特開2002−077633号公報などに記載の方法を用いることができる。本発明の透明テキストを描画する際に用いるフォントデータのデータ量を抑える処理と、これらの画像圧縮処理とを組み合わせることで、更に高圧縮された電子文書を生成することが可能になる。
【0129】
また、全面イメージの代わりに、文字領域、図領域、表領域、写真領域などの部分領域だけを位置データとともに保存するようにしても構わない。
【0130】
<実施形態5>
上述した実施形態では、検索した結果に対応する個所を強調表示する際、画像の色(r,g,b)を反転することにより強調表示したが、使用する色はこれに限るものではない。例えば、検索結果を特定させるための予め決めた色(例えば黄色)を、半透明(例えばアルファチャネル128)で描画させるようにしてもよい。また、文字色(Cr,Cg,Cb)を利用して、強調色を決めるようにしてもよい。
【0131】
<実施形態6>
また、上述した実施形態では、図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】
上記課題を解決するために、本発明の画像処理装置は、文書画像内の複数の文字画像に対して文字認識処理を行うことにより、それぞれの文字画像に対応する文字コードを得る文字認識手段と、幅の異なる複数種類の字形データの中から、前記文書画像内の各文字画像の文字の幅に適合する字形データの種類を選択する選択手段と、前記文書画像と、前記文字認識手段で得た複数の文字コードと、前記複数の文字コードに対応する文字を描画する際に複数の異なる文字コードで共通利用させるための前記複数種類の字形データと、前記複数の文字コードの描画の際に使用する字形データの種類を示すデータとを格納した電子文書を生成する生成手段と、前記生成手段で生成した電子文書を、指定された送信先へ送信する送信手段と、を有し、前記電子文書に格納される、前記複数の文字コードの描画の際に使用する字形データの種類を示すデータは、前記文書画像内の各文字画像に対して前記選択手段で選択された字形データの種類に基づいて記述されることを特徴とする。
【0015】
または、上記課題を解決するために、本発明の画像処理装置は、文書画像内の複数の文字画像に対して文字認識処理を行うことにより、それぞれの文字画像に対応する文字コードを得る文字認識手段と、幅の異なる複数種類の字形データの中から、前記文書画像内の各文字画像の文字送り幅に適合する字形データの種類を選択する選択手段と、前記文書画像と、前記文字認識手段で得た複数の文字コードと、前記複数の文字コードに対応する文字を描画する際に複数の異なる文字コードで共通利用させるための前記複数種類の字形データと、前記複数の文字コードの描画の際に使用する字形データの種類を示すデータとを格納した電子文書を生成する生成手段と、前記生成手段で生成した電子文書を、指定された送信先へ送信する送信手段と、を有し、前記電子文書に格納される、前記複数の文字コードの描画の際に使用する字形データの種類を示すデータは、前記文書画像内の各文字画像に対して前記選択手段で選択された字形データの種類に基づいて記述されることを特徴とする。
【発明の効果】
【0016】
本発明によれば、幅の異なる複数の字形データの中から、文書画像内の各文字画像の文字の幅(あるいは文字送り幅)に適合する字形データの種類を選択しておくことで、テキストの描画位置と文書画像内の各文字画像の位置とが合うようにできる。また複数種類の字形データとして、幅の異なる単純な字形(例えば矩形)をいくつか用意しておき、様々な字種を描画する際、共通して利用するようにしている。よって、記述するデータの量が少なくて済む。ゆえに、フォントデータを電子文書内に保存しなければならないような場合であっても、電子文書のファイルサイズを小さく抑えることができる。
【図面の簡単な説明】
【0017】
【図1】実施形態1の構成例を表すブロック図
【図2】実施形態1の電子文書生成処理の例を表すフローチャート
【図3】実施形態1の電子文書検索・閲覧処理の例を表すフローチャート
【図4】図2のステップS208でおこなわれる電子文書データ生成処理の詳細を表すフローチャート
【図5】図3のステップS306でおこなわれるページの描画処理の詳細を表すフローチャート
【図6】実施形態1により生成される電子文書の例
【図7】処理対象のページ画像の例
【図8】領域分割処理結果の例
【図9】生成される領域データの例
【図10】文字認識処理時に文字画像を抽出する際の処理を示す例
【図11】文字認識結果で生成される文字コード列データの例
【図12】文字コード配列テーブルの例
【図13】検索結果が強調表示されたページ表示の例
【図14】別の強調表示処理で検索結果が強調表示されたページ表示の例
【図15】グリフID決定処理を示すフローチャートの例
【図16】実施形態2において、検索結果が強調表示されたページ表示の例
【発明を実施するための形態】
【0018】
<実施形態1>
図1は画像処理装置の構成を示すブロック図の一例である。
【0019】
画像処理装置100は本実施形態を実現するための装置であり、文書画像データを検索可能な電子文書に変換する。画像処理装置100は、スキャナ101、中央処理ユニット(CPU)102、メモリ103、ハードディスク104、ネットワークインタフェース105、ユーザインタフェース(UI)106で構成される。スキャナ101は紙文書の紙面情報を読み取り、文書画像データに変換を行う。CPU102は、画像データを解析して検索可能な電子文書へ変換するためのコンピュータプログラムなどを実行する処理部である。メモリ103は、該プログラムや処理中のデータを保持したり、CPUのワークスペースとして使用したりするための記憶媒体である。ハードディスク104は、該コンピュータプログラムや電子文書などのデータを格納するための大容量記憶媒体である。ネットワークインタフェース105は、ネットワーク120と接続するためのインタフェースであり、スキャン画像や前記変換された検索可能な電子文書などのデータを外部装置へ送信したり、外部装置からデータを受信したりするために使用される。ユーザインタフェース106は、ユーザからの指示を受け取るためのインタフェースであり、入力キーやタッチパネルなどの入力デバイスと、液晶などの表示デバイスから構成される。なお、本発明の装置の構成は、これに限るものではない。
【0020】
画像処理装置110は、画像処理装置100で作成された電子文書の検索や閲覧をおこなうことができる。CPU111は、電子文書を検索したり閲覧したりするための処理をおこなうためのコンピュータプログラムを実行する。メモリ112は、該プログラムを実行するためのワークスペースとして使用したり、データを一時保存したりするための記憶媒体である。ハードディスク113は、コンピュータプログラムや電子文書などのデータを格納するための大容量記憶媒体である。ネットワークインタフェース114は、外部装置から電子文書などのデータを受信したり、外部装置へデータを送信したりするためのインタフェースである。ユーザインタフェース115は、ユーザからの指示を受け取るためのインタフェースであり、入力キーやタッチパネルなどの入力デバイスと、液晶などの表示デバイスから構成される。
【0021】
次に、本実施形態1における処理を図2および図3のフローチャートを用いて説明する。
図2は、画像処理装置100が、紙文書をスキャンするなどして取得した画像データから検索可能な電子文書を生成し、画像処理装置110へ当該電子文書を送信する処理の例を示すフローチャートである。
【0022】
ステップS201では、ユーザからの指示操作にしたがって、生成される電子文書の送信先と送信方法を決定する。ユーザからの指示はユーザインタフェース106を介して行われる。また、送信方法は、例えば、電子メール、FTPを用いたファイル転送、などの選択肢から選択される。
【0023】
ユーザが紙文書をセットしてスタートキーを押下すると、ステップS202では、スキャナ101を用いて当該セットされた紙文書をスキャンして文書画像データを生成してメモリに保存する。なお、オートドキュメントフィーダなどを用いて、複数ページで構成される文書が入力された場合は、1ページ毎に1つのページ画像データへと変換され、入力順にメモリ103に保存されるものとする。
【0024】
図7にページ画像の例を示す。図7中のページ画像701には、「あ1A」という文字列702と、「かBc」という文字列703、および写真704が存在する。なお、説明のために、写真704を黒の矩形で簡略的に示しているが、実際には自然画である。また、図7の例では、文字列702,703と、写真704の例しか示していないが、その他に、図形等の領域があっても構わない。
【0025】
なお、ページ画像データの形式は、例えば、紙文書がカラーであれば、RGB各々8bitで階調を表現するカラー画像で扱い、紙文書が白黒であれば8bitで輝度を表現するグレー画像もしくは1bitで白黒を表現する二値画像で扱うものとする。
【0026】
ステップS203では、メモリ103に保存された未処理のページ画像データを、処理対象画像として選択する。なお、複数ページの画像がある場合は、入力順にしたがって1ページの画像を処理対象として選択する。
【0027】
ステップS204では、処理対象の画像を解析して、テキスト領域、図領域、写真領域、表領域などといった性質の異なる領域ごとに領域識別する領域解析処理を行い、識別された各領域に関する領域データを生成してメモリ103に保存する。ここで領域データには、各領域の外接矩形の左上位置座標(x,y座標値)と、該外接矩形のサイズ(幅と高さ)を表わす画素数の値と、当該判別された領域の種別とが含まれるものとする。なお、前記領域解析処理には、公知の技術(領域識別処理、領域判別処理、領域抽出処理などとも言う)を用いるものとする。例えば、特開平6−68301号公報に開示される技術を用いれば、二値化した文書画像データから、似たような大きさの黒画素塊が縦または横に連なる範囲をテキスト領域として抽出することができる。
【0028】
図7のページ画像701に対して領域解析処理を行った結果、図8のように、テキスト領域801、写真領域802とが識別される。図9は、その領域解析処理で得られた領域データの例である。
【0029】
ステップS205では、領域解析処理で識別された各テキスト領域内の文字画像に対して文字認識処理をおこなうことにより、各テキスト領域についての文字コード列のデータを得て、メモリ103に保存する。ここで、文字コード列のデータには、テキスト領域内に含まれる各文字画像に対する認識結果である文字コード情報と、各文字画像の外接矩形の情報(外接矩形の左上座標と幅と高さの情報、ならびに該文字が含まれる行の高さの情報)とが含まれるものとする。
【0030】
文字認識処理の一例を簡単に説明する。なお、文字画像を文字認識する処理は、公知の技術を利用することが可能である。
【0031】
まず、文書画像が二値画像でない場合はテキスト領域内を二値化するなどして、テキスト領域内の二値画像を得る。当該二値化された各テキスト領域内について、縦横のライン毎の黒画素数を計数してヒストグラムを作成する。縦横のヒストグラムに基づいて、周期的なヒストグラムになっている方向を行方向とし、ヒストグラムの黒画素数が所定の閾値以上になる部分を文字行を構成する部分として、短冊状の行画像を得る。次に、各行画像に対して、行方向と垂直な方向でヒストグラムをとり、ヒストグラムの結果に基づいて1文字ずつの画像を切り出す。この切り出された範囲が1文字の外接矩形情報となる。なお、ここでは、黒画素数を計数したヒストグラムを用いて判別を行ったが、各ラインに黒画素があるかないかを示す射影を用いて文字領域の判別を行うようにしてもよい。
【0032】
次に、各文字画像の外接矩形内の画像から、エッジ成分などを取り出して特徴ベクトルを得て、あらかじめ登録された文字認識用辞書内の特徴ベクトルと比較し、類似度を求める。そして、最も類似度の高い字種(文字種)のコードを、当該矩形内の文字画像に対する文字コードとする。このようにして、テキスト領域内に存在する全ての文字の外接矩形に対して、文字コードを割り当てたデータが得られる。そして、各テキスト領域から得た文字コード群が文字コード列となる。
【0033】
また、英文の文字領域に対しては、文字間に単語間スペースが存在するか否かの判定も行うこととする。例えば、文字間の距離が広いかどうかや、文字画像の文字認識結果の文字列と単語辞書とのマッチングを行って単語の切れ目であるかどうかなどを判別することにより、単語間スペースが存在するかどうか判定することができる。単語間スペースが存在すると判定した場合は、当該スペースの文字コードを文字コード列に挿入することになる。
【0034】
図10及び図11は、図8のテキスト領域801に対して文字認識処理を行った例を示す。図10中のテキスト領域1000から文字行1001と1002が先ず切り出される。そして、文字行1001内から1011,1012,1013の3文字が切り出されて、それぞれ認識処理が行われる。その結果、各文字に対応する文字コードが得られて、図11の1101に示したような文字コード列データが生成される。同様に、文字行1002内から切り出された1021,1022,1023の3文字にも文字認識処理が実行され、図11の1102に示したような文字コード列データが生成される。
【0035】
なお、上記説明は一例であって、他の公知の文字認識技術を利用した処理方法を用いて、文字コード列を取得してもよい。
【0036】
ステップS206では、当該処理対象となっているページ画像データと領域データと文字コード列データとを関連付けて、メモリ103もしくはハードディスク104に一時保存する。
【0037】
ステップS207では、未処理の画像データがあるかどうかを判定し、あればステップS203に戻り、次のページ画像データの処理を行う。なければ、ステップS208に進む。
【0038】
ステップS208では、メモリ103あるいはハードディスク104に保存された全ページ分のデータをページ順に合成して、複数ページからなる検索可能な電子文書を生成する。
【0039】
このステップS208で生成される電子文書のデータは、各ページ画像をディスプレイ等に電子的に表示あるいはプリンタにより印刷する為の描画情報と、検索キーワードで検索できるようにするための内容情報の両方を保持可能なデータである。そのような条件を満たすデータフォーマットとしては、PDF、SVGなどがあるが、本実施形態では、このとき生成される電子文書のフォーマットとして、フォントデータを埋め込むことが指定されていたとする。なお、フォントデータを埋め込むことが必須条件になっているフォーマット形式としては、例えば、XPSなどがある。以下では、XML表現を用いたページ記述フォーマットの仕様を仮定しながら説明するが、本発明はこのフォーマットに限るものではない。
【0040】
図6は、2ページ分のページ画像で構成される文書が入力された場合に、本説明で用いるページ記述フォーマットの仕様に基づいて生成された電子文書のページ記述例である。なお、ここでは、ページ記述フォーマットの例として、図6に示したように、1つのファイル内にまとめて記述するものとするが、これに限るものではない。例えば、フォントデータの部分を別ファイルにして、本体のファイルからフォントデータファイルを参照するようにし、それらをZIP圧縮等で1つの電子文書にまとめるようなフォーマット(例えば、XPS)でもよい。
【0041】
以下に、ステップS208にて行われる電子文書データ生成処理の例を、図4のフローチャートを用いて説明する。
【0042】
ステップS401では、電子文書の開始タグの記述を行う。本説明のページデータ記述フォーマット仕様では、<Document>という要素が電子文書の開始タグを表すものとする。なお、その<Document>の終了を示す</Document>までに挟まれた範囲のXML記述が、当該文書に含まれる各ページに関する記述データとなる。図6の例では601が電子文書の開始タグ、612が終了タグを表す。
【0043】
ステップS402では、未記述のページのうち、先頭ページに関するデータを特定して処理対象とする。
【0044】
ステップS403では、処理対象ページデータの開始を表わすタグを生成して記述する。本例では<Page>という要素タグがページデータの開始を表わし、その終了タグとなる</Page>までに挟まれた範囲のXML記述が、当該ページ内の描画データおよび内容データとなる。また、<Page>タグには、当該ページの画素幅と高さを示す属性WidthとHeight、ならびに解像度を示す属性Dpiを用いてページの物理的な大きさが記述され、また、ページ番号を示す属性Numberを用いてページ番号が記述される。
【0045】
図6の記述例では、<Page>要素の開始タグ602に、当該ページの幅Widthが“1680”、高さHeightが“2376”、解像度Dpiが“200”であり、ページ番号Numberが“1”であることが記述されている。また、当該1ページ目のデータは、終了タグ606までの間(603〜606)に記述されている。
【0046】
ステップS404では、ページを構成するデータのうち、画像の描画データを表わすタグを生成して記述する。
【0047】
本説明のページデータ記述フォーマット仕様では、1つの<Image>要素が1つの画像の描画データを表わすものとする。また、画像データの内容を属性Data内に記述し、その画像がページ内に描画される位置を属性X,Y,Width,Heightの座標情報で記述するものとする。ページ内に画像が複数ある場合は、各画像データを登場順に上へ重ね書きしていくことを意味する。なお、属性Data内には圧縮された画像データ形式で記述されるものとし、ここでは、圧縮方式として、カラー・グレーの場合はJPEG圧縮、二値の場合はMMR圧縮したコード列を用いるものとする。
【0048】
図6の記述例603では、文書の1ページ目のスキャン画像が全面にわたって描画されるようにしている。図6のタグ603では、画像の位置とサイズを「X=“0”、Y=“0”、Width=“1680”、Height=“2376”」として記述している。また、画像をJPEG圧縮して生成されたコード列の文字列を、属性Dataの値として記述している(なお、図6では、図を単純に示すため、Data属性の文字列を一部省略して示している)。このようにして、<Image>要素603が記述されている。なお、スキャン画像をJPEG圧縮して保存する前に、必要に応じて、解像度を変更して保存するようにしてもよい(例えば600dpiでスキャンした画像を300dpiに変更して保存してもよい)。
【0049】
ステップS405では、ページを構成するデータのうち、文字の描画データを表わす記述を生成する。
【0050】
本説明のページ記述フォーマット仕様では、1つの<Text>要素が1行分の文字の描画データを表わしている。また、<Text>要素内に記述される属性データは、Direction、X,Y、Font、Size、Color、String、CGlyphIdなどがある。ここで、属性Directionは、文字列が縦書きか横書きかを示し、Direction属性が記述されていない場合はデフォルトの方向(例えば、左から右に向かう水平方向)が使用される。また、属性X,Yは、文字の開始位置の座標を指定する。属性Fontは、文字コードを描画するためのフォントデータのIDを指定する。属性Sizeは、フォントサイズを指定する。また、属性Colorは、描画時の文字色を、R成分値,G成分値,B成分値、透過度を表すアルファチャネル値の4値組で指定する。また、属性Stringは、文字列の内容(文字コード列)を指定する。また、属性CGlyphIdは、String内の各文字が描画の際に使用する字形データすなわちグリフのIDを指定する。なお、Directionが指定されていない場合は、デフォルトで横書きとする。
【0051】
<Text>要素を構成する文字コード列は、図2のステップS205で生成された文字コード列のデータを、文字行毎、すなわち縦または横に連なる文字の集合に更に分割したものが使用される。
【0052】
図6の記述例では、2つの<Text>604および605は、1ページ目の文字描画記述に関するものであり、図11の文字コード列データ1101および1102それぞれに対応する記述である。例えば、図11の1101の3文字の横書き文字列「あ1A」に対応する<Text>要素604では、下記のような属性が指定されている。
【0053】
属性X,Yには、3文字分の外接矩形の左上座標としてX=“236”、Y=“272”が指定されている。
【0054】
フォントの種類を示す属性Fontには、“Font01”が指定されている。また、フォントサイズを示す属性Sizeには、当該文字行内の文字の高さから類推して“97”ピクセルが指定されている。描画時の文字色を示す属性Colorには、R成分値=G成分値=B成分値=0とアルファチャネル=255とが指定されている(つまり、透明色が指定されている)。
【0055】
また、文字列の内容(各文字に対応する文字コードの列)を示す属性Stringには、“0x2422,0x2332,0x2341”とが指定されている。
【0056】
属性CGlyphIdには、各文字の字形データとして用いるグリフのIDが指定される。ここでは、ステップS205で得た各文字の幅情報に基づきグリフのIDが指定されるものとする。なお、本実施形態では、スキャン画像上に透明色の文字の字形を描画するようにしているので、ユーザの視覚には見えていない。そこで、本実施形態では、字形データとして、文字画像の形状そのままの字形を用いるのではなく、単純な形状(例えば矩形)の字形データをいくつか(例えば8種類)用意しておき、その中から使用する字形データ(グリフのID)を選択して用いることとする。つまり、グリフとして、矩形幅のサイズが異なるグリフ(縦横比の異なるグリフ)を複数用意しておき、その中から文字毎に適したグリフを選択するように制御する。したがって、本実施形態では、文字が含まれている行の高さと各文字の文字幅との比に基づいて、グリフのIDが選択されるものとする。図15は、画像処理装置100が、各文字画像に対するグリフのIDを選択するためのフローチャートの例である。ステップS1501〜S1507では、(文字幅/行高さ)を、(7/8)、(6/8)、(5/8)、(4/8)、(3/8)、(2/8)、(1/8)と比較する。その比較結果に応じて、ステップS1508〜S1515のいずれかに進んで、グリフのID(0〜7)を選択する。すなわち、(文字幅/行高さ)>(7/8)であると判断された場合は、グリフID=0と選択される。(7/8)>=(文字幅/行高さ)>(6/8)であると判断された場合は、グリフID=1と選択される。(6/8)>=(文字幅/行高さ)>(5/8)であると判断された場合は、グリフID=2と選択される。(5/8)>=(文字幅/行高さ)>(4/8)であると判断された場合は、グリフID=3と選択される。(4/8)>=(文字幅/行高さ)>(3/8)であると判断された場合は、グリフID=4と選択される。(3/8)>=(文字幅/行高さ)>(2/8)であると判断された場合は、グリフID=5と選択される。(2/8)>=(文字幅/行高さ)>(1/8)であると判断された場合は、グリフID=6と選択される。(文字幅/行高さ)<=(1/8)であると判断された場合は、グリフID=7と選択される。なお、この例では、グリフIDの番号が小さい方が、より矩形幅が広いグリフになっている。例えば、図11の1101の文字列では、(文字幅/行高さ)がそれぞれ「0.82」、「0.14」、「0.57」であるので、図15の選択処理により、グリフのIDは、“1,6,3”と指定されることになる。なお、英文の単語間スペースに関しても同様に、スペースの幅を文字幅として扱うことにより、当該スペースが含まれている文字行の高さと当該スペースの幅との比に基づいて、グリフIDが選択される。なお、グリフの形状の詳細については、後述する。
【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は、左下を原点とする描画矩形単位内で、直線や曲線関数を用いてグリフを表現するように記述される。
【0063】
図6の記述例では、<Font>要素611において、Id=“Font01”のフォントが定義され、その中に、グリフId=“0”〜“7”のグリフが8種類定義されている。例えば、Id=“7”のグリフの字形を表わすPath属性“M0,0 V−1024 H128 V1024 f”は、「原点(0,0)にMOVE,上方向に1024単位縦線を描画、右方向に128単位横線描画、下方向に1024単位縦線描画、現在の点から開始点まで線を描画して囲まれた範囲を塗りつぶす」というグリフを記述している。すなわち、1024×128の矩形を塗りつぶした矩形のグリフを表現する記述となっている。そのほかのIDはそれぞれID=“7”を横方向に段階的に整数倍した長方形のグリフであり、例えば、ID=“0”は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”、“0x2332”、“0x2341”は、それぞれこの電子文書の先頭から数えて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の文字コード配列テーブルの例に対し、検索キーワード「かB」の文字コード列“0x242b”,“0x2342”を先頭から走査して一致する部分を探した場合、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)に則した大きさの矩形サイズになるよう変倍する。このとき、変倍後のグリフ二値画像の描画が行われる部分1の幅を、変倍グリフ幅Wiとして取得する。
【0093】
ステップS513では、ページ画像メモリ中の座標位置(X,Y)を基準とした矩形領域に、ステップS512で変倍されたグリフの二値画像を描画する。ページ画像上に二値画像を重ねて描画したときの各画素の画素値を以下の式で定義する。なお、グリフを描画する前のページ画像の各画素値(r,g,b)に対して、グリフを描画した後の画素値は(r’,g’,b’)になるものとする。
【0094】
グリフ二値画像の画素値が0に対応する画素:(r’,g’,b’)=(r,g,b)
グリフ二値画像の画素値が1に対応する画素:(r’,g’,b’)=(F(r,Cr),F(g,Cg),F(b,Cb))
ここで、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’)へと変更する。
【0097】
(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’)にそれぞれ変更するようにしてもよい。
【0098】
ステップS516では、次の文字の描画開始位置Xを決定し、nを1インクリメント(n=n+1)して、ステップS508に戻る。次の文字の描画開始位置Xは、現在の文字の描画開始位置に、変形グリフ幅Wiと文字間の距離とを加算したもので計算される。本実施形態では、データ容量が少なくて済むように、文字送り幅や文字間の距離などのデータを保存していないので、文字間の距離は変形グリフ幅の10%であると仮定して計算を行うこととする。したがって、ここでは、次の文字の描画開始位置は、X=X+1.1Wiで計算することとしている。なお、文字間の距離は、この計算に限るものではない。例えば、文字間の距離として、文字サイズSの10%としてもよいし、予め決めておいた定数であってもよい。
【0099】
ステップS517では、1ページ分の描画結果、すなわち<Page>要素内の<Image>および<Text>要素記述を描画したページ画像メモリの内容を、UI115の表示バッファに転送して表示させる。
【0100】
以下では、図6の電子文書の1ページ目の描画記述を例として、図5のフローチャートの処理を実行した場合を説明する。
【0101】
ステップS501の処理により、図6の1ページ目の<Page>要素602の属性値Width=“1680”、Height=“2376”に基づいて、ページの画像サイズを1680×2376ピクセルと決定する。
【0102】
ステップS502の処理により、例えば、ページ画像がRGB24bitカラーで表現される場合、1680×2376×3バイトのメモリが確保される。
【0103】
ステップS504の処理により、図6の<Image>要素603のData属性値に記述された圧縮のコードが展開されて画像になり、ページ画像メモリの全域に上書きされる。なお、本例では画像データは元のページと同サイズの1680×2376のピクセルの大きさを持っているので変倍処理は施されない。
【0104】
次に、ステップS505の処理により、図6の<Text>要素604から、X=“236”,Y=“272”,文字数N=“3”,文字フォントID=“Font01”,文字サイズ=“97”,文字色=“0,0,0,255”が得られる。
【0105】
ステップS509の処理により、まず最初は、<Text>要素604のString属性の1番目の文字コード=0x2422およびGlyphId=“1”が得られる。
【0106】
ステップS511でグリフの二値画像を生成するにあたって、まず、得られた文字フォントID=“Font01”に基づき、当該IDを有するグリフのPathデータをステップS510で取得する。ここでは、図6の例では、<Font>要素611内にある、<Glyph>要素のId=“1”のPath属性を取得する。そして、ステップS511において、当該取得した<Glyph>要素のId=“1”のPath属性のデータに基づいてグリフ画像を生成する。具体的には、Path属性の記述に従って、1024×896ピクセルの矩形領域すべてを1で塗りつぶした画像となる。つまり、グリフ画像生成用メモリとして確保した1024×1024の領域のうち、縦1024ピクセル、左端から横に896ピクセルで構成される長方形を1で塗りつぶすことにより、グリフ画像を生成する。
【0107】
ステップS512では、文字サイズ=“97”に基づいて、グリフ画像生成用メモリ1024×1024が97×97ピクセルに変倍される。したがって、塗りつぶされる領域は、縦97×横85ピクセル(変倍グリフ幅Wi=85)となる。
【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】
この<Text>要素605内の1番目の文字に対するグリフIDは“0”のため、ページ画像メモリの位置(236,472)から始まる92×92の領域が透明色で塗りつぶされている。そこで、ステップS515では、ページ画像メモリの位置(236,472)から始まる92×92の領域内の各画素値(r,g,b)を、(G(r),G(g),G(b))へと変更させる。
【0113】
また、例えば、図6の<Text>要素604内の1番目の文字コード(描画開始位置は(236,272)である)を描画した場合、ステップS516では、次の文字の描画開始位置Xとして、236+1.1×85=330が計算される。したがって、<Text>要素604内の2番目の文字コードの描画開始位置は、(330,272)となる。
【0114】
以上のようにして全<Text>を描画した後、ページ画像は図13のようになる。ステップS304で一致すると判定された範囲の文字に対応する領域に関しては、各矩形内で輝度が反転された状態となり、残りの文字に対応する領域は、<Image>要素が描画した画像データのままとなる。
【0115】
このように、検索した文字列が強調表示されるので、ページ内のどこに検索キーワードが存在するかを、ユーザはステップS306で表示されたページの画像を見るだけで容易に判断することができる。また、文字幅に合わせたグリフを用いて透明色で描画するため、検索時に強調される文字と文書画像内の当該文字画像との位置が合いやすくなり、ユーザは判別しやすくなる。
【0116】
図14は、別の方法で強調表示をおこなうように設定した場合、どのようにページ画像表示がなされるかの例を示している。図14(a)のページ描画記述では、フォントデータのグリフとして、文字高さ1024の下部の位置に、高さが128で幅が1024〜128の塗りつぶし矩形を描画する8種類のグリフを定義している。図4のステップS405で<Text>要素の属性データを記述する際、対応する文字画像の下部に相当する位置に、各グリフに対応する高さの低い矩形の透明文字が描画される。このようなページ描画記述に対し、ステップS515での強調処理において、各グリフの矩形範囲が反転強調されるようにすれば、図14(b)のように強調表示されたページ画像が生成される。このように、ユーザにとっては、検索した部分が下線(アンダーライン)を引かれて強調されているかのように見えることになり、ユーザは検索した文字列がページ内のどこに存在するかを容易に判断することができる。
【0117】
図3に戻って、ステップS307では、検索・閲覧処理を終了するか、あるいは更に別の検索箇所を対象に検索を継続するかどうかをユーザに選択させる。ユーザが終了を選択した場合は、図3の処理を終了し、継続を選択した場合はステップS308に進む。
【0118】
ステップS308では、n=n+kとし、ステップS304に戻って、次に検索キーワードと一致する部分を検索する。
【0119】
以上説明したように、本発明の実施形態1によれば、紙の文書が電子文書へと変換される際に、ページ画像上にページから抽出した文字が透明色で描画されるように記述される。この電子文書に対しては、検索キーワードに一致する箇所が強調表示されたページ表示を確認しながら検索を進めていくことが可能である。
【0120】
この電子文書は、いくつかの文字幅の異なる単純な字形(例えば矩形)からなるフォントデータを内部で持ち、文書内の様々な字種の透明文字を描画する際に、各字種の幅に適合する単純な字形を選択して描画するように記述している。つまり、多数の字種(例えば数百種類の字種)に対して、数種の字形(例えば8種の幅の異なる字形)を共通して利用するようにしている。また、透明テキストの描画位置を全ての文字に対して文字ごとに(文字の位置座標などを用いて)細かく記述しなくても、透明テキストの描画位置と文書画像内の各文字画像の位置とがほぼ合うようになる。したがって、電子文書内で使用されるフォントデータを当該電子文書内に保存しなければならないような場合であっても、電子文書のファイルサイズ(データ容量)を小さく抑えることができる。
【0121】
<実施形態2>
実施形態1では、図4のステップS405で<Text>要素のグリフIDの属性データを記述する際、各文字の幅情報と行高さとに基づいて、各文字に対応させるグリフを決定していたが、これに限るものではない。
【0122】
例えば、ステップS205の文字認識処理時に取得した各文字画像の位置情報を用いて、注目文字の左端から次の文字の左端までの間隔(文字送り幅)を求め、当該間隔と文字行高さとの比率に基づいて、グリフIDを選択するようにしてもよい。なお、各文字行の最後の文字についてはその文字の文字幅を前記間隔として用いる。なお、このようにした場合、前記間隔の方が文字行高さよりも大きくなるときがあるので、幅が高さよりも大きい矩形のグリフ(例えば、幅が1152や1280などのグリフ)も用意しておけばよい。また、このようにした場合、図5のステップS516では、次の文字の描画開始位置Xは、X=X+Wiで求められることになる。
【0123】
このように文字送り幅を基準としてグリフIDを選択するようにして生成した電子文書に対して、検索処理を行うと、図16のように、キーワードに一致する文字列内の文字間も含めて強調処理されることになる。
【0124】
このように、実施形態2においても、透明テキストの描画位置(文字の位置座標など)を全ての文字に対して文字ごとに細かくしなくても、透明テキストの描画位置と文書画像内の各文字画像の位置とがほぼ合うようになる。また、格納するグリフの総数は限られた数(例えば、10個)になるので、フォントデータのデータ量を抑えることができる。また、グリフの字形自体も単純化されて保存されているので、字形データ自体のデータ量も抑えることができる。
【0125】
<実施形態3>
上述した実施形態の図5のステップS516における次の文字の描画開始位置Xを決定するための別実施形態について述べる。
【0126】
上述した実施形態の図2のステップS205の文字認識処理で識別した各文字画像の位置の情報に基づいて、文字間距離の平均値を算出する。そして、図4のステップS405で<Text>要素を記述する際に、当該文字領域における文字間距離の平均値を属性データ(AvC)として記述しておく。そして、ステップS516では、その記述しておいた文字間距離平均値(AvC)を用いて、次の文字の描画開始位置を決定するようにしてもよい。この場合、次の文字の描画開始位置は、X=X+Wi+AvCとなる。
【0127】
<実施形態4>
また、上述した実施形態では、スキャン画像に対してJPEG圧縮等を行った全面イメージを<Image>要素に記述し、透明テキストを<Text>要素に記述した電子文書を生成することとしたが、これに限るものではない。
【0128】
例えば、<Image>要素に、スキャン画像全体をJPEG圧縮したものを記述する代わりに、文字領域や図領域は色別に2値画像を作成してMMR圧縮したもの、それ以外の領域はJPEG圧縮したものを格納するようにしてもよい。このように、文書画像に含まれる領域を解析して適応的に圧縮処理を行う方法は、例えば、特開平07−236062号公報や特開2002−077633号公報などに記載の方法を用いることができる。本発明の透明テキストを描画する際に用いるフォントデータのデータ量を抑える処理と、これらの画像圧縮処理とを組み合わせることで、更に高圧縮された電子文書を生成することが可能になる。
【0129】
また、全面イメージの代わりに、文字領域、図領域、表領域、写真領域などの部分領域だけを位置データとともに保存するようにしても構わない。
【0130】
<実施形態5>
上述した実施形態では、検索した結果に対応する個所を強調表示する際、画像の色(r,g,b)を反転することにより強調表示したが、使用する色はこれに限るものではない。例えば、検索結果を特定させるための予め決めた色(例えば黄色)を、半透明(例えばアルファチャネル128)で描画させるようにしてもよい。また、文字色(Cr,Cg,Cb)を利用して、強調色を決めるようにしてもよい。
【0131】
<実施形態6>
また、上述した実施形態では、図3及び図5で説明したように、検索を行う際は、キーワードに一致する文字列を文書の先頭から順に検索していき、最初に検索された文字列を強調表示した。そして、「次を検索」の指示があれば、順次、次に一致する文字列を検索して強調表示するように構成した。このように、上述した実施形態では、検索キーワードに一致する文字列を先頭から順に検索をおこない、検索キーワードがヒットするごとに順次強調表示を行っていたが、これに限るものではない。例えば、電子文書内に含まれる全ての文字列について、検索キーワードと比較を行い、全ての一致する文字列を特定し、そのキーワードに一致した全ての文字列を同時に強調表示するような構成にしてもよい。
【0132】
<その他の実施形態>
なお、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコード(コンピュータプログラム)を記憶した、コンピュータ読取可能な記憶媒体を、システムあるいは装置に供給することによっても達成される。また、システムあるいは装置のコンピュータ(またはCPUやMPU)が記憶媒体に格納されたプログラムコードを読出し実行することによっても達成される。
【0133】
本発明のコンピュータプログラムは、上述したフローチャートに記載した各ステップを装置に実行させることになる。言い換えると、このコンピュータプログラムは、フローチャートの各ステップに対応する各処理部(各処理手段)として、コンピュータを機能させるためのプログラムである。この場合、コンピュータ可読記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【0134】
プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、CD−ROM、CD−R、不揮発性のメモリカード、ROMなどを用いることができる。
【0135】
また、プログラムコードの指示に基づき、コンピュータ上で稼働しているOS(オペレーティングシステム)などが実際の処理の一部または全部を行い、その処理によって前述した実施形態が実現される場合も本発明に含まれることは言うまでもない。
【0136】
また、一方、上述した実施形態1,2では、CPUがメモリやハードディスク、表示デバイス等と協働して各フローチャートの各ステップを実行する形態について説明した。本発明は、上述した構成に限るものではなく、各フローチャートで説明した各ステップの処理の一部または全部を、CPUの代わりに専用の電子回路で構成するようにしても構わない。
【特許請求の範囲】
【請求項1】
文書画像内の複数の文字画像に対して文字認識処理を行うことにより、それぞれの文字画像に対応する文字コードを得る文字認識手段と、
幅の異なる複数種類の字形データの中から、前記文書画像内の各文字画像の文字の幅に適合する字形データの種類を選択する選択手段と、
前記文書画像と、前記文字認識手段で得た複数の文字コードと、前記複数の文字コードに対応する文字を描画する際に複数の異なる文字コードで共通利用させるための前記複数種類の字形データと、前記複数の文字コードの描画の際に使用する字形データの種類を示すデータとを格納した電子文書を生成する生成手段と、
前記生成手段で生成した電子文書を、指定された送信先へ送信する送信手段と、を有し、
前記電子文書に格納される、前記複数の文字コードの描画の際に使用する字形データの種類を示すデータは、前記文書画像内の各文字画像に対して前記選択手段で選択された字形データの種類に基づいて記述されることを特徴とする画像処理装置。
【請求項2】
文書画像内の複数の文字画像に対して文字認識処理を行うことにより、それぞれの文字画像に対応する文字コードを得る文字認識手段と、
幅の異なる複数種類の字形データの中から、前記文書画像内の各文字画像の文字送り幅に適合する字形データの種類を選択する選択手段と、
前記文書画像と、前記文字認識手段で得た複数の文字コードと、前記複数の文字コードに対応する文字を描画する際に複数の異なる文字コードで共通利用させるための前記複数種類の字形データと、前記複数の文字コードの描画の際に使用する字形データの種類を示すデータとを格納した電子文書を生成する生成手段と、
前記生成手段で生成した電子文書を、指定された送信先へ送信する送信手段と、を有し、
前記電子文書に格納される、前記複数の文字コードの描画の際に使用する字形データの種類を示すデータは、前記文書画像内の各文字画像に対して前記選択手段で選択された字形データの種類に基づいて記述されることを特徴とする画像処理装置。
【請求項3】
前記字形データは、矩形または三角または丸または直線のいずれかの形状を有する字形データであることを特徴とする請求項1または2のいずれかに記載の画像処理装置。
【請求項4】
前記字形データは、文字行の下部に描画を行う字形データであることを特徴とする請求項1または2のいずれかに記載の画像処理装置。
【請求項5】
前記生成手段は、文字間距離の平均値を更に格納させた前記電子文書を生成することを特徴とする請求項1に記載の画像処理装置。
【請求項6】
前記生成手段で生成された電子文書には、前記複数の文字コードに対応させた字形データを、前記文書画像内の各文字画像に重なる位置に透明色で描画させるための記述が含まれることを特徴とする請求項1乃至5のいずれかに記載の画像処理装置。
【請求項7】
前記電子文書は、XMLフォーマットまたはXPSフォーマットのいずれかで記述された電子文書であることを特徴とする請求項1乃至6のいずれかに記載の画像処理装置。
【請求項8】
前記画像処理装置は、前記文書画像を圧縮する圧縮手段を更に有し、
前記電子文書に格納される文書画像は、前記圧縮手段で圧縮処理が施された文書画像であることを特徴とする請求項1乃至7のいずれかに記載の画像処理装置。
【請求項9】
前記圧縮手段は、前記文書画像内に含まれる領域を解析して適応的に圧縮することを特徴とする請求項8に記載の画像処理装置。
【請求項10】
前記生成された電子文書に対して、入力されたキーワードで検索し、当該キーワードに一致する部分を強調表示させる検索手段を、更に有することを特徴とする請求項1乃至9のいずれかに記載の画像処理装置。
【請求項11】
前記検索手段は、前記キーワードに一致する部分の色を反転することにより強調表示させることを特徴とする請求項10に記載の画像処理装置。
【請求項12】
紙文書をスキャンして前記文書画像を生成するスキャナを更に有することを特徴とする請求項1乃至11のいずれかに記載の画像処理装置。
【請求項13】
文字認識手段が、文書画像内の複数の文字画像に対して文字認識処理を行うことにより、それぞれの文字画像に対応する文字コードを得る文字認識ステップと、
選択手段が、幅の異なる複数種類の字形データの中から、前記文書画像内の各文字画像の文字の幅に適合する字形データの種類を選択する選択ステップと、
生成手段が、前記文書画像と、前記文字認識ステップで得た複数の文字コードと、前記複数の文字コードに対応する文字を描画する際に複数の異なる文字コードで共通利用させるための前記複数種類の字形データと、前記複数の文字コードの描画の際に使用する字形データの種類を示すデータとを格納した電子文書を生成する生成ステップと、
送信手段が、前記生成ステップで生成した電子文書を、指定された送信先へ送信する送信ステップと、を有し、
前記電子文書に格納される、前記複数の文字コードの描画の際に使用する字形データの種類を示すデータは、前記文書画像内の各文字画像に対して前記選択ステップで選択された字形データの種類に基づいて記述されることを特徴とする画像処理方法。
【請求項14】
文字認識手段が、文書画像内の複数の文字画像に対して文字認識処理を行うことにより、それぞれの文字画像に対応する文字コードを得る文字認識ステップと、
選択手段が、幅の異なる複数種類の字形データの中から、前記文書画像内の各文字画像の文字送り幅に適合する字形データの種類を選択する選択ステップと、
生成手段が、前記文書画像と、前記文字認識ステップで得た複数の文字コードと、前記複数の文字コードに対応する文字を描画する際に複数の異なる文字コードで共通利用させるための前記複数種類の字形データと、前記複数の文字コードの描画の際に使用する字形データの種類を示すデータとを格納した電子文書を生成する生成ステップと、
送信手段が、前記生成ステップで生成した電子文書を、指定された送信先へ送信する送信ステップと、を有し、
前記電子文書に格納される、前記複数の文字コードの描画の際に使用する字形データの種類を示すデータは、前記文書画像内の各文字画像に対して前記選択ステップで選択された字形データの種類に基づいて記述されることを特徴とする画像処理方法。
【請求項15】
コンピュータを、
文書画像内の複数の文字画像に対して文字認識処理を行うことにより、それぞれの文字画像に対応する文字コードを得る文字認識手段、
幅の異なる複数種類の字形データの中から、前記文書画像内の各文字画像の文字の幅に適合する字形データの種類を選択する選択手段、
前記文書画像と、前記文字認識手段で得た複数の文字コードと、前記複数の文字コードに対応する文字を描画する際に複数の異なる文字コードで共通利用させるための前記複数種類の字形データと、前記複数の文字コードの描画の際に使用する字形データの種類を示すデータを格納した電子文書とを生成する生成手段、
前記生成手段で生成した電子文書を、指定された送信先へ送信するように制御する送信手段、
として機能させるための、コンピュータプログラムであって、
前記電子文書に格納される、前記複数の文字コードの描画の際に使用する字形データの種類を示すデータは、前記文書画像内の各文字画像に対して前記選択手段で選択された字形データの種類に基づいて記述されることを特徴とするコンピュータプログラム。
【請求項16】
コンピュータを、
文書画像内の複数の文字画像に対して文字認識処理を行うことにより、それぞれの文字画像に対応する文字コードを得る文字認識手段、
幅の異なる複数種類の字形データの中から、前記文書画像内の各文字画像の文字送り幅に適合する字形データの種類を選択する選択手段、
前記文書画像と、前記文字認識手段で得た複数の文字コードと、前記複数の文字コードに対応する文字を描画する際に複数の異なる文字コードで共通利用させるための前記複数種類の字形データと、前記複数の文字コードの描画の際に使用する字形データの種類を示すデータとを格納した電子文書を生成する生成手段、
前記生成手段で生成した電子文書を、指定された送信先へ送信するように制御する送信手段、
として機能させるための、コンピュータプログラムであって、
前記電子文書に格納される、前記複数の文字コードの描画の際に使用する字形データの種類を示すデータは、前記文書画像内の各文字画像に対して前記選択手段で選択された字形データの種類に基づいて記述されることを特徴とするコンピュータプログラム。
【請求項17】
請求項15または16のいずれかに記載のコンピュータプログラムを記憶した、コンピュータ読取可能な記憶媒体。
【請求項1】
文書画像内の複数の文字画像に対して文字認識処理を行うことにより、それぞれの文字画像に対応する文字コードを得る文字認識手段と、
幅の異なる複数種類の字形データの中から、前記文書画像内の各文字画像の文字の幅に適合する字形データの種類を選択する選択手段と、
前記文書画像と、前記文字認識手段で得た複数の文字コードと、前記複数の文字コードに対応する文字を描画する際に複数の異なる文字コードで共通利用させるための前記複数種類の字形データと、前記複数の文字コードの描画の際に使用する字形データの種類を示すデータとを格納した電子文書を生成する生成手段と、
前記生成手段で生成した電子文書を、指定された送信先へ送信する送信手段と、を有し、
前記電子文書に格納される、前記複数の文字コードの描画の際に使用する字形データの種類を示すデータは、前記文書画像内の各文字画像に対して前記選択手段で選択された字形データの種類に基づいて記述されることを特徴とする画像処理装置。
【請求項2】
文書画像内の複数の文字画像に対して文字認識処理を行うことにより、それぞれの文字画像に対応する文字コードを得る文字認識手段と、
幅の異なる複数種類の字形データの中から、前記文書画像内の各文字画像の文字送り幅に適合する字形データの種類を選択する選択手段と、
前記文書画像と、前記文字認識手段で得た複数の文字コードと、前記複数の文字コードに対応する文字を描画する際に複数の異なる文字コードで共通利用させるための前記複数種類の字形データと、前記複数の文字コードの描画の際に使用する字形データの種類を示すデータとを格納した電子文書を生成する生成手段と、
前記生成手段で生成した電子文書を、指定された送信先へ送信する送信手段と、を有し、
前記電子文書に格納される、前記複数の文字コードの描画の際に使用する字形データの種類を示すデータは、前記文書画像内の各文字画像に対して前記選択手段で選択された字形データの種類に基づいて記述されることを特徴とする画像処理装置。
【請求項3】
前記字形データは、矩形または三角または丸または直線のいずれかの形状を有する字形データであることを特徴とする請求項1または2のいずれかに記載の画像処理装置。
【請求項4】
前記字形データは、文字行の下部に描画を行う字形データであることを特徴とする請求項1または2のいずれかに記載の画像処理装置。
【請求項5】
前記生成手段は、文字間距離の平均値を更に格納させた前記電子文書を生成することを特徴とする請求項1に記載の画像処理装置。
【請求項6】
前記生成手段で生成された電子文書には、前記複数の文字コードに対応させた字形データを、前記文書画像内の各文字画像に重なる位置に透明色で描画させるための記述が含まれることを特徴とする請求項1乃至5のいずれかに記載の画像処理装置。
【請求項7】
前記電子文書は、XMLフォーマットまたはXPSフォーマットのいずれかで記述された電子文書であることを特徴とする請求項1乃至6のいずれかに記載の画像処理装置。
【請求項8】
前記画像処理装置は、前記文書画像を圧縮する圧縮手段を更に有し、
前記電子文書に格納される文書画像は、前記圧縮手段で圧縮処理が施された文書画像であることを特徴とする請求項1乃至7のいずれかに記載の画像処理装置。
【請求項9】
前記圧縮手段は、前記文書画像内に含まれる領域を解析して適応的に圧縮することを特徴とする請求項8に記載の画像処理装置。
【請求項10】
前記生成された電子文書に対して、入力されたキーワードで検索し、当該キーワードに一致する部分を強調表示させる検索手段を、更に有することを特徴とする請求項1乃至9のいずれかに記載の画像処理装置。
【請求項11】
前記検索手段は、前記キーワードに一致する部分の色を反転することにより強調表示させることを特徴とする請求項10に記載の画像処理装置。
【請求項12】
紙文書をスキャンして前記文書画像を生成するスキャナを更に有することを特徴とする請求項1乃至11のいずれかに記載の画像処理装置。
【請求項13】
文字認識手段が、文書画像内の複数の文字画像に対して文字認識処理を行うことにより、それぞれの文字画像に対応する文字コードを得る文字認識ステップと、
選択手段が、幅の異なる複数種類の字形データの中から、前記文書画像内の各文字画像の文字の幅に適合する字形データの種類を選択する選択ステップと、
生成手段が、前記文書画像と、前記文字認識ステップで得た複数の文字コードと、前記複数の文字コードに対応する文字を描画する際に複数の異なる文字コードで共通利用させるための前記複数種類の字形データと、前記複数の文字コードの描画の際に使用する字形データの種類を示すデータとを格納した電子文書を生成する生成ステップと、
送信手段が、前記生成ステップで生成した電子文書を、指定された送信先へ送信する送信ステップと、を有し、
前記電子文書に格納される、前記複数の文字コードの描画の際に使用する字形データの種類を示すデータは、前記文書画像内の各文字画像に対して前記選択ステップで選択された字形データの種類に基づいて記述されることを特徴とする画像処理方法。
【請求項14】
文字認識手段が、文書画像内の複数の文字画像に対して文字認識処理を行うことにより、それぞれの文字画像に対応する文字コードを得る文字認識ステップと、
選択手段が、幅の異なる複数種類の字形データの中から、前記文書画像内の各文字画像の文字送り幅に適合する字形データの種類を選択する選択ステップと、
生成手段が、前記文書画像と、前記文字認識ステップで得た複数の文字コードと、前記複数の文字コードに対応する文字を描画する際に複数の異なる文字コードで共通利用させるための前記複数種類の字形データと、前記複数の文字コードの描画の際に使用する字形データの種類を示すデータとを格納した電子文書を生成する生成ステップと、
送信手段が、前記生成ステップで生成した電子文書を、指定された送信先へ送信する送信ステップと、を有し、
前記電子文書に格納される、前記複数の文字コードの描画の際に使用する字形データの種類を示すデータは、前記文書画像内の各文字画像に対して前記選択ステップで選択された字形データの種類に基づいて記述されることを特徴とする画像処理方法。
【請求項15】
コンピュータを、
文書画像内の複数の文字画像に対して文字認識処理を行うことにより、それぞれの文字画像に対応する文字コードを得る文字認識手段、
幅の異なる複数種類の字形データの中から、前記文書画像内の各文字画像の文字の幅に適合する字形データの種類を選択する選択手段、
前記文書画像と、前記文字認識手段で得た複数の文字コードと、前記複数の文字コードに対応する文字を描画する際に複数の異なる文字コードで共通利用させるための前記複数種類の字形データと、前記複数の文字コードの描画の際に使用する字形データの種類を示すデータを格納した電子文書とを生成する生成手段、
前記生成手段で生成した電子文書を、指定された送信先へ送信するように制御する送信手段、
として機能させるための、コンピュータプログラムであって、
前記電子文書に格納される、前記複数の文字コードの描画の際に使用する字形データの種類を示すデータは、前記文書画像内の各文字画像に対して前記選択手段で選択された字形データの種類に基づいて記述されることを特徴とするコンピュータプログラム。
【請求項16】
コンピュータを、
文書画像内の複数の文字画像に対して文字認識処理を行うことにより、それぞれの文字画像に対応する文字コードを得る文字認識手段、
幅の異なる複数種類の字形データの中から、前記文書画像内の各文字画像の文字送り幅に適合する字形データの種類を選択する選択手段、
前記文書画像と、前記文字認識手段で得た複数の文字コードと、前記複数の文字コードに対応する文字を描画する際に複数の異なる文字コードで共通利用させるための前記複数種類の字形データと、前記複数の文字コードの描画の際に使用する字形データの種類を示すデータとを格納した電子文書を生成する生成手段、
前記生成手段で生成した電子文書を、指定された送信先へ送信するように制御する送信手段、
として機能させるための、コンピュータプログラムであって、
前記電子文書に格納される、前記複数の文字コードの描画の際に使用する字形データの種類を示すデータは、前記文書画像内の各文字画像に対して前記選択手段で選択された字形データの種類に基づいて記述されることを特徴とするコンピュータプログラム。
【請求項17】
請求項15または16のいずれかに記載のコンピュータプログラムを記憶した、コンピュータ読取可能な記憶媒体。
【図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】
【公開番号】特開2011−40075(P2011−40075A)
【公開日】平成23年2月24日(2011.2.24)
【国際特許分類】
【出願番号】特願2010−193846(P2010−193846)
【出願日】平成22年8月31日(2010.8.31)
【分割の表示】特願2007−172737(P2007−172737)の分割
【原出願日】平成19年6月29日(2007.6.29)
【出願人】(000001007)キヤノン株式会社 (59,756)
【Fターム(参考)】
【公開日】平成23年2月24日(2011.2.24)
【国際特許分類】
【出願日】平成22年8月31日(2010.8.31)
【分割の表示】特願2007−172737(P2007−172737)の分割
【原出願日】平成19年6月29日(2007.6.29)
【出願人】(000001007)キヤノン株式会社 (59,756)
【Fターム(参考)】
[ Back to top ]