Passer au contenu principal
Si toutes les hypothèses de la chaîne d’éléments dans l’élément Group (Group) ont une qualité égale à 1, les autres hypothèses de ces éléments ne seront pas analysées.
Cela permet d’optimiser le FlexiLayout, d’accélérer la procédure de mise en correspondance et d’éviter la « ramification » indésirable de l’arbre des hypothèses. Mais une hypothèse optimale pour le programme ne correspond pas forcément à l’objet recherché dans l’image. Cela peut se produire si les contraintes de recherche de l’élément ne sont pas suffisamment strictes. Dans ce cas, vous devez avant tout analyser les paramètres définis pour la recherche des éléments.
Prenons le projet GO.fsp (dossier %public%\ABBYY\FlexiCapture\12.0\Samples\FLS\Tips and Tricks\GO\1), dans lequel nous allons rechercher le champ « Numéro de facture ». Le projet comporte 2 pages :
  • Page 1 – la qualité de l’image est bonne ;
  • Page 2 – le nom du champ recherché est bruité.
Nous avons créé le groupe InvoiceGroup, qui contient l’élément utilisé pour rechercher le nom du champ. Il s’agit d’un élément de type Static Text, nommé InvoiceHeader, avec la valeur « INVOICE ». Pour rechercher le champ « Numéro de facture » lui-même, nous avons créé un élément de type Character String, nommé InvoiceNumber. Nous avons spécifié les contraintes de recherche du champ de date par rapport à son nom dans la section Relations de l’élément InvoiceNumber.
La casse du nom dans la section Search text n’a pas d’importance.
Notez que la chaîne « Invoice » spécifiée comme valeur de l’élément InvoiceHeader apparaît trois fois dans les images : comme nom du champ « Numéro de facture », comme sous-chaîne dans le nom « Date de la facture » et en bas de la facture, comme sous-chaîne dans les conditions de paiement « Current invoice is… ». Nous pouvons donc prévoir qu’il y aura trois hypothèses après la procédure de mise en correspondance. Après avoir exécuté la procédure de mise en correspondance du FlexiLayout en sélectionnant la commande Associer, nous constatons que l’arbre des hypothèses dans le groupe InvoiceGroup ne comporte qu’une seule chaîne complète au lieu des trois attendues, et que la chaîne complète d’hypothèses restante ne correspond pas au nom que nous cherchons à détecter. Si vous examinez les propriétés de chacun des éléments de la chaîne générée, vous verrez que la Chain quality de chaque hypothèse est égale à 1, ce qui a déclenché l’optimisation : lorsque le programme détecte une chaîne idéale en termes de qualité (c’est-à-dire avec une qualité de 1), il cesse de générer des hypothèses.
Pour afficher l’arbre des hypothèses du groupe, double-cliquez sur le nom de l’élément Group dans l’arbre des hypothèses, appuyez sur Enter ou sélectionnez Show Details dans le menu contextuel.
La raison pour laquelle, au stade de la génération des hypothèses, un objet de l’image est préféré aux autres est déterminée par l’algorithme du programme. Comme les résultats de la mise en correspondance du FlexiLayout ne sont pas satisfaisants, nous devons analyser les causes du problème et décider comment y remédier. Premièrement, nous n’avons pas limité la zone de recherche de l’élément InvoiceHeader. Deuxièmement, lors de la définition de l’élément InvoiceNumber, nous avons indiqué que la chaîne de chiffres pouvait avoir n’importe quelle longueur (car nous ne connaissons pas la longueur possible du numéro de facture). Nous avons également indiqué qu’elle devait être recherchée à droite du nom, à peu près au même niveau horizontal. Comme vous pouvez le constater, les trois occurrences du mot « Invoice » satisfont à ces conditions. C’est pourquoi la détection incorrecte du nom a automatiquement entraîné la détection incorrecte du champ « Numéro de facture ». Vous devez ajouter certaines contraintes restrictives afin que l’hypothèse correcte soit finalement la meilleure et que le FlexiLayout soit optimal non seulement en termes de vitesse de mise en correspondance.” Si nous supposons que la disposition des champs est identique sur toutes les pages du projet, le plus simple est alors d’« indiquer » au programme que nous avons besoin de la chaîne “Invoice”, qui est l’élément le plus proche du bord droit de la page. Nous écrivons donc le code suivant dans la section relations avancées de pré-recherche de l’élément InvoiceHeader : Nearest: PageRight;. Nous pouvons le faire parce que l’intitulé du champ recherché “Numéro de facture” est le seul élément le plus proche du bord droit de la page. Si ce n’était pas le cas, ou si le document n’était pas formalisé, la fonction Nearest ne pourrait pas nous aider à résoudre le problème. Pour montrer d’autres façons d’effectuer cette tâche, y compris dans le cas d’un document semi-structuré, nous avons créé le projet GO.fsp (dossier GO\2). Comme vous pouvez le voir sur les images, la distance entre la chaîne de chiffres et le mot “invoice” est la plus faible dans le champ recherché “Numéro de facture”. C’est le cas sur toutes les pages, ce qui nous permet d’influer sur les valeurs de qualité des hypothèses générées en saisissant le code suivant dans la section Advanced post-search relations de l’élément InvoiceNumber : if (not InvoiceHeader.IsNull) and (not IsNull) then { FuzzyQuality: Rect.Left - InvoiceHeader.Rect.Right, {0, 0, 0, 10000}*dt; } Cela signifie que si les deux éléments sont détectés, la distance entre eux est calculée pour l’hypothèse de l’élément InvoiceNumber, et le programme vérifie si elle appartient à l’intervalle {0, 0, 0, 10000}*dt. Cette description de l’intervalle montre la dépendance linéaire entre la qualité de l’hypothèse et la distance entre les éléments : plus la distance est grande, plus la pénalité est élevée (la fonction FuzzyQuality rétablit la Post-search quality de l’hypothèse ; celle-ci est visible dans la fenêtre Properties de l’hypothèse). La valeur de la limite droite de l’intervalle (10000dt) a été déterminée expérimentalement. Lors du choix de cette valeur, vous devez tenir compte de la distance entre les objets correspondants sur les images de test. Comme le montre l’image ci-dessous, avec les propriétés d’intervalle spécifiées, la pénalité maximale (1) correspondra à une distance de 10000dt. En conséquence, une distance de 1000dt entraînera une pénalité de 0.1, une distance de 100dt, une pénalité de 0.01, etc. Ainsi, pour des distances réelles d’environ 100 à 300 dot, comme on peut le voir sur nos images, le coefficient de pénalité sera de 0.99 à 0.97.
Voir Using Nearest and FuzzyQuality to look for elements pour plus de détails sur l’utilisation de ces fonctions.
Pour les images de ce batch, l’hypothèse correspondant au champ indésirable “Numéro de facture” avec la valeur “2005” a reçu la pénalité maximale, tandis que l’hypothèse correspondant au champ recherché a reçu la pénalité minimale. Comme la pénalisation a rendu la Post-search quality de toutes les hypothèses différente de 1, toutes les hypothèses des deux éléments du Group element InvoiceGroup seront désormais analysées. Notez que le champ “Numéro de facture” a été correctement détecté même sur la page 2, où le mot “Invoice” est très bruité, ce qui a provoqué une erreur de reconnaissance et, par conséquent, des pénalités supplémentaires pour l’hypothèse.