Zum Hauptinhalt springen
Verwenden Sie diese Methode, wenn Sie dieselben umfangreichen Suchbedingungen für mehrere Elemente prüfen müssen. Die Grundidee besteht darin, dass die Bedingungen geprüft und die Berechnungen nur einmal in einem Hilfselement durchgeführt werden. Je nach Ergebnis dieser Prüfung wird nach dem betreffenden Element entweder gesucht oder nicht; die gefundene bzw. nicht gefundene Hypothese dient also als Marker, der signalisiert, ob die Bedingungen erfüllt sind.

​
Wie das Dummy-Element signalisiert, dass die Bedingungen erfüllt sind

Dieses Hilfselement wird so erstellt, dass es auf den Bildern immer etwas finden kann, sofern die Funktion DontFind() (also „die Suche beenden“) nicht aktiviert ist. Die Anzahl der Hypothesen sollte nicht zu groß sein, damit der Hypothesenbaum nicht unnötig aufgebläht und die Zeit für den Abgleich des FlexiLayouts nicht erhöht wird. Um dies zu erreichen, können Sie beispielsweise Elemente der Typen Object Collection oder Paragraph verwenden. Diese Elemente erzeugen immer genau eine Hypothese, die alle Objekte des angegebenen Typs aus dem Suchbereich umfasst. Der Abschnitt Advanced pre-search relations des Dummy-Elements enthält die Bedingungen zur Prüfung einiger Elemente, die sich im Projektbaum unterhalb des Dummy-Elements befinden. Wenn alle Bedingungen erfüllt sind, wird für das Dummy-Element die Funktion DontFind() aufgerufen. In diesem Fall wird für das Dummy-Element eine Nullhypothese erzeugt. Sie dient dann als Marker dafür, dass alle Bedingungen erfüllt sind, wenn FlexiLayout Studio mit der Suche nach anderen Elementen beginnt. Dadurch wird FlexiLayout Studio mitgeteilt, dass nur die IsNull-Prüfung des Dummy-Elements ausgeführt werden soll, anstatt dieselben umfangreichen Bedingungen für mehrere Elemente zu prüfen.
Diese Methode trägt dazu bei, den Code aussagekräftiger zu machen. Wenn Sie die Bedingungen bearbeiten müssen, können Sie dies außerdem nur in der Beschreibung des Dummy-Elements tun. Das verringert die Wahrscheinlichkeit logischer und syntaktischer Fehler beim Duplizieren des Codes.
Für künftige Versionen des Produkts ist geplant, die Erstellung von Variablen im Bereich der Subelemente von Gruppen zu unterstützen. Die Ergebnisse der Prüfung der Bedingungen werden dann in den Werten verschiedener Variablen gespeichert.Die aktuelle Methode ist eine vorübergehende Lösung (Workaround), die dabei hilft, den Code in den Advanced-Abschnitten in der aktuellen Version von FlexiLayout Studio zu vereinfachen.

​
Die beiden Rechnungslayouts im Beispielprojekt

Das Project 1.fsp (Ordner %public%\ABBYY\FlexiCapture\12.0\Samples\FLS\Tips and Tricks\Auxiliary element) zeigt, wie diese Methode funktioniert. Auf diesen Bildern sollen die folgenden Felder gefunden werden: „Rechnungsnummer“, „Rechnungsdatum“, „Firmenname“ und „Firmenadresse“. Angenommen, es müssen Rechnungen von zwei verschiedenen Typen verarbeitet werden:
  • Die Felder „Firmenname“ und „Firmenadresse“ befinden sich oberhalb des Feldes „Rechnungsnummer“.
  • Die Felder „Firmenname“ und „Firmenadresse“ befinden sich unterhalb des Feldes „Rechnungsnummer“.
Wie Sie auf den Bildern sehen können, haben die Felder „Firmenname“ und „Firmenadresse“ keine Namen, sodass das Standardverfahren, bei dem ein Datenfeld anhand seines Namens gesucht wird, hier nicht verwendet werden kann. Es gibt jedoch ein bestimmtes Muster: Wenn sich das Datumsfeld rechts von der Rechnungsnummer befindet, liegen Firmenname und Firmenadresse unterhalb des Feldes „Rechnungsnummer“ (Seiten 1 und 3). Befindet sich das Datumsfeld unterhalb des Feldes „Rechnungsnummer“, liegen die Firmendaten oberhalb des Feldes „Rechnungsnummer“ (Seiten 2 und 4). Unter Berücksichtigung dieses Musters sucht man am besten zunächst nach der Position der Felder „Rechnungsnummer“ und „Rechnungsdatum“ und ermittelt dann die anderen Felder anhand dieser beiden, indem man ihre relative Lage zueinander angibt.

​
Nach dem Datumsfeld mit zwei Gruppen von Einschränkungen suchen

Das Projekt enthält ein Group-Element InvoiceGroup mit den Elementen InvoiceHeader, InvoiceNum und DateHeader sowie ein Group-Element DateGroup. Diese Subelemente sind erforderlich, um Feldnamen sowie die Felder “Rechnungsnummer” und “Rechnungsdatum” zu erkennen.
Weitere Informationen zu den Methoden der Datumssuche finden Sie unter Datumssuche nach Erkennung hoher oder niedriger Qualität. In diesem Abschnitt werden nur die Einschränkungen für die Datumssuche im aktuellen Projekt beschrieben.
Wie Sie sehen, haben die Datumsfelder in den Bildern nicht immer Bezeichnungen. Wenn Sie also nach einem Datumsfeld suchen, müssen Sie zwei Gruppen von Einschränkungen angeben: für Fälle, in denen die Bezeichnung erkannt wurde, und für Fälle, in denen sie nicht erkannt wurde (ein Sonderfall wäre, wenn die Bezeichnung auf der Seite vorhanden ist, aber beispielsweise aufgrund von Bildrauschen nicht erkannt wurde).
Wenn der Name des Datumsfelds erkannt wird (die Bedingung if not DateHeader.IsNull wird geprüft), wird die Suche relativ zum Namen des Datumsfelds durchgeführt: rechts vom Namen, auf derselben horizontalen Ebene, mit einem gewissen Toleranzspielraum für vertikale Verschiebungen:
Andernfalls wird der Suchbereich in zwei Rechtecke aufgeteilt: eines rechts von der Rechnungsnummer auf derselben Höhe wie die Rechnungsnummer und eines unterhalb des Rechnungsfelds.
Der Einfachheit halber nehmen wir an, dass die Bilder von guter Qualität sind und das Feld “Rechnungsnummer” und seine Bezeichnung immer erkannt werden.In der Praxis müssen Sie vor dem Aufrufen der Eigenschaften dieser Elemente deren IsNull-Prüfung ausführen. Denn wenn die Elemente nicht erkannt werden, wird die weitere Suche relativ zu den Suchbereichen der entsprechenden Elemente durchgeführt.
Screenshot in ABBYY FlexiLayout Studio, der den Suchbereich für das Datumsfeld zeigt, der als Array von Rechtecken rechts von und unterhalb des Felds „Rechnungsnummer“ definiert ist, wenn die Bezeichnung des Datumsfelds nicht erkannt wird.

​
Datumshypothesen abwerten, die weit von den Rechnungsfeldern entfernt liegen

Der Abschnitt Erweiterte Nach-Suchbeziehungen des Date-Elements enthält den folgenden Code:
Dieser Code beeinflusst die Quality der Datumshypothese abhängig von ihrer Distanz zum Namen des Rechnungsfelds und – falls der Name des Datumsfelds nicht erkannt wird – zum Feld “Rechnungsnummer” selbst. Je größer die Distanz zu den angegebenen Feldern ist, desto höher fällt die Strafe für die entsprechenden Hypothesen aus. Das heißt, es wird nach dem Datumsfeld gesucht, das dem Feld “Rechnungsnummer” am nächsten liegt.
Weitere Informationen zur Verwendung dieser Funktionen finden Sie unter Nach Elementen mit Nearest und FuzzyQuality suchen.

​
Suchbedingungen für das Element DateAsString

Für das Element DateAsString werden dieselben Suchbedingungen angegeben, aber im Abschnitt Erweiterte Nach-Suchbeziehungen wird dem zuvor gezeigten Code noch eine weitere Zeile hinzugefügt:
Diese Zeile wird bei der Datumssuche benötigt, damit eine Hypothese mit einer längeren Folge von Alphabetzeichen gegenüber einer kürzeren bevorzugt wird. Zusätzlich legt die Registerkarte Search Constraints des Elements DateAsString fest, dass beim Suchen nach dem Datum als Zeichenfolge die Region des Elements InvoiceNum ausgeschlossen werden muss. Der Grund dafür ist, dass der Einfachheit halber die im Abschnitt Advanced pre-search relations des Elements Date angegebenen Suchbedingungen für das Element DateAsString nicht dupliziert werden. Stattdessen wird der Suchbereich als RestrictSearchArea (Date.Rect); festgelegt. Damit weist FlexiLayout Studio an, nach dem Objekt des Elements DateAsString im Bereich des unscharfen Rechtecks des Elements Date zu suchen. Der Suchbereich des Elements Date kann als Array von Rechtecken dargestellt werden. Wenn für das Element Date eine Nullhypothese erzeugt wird, wird das den Suchbereich umschließende Rechteck als Rechteck (Rect) des aktuellen Elements verwendet. Wie Sie in der Abbildung unten sehen können, umschließt es auch das durch das Element InvoiceNum beschriebene Feld „Rechnungsnummer“. Unter bestimmten Bedingungen (zum Beispiel, wenn das Datumsfeld stark verrauscht ist) kann es vorkommen, dass das Element DateAsString statt des Datumsfelds das Feld mit der Rechnungsnummer erkennt, da die für dieses Element angegebenen Zeichen (einschließlich Ziffern) keinerlei Formateinschränkungen unterliegen.
Screenshot in ABBYY FlexiLayout Studio, der den Suchbereich des Elements DateAsString zeigt, definiert durch RestrictSearchArea für das nicht erkannte Element Date, wobei auch das durch das Element InvoiceNum beschriebene Feld Rechnungsnummer eingeschlossen ist.

​
Prüfen Sie die Feldanordnung mit dem Hilfselement ShamElement

Nachdem die Elemente beschrieben wurden, die für die Suche nach den Feldern “Rechnungsnummer” und “Rechnungsdatum” erforderlich sind, folgt als nächster Schritt die Suche nach den Feldern “Firmenname” und “Firmenadresse”. Das Projekt verwendet ein Paragraph-Element mit dem Namen ShamElement. Dieses Element dient als Hilfselement und wird ausschließlich verwendet, um die relative Position der Felder “Rechnungsnummer” und “Rechnungsdatum” zueinander zu prüfen. Der Abschnitt Advanced pre-search relations des Hilfselements enthält den folgenden Code:
Trotz der Einfachheit der von diesem Code geprüften Bedingungen ist der Code selbst recht umfangreich. Die Idee ist, dass FlexiLayout Studio angewiesen wird, eine Nullhypothese für das Hilfselement zu erzeugen, wenn sich das Datumsfeld, das mithilfe eines der Elemente Date oder DateAsString erkannt wurde, rechts vom Feld „Rechnungsnummer“ befindet, aber auf gleicher Höhe liegt (mit einer vertikalen Toleranz von 30 dt). In den anderen Fällen wird unterhalb des oberen Seitenrands nach dem Element ShamElement gesucht. Da das Hilfselement ein Paragraph-Element ohne zusätzliche Suchbedingungen ist, schließt es alle Textobjekte auf der Seite ein, und es wird eine einzelne Hypothese erzeugt. Nahezu alle zu prüfenden Bedingungen sind intuitiv verständlich, daher werden hier nur die kompliziertesten beschrieben.
Dieser Teil des Codes prüft, ob sich das Datumsfeld (in diesem Fall, wenn es durch das Element Date erkannt wird) auf derselben horizontalen Ebene befindet wie das Element mit dem Feldnamen “Rechnungsnummer”. Das Datum kann etwas höher oder niedriger als der Name stehen (aufgrund möglicher Fehler beim Scannen oder beim Ausfüllen des Dokuments). Die maximale Differenz ist mit 30 dt angegeben. Die relative vertikale Position der Felder “Rechnungsdatum” und “Rechnungsnummer” wird mit derselben Methode geprüft.
Diese Zeile prüft, ob sich das Datumsfeld rechts vom Namen des Feldes “Rechnungsnummer” befindet (die Koordinate der linken Grenze des Datums ist größer als die der rechten Grenze des Namens). Eine Toleranz von 100dt wird angegeben, weil sich die Rechnungsnummer selbst zwischen dem Namen und dem Datum befinden muss. Das Datumsfeld befindet sich rechts vom Feld “Rechnungsnummer”. Anschließend werden alle Bedingungen dieser Prüfung für das Element DateAsString dupliziert. Um zu überprüfen, ob der Code korrekt ist, führen Sie den Abgleich des FlexiLayouts auf allen Seiten aus. Auf den Seiten 1 und 3, auf denen sich das Datumsfeld rechts von der Rechnungsnummer befindet, wurde für das Element ShamElement eine Nullhypothese erzeugt. Auf den beiden anderen Seiten wurden Textfragmente erkannt.
Screenshot des Ergebnisses des FlexiLayout-Abgleichs in ABBYY FlexiLayout Studio, der eine für das Hilfselement ShamElement auf den Seiten 1 und 3 erzeugte Nullhypothese zeigt, auf denen sich das Datumsfeld rechts von der Rechnungsnummer befindet.

​
Suche nach dem Firmennamen relativ zu den Rechnungsfeldern

Um die Unternehmensdaten zu erkennen, verwendet das Projekt ein Group-Element CompanyGroup. Es gruppiert das Element CompanyName vom Typ Zeichenkette (auf den Testbildern steht der Firmenname in einer einzigen Zeile) und das Element Adresse vom Typ Paragraph. Das letztgenannte Element wird verwendet, um den Block zu suchen, der die Firmenadresse enthält. Die Verwendung des Hilfselements vereinfacht den Code, der die Suchbedingungen des Elements im Abschnitt Advanced pre-search relations beschreibt. Wird das Hilfselement nicht erkannt (das heißt, wird dafür eine Nullhypothese erzeugt), bedeutet dies, dass sich das Datumsfeld rechts vom Rechnungsfeld befindet. In diesem Fall wird das Feld “Firmenname” unterhalb des Felds “Rechnungsnummer” gesucht. Wird das Hilfselement erkannt, wird das Feld “Firmenname” oberhalb des Felds “Rechnungsnummer” gesucht.
In diesem Fall kann die Funktion Nearest verwendet werden, da sie dabei hilft, das Feld mit dem Unternehmensnamen eindeutig und präzise zu erkennen (es gibt keine Objekte, die denselben Suchbedingungen entsprechen).
Der Abschnitt „Erweiterte Nach-Suchbeziehungen“ des Elements CompanyName enthält den folgenden Code.
Dieser Code funktioniert, wenn das einzeilige Feld “Company name” oberhalb des Feldes mit der Rechnungsnummer gesucht wird. Die gesuchten Felder haben keine Namen. Gleichzeitig ist die relative Position der Felder “Company name” und “Company address” auf den Seiten 2 und 4 unterschiedlich. Die Bedingungen Above: InvoiceGroup.InvoiceHeader; und Above: InvoiceGroup.InvoiceNum; werden nicht nur von der Zeile mit dem Firmennamen erfüllt, sondern auch von den Zeilen im Adressfeld.
Screenshot in ABBYY FlexiLayout Studio, der zeigt, dass die Oberhalb-Bedingung relativ zu den Elementen InvoiceHeader und InvoiceNum sowohl von der Zeichenfolge Company name als auch von den Zeilen des Adressfelds erfüllt wird.
Um unter allen erzeugten Hypothesen die einzig richtige auszuwählen, wird im Abschnitt Erweiterte Nach-Suchbeziehungen der folgende Code verwendet. Die Zeilen
und
weisen FlexiLayout Studio an, stärkere Abzüge für Hypothesen mit Objekten vorzunehmen, die sich nahe den unteren und rechten Bildgrenzen befinden. Auf Seite 2 befindet sich das Feld “Firmenname” jedoch links vom Adressfeld, aber unterhalb seiner oberen Zeile. Daher reichen die beschriebenen Einschränkungen nicht aus, um das gesuchte Feld “Firmenname” zu erkennen, und es ist eine weitere Einschränkung erforderlich.
Diese Zeile weist FlexiLayout Studio an, die Höhe aller Zeilen für die generierten Hypothesen zu prüfen. Je höher die Zeichen in der Zeile sind, desto höher ist die Quality der entsprechenden Hypothese. Nach dem Abgleich des FlexiLayouts können Sie sehen, dass das Feld “Firmenname” auf allen Seiten erfolgreich erkannt wurde.

​
Suche nach dem Adressfeld mit dem Hilfselement

Um das Adressfeld zu erkennen, wird im Abschnitt Advanced pre-search relations des Elements Adresse der folgende Code verwendet:
Auch hier wird das Hilfselement ShamElement verwendet, um den Code zu vereinfachen. Die Erstellung des FlexiLayouts ist nun abgeschlossen. Sobald Sie den Abgleich des FlexiLayouts ausgeführt haben, sehen Sie, dass alle Felder erfolgreich erkannt wurden.