メインコンテンツへスキップ
ドキュメント、テーブル、field のさまざまなタイトルや、ドキュメント内のすべてまたは大半の画像に含まれる任意のテキストを検出するために、FlexiLayout Studio では特別な Static Text 要素を使用します。同じ FlexiLayout で処理する画像ごとに同じ名前の表記ゆれがある場合 (たとえば、field「Invoice number」には「Invoice」、「Invoice:」、「Invoice No.」などのバリエーションがある場合) 、句読点だけの違いであっても、考えられる static text の値をすべて指定する必要があります。 これは、次の理由から必要です。
  1. 指定した値に対応する仮説を生成するためです。たとえば、「Invoice:」という候補を指定せず、「Invoice」だけを指定した場合、コロンは field 名の仮説に含まれません。すると、そのコロンが、プログラムが名前の右側で検索する請求書番号の検索領域に含まれてしまう可能性があります。番号の検索で数字以外の文字や未指定の文字が許可されている場合、そのコロンが請求書番号を表す要素の仮説に入り込むことがあります。
  2. Search text ウィンドウで指定していない文字によって仮説が減点されるのを防ぐためです。たとえば、Search text セクションで「Invoice:」を指定していて、処理対象の画像に「Invoice#」という名前も存在する場合、その要素である程度の誤りが許可されていれば仮説は生成されますが、その品質は減点されます (この例では、FlexiLayout で少なくとも 1 つの誤りが許可されています) 。
  3. たとえば「Invoice|Invoice:」のように候補仮説がある場合、プログラムは長い方の仮説にわずかに高い品質を割り当てるため、「Invoice:」の仮説が優先されます。「:」を含む候補が指定されている場合、「Invoice」は「Invoice:」の部分文字列であるため、「:」を含まない方は 0.001 減点されます。もう一方の部分文字列である短い名前文字列を減点することで、長い仮説が winner になります。
Static Text 要素の値を指定することで、「Invoice number」field の名前と field 自体の検出にどのように役立つかを確認するため、サンプルプロジェクト StaticText.fsp (フォルダー %public%\ABBYY\FlexiCapture\12.0\Samples\FLS\Tips and Tricks\Variants of StaticText) を使用してみましょう。 このプロジェクトには 5 ページあります。
  • ページ 1 - 「Invoice number」field の名前は「INVOICE」です。
  • ページ 2 – 「Invoice number」field の名前は「Invoice:」です。
  • ページ 3 – 「Invoice number」field の名前は「Invoice #:」です。
  • ページ 4 – 「Invoice number」field の名前は「Invoice -」です。
  • ページ 5 – 「Invoice number」field の名前は「Invoice:」ですが、このページには「Invoice date」field もあり、そこにも「Invoice」という単語が含まれています。
InvoiceHeader という名前の Static Text 要素の Properties ダイアログでは、処理対象ドキュメント上で見つかる可能性がある field 名をすべて指定しています。この場合は、前述の値です。検索では、名前の大文字と小文字は区別されません: Invoice|Invoice:|Invoice#:|Invoice-。
要素の検索を高速化するため、すべての候補はスペースを入れずに記述しています。スペースの有無は仮説の品質に影響しません。
簡単のため、請求書番号は常に名前の右側にあるものとします。請求書番号を検索するために、InvoiceNumber という名前の Character String 要素を作成しています。その alphabet と search constraints は Relations field で指定されています。これらの設定は非常に単純なため、ここでは説明しません。詳細はプロジェクト内で直接確認できます。 FlexiLayout ツリーには Invoice というテキストブロックが作成されています。このブロックの Source 要素として InvoiceNumber 要素が指定されています。 解析手順を実行するとわかるように、field 名と請求書番号はすべてのページで正しく検出できます。 次に、InvoiceHeader 要素から最初の (Invoice) を除くすべての Static Text の値を一時的に削除し、その後、もう一度すべてのページに対して FlexiLayout のマッチングを試してください。名前と請求書番号が正常に検出されたのはページ 1 だけであることがわかります。これは、ページ 1 では名前が指定した値 (Invoice) と完全に一致しているためです。ページ 2～4 では、名前の一部が請求書番号に入り込んでしまいました。ページ 5 では、番号 field の位置特定でエラーが発生しました。 それでは、削除した値を元に戻してみましょう。Invoice という単語が 2 回出現しているページ 5 の解析結果を見てください。ご覧のとおり、プログラムは InvoiceHeader 要素に対して 5 つの仮説を生成しました。最も高い品質 (Chain quality = 1。この場合、これは Pre-search quality と同じです) は、“Invoice:” という名前に対する仮説に割り当てられています。“Invoice” および “Invoice d” という値についても仮説が生成されました。これは、これらの文字列が InvoiceHeader 要素に指定された値の派生形であり、そこでは一定割合の誤りが許容されているためです。これらの仮説にはペナルティが課されているため (考えられるすべての Static Text の値を列挙することについては、上記の説明を参照してください) 、最終的な品質は低くなっています。