Por qué debe enumerarse cada variante de texto estático
Esto es necesario por las siguientes razones:- Para generar una hipótesis correspondiente al valor especificado. Por ejemplo, si no especifica la variante Factura: y solo la variante Factura, los dos puntos no se incluirán en la hipótesis del nombre del campo. Entonces podrían quedar incluidos en el área de búsqueda del número de factura, que se busca a la derecha del nombre. Si la búsqueda del número permite caracteres no numéricos o no especificados, los dos puntos pueden acabar en la hipótesis del elemento que describe el número de factura.
- Para evitar penalizar una hipótesis por caracteres no especificados en la ventana Texto a buscar. Por ejemplo, si el valor Factura: se especifica en la sección Texto a buscar y el nombre Factura# también aparece en las imágenes procesadas, entonces, siempre que se permitan algunos errores para el elemento, se seguirá generando una hipótesis, pero su calidad se penalizará (en este ejemplo, el FlexiLayout permite al menos un error).
- Si hay hipótesis variantes disponibles, por ejemplo, Factura|Factura:, FlexiLayout Studio asignará a la hipótesis más larga una calidad ligeramente superior, de modo que la hipótesis Factura: será la preferida. Si se especifica una variante con dos puntos, la que no los tenga será penalizada en 0.001, porque la cadena Factura es una subcadena de Factura:. Penalizar la cadena más corta del nombre, que es una subcadena de la otra, hace que la hipótesis más larga sea la ganadora.
El proyecto de ejemplo StaticText.fsp
Usemos el proyecto de ejemploStaticText.fsp (carpeta %public%\ABBYY\FlexiCapture\12.0\Samples\FLS\Tips and Tricks\Variants of StaticText) para ver cómo especificar los valores de un elemento de texto estático ayuda a detectar el nombre del campo Número de factura y el propio campo.
El proyecto tiene cinco páginas, cada una de las cuales muestra una variante del nombre del campo Número de factura.
Especifique todas las variantes del nombre en el elemento InvoiceHeader
En el cuadro de diálogo de Propiedades del elemento de texto estático llamado InvoiceHeader, hemos especificado todos los nombres posibles del campo que puede encontrarse en los documentos procesados, en este caso, los valores mencionados anteriormente. El uso de mayúsculas y minúsculas en los nombres es irrelevante para la búsqueda: Factura|Factura:|Factura#:|Factura-.Para acelerar la búsqueda del elemento, todas las variantes se escriben sin espacios. La ausencia o presencia de espacios no influye en la calidad de una hipótesis.
Elimine todos los valores excepto Factura y vuelva a hacer el emparejamiento
Ahora intente eliminar temporalmente todos los valores de texto estático excepto el primero (Factura) del elemento InvoiceHeader y, a continuación, vuelva a intentar emparejar el FlexiLayout con todas las páginas. Verá que el nombre y el número de factura se detectaron correctamente solo en la página 1, porque allí el nombre coincide por completo con el valor especificado (Factura). En las páginas 2-4, una parte del nombre pasó al número de factura. En la página 5, hubo un error al localizar el campo del número.
Restaure los valores y compare las hipótesis de la página 5
Ahora restaure los valores eliminados y observe los resultados del análisis en la página 5, donde la palabra Factura aparece dos veces. Como puede ver, FlexiLayout Studio generó cinco hipótesis para el elemento InvoiceHeader. La calidad más alta (calidad de la cadena = 1, que, en este caso, es igual a la calidad de prebúsqueda) se asigna a la hipótesis correspondiente al nombre Factura:. También se generaron hipótesis para los valores Factura y Factura d, porque estas cadenas derivan de los valores especificados para el elemento InvoiceHeader, para el cual se permite un cierto porcentaje de errores. Estas hipótesis fueron penalizadas por las razones descritas anteriormente en esta página, por lo que su calidad final es menor.