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