Skip to main content
単一行fieldを検出するために、FlexiLayout Studio には専用の Character String 要素があります。fieldの形式が既知であれば、要素のプロパティで、Character String タブの Regular expression field にその形式を記述できます。 ただし、正規表現を使用するには、印字文書であり、かつ画質が良好であることが必要です。というのも、正規表現による記述ではfield内の誤りを許容できないため、少しでも誤りがあると要素は検出されないからです。 また、文書のlayoutを記述できる場合でも、手書きで記入された文書に正規表現を使用してはいけません。それでも、そのようなfieldを検出することは可能です。

​
StructuredStrings.fsp サンプルプロジェクト

サンプルプロジェクト StructuredStrings.fsp では、すべてのページで類似した形式を持つ単一行field「請求書番号」を検索する方法を示しています (フォルダー %public%\ABBYY\FlexiCapture\12.0\Samples\FLS\Tips and Tricks\Structured strings)。 このプロジェクトには4つのページがあります。
  • 1ページ目と2ページ目 – field「請求書番号」は高品質で印字されています。
  • 3ページ目 – field「請求書番号」は印字されていますが、画像にノイズがあります。
  • 4ページ目 – 画質は良好ですが、field「請求書番号」は手書きで記入されています。

​
正規表現で請求書番号を記述する

field名を手がかりに 請求書番号 fieldを探します。まず、field名の検索条件を記述する要素が必要です。プロジェクトでは、これは Static Text 要素で、名前は InvoiceNumberHeader、値は InvoiceN: です。 請求書番号 fieldは単一行fieldです。これを検出するために、プロジェクトでは Character String 要素 NumAsRegularExpression を使用します。プロジェクトのページを見ると、請求書番号 fieldの形式は次の正規表現で記述できます。
または (同じ意味ですが)
これは、その番号が「4桁の数字 - 2桁の数字 - 1つのラテン大文字/2桁の数字」という並びであることを意味します。 プロジェクトを見ると、Match コマンドを選択して FlexiLayout のマッチング手順を実行した後、3ページ目と4ページ目では要素 NumAsRegularExpression に対して null 仮説が生成され、つまり要素は検出されませんでした。 3ページ目では、ノイズによってfieldと正規表現の間に不一致が生じました。3ページ目を開いてツールバーの L (Show Recognized Lines) をクリックすると、そのページ上の請求書番号の事前認識結果は 10&0-20-A/04 のように表示されます。 4ページ目では、請求書番号は手書きで記入されています。事前認識結果 (Z.OOO-41-C/03) も、記述された形式に一致していません。

​
アルファベットを使用したフォールバック用の Character String 要素 を追加する

推奨される解決策は次のとおりです。Character String 要素 をもう 1 つ作成し、NumAsAlphabet という名前を付けます。この 要素 には、NumAsRegularExpression 要素 と同じ 検索条件 を指定します。次に、この 2 つの 要素 を 1 つの Group 要素 InvoiceNumber にまとめます。 ただし、NumAsAlphabet 要素 は 正規表現 としてではなく、有効な文字をすべて列挙したリストとして記述します。
NumAsAlphabet 要素に対して有効なすべての文字が一覧表示された、ABBYY FlexiLayout Studio の Edit Alphabet ダイアログのスクリーンショット。
次のコードを Advanced pre-search relations field に記述します。
これは、NumAsAlphabet 要素で記述された形式不明の文字列の検索は、固定形式の文字列を記述する NumAsRegularExpression 要素で FlexiLayout Studio が検出できなかった場合にのみ実行されることを意味します。
NumAsAlphabet 要素の検索条件を指定する際は、ドラッグアンドドロップを使用して、NumAsRegularExpression 要素の Relations セクションの設定を現在の要素の同じセクションにコピーできます。あるいは、Advanced pre-search relations field に次のコードを記述することもできます。
このコードは、請求書番号の構造が指定した形式に一致せず、つまり FlexiLayout Studio が NumAsRegularExpression 要素を検出できなかった場合にのみ、NumAsAlphabet 要素の検索が実行されることを意味します。続いて、NumAsRegularExpression 要素が見つからなかったのと同じ領域で NumAsAlphabet 要素が検索されます。 次に、すべてのページで FlexiLayout マッチングを再度実行します。プロジェクトに示されているとおり、請求書番号 field は各ページで正常に見つかるようになりました。 プロジェクトツリーには、InvoiceNum という名前のテキストブロックがあります。その ソース要素 として、グループ SearchElements.InvoiceNumber が指定されています。この段階で、請求書番号 fields を検出するための FlexiLayout は完成です。
何らかの理由で、前述のメソッドだけではデータfield (形式が既知か未知かを問わず) の検出に不十分な場合は、グループ内にもう 1 つ要素 (型は Object Collection) を作成できます。このプロジェクトでは、これは NumAsObjectCollection という名前の Object Collection 要素です。このプロジェクトでは画像の品質が良いため、これは実際には不要で、単なる例として示しているだけです (これには Disable コマンドが指定されています) 。追加の Object Collection 要素が必要になるのは、ページごとの事前認識結果の予測は難しくても、検索領域は正確に記述でき、不要な情報が仮説に入り込むのを防げる場合です。

​
正規表現が信頼性を向上させる理由

ここで、次のような疑問が生じるかもしれません。field が場合によってはそれなしでも検出できるのに、なぜ正規表現が必要なのでしょうか。答えは、正規表現を使うことで検索の信頼性が高まるからです。 この要素が見つかれば、必要なその行を見つけたと確信できます。この情報は、その後の要素やそれらのリレーションを検出するために安心して使用できます。検索条件が緩い場合は、必要なものを正確に見つけたと完全に確信することはできません。 これは、画像にノイズが非常に多い場合に起こることがあります。そのような場合、指定されたアルファベットを持つ Character String 要素を使用すると、エラー率 (Percentage of non-alphabet characters parameter) が高くなりすぎることがあります。 その結果、要素はまったく検出されないか、一部しか検出されません。そのような状況の例を次の図に示します。
ABBYY FlexiLayout Studio のスクリーンショット。ノイズの多い画像で、指定されたアルファベットを持つ Character String 要素が、アルファベット以外の文字の割合が高すぎるため、請求書番号 field を部分的にしか検出できていません。