Carlos,
Por partes, como diría el carnicero de York:
[quote="Carlos Mora":1sjoanec]Hola Paquito,
En su momento busque mimetizar la definición de los fonts al máximo, pero hay que considerar que buscar esa compatibilización tiene tres aspectos importantes.
Primero, la dificultad de lo que propones. Es muy muy muy complejo gestionar los fonts siguiendo los parámetros de Windows. Y lo sé positivamente porque estuve tratando de ayudar al auto de la Image2Pdf.dll que transforma los emfs a pdf. No logró hacer una buena transformación de las fuentes porque los nombres cambian segun el idioma, y no coinciden con el nombre del fichero .ttf correspondiente. Por ejemplo una Arial de peso 700 puede usar el arial.ttf recargado por el SSOO o el arialb.ttf en modo normal, depende de la versión de ssoo y del idioma. En algunos casos el tema del peso es una cuestion propia de la fuente, igual que si es itálica, negrita, etc. que a veces viene en diferentes fuentes, y en otras Windows la gestiona internamente. Al final dejé de usar la image2pdf porque la única forma de que generase pdfs que fueran i´magen fiel de la impresión era hacer un bmp a partir de emf e incluir la imgen en el pdf, con las desventajas que eso suponia: tamaño del pdf, no poder seleccionar texto ni procesar el texto del pdf, etc. Créeme que el tema fonts es extremadamente complejo, y te vas a ahorrar muy poco y vas a perder en optimización. [/quote:1sjoanec]
Un camino un poco parecido seguí yo. Contacté con el creador de img2pdf.dll, y cuando me dijo, o eso entendí yo del inglés, que para los pdfs. había que tener algunas fuentes instaladas y que podrían no mostrarse bien o distintas, ya no seguí con la herramienta. No podía tener pdfs que dentro de N años no se mostraran bien porque el SO hubiera cambiado.
[quote="Carlos Mora":1sjoanec]
Segundo, de esa manera pierdes los aspectos positivos de gestionar tu mismo las fuentes en el pdf: puedes decidir tu si incluyes o no la fuente en el pdf, cuales si y cuales no, que te permite jugar con los resultados. Además de esta manera no requiere que tengas instalada la fuente en Windows para poder usarla (en el ejemplo, para imprimir el codigo de barras no hace falta instalar la fuente correspondiente en Windows).
Otro aspecto a tener en cuenta: tal y como está la librería se puede usar en modo consola, independizándote de la librería gráfica, algo que la despega de vincularse con la definición de fuentes. De hecho, la intercepción de las fuentes tal y como lo sugieres apunta a modificar la librería gráfica, que es la que "sabe" como vincula los parámetros con las librerias del sistema operativo.
Lo único diferente en el uso de la librería es la declaración de la clase Printer, y la definición de las fuentes, el resto es 100% compatible. Es decir que estamos hablando de 1 comando por cada fuente + 1 para la definición de la impresora, virtualmente nada.[/quote:1sjoanec]
Mi intención es que pdfPrinter sea compatible 100% con TPrinter, de manera que cambiando el constructor funcione todo. Pretendía tener una salida automática a pdf, compatible con el código existente que ya tengo usado para el dispositivo TPrinter, pero en mis fuentes hay definicion de fonts en multiples sitios y no todos al principio del programa.
[quote="Carlos Mora":1sjoanec]
Si alguien quiere encarar el desafío, por supuesto que contará con mi apoyo, el 100% del código está disponible en el repositorio.[/quote:1sjoanec]
Debe ser mi ignorancia, pero pensé que no era demasiado difícil, y que se trataria de:
1. Buscar fichero fuente .ttf según si normal/ bold/ italic
2. Si no encuentra fichero, aplicar el mas parecido
3. Sacar lista con aquellos que no coinciden para ir perfilando
Se podria hacer una lista de archivos .ttf según version Windows e idioma de Windows.
Aquí siguen la estrategia de cambiar a Courier New cuando encuentran un font no existente.
Lo curioso es que Word transforma a pdf con exactitud 100%. ¿ Es que va a ser Word más que nosotros ?
Saludos.
↧