11 de julio de 2017

Observaciones sobre etiquetas alineadas a la derecha en informes de VFP 9.0

Artículo original: Observations on Rightaligned labels in VFP9 Reports
http://www.spacefold.com/colin/archive/articles/vfp9reporting/rightalign/monofonts.html
Autor: Colin Nicholls
Traducido por: Ana María Bisbé York


Introducción

Este artículo se basa en un trabajo que realicé tratando de contestar a una pregunta realizada por Alejandro Sosa en Universal Thread. Alex estaba teniendo problemas al alinear correctamente a la derecha títulos con campos/expresiones alineados a la derecha. Su informe era complejo y migraba desde una versión antigua de FoxPro, por lo que he creado una prueba sencilla para mostrar lo que ocurría.

Revisando: REPORTBEHAVIOR

En Visual FoxPro 9.0, existe un nuevo motor de informes que emplea GDI+ para generar la salida. Sin embargo, está soportado el motor viejo, con compatibilidad hacia atrás. Puede alternar entre los dos motores al vuelo empleando el comando SET REPORTBEHAVIOR.

Revisando: Fuentes con un único espacio contra fuentes proporcionales

Las fuentes que emplean igual espaciado tienen un ancho constante para todos los caracteres en dependencia de una altura dada. Las fuentes proporcionales utilizan anchos variables apropiado para hacer la fuente más legible. En este artículo verá la diferencia de forma muy simple: Los textos son proporcionales y los trozos de código están todos en formato de espacio único.

Resumen

En REPORTBEHAVIOR=90, todas las etiquetas de texto se van a generar con longitudes mayores que las que puede esperar al ver el Diseñador de informes. Esto se debe a que la generación de texto con GDI+ emplea más espacio. Las etiquetas sufren por esto, debido a que los diseños almacenan su posición inicial exacta, lo contrario a los campos / expresiones que permiten calcular la alineación a realizar por el motor, utilizando GDI+.

Lea más para detalles.

Observaciones

Datos de prueba

Quise comparar la alineación a la derecha para ambos tipos de valores: cadena y números, así que creé dos columnas en mi cursor de pruebas:

CREATE CURSOR x ( ftitle C(10), fnumb N(8,2) )
INSERT INTO x VALUES ( 'Bagels', 32.45 )
INSERT INTO x VALUES ( 'Cucumber', 5.23)
El informe de prueba

He aquí una imagen del informe de prueba, abierto en el diseñador, con los controles etiqueta seleccionados para mostrar sus posiciones exactas. He empleado líneas rojas para mostrar los ejes de alineación:

El control campo/expresión para los campos FTITLE y FNUMB tienen que ser configurados con Justificación: Derecha, el campo tiene que ser configurado manualmente: el campo numérico está alineado a la izquierda predeterminado. Puede ver que tengo visualmente alineadas las etiquetas con el final de cada control de campo/expresión. He duplicado el diseño de estos controles para cada una de las fuentes diferentes. Tahoma y Candara son fuentes proporcionales, y Courier New, Bitstream Vera Sans Mono y Consolas son mono espaciadas.[1]

Con REPORTBEHAVIOR 80

Así se ve la Presentación preliminar con REPORTBEHAVIOR = 80:

Y el resultado impreso

Asumiendo que las líneas rojas son una referencia exacta, se puede ver que los mejores resultados se ven con Courier New y Vera Sans Mono. Consolas y las fuentes proporcionales al parecer exceden sus posiciones esperadas ligeramente. Por tanto, debe estar muy ajustada la tolerancia para una salida aceptable, al utilizar estos tipos de fuente, o será un gran problema.

Con REPORTBEHAVIOR 90

He aquí cómo se ve la Presentación preliminar con REPORTBEHAVIOR = 90:

y el resultado impreso

Conclusiones

Es fácil ver desde la comparación que con REPORTBEHAVIOR = 90, todas las etiquetas de texto exceden su longitudes esperada, no sólo en las fuentes no espaciadas. Sin embargo, el efecto es definitivamente más pronunciado en fuentes mono espaciadas.

¿Por qué ocurre esto para etiquetas y no para para campos/expresiones?

Con REPORTBEHAVIOR = 90, el nuevo motor de informe utiliza GDI+ para generar la salida, y la generación de las cadenas de textos necesitan más espacio que la forma plana del viejo GDI. Escribí sobre por qué GDI+ necesita espacio adicional antes de las cadenas de texto: http://www.spacefold.com/colin/posts/2005/08-18GDIplusinreports.html

El Diseñador de informe utiliza GDI - no GDI + para generar los componentes del diseño del informe, incluyendo todas cadenas de texto que ve. Entonces, si visualmente ha justificado a la derecha un elemento de informe, el diseñador de informe guarda la coordenada más izquierda del elemento (la posición inicial del texto) en el diseño. La longitud de la cadena generada por GDI+ será mucho más grande que lo que cree, basada en que es lo que ve en el Diseñador.

No hay dudas del hecho de que tiene que tener en cuenta este efecto al diseñar sus controles etiqueta en los informes.

Ahora, verá que este problema no ocurre con los controles campo/expresiones. Ellos están todos alineados correctamente, debido a que el Diseñador de Informe, no especifica una posición exacta para la cadena de texto, pero sí especifica la caja donde el texto va a ser generado. Entonces, el cálculo de la alineación tiene lugar en el motor de informe, mientras GDI+ tiene en cuenta el tamaño del texto.

Notas al pie:

[1] Candara y Consolas son fuentes nuevas de Microsoft, distribuidas con Windows Vista.

Agradecimientos:

Gracias a Alex Sosa por su pregunta tan interesante.

No hay comentarios. :

Publicar un comentario

Los comentarios son moderados, por lo que pueden demorar varias horas para su publicación.