Saltar al contenido principal
Si todas las hipótesis de la cadena de elementos del elemento de grupo (Group) tienen un valor de calidad de 1, no se analizarán las demás hipótesis de estos elementos.
Esto se hace para optimizar el FlexiLayout, acelerar el procedimiento de emparejamiento y evitar la “ramificación” no deseada del árbol de hipótesis. Sin embargo, una hipótesis que es óptima para el programa no necesariamente corresponde al objeto buscado en la imagen. Esto puede ocurrir si las restricciones de búsqueda del elemento no son lo bastante estrictas. Por eso, cuando se produce una situación así, lo primero que debe hacer es analizar los parámetros establecidos para la búsqueda de elementos.
Consideremos el proyecto GO.fsp (carpeta %public%\ABBYY\FlexiCapture\12.0\Samples\FLS\Tips and Tricks\GO\1), donde vamos a buscar el campo “Número de factura”. El proyecto tiene 2 páginas:
  • Página 1 – la calidad de la imagen es buena;
  • Página 2 – el nombre del campo buscado tiene ruido.
Creamos el grupo InvoiceGroup, que contiene el elemento utilizado para buscar el nombre del campo. Se trata de un elemento del tipo Static Text, llamado InvoiceHeader, con el valor “INVOICE”. Para buscar el propio campo “Número de factura”, creamos un elemento del tipo Character String, llamado InvoiceNumber. Especificamos las restricciones de búsqueda del campo con respecto al nombre en la sección Relations del elemento InvoiceNumber.
El uso de mayúsculas y minúsculas del nombre en la sección Search text es irrelevante.
Tenga en cuenta que la cadena “Invoice” especificada como valor para el elemento InvoiceHeader aparece en las imágenes tres veces: como nombre del campo “Número de factura”, como subcadena del nombre “Fecha de la factura” y en la parte inferior de la factura, como subcadena en las condiciones de pago “Current invoice is…”. Por lo tanto, podemos prever que habrá tres hipótesis después del procedimiento de emparejamiento. Después de ejecutar el procedimiento de emparejamiento de FlexiLayout seleccionando el comando Match, vemos que el árbol de hipótesis del grupo InvoiceGroup solo tiene una cadena completa en lugar de las tres esperadas, y la cadena completa de hipótesis que queda no corresponde al nombre que estamos intentando detectar. Si observa las propiedades de cada uno de los elementos de la cadena generada, verá que la Chain quality de cada hipótesis es 1, lo que activó la optimización: cuando el programa detecta una cadena ideal en términos de calidad (es decir, con calidad 1), deja de generar hipótesis.
Para ver el árbol de hipótesis del grupo, haga doble clic en el nombre del elemento de grupo en el árbol de hipótesis, pulse Enter o seleccione Mostrar detalles en el menú contextual.
El algoritmo del programa es el que determina por qué, en la fase de generación de hipótesis, un objeto de la imagen es preferible a los demás. Como los resultados del emparejamiento de FlexiLayout no son satisfactorios, debemos analizar las causas del problema y decidir cómo resolverlo. En primer lugar, no limitamos el área de búsqueda del elemento InvoiceHeader. En segundo lugar, al describir el elemento InvoiceNumber, especificamos que la cadena de dígitos podía tener cualquier longitud (porque no conocemos la posible longitud del número de factura). También especificamos que debía buscarse a la derecha del nombre, aproximadamente al mismo nivel horizontal. Como puede ver, las tres instancias de la palabra “Invoice” cumplen estas condiciones. Por eso, la detección incorrecta del nombre provocó automáticamente la detección incorrecta del campo “Número de factura”. Debe añadir algunas restricciones adicionales, para que al final la hipótesis correcta sea la mejor y el FlexiLayout sea óptimo no solo en términos de velocidad de emparejamiento.” Si asumimos que la disposición de los campos es idéntica en todas las páginas del proyecto, la forma más sencilla es «decirle» al programa que necesitamos la cadena «Invoice», que es el elemento más cercano al borde derecho de la página. Así, escribimos el siguiente código en la sección relación avanzada de prebúsqueda del elemento InvoiceHeader: Nearest: PageRight;. Podemos hacerlo porque el nombre del campo buscado «Número de factura» es el único elemento más cercano al borde derecho de la página. Si no fuera así o si el documento no estuviera formalizado, la función Nearest no podría ayudarnos a resolver el problema. Para mostrar formas alternativas de realizar esta tarea, incluido el caso de un documento semiestructurado, creamos el proyecto GO.fsp (carpeta GO\2). Como puede ver en las imágenes, la distancia entre la cadena de dígitos y la palabra “invoice” es la menor en el campo buscado “Número de factura”. Esto se cumple en todas las páginas, lo que nos permite influir en los valores de calidad de las hipótesis generadas introduciendo el siguiente código en la sección Relaciones avanzadas de posbúsqueda del elemento InvoiceNumber: if (not InvoiceHeader.IsNull) and (not IsNull) then { FuzzyQuality: Rect.Left - InvoiceHeader.Rect.Right, {0, 0, 0, 10000}*dt; } Esto significa que, si se detectan ambos elementos, se calcula la distancia entre ellos para la hipótesis del elemento InvoiceNumber, y el programa comprueba si pertenece al intervalo {0, 0, 0, 10000}*dt. Esta descripción del intervalo muestra la dependencia lineal entre la calidad de la hipótesis y la distancia entre los elementos: cuanto mayor sea la distancia, mayor será la penalización (la función FuzzyQuality define la calidad de posbúsqueda de la hipótesis; puede verse en la ventana Propiedades de la hipótesis). El valor del límite derecho del intervalo (10000dt) se determinó experimentalmente. Al elegir este valor, debe tener en cuenta la distancia entre los objetos correspondientes en las imágenes de prueba. Como puede verse en la imagen siguiente, con las propiedades del intervalo especificadas, la penalización máxima (1) corresponderá a una distancia de 10000dt. En consecuencia, una distancia de 1000dt dará una penalización de 0,1; una distancia de 100dt, una penalización de 0,01; etc. Así, para distancias reales de aproximadamente 100-300 dot, que podemos ver en nuestras imágenes, el coeficiente de penalización será de 0,99 a 0,97.
Consulte Uso de Nearest y FuzzyQuality para buscar elementos para obtener más información sobre el uso de estas funciones.
Para las imágenes de este lote, la hipótesis correspondiente al campo no deseado “Número de factura” con el valor “2005” recibió la penalización máxima, mientras que la hipótesis correspondiente al campo buscado recibió la penalización mínima. Dado que la penalización hizo que la calidad de posbúsqueda de todas las hipótesis fuera distinta de 1, ahora se analizarán todas las hipótesis de ambos elementos del elemento de grupo InvoiceGroup. Tenga en cuenta que el campo “Número de factura” se detectó correctamente incluso en la página 2, donde el nombre “Invoice” tiene mucho ruido, lo que provocó un error de reconocimiento y, en consecuencia, penalizaciones adicionales para la hipótesis.