Pour détecter des champs sur une seule ligne, FlexiLayout Studio dispose d’un élément spécial Character String. Si le champ recherché a un format connu, il peut être décrit dans les propriétés de l’élément correspondant, dans le champ Regular expression de l’onglet Character String. Mais l’utilisation d’une expression régulière exige des documents imprimés et une bonne qualité d’image, car une description par expression régulière ne tolère aucune erreur dans le champ, faute de quoi l’élément ne sera tout simplement pas détecté. Les expressions régulières ne doivent pas non plus être utilisées si le document est rempli à la main, même si sa mise en page peut être décrite. Néanmoins, un tel champ peut être détecté.
La recherche d’un champ sur une seule ligne “Numéro de facture” avec un format similaire sur toutes les pages est illustrée dans l’exemple de projet StructuredStrings.fsp (dossier %public%\ABBYY\FlexiCapture\12.0\Samples\FLS\Tips and Tricks\Structured strings).
Le projet comporte quatre pages :
- Pages 1 et 2 - le champ “Numéro de facture” est renseigné à l’aide d’une imprimante, la qualité d’impression est bonne ;
- Page 3 – le champ “Numéro de facture” est renseigné à l’aide d’une imprimante, l’image est bruitée ;
- Page 4 – la qualité de l’image est bonne, mais le champ “Numéro de facture” est rempli à la main.
Nous allons rechercher le champ “Numéro de facture” en nous appuyant sur le nom du champ. Nous devons d’abord créer un élément décrivant les contraintes de recherche du nom du champ. L’élément créé est de type Static Text, nommé InvoiceNumberHeader, et a pour valeur “InvoiceN:”.
Le champ “Numéro de facture” est un champ sur une seule ligne. Pour le détecter, nous avons créé un élément de type Character String, nommé NumAsRegularExpression. Comme on peut le voir sur les pages du projet, le format du champ “Numéro de facture” peut être décrit à l’aide de l’expression régulière suivante :
NNNN”-“NN”-“[A-Z]”/“NN
ou, ce qui revient au même :
[0-9]{4}”-“[0-9]{2}”-“[A-Z]”/” [0-9]{2}
Cela signifie que le numéro est une séquence de type : “quatre chiffres - deux chiffres - une lettre majuscule latine/deux chiffres”.
Comme on peut le voir dans le projet, après l’exécution de la procédure de mise en correspondance FlexiLayout en sélectionnant la commande Associer, des hypothèses nulles ont été générées pour l’élément NumAsRegularExpression aux pages 3 et 4, c’est-à-dire que l’élément n’a pas été détecté. À la page 3, le bruit a entraîné une non-correspondance entre le champ et l’expression régulière. Si vous ouvrez la Page 3 et cliquez sur “L” (“Show Recognized Lines”) dans la barre d’outils, la pré-reconnaissance du numéro de facture sur la page apparaîtra sous la forme “10&0-20-A/04”. À la page 4, le numéro de facture est rempli à la main. Vous pouvez voir dans les résultats de la pré-reconnaissance (Z.OOO-41-C/03) qu’il ne correspond pas non plus au format décrit.
La solution suivante est recommandée pour résoudre ce problème. Nous créons un élément supplémentaire de type Character String, nommé NumAsAlphabet. Nous lui spécifions les mêmes contraintes de recherche que pour l’élément NumAsRegularExpression. Ensuite, nous regroupons les deux éléments dans un élément Group unique, InvoiceNumber. Mais nous décrivons l’élément NumAsAlphabet non pas comme une expression régulière, mais comme une liste de tous les caractères valides.
Le code suivant doit être saisi dans le champ Relations avancées avant recherche :
if (NumAsRegularExpression.IsNull == FALSE) then Dontfind();
Cela signifie que la recherche d’une chaîne de format inconnu, décrite par l’élément NumAsAlphabet, ne sera tentée que si le programme ne parvient pas à la détecter au moyen de l’élément NumAsRegularExpression, qui décrit une chaîne de format fixe.
Lorsque vous spécifiez des contraintes de recherche pour l’élément NumAsAlphabet, vous pouvez utiliser la méthode drag&drop pour copier les paramètres de la section Relations de l’élément NumAsRegularExpression dans la même section de l’élément actuel. Vous pouvez également écrire le code suivant dans le champ Relations avancées avant recherche :
if (NumAsRegularExpression.IsNull == FALSE) then Dontfind();
else RestrictSearchArea (NumAsRegularExpression.Rect);
Ce code signifie qu’une recherche de l’élément NumAsAlphabet ne sera lancée que si la structure du numéro de facture ne correspond pas au format spécifié, c’est-à-dire si le programme n’a pas réussi à détecter l’élément NumAsRegularExpression. L’élément NumAsAlphabet sera alors recherché dans la même zone que celle où l’élément NumAsRegularExpression n’a pas été trouvé.
Nous relançons maintenant la procédure de mise en correspondance FlexiLayout sur toutes les pages. Comme on peut le voir dans le projet, le champ du numéro de facture est désormais correctement trouvé sur chacune des pages.
Dans l’arborescence du projet, nous avons créé un bloc de texte nommé InvoiceNum. Le groupe SearchElements.InvoiceNumber est défini comme son élément source. À ce stade, la création d’un FlexiLayout pour détecter les champs « Numéro de facture » est terminée.
Si, pour une raison quelconque, la méthode décrite ci-dessus ne suffit pas à détecter le champ de données (que son format soit connu ou inconnu), un élément supplémentaire (de type Object Collection) peut être créé dans le groupe. Dans ce projet, il s’agit de l’élément de type Object Collection nommé NumAsObjectCollection. Il n’est en fait pas nécessaire, compte tenu de la bonne qualité des images du projet, et n’est présenté qu’à titre d’exemple (la commande Disable lui est appliquée). L’ajout d’un élément supplémentaire de type Object Collection peut être nécessaire lorsqu’il est difficile de prévoir les résultats de pré-reconnaissance sur différentes pages, mais que la zone de recherche peut être décrite avec précision, ce qui évite que des informations indésirables ne figurent parmi les hypothèses.
La question suivante peut se poser : pourquoi une expression régulière est-elle nécessaire si le champ peut parfois être détecté sans elle ? La réponse est que l’utilisation d’une expression régulière rend la recherche plus fiable. Si cet élément est trouvé, vous pouvez alors être certain d’avoir trouvé exactement la ligne recherchée. Cette information peut ensuite être utilisée en toute sécurité pour détecter d’autres éléments et leurs relations. Lorsque les contraintes de recherche sont souples, vous ne pouvez pas être absolument certain d’avoir trouvé exactement ce dont vous avez besoin.
Cela peut se produire si l’image est très bruitée. Dans ce cas, l’utilisation d’un élément de type Character String avec un alphabet spécifié peut entraîner un pourcentage d’erreurs excessif (le paramètre Percentage of non-alphabet characters). Par conséquent, l’élément ne sera soit pas détecté du tout, soit détecté seulement partiellement. Un exemple d’une telle situation est donné dans l’image ci-dessous.
