Skip to main content
Par souci de simplicité, un document d’une seule page est utilisé dans cet exemple.
Dans le traitement des documents, il ne suffit souvent pas de décrire l’emplacement des éléments les uns par rapport aux autres en termes de « au-dessus - en dessous - à droite - à gauche ». Cela peut se produire, par exemple, si, dans la zone de recherche, plusieurs objets correspondent aux contraintes de recherche. Ce type de situation nécessite des propriétés distinctives supplémentaires, notamment la distance entre les objets. À cette fin, FlexiLayout Studio propose la fonction FuzzyQuality, ainsi que les fonctions du groupe Nearest (Nearest, NearestX, NearestY).

​
En quoi les fonctions Nearest et FuzzyQuality diffèrent

Les applications de ces fonctions sont différentes. La fonction Nearest ne peut être utilisée que dans le champ relations avancées de pré-recherche. Elle indique que, parmi les différentes hypothèses de l’élément, FlexiLayout Studio doit sélectionner l’hypothèse la plus proche d’un certain élément ou point de l’image, défini dans les propriétés de la fonction Nearest. Dans le champ relations avancées de pré-recherche de l’élément, une seule fonction du groupe Nearest peut être utilisée. Après son exécution, il ne reste qu’une seule hypothèse. Cela se produit à l’étape de génération des hypothèses, c’est-à-dire avant l’exécution du code spécifié dans le champ Advanced post-search relations. Le paramètre Minimum quality, qui spécifie la qualité minimale des hypothèses pour l’élément, peut être défini pour les éléments Static Text, Character String, Paragraph, Date et Separator. Rien ne garantit que l’hypothèse restante soit la meilleure (et corresponde à l’objet recherché dans l’image), car Advanced post-search relations joue un rôle très important dans l’attribution d’une valeur de qualité à une hypothèse. Lors de l’utilisation de la fonction Nearest, le choix de l’hypothèse est effectué à l’étape de génération des hypothèses et repose sur la proximité avec un certain point, et non sur la qualité de l’hypothèse. Il faut toujours garder à l’esprit que, si les propriétés spécifiées dans la section Advanced post-search relations sont importantes pour sélectionner correctement l’hypothèse, vous devez utiliser la fonction FuzzyQuality au lieu des fonctions du groupe Nearest. La fonction FuzzyQuality ne peut être utilisée que dans la section Advanced post-search relations. Contrairement aux fonctions du groupe Nearest, elle ne sélectionne pas une seule hypothèse, mais influe sur la qualité globale de toutes les hypothèses générées en fonction des propriétés de ces hypothèses et des paramètres de la fonction FuzzyQuality. En outre, la fonction FuzzyQuality peut être utilisée plusieurs fois pour un même élément dans le champ Advanced post-search relations. Cela signifie que plusieurs contraintes différentes, associées à différentes valeurs de qualité, peuvent être appliquées à une hypothèse. Toutes les valeurs seront multipliées pour déterminer la qualité après recherche de l’hypothèse. La fonction FuzzyQuality se présente comme suit :
Son algorithme est le suivant : la fonction vérifie si la valeur du paramètre x appartient à l’intervalle défini par les paramètres f1, f2, f3, f4. La signification de cet intervalle flou est similaire à celle des intervalles flous spécifiés pour certains paramètres de l’élément Character String.

​
Le projet d’exemple FuzzyAndNearest

Cet exemple montre comment les fonctions Nearest et FuzzyQuality peuvent être utilisées sur les images suivantes. Comme le montrent les images, la facture est semi-structurée : la disposition des champs diffère d’une image à l’autre. L’objectif est de détecter les champs « Numéro de facture » et « Date de la facture ». Cela est réalisé dans le projet 1.fsp (dossier %public%\ABBYY\FlexiCapture\12.0\Samples\FLS\Tips and Tricks\FuzzyAndNearest \Project1). Pour optimiser la structure FlexiLayout et suivre la logique de disposition des champs recherchés dans le document, le projet regroupe tous les éléments recherchés dans un élément composé, InvoiceGroup. La création du FlexiLayout peut commencer par un élément décrivant les contraintes de recherche pour le nom du champ « Numéro de facture ». Cependant, l’analyse des images montre que le mot « Invoice », qui entre dans la composition de ce nom, apparaît plusieurs fois dans le document. Comme la position relative des champs change d’une fois à l’autre, il est impossible de définir des contraintes garantissant la détection correcte du mot « Invoice ». Il peut, par exemple, apparaître dans l’intitulé « Date de la facture ». Pour éviter cette confusion, la description commence par le nom du champ de date, à l’aide d’un élément Static Text nommé DateHeader. Le champ Texte de recherche spécifie deux valeurs du nom : Invoicedate:|Invoicedate (liste des variantes du nom telles qu’elles apparaissent sur les images). La casse du nom n’a pas d’importance.
Pour plus d’informations sur la raison pour laquelle vous devez spécifier les deux variantes, consultez Définir plusieurs valeurs de Static Text pour les variantes de libellé du champ.

​
Rechercher le champ de date avec un tableau de rectangles

La recherche du champ de date s’appuie sur le nom du champ. Le projet contient un groupe DateAlternative, composé de deux éléments : un élément Date pour rechercher le champ de date dans l’un des formats spécifiés, et un élément Character String au cas où le format du champ recherché serait différent.
Pour une description détaillée de la création d’un FlexiLayout pour la recherche de date, voir Recherche de date après une reconnaissance de haute ou de basse qualité.
Comme le montrent les images, le champ de date peut se trouver soit à droite de l’intitulé « Date de la facture », soit en dessous. Si des contraintes de recherche standard sont définies dans le champ Relations (elles sont affichées dans le projet, mais désactivées), la zone de recherche sera trop grande et pourra englober certains champs susceptibles d’être pris à tort pour le champ de date (un exemple est illustré sur l’image). Cela peut se produire, par exemple, si la date ne correspond pas au format spécifié pour l’élément Date.
Capture d’écran dans ABBYY FlexiLayout Studio montrant comment les contraintes Relations standard rendent la zone de recherche du champ de date trop grande, en englobant d’autres champs qui peuvent être pris par erreur pour le champ Date de la facture.
Pour éviter que FlexiLayout Studio n’analyse une zone non souhaitée, le projet utilise une autre méthode. Le champ relations avancées de pré-recherche contient le code suivant :
Le code vérifie si le nom du champ de date a été trouvé. Si c’est le cas, la zone de recherche est définie comme un tableau de rectangles (dans l’exemple, 2 rectangles). Un rectangle recherche la date à droite du nom, et l’autre en dessous du nom. Si le nom n’est pas trouvé, la recherche sera effectuée dans la moitié supérieure de l’image. Dans le cas d’une page où les contraintes de recherche ont été spécifiées dans la section Relations, la forme de la zone de recherche après l’exécution de ce code sera différente d’un rectangle. Comme l’image le montre, tous les objets indésirables en ont été supprimés.
La première ligne du code (let Header = InvoiceGroup.DateHeader;) simplifie le code en définissant la variable Header et en lui attribuant la valeur de l’élément DateHeader.
Capture d'écran dans ABBYY FlexiLayout Studio montrant la zone de recherche non rectangulaire du champ de date produite par le code RestrictSearchArea, dont tous les objets indésirables ont été supprimés.
Ce code n’est pas dupliqué pour l’élément DateAsString. À la place, sa section de relations avancées de pré-recherche contient la contrainte de recherche suivante :
Cela signifie que si l’élément Date n’est pas détecté, la recherche s’effectuera dans le rectangle qui englobe la zone de recherche de l’élément Date.
Pour spécifier la zone de recherche de l’élément DateAsString sous forme de tableau de rectangles, au lieu d’appeler RestrictSearchArea (Date.Rect), copiez le code correspondant depuis la section relations avancées de pré-recherche de l’élément Date.

​
Détecter le nom du champ Invoice avec Exclude et NearestY

Le projet contient également un élément Static Text (nommé InvoiceHeader) permettant de détecter l’intitulé du champ “Numéro de facture”, avec la valeur recherchée “Invoice”. Comme le document n’est pas structuré, aucune contrainte de recherche spécifique ne peut être définie. Une fois la procédure de mise en correspondance de FlexiLayout terminée, vous pouvez constater que l’intitulé n’a été correctement détecté que sur la première page. Sur les pages 2 et 4, le mot “Invoice” a été détecté par erreur dans le nom du champ de date. Sur la page 3, il a été trouvé en bas de la page et, conformément à l’algorithme d’optimisation, les autres hypothèses du nom n’ont pas été générées, même si le mot “Invoice” apparaît trois fois dans l’image.
Pour plus d’informations sur la recherche optimale des éléments du groupe, voir Optimisation de la recherche d’éléments de groupe.
Pour résoudre ces problèmes, on utilise la méthode suivante. Pour exclure la région du nom du champ de date de la zone de recherche du nom du champ “Invoice”, l’élément DateHeader est ajouté à la section Exclude regions of elements (voir la figure suivante).
Si le FlexiLayout avait commencé non pas par le nom DateHeader mais par le nom InvoiceHeader, la fonction Exclude n’aurait pas pu être utilisée, car cette fonction ne peut exclure que les éléments situés plus haut que l’élément actuel dans l’arborescence du projet.
Pour exclure la détection indésirable du mot “Invoice” en bas de la page, le code suivant est écrit dans la section relations avancées de pré-recherche.
Ce code indique à FlexiLayout Studio de rechercher l’élément le plus proche du bord supérieur de la page.
Capture d’écran de la section relations avancées de pré-recherche dans ABBYY FlexiLayout Studio montrant le code NearestY: PageRect.Top, qui recherche l’élément correspondant au nom du champ Invoice le plus proche du bord supérieur de la page.
Une fois le FlexiLayout associé, vous pouvez voir que cette méthode a échoué sur la page 2, car le nom du champ de date y est très parasité et n’a pas été détecté. Sur cette page, la contrainte spécifiée dans la fonction Nearest est vraie pour les deux chaînes “Invoice”, car elles se trouvent au même niveau. Comme la qualité de reconnaissance des chaînes “Invoice” est bonne dans les deux cas, l’algorithme d’optimisation a généré une seule hypothèse au lieu de deux hypothèses distinctes. Malheureusement, cette hypothèse n’est pas correcte.

​
Rechercher le numéro de facture avec Nearest

Pour détecter le champ “Numéro de facture”, le projet utilise un élément Character String nommé InvoiceNumber. Comme pour l’élément du champ de date, les contraintes de recherche du champ “Numéro de facture” sont spécifiées dans la section Relations avancées de pré-recherche. La zone de recherche de cet élément est un tableau de rectangles.
De plus, le code contient une contrainte supplémentaire, qui indique à FlexiLayout Studio que l’élément InvoiceNumber est le plus proche de l’élément correspondant au nom. Après avoir exécuté la procédure de mise en correspondance, vous pouvez voir que le champ “Numéro de facture” a été détecté incorrectement sur les pages 2 et 4. Il a été détecté incorrectement à la page 4, même si le nom du champ a été détecté correctement.
Comme alternative (pour les images du projet actuel) à Nearest: Header;, vous pourriez écrire NearestY: Header.Rect.YCenter; pour indiquer à FlexiLayout Studio que le champ recherché est verticalement le plus proche du centre du nom.Cela pourrait résoudre le problème de détection incorrecte du champ “Numéro de facture” à la page 4. Cependant, cela n’aide pas pour la page 5, car le champ recherché est détecté dans le champ de date après la détection incorrecte du nom “Numéro de facture”.

​
Remplacer Nearest par des pénalités FuzzyQuality

Voyons maintenant comment la fonction FuzzyQuality peut être utilisée dans ce type de situation. Cela est illustré dans le projet 2.fsp (dossier FuzzyAndNearest\Project2). Les paramètres de ce projet sont presque identiques à ceux du projet décrit précédemment. Il existe toutefois une différence importante : la fonction Nearest n’est pas utilisée dans la section des relations avancées de pré-recherche. À la place, la section Advanced post-search relations contient le code suivant :
Cette méthode affecte la qualité de toutes les hypothèses sans en exclure aucune. Le choix de la meilleure chaîne s’effectue individuellement pour chaque chaîne en multipliant les valeurs de qualité de toutes les hypothèses constitutives des éléments. La ligne FuzzyQuality: Rect.Top - PageRect.Top, {0,0,0,50000} * dt; signifie que, si une hypothèse non nulle est générée (la vérification if not IsNull est exécutée en premier), la distance entre la position de l’élément et le bord supérieur de la page est déterminée. Autrement dit, la différence (Rect.Top - PageRect.Top) est calculée, puis FlexiLayout Studio vérifie si cette différence appartient à l’intervalle {0, 0, 0, 50000}*dt. Une telle définition de l’intervalle signifie que la pénalité de qualité dépend directement de la distance entre l’élément et le bord supérieur de la page : plus la distance est grande, plus la pénalité est élevée. Comme le montre l’illustration (a), avec les valeurs de paramètres indiquées, la pénalité maximale (1) correspond à une distance de 50000dt, tandis qu’une distance de 1000 dots (1 dot équivaut à 1/300 de pouce) entraîne une pénalité de 0.02, et une distance de 100dt une pénalité de 0.002.
Lors du choix des paramètres qui définissent les limites de l’intervalle (en particulier lorsqu’il y a plusieurs vérifications d’éléments avec la fonction FuzzyQuality), assurez-vous qu’ils ne pénalisent pas l’hypothèse correcte au point que sa qualité finale devienne inférieure à celle d’une hypothèse nulle.Si la qualité de toutes les hypothèses (y compris la bonne) est inférieure à la valeur de qualité d’une hypothèse nulle, l’hypothèse nulle peut être sélectionnée, c’est-à-dire que l’élément ne sera pas détecté.
Schéma montrant que la pénalité de qualité augmente avec la distance entre l’élément et le bord supérieur de la page, où une distance de 50000dt produit la pénalité maximale de 1.

(a)

La ligne FuzzyQuality: 500dt - Width, {0,0,0,100000}*dt; signifie que FlexiLayout Studio prend en compte la différence entre 500dt et la largeur de l’objet détecté correspondant à l’hypothèse. Autrement dit, la différence (500dt - Width) est calculée, puis FlexiLayout Studio vérifie si cette différence appartient à l’intervalle {0, 0, 0, 100000}*dt. Plus l’objet est étroit, plus la pénalité est élevée, de sorte que les numéros de facture plus longs seront favorisés. Cette contrainte peut être utilisée si l’image est bruitée. Si le bruit est reconnu comme un caractère de l’alphabet spécifié (comme on peut le voir, par exemple, à la page 2), son hypothèse doit être pénalisée afin de l’exclure de l’analyse ultérieure.
La valeur de 500dt est choisie par examen visuel, en supposant que la longueur de la chaîne dans le champ “Numéro de facture” n’est pas supérieure à cette valeur. Les paramètres spécifiés ici définissent que la pénalité maximale (0.005) correspondrait à une largeur nulle du champ “Numéro de facture”. Pour toute autre largeur comprise entre 0 et 500dt, les pénalités de qualité seraient plus faibles.
La ligne FuzzyQuality: Rect.XCenter - InvoiceHeader.Rect.XCenter, {-10000,0,0,50000} *dt; signifie que si une hypothèse non nulle est générée pour l’élément correspondant au nom du champ « Numéro de facture » (la vérification if not InvoiceHeader.IsNull est exécutée en premier), la distance entre le centre de l’élément InvoiceNumber détecté et le centre de l’intitulé InvoiceHeader est déterminée. La différence (Rect.XCenter - InvoiceHeader.Rect.XCenter) est calculée, puis FlexiLayout Studio vérifie si cette différence appartient à l’intervalle {-10000, 0, 0, 50000}*dt. Cette description tient également compte du fait que le champ « Numéro de facture » peut être situé sous le nom. Dans ce cas, plus les éléments sont éloignés l’un de l’autre, plus la pénalité appliquée à l’hypothèse correspondante est élevée. Les hypothèses selon lesquelles le numéro se trouve à droite du nom seront moins pénalisées que celles selon lesquelles il se trouve en dessous du nom, car la disposition « à droite » du champ « Numéro de facture » par rapport à son intitulé est bien plus courante. Comme le montre l’illustration (b), avec les paramètres spécifiés pour les limites gauche et droite de l’intervalle, la pénalité maximale (1) correspondra à un décalage du champ « Numéro de facture » par rapport au champ du nom de 10000dt vers la gauche ou de 50000dt vers la droite. Un décalage de 1000 points sera pénalisé de 0.1 s’il s’agit d’un décalage « vers la gauche », ou de 0.02 s’il s’agit d’un décalage « vers la droite ». De même, un décalage de 100 points sera pénalisé de 0.01 s’il s’agit d’un décalage « vers la gauche », ou de 0.002 s’il s’agit d’un décalage « vers la droite ».
Schéma montrant la pénalité de qualité pour le décalage horizontal du champ Numéro de facture par rapport à son intitulé, où la pénalité maximale de 1 correspond à un décalage de 10000dt vers la gauche ou de 50000dt vers la droite.

(b)

La ligne FuzzyQuality: Rect.YCenter - InvoiceHeader.Rect.YCenter, {-10000,0,0,10000} *dt; est identique à la précédente. Elle est toutefois réservée aux cas où le champ « Numéro de facture » se trouve au même niveau horizontal que le champ du nom, voire légèrement au-dessus. Les pénalités y sont identiques pour tout décalage vertical. Les limites de l’intervalle sont définies selon la même logique : donner la priorité aux hypothèses qui trouvent le champ de données à droite de son intitulé. Cependant, le projet montre que ces paramètres n’ont pas empêché la détection correcte du numéro de facture, même lorsqu’il était situé sous le nom (page 3). Après mise en correspondance du FlexiLayout avec toutes les pages, vous pouvez constater que les deux champs recherchés ont bien été détectés. En conclusion, la fonction FuzzyQuality est plus efficace et plus flexible que les fonctions du groupe Nearest, ce qui est particulièrement important lors du traitement de documents semi-structurés.