Raro resultado al convertir mm a pixels para usar con QuickRepor

[rolandoj]

Hola Casimiro,

Si, ese es el problema. Por eso pregunto aquí.

Es que la lógica indica que para tener una vista preliminar en pantalla, como lo hace QuickReport, las posiciones y tamaños de los campos en mm deben ser las que efectivamente se van a imprimir; pero, en pantalla se despliega en Pixels (y las medidas de los componentes QuickReport están en pixels), luego deben convertirse los mm a pixels.

Como hacerlo es el problema. El método que empleo es lo lógico; pero, como dije antes, la evidencia indica que no es el mismo que usa Quick Report. La gran pregunta es por qué ? (bueno, y por supuesto, que método usa '). En este momento ni siquiera se me ocurre una razón para usar un método distinto.

[[Lepe]]

Todos los generadores de informes que conozco, trabajan en twips ( 1 pulgada tiene 1440 twips si no recuerdo mal), ya que es una medida independiente del dispositivo (papel, impresora, pantalla, escaner). Para colmo de males, se tiene en cuenta la propiedad del Form PixelPerInch (varía al usar fuentes grandes o normales en windows).

Cuando trabajé con Reportman (la versión OpenSource), usé estas conversiones:

                   1440 twips                          2.54 cms
twips_per_Inch  = ------------        cms_per_Inch =  ---------
                   1 Inch                               1  Inch

                    72  pixels
pixels_per_inch = -----------
                     1 inch
-----------------------------------------------------------------------------}

Estas rutinas están hechas por mí (editado, porque me equivoqué antes):

Código Delphi [-]
const
 CMS_PER_INCHESS=2.54;
 TWIPS_PER_INCHESS=1440;
 POINTS_PER_INCHESS=72;


function PixelsToTwips(apixels:integer):integer;
begin
  Result:=Round((APixels/(Screen.PixelsPerInch))* TWIPS_PER_INCHESS);
end;

function TwipsToPixels(atwips:integer):integer;
begin
  Result:=Round((atwips *Screen.PixelsPerInch) / TWIPS_PER_INCHESS);
end;

Estas otras, son de ReportMan (Open Source):

Código Delphi [-]
type 
TRpTwips=integer;
function twipstoinchess(twips1:TRpTwips):double;
begin
 Result:=twips1/TWIPS_PER_INCHESS;
end;

function twipstocms(twips1:TRpTwips):double;
begin
 Result:=(twips1/TWIPS_PER_INCHESS)*CMS_PER_INCHESS;
end;

Te recomiendo (por el bien de tu salud mental ) uses siempre una sola unidad, todo en twips, y, si tienes que mostrar algo al usuario, entonces haces al conversión a pixels o pulgosos.

Saludos

[rolandoj]

Hola Lepe,

Muchas gracias por el dato.

Toca analizar esto con calma; empezando porque yo nunca he trabajado en pulgadas.

Por otra parte, no entiendo la necesidad de pasar la escala a trabajar con pulgadas; en últimas las pulgadas son covertibles a mm y lo máximo que debería haber de diferencia son errores de redondeo.

Entiendo que los generadores trabajen internamente así porque pulgadas sea la unidad de medida de sus países; pero, por eso no debería haber diferencias

Lo que más me causa curiosidad es que ese método que muestras parece operar ignorando que, en general, la resolución horizontal de pantalla es distinta a la resolución vertical; como es indicado por la función GetDeviceCaps que yo estoy usando.

Puede que tengas razón en lo de cuidar la salud mental; pero, no me gusta hacer cosas sin entender la razón de las mismas. Para mi el aspecto conceptual es importante más allá de que operativamente las cosas funcionen.

[anubis]

Bueno si me lo permitis, he visto el mismo problema con los informes de fortesreport en lazarus.
Como sabeis para crear un report lo tienes que añadir a un form (por lo menos lo hago asi) y luego le voy poniendo los campos.

Bueno, segun la hoja que le puse 1 cm de margen, coloco el label a un cm y ahi me marca 40 pixels.

Por el otro lado, tenia algun report ya creado e impreso, y compare las medidas, mas o menos se ajustan a 40 pixeles, en algunos casos, 3.6, nose si se ajusta a la realidad.

De todas formas probare el metodo que comentais .

[rolandoj]

Hola Anubis,

Muchas gracias por el aporte.

Con eso, el asunto me intriga más.

Ojalá algún colega pueda traer una explicación. Tiene que existir alguna razón en el fondo de este asunto; pero, no deja de ser muy raro.

Milímetros y pulgadas son medidas exactas independientemente de si estamos en un monito o sobre un papel. El pixel si cambia segùn el monitor y la resolución que tenga; pero, como las anteriores son exactas, el mètodo para convertir de una resolución específica de un monitor específico a ellas debería ser el mismo; y hasta donde sé debería usar el GetDeviceCaps de Windows que se supone que se implementó para soportar ese tema.

Saludos

[[Lepe]]

rolandoj, se ve que no has entendido mi mensaje anterior. La unidad por excelencia en generadores de informes es el twip, ni pulgadas, ni milímetros, repito es el twip.

Si no entiendes por qué, entonces crea tu propio generador de informes, desde cero, y seguro en algún punto, entenderás por qué nació el twip.

No te enfoques en "como tú crees que debe ser", enfócalo de la misma forma que FreeReports, FastReport, QuickReport, Reportman, Crystal Reports y todo parece que fortesreport también. Se necesita una unidad de medida que sea lógica, que no dependa de ninguna unidad física ni dispositivo, por eso se creó el twips (ni dependa de mm, ni inch, ni nada). Ten en cuenta que casi todos tratan un informe como una imagen (al fin y al cabo tienen que pintar en distintos dispositivos físicos). No te centres en el papel que sale... céntrate en el formato interno que la impresora tiene que diseñar para luego decirle al cabezal donde y como debe imprimir.

Piensa en los scaners, que tienen distinta profundida de escaneo (dpi 300 pixels por pulgada, 600, etc). Si una pulgada se escanea con 300 puntos de calidad, no es lo mismo que a 600. Por eso se creó la unidad twip. Porque así lo pasas todo a twips y trabajas sin importar la calidad del dispositivo que muestra el informe (monitor de 17 ó de 22 pulgadas, ancho o extra-ancho, con relación de aspecto 16:9, 4:3 ó 16:10... eso da igual, lo ponemos todo en twips y listo.

[rolandoj]

Hola Lepe,

Gracias por ampliar tú explicación. Me diste una idea:

La posibilidad de que las propiedades de los componentes QuickReport estén en twips y no en pixels como yo pensaba. Esa hubiese sido una explicación perfecta para las diferencias; sin embargo, verifiqué y no es cierto. Las propiedades Height y Width de la banda están en Pixels.

Ahora, creo que yo también debo ampliar la explicación de mi objetivo.

La impresión final la manejará QuickReport, e internamente manejará twips; pero, a mi lo que me interesa es tener posiciones y dimensiones de los campos sobre el panel para crear, a tiempo de ejecución, los TLabels, a partir de los cuales se generarán los respectivos TQRLabels que irán sobre la franja

Las posiciones y dimensiones tanto de la franja como los TQRLabels las expone QuickReport en Pixels. En el caso de los TQRLabel puedo entonces asignar directamente las propiedades de sus TLabels análogos; pero, en el caso de la banda es diferente porque las propiedades que demarcan los márgenes las expone en MM (bueno, pueden usarse otras unidades; pero, ninguna es TWIP).

Por tanto, el verdadero problema es calcular el ancho del panel en pixels teniendo como entradas el ancho de la hoja en pixels y el ancho de los márgenes en MM. Por eso es que lo que realmente interesa es pasar de MM a Pixels.

Ahora, lo que tú propones es pasar primero de MM a twips para luego pasar de twips a Pixels. Debería ser lo mismo que pasar de MM a Pixels directamente; pero, hay un detalle :

Las fórmulas que indicas son en función PixelsPerInch. Ignoran el hecho de que el tamaño horizontal del pixel podría ser diferente del tamaño vertical; lo que estaría diciendo que con esas fórmulas las dimensiones físicas en pantalla podrían no coincidir con las de papel y eso es lo que no entiendo porque se supone que las dimensiones físicas deben ser idénticas.

Si se estuviera aplicando un Zoom sería entendible; pero, estamos en un escenario de tamaño natural.

Bueno, de todas formas voy a probar y les cuento si coincidieron