Skip to main content
To detect single-line fields, FlexiLayout Studio has a special Character String element. If the sought field has a known format, then it can be described in the properties of the corresponding element on the Character String tab in the Regular expression field. However, the use of a regular expression requires printed documents and good image quality, because a regular expression does not permit any errors in the field; otherwise, the element simply will not be detected. Regular expressions also must not be used if the document is filled in by hand, even if its layout can be described. Nevertheless, such a field can be detected.

​
The StructuredStrings.fsp sample project

The search for a single-line field “Invoice number” with a similar format on all the pages is shown in the sample project StructuredStrings.fsp (folder %public%\ABBYY\FlexiCapture\12.0\Samples\FLS\Tips and Tricks\Structured strings). The project has four pages:
  • Pages 1 and 2: The field “Invoice number” is filled in by means of a printer, and the printing quality is good.
  • Page 3: The field “Invoice number” is filled in by means of a printer, but the image is noisy.
  • Page 4: The image quality is good, but the field “Invoice number” is filled in by hand.
Screenshot of invoice page 1 with the Invoice number field printed at good qualityScreenshot of invoice page 2 with the Invoice number field printed at good quality
Screenshot of invoice page 3 with the printed Invoice number field on a noisy imageScreenshot of invoice page 4 with the Invoice number field filled in by hand

​
Describe the invoice number with a regular expression

The search for the field “Invoice number” relies on the field name. First, an element describing the search constraints of the field name is needed. In the project, this is a Static Text element named InvoiceNumberHeader with the value “InvoiceN:”. The field “Invoice number” is a single-line field. To detect it, the project uses a Character String element named NumAsRegularExpression. As the pages of the project show, the format of the field “Invoice number” can be described with the following regular expression: 
NNNN"-"NN"-"[A-Z]"/"NN
or (which is the same) 
[0-9]{4}"-"[0-9]{2}"-"[A-Z]"/" [0-9]{2}
It means that the number is a sequence: “four digits - two digits - one Latin capital letter/two digits”. As the project shows, after running the FlexiLayout matching procedure by selecting the Match command, null hypotheses were generated for the NumAsRegularExpression element on pages 3 and 4, that is, the element was not detected. On page 3, the noise caused a mismatch of the field and the regular expression. If you open Page 3 and click “L” (“Show Recognized Lines”) on the toolbar, the pre-recognition of the invoice number on the page will look like “10&0-20-A/04”. On Page 4, the invoice number is filled in by hand. You can see in the results of pre-recognition (Z.OOO-41-C/03) that it does not match the described format either.

​
Add a fallback Character String element with an alphabet

The recommended solution to this problem is as follows. Create one more Character String element and name it NumAsAlphabet. Specify for it the same search constraints as for the NumAsRegularExpression element. Then group the two elements into one Group element, InvoiceNumber. However, describe the NumAsAlphabet element not as a regular expression but as a list of all valid characters.
Screenshot of the Edit Alphabet dialog box in ABBYY FlexiLayout Studio listing all valid characters for the NumAsAlphabet element.
The following code should be written in the Advanced pre-search relations field: 
if (NumAsRegularExpression.IsNull == FALSE) then Dontfind();
This means that the search for a string of an unknown format, described by the NumAsAlphabet element, will be attempted only if the program fails to detect it by means of the NumAsRegularExpression element, which describes a string of fixed format.
When specifying search constraints for the NumAsAlphabet element, you can use drag-and-drop to copy the settings from the Relations section of the NumAsRegularExpression element into the same section of the current element. Alternatively, the following code can be written in the Advanced pre-search relations field:
if (NumAsRegularExpression.IsNull == FALSE) then Dontfind();
else RestrictSearchArea (NumAsRegularExpression.Rect);
This code means that a search for the NumAsAlphabet element will be attempted only if the structure of the invoice number does not match the specified format, that is, the program failed to detect the NumAsRegularExpression element. The NumAsAlphabet element will then be looked for in the same area where the NumAsRegularExpression element was not found. Now run the FlexiLayout matching procedure again on all the pages. As the project shows, the invoice number field is now successfully found on each of the pages. The project tree contains a text block named InvoiceNum. The group SearchElements.InvoiceNumber is specified as its Source element. At this stage, the creation of a FlexiLayout to detect “Invoice number” fields is complete.
If, for some reason, the method described earlier is not sufficient for detecting the data field (whether its format is known or unknown), one more element (of type Object Collection) can be created in the group. In this project, it is an Object Collection element named NumAsObjectCollection.It is not actually needed given the good quality of the images in this project and is only shown as an example (the Disable command is specified for it).An additional Object Collection element might be needed when it is difficult to predict pre-recognition results on different pages, but the search area can be accurately described, preventing unwanted information from getting into the hypotheses.

​
Why the regular expression improves reliability

The following question may arise: why is a regular expression needed if the field can sometimes be detected without it? The answer is that the use of a regular expression makes the search more reliable. If this element is found, then you can be sure that you have found the very line that you need. This information can then be safely used to detect further elements and their relations. When the search constraints are lax, you cannot be absolutely sure that you have found exactly what you need. This may happen if the image is very noisy. In such cases, the use of a Character String element with a specified alphabet can lead to an excessive percentage of errors (the Percentage of non-alphabet characters parameter). As a result, the element will either not be detected at all or be detected only partially. The following figure shows an example of such a situation.
Screenshot in ABBYY FlexiLayout Studio of a noisy image where a Character String element with a specified alphabet detects the invoice number field only partially because of the excessive percentage of non-alphabet characters.