https://drive.google.com/open?id=0B3uWe ... k9pZEdNR0k
El repositorio GIT refleja las correcciones
Carlos Mora wrote:https://drive.google.com/open?id=0B3uWeESvC613ajdOak9pZEdNR0k
El repositorio GIT refleja las correcciones
Bien! Gracias por las pruebas.
Habras notado que el tamaño del pdf pasó de 10Kb a 15Kb. Eso es porque ha embebido la fuente del codigo de barras. Si tienes instalada la fuente del codigo de barras en el Windows de tu ordenador, no es necesario incluir la fuente en el pdf, con lo que mejoras el tamaño final.
Espero que puedas hacer tus propias pruebas y me hagas llegar tus comentarios.
Un saludo
Hola Carlos,
Trasteando la clase, veo que la definicion de los fonts es distinta a como hacemos en Fwh: DEFINE FONT "Arial" BOLD ITALIC... Con pdfPrinter creariamos el font solo con el nombre y el tamaño DefineFont(). Parece que el nombre ha de cambiar para incluir las propiedades o no de Bold e Italic.
¿ Crees que es posible hacer una compatibilizacion entre fonts Fwh (Win32) y fonts haruPdf ?
Se trataria de que con los menos cambios posibles se pueda incorporar a un programa (fuente) existente el manejo de pdf con tu pdfPrinter, utilizando los mismos fonts usados en Fwh (Win32)
Para ello habia pensado en "interceptar" los metodos que usan fonts, y redefinirlos en THaruPdf.prg y hacer ahi toda la conversion de fonts: convertir de font fwh/Win32 a font pdf. Ahora mismo creo que solo seria el metodo ::CmSay()
Habria que solucionar el problema de las fuentes que han de ser añadidas con AddFont... pero quiza haciendo un hash con nombre de fuente y nombre de fichero .ttf en disco seria suficiente, y asi segun fuente que viene, si no es Base14, se incorpora con AddFont(), si no esta ya incorporada, claro esta.
¿ Que te parece ?
Saludos
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.
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.
Si alguien quiere encarar el desafío, por supuesto que contará con mi apoyo, el 100% del código está disponible en el repositorio.
Un saludo
Carlos Mora wrote: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.
Carlos Mora wrote:
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.
Carlos Mora wrote:
Si alguien quiere encarar el desafío, por supuesto que contará con mi apoyo, el 100% del código está disponible en el repositorio.
hmpaquito wrote:
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.
hmpaquito wrote:
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.
hmpaquito wrote:
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
hmpaquito wrote:
3. Sacar lista con aquellos que no coinciden para ir perfilando
hmpaquito wrote:
Se podria hacer una lista de archivos .ttf según version Windows e idioma de Windows.
hmpaquito wrote:
Aquí https://community.microstrategy.com/t5/ ... a-p/207606 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 ?
Gracias por tu ejemplo, lo he tratado de compilar pero me genera errores.
el archivo DemoPdf.xpj DemoPdf.xdt DemoPdf.tds que herramientas usas para verlo, este es el que compila.
creo mi compilacion con .mak Pero me genera estos errores.
Turbo Incremental Link 6.70 Copyright (c) 1997-2014 Embarcadero Technologies, Inc.
Error: Unresolved external '_HPDF_UseUTFEncodings' referenced from K:\HARBOUR\LIB\HBHPDF.LIB|core
Error: Unable to perform link
Hola!
Me alegra que lo estés probando.
Esa es una función que está en libhpdf.lib. Está en el directorio Lib.
¿Puedes subir tu .mak? Así lo chequeamos y vemos que puede ser. De paso lo añadimos al ejemplo.
Un saludo
Rubén,
La solución es que enlace la libreria libhpdf.lib del harbour que está usando y NO la que provee Carlos con pdfPrinter.
Dicho de otro modo: usar Harbour\lib\libhpdf.lib y NO USAR pdfPrinter\lib\libhpdf.lib
Para evitar más conflictos habría que quitar esa librería del directorio lib de distribución de pdfPrinter.
La explicación de lo que ocurre: probablemente la libreria libhpdf.lib que viene con pdfPrinter es MAS moderna que la del harbour que utilizas para montar la aplicacion.
Saludos
HBDIR=k:\harbour
BCDIR=k:\bcc582
FWDIR=k:\fwh
fprg =c:\temp\DemoPdf
.path.obj = .\obj_h
.path.prg = .\Source
.path.ch = $(FWDIR)\include;$(HBDIR)\include;$(fprg)\include
.path.c = .\lc
.path.rc = .\rc
.path.res = .\rc
HFLAG1 = /n /m /es2 /gc1
HCLAG1 = -c -tWM
CINCLU = $(HBDIR)\include;$(fprg)\include;$(FWDIR)\include
CINCL1 = $(HBDIR)\include
CINCL2 = $(BCDIR)\include
OBJFIL = .\obj_h
NOMEXE = DemoPdf
LIBFIL = $(fprg)\lib
DEFX=__HARBOUR__
DEXP=__EXPORT__
EXTLIBFILES =
DEFFILE =
HBFLAGS = -w0
CFLAG1 = -OS $(SHELL) $(CFLAGS) -d -c -L$(HBDIR)\lib
RFLAGS =
LFLAGS = -L$(BCDIR)\lib\obj;$(BCDIR)\lib;$(HBDIR)\lib -Gn -M -m -s -Tpe -x -ap
IFLAGS =
LINKER = ilink32
#ALLOBJ = c0x32.obj $(OBJFILES) $(OBJCFILES)
ALLOBJ = $(OBJS) $(COBJS)
ALLRES = $(RESDEPEN)
ALLLIB = $(LIBFILES) import32.lib cw32.lib
#important: Use Uppercase for filenames extensions, in the next two rules!
PRG = \
.\DemoPdf.prg \
.\i2of5txt.prg \
#.\THaruPDFBase.prg \
#.\THaruPDF.prg \
#.\HaruFonts.prg \
C = \
CPP = \
OBJ=$(PRG:.prg=.obj)
OBJS=$(OBJ:.\=.\obj_h\)
COBJ=$(C:.c=.obj)
COBJS=$(COBJ:.\=.\obj_h\)
COBJ=$(CPP:.cpp=.obj)
COBJS=$(COBJ:.\=.\obj_h\)
PROJECT : $(NOMEXE).exe
$(NOMEXE).exe : $(OBJS) $(COBJS)
echo off
echo $(BCDIR)\lib\c0x32.obj + > b32.bc
echo $(OBJS) $(COBJS), + >> b32.bc
echo $(NOMEXE).exe, + >> b32.bc
echo $(NOMEXE).map, + >> b32.bc
echo $(HBDIR)\lib\hbrtl.lib + >> b32.bc
echo $(HBDIR)\lib\hbvm.lib + >> b32.bc
echo $(HBDIR)\lib\hblang.lib + >> b32.bc
echo $(HBDIR)\lib\hbmacro.lib + >> b32.bc
echo $(HBDIR)\lib\hbrdd.lib + >> b32.bc
echo $(HBDIR)\lib\rddntx.lib + >> b32.bc
echo $(HBDIR)\lib\rddcdx.lib + >> b32.bc
echo $(HBDIR)\lib\rddfpt.lib + >> b32.bc
echo $(HBDIR)\lib\hbsix.lib + >> b32.bc
echo $(HBDIR)\lib\hbdebug.lib + >> b32.bc
echo $(HBDIR)\lib\hbhpdf.lib + >> b32.bc
echo $(HBDIR)\lib\hbcommon.lib + >> b32.bc
echo $(HBDIR)\lib\hbpp.lib + >> b32.bc
echo $(HBDIR)\lib\hbcpage.lib + >> b32.bc
echo $(HBDIR)\lib\hbnulrdd.lib + >> b32.bc
echo $(HBDIR)\lib\hbwin.lib + >> b32.bc
echo $(HBDIR)\lib\hbct.lib + >> b32.bc
echo $(HBDIR)\lib\xhb.lib + >> b32.bc
echo $(HBDIR)\lib\hbcplr.lib + >> b32.bc
echo $(HBDIR)\lib\hbpcre.lib + >> b32.bc
echo $(HBDIR)\lib\png.lib + >> b32.bc
echo $(HBDIR)\lib\hbzlib.lib + >> b32.bc
echo $(HBDIR)\lib\hbmisc.lib + >> b32.bc
echo $(HBDIR)\lib\hbusrrdd.lib + >> b32.bc
echo $(HBDIR)\lib\hbnf.lib + >> b32.bc
echo $(HBDIR)\lib\hbmzip.lib + >> b32.bc
echo $(HBDIR)\lib\minizip.lib + >> b32.bc
echo $(HBDIR)\lib\hbziparc.lib + >> b32.bc
echo $(HBDIR)\lib\hbtip.lib + >> b32.bc
echo $(HBDIR)\lib\libhpdf.lib + >> b32.bc
echo $(HBDIR)\lib\gtwin.lib + >> b32.bc
echo $(BCDIR)\lib\cw32.lib + >> b32.bc
echo $(BCDIR)\lib\import32.lib + >> b32.bc
echo $(BCDIR)\lib\psdk\odbc32.lib + >> b32.bc
echo $(BCDIR)\lib\psdk\msimg32.lib + >> b32.bc
echo $(BCDIR)\lib\psdk\nddeapi.lib + >> b32.bc
echo $(BCDIR)\lib\psdk\iphlpapi.lib + >> b32.bc
echo $(BCDIR)\lib\psdk\psapi.lib + >> b32.bc
echo $(BCDIR)\lib\psdk\ws2_32.lib + >> b32.bc
echo $(BCDIR)\lib\psdk\rasapi32.lib + >> b32.bc
echo $(BCDIR)\lib\psdk\shell32.lib + >> b32.bc
echo $(BCDIR)\lib\psdk\wininet.lib + >> b32.bc
# echo $(LIBFIL)\libhpdf.lib + >> b32.bc
echo $(LIBFIL)\PdfPrinter.lib + >> b32.bc
# echo $(LIBFIL)\png.lib + >> b32.bc
$(BCDIR)\bin\ilink32 -Gn -aa -Tpe -s @b32.bc
del b32.bc
del .\obj_h\*.* /Q
del .\obj_h\*.c /Q
del *.tds /Q
upx $(NOMEXE).exe -9
.PRG.OBJ:
$(HBDIR)\bin\harbour $< $(HFLAG1) -D$(DEXP) -D$(DEFX) /O$(OBJFIL)\ /I$(CINCLU)
$(BCDIR)\bin\bcc32 $(HCLAG1) -I$(CINCL1) -o$(OBJFIL)\$& $(OBJFIL)\$&.c
.C.OBJ:
echo $(HCLAG1) -D$(DEFX) -DHB_API_MACROS > tmp
echo -I$(HBDIR)\include;$(FWDIR)\include >> tmp
$(BCDIR)\bin\bcc32 -o$(OBJFIL)\$& @tmp $<
del tmp
.CPP.OBJ:
echo $(HCLAG1) -D$(DEFX) -DHB_API_MACROS > tmp
echo -I$(HBDIR)\include;$(FWDIR)\include >> tmp
$(BCDIR)\bin\bcc32 -o$(OBJFIL)\$& @tmp $<
del tmp
$(NOMEXE).res : $(NOMEXE).rc
# $(BCDIR)\bin\brc32.exe -r -I$(BCDIR)\include $(NOMEXE).rcEstimado Ruben
La lib libhpdf.lib es la librería Haru propiamente dicha, hbhpdf.lib es la que viene en el contrib con Harbour. Seguramente hay que tener la libhpdf apropiada para la version de hbhpdf.lib que estés usando. En el ejemplo que puse, todo está compilado con Harbour 2.1 rc 2, por ahí tal vez la he liado más que ayudado.
Mira el lado positivo: Si compila con el viejo Harbour, con mayor razón lo hará con el nuevo 
.
Por supuesto que lo apropiado sería recompilar la librería para tu entorno de desarrollo. Tenemos disponible el 100% del código, está en GitHub. He subido un .mak para reconstruir la lib, al menos con bcc. Hay que modificarlo para apuntar a los directorios correctos de Harbour y BCC
Los archivos HaruPdfBase.prg, HaruPdf.prg y HaruFonts.prg son los que están dentro de la librería PdfPrinter, si ves complicado reconstruir la lib tambien puedes añadir los prgs directamente a tu proyecto.
Creería que se puede recompilar con xHarbour, yo no lo uso, pero tampoco se usan cosas demasiado especiales en la librería, debería funcionar con solo campiar el path del compilador.
Loa archivos DemoPdf.xpj DemoPdf.xdt son los archivos de proyecto de xEdit, el IDE que uso para programar.
Muchas Gracias por Tu informacion Carlos, pero me esta funcionando mu bien con Harbour Excelente.
Voy hacer pruebas con xHarbour y te cuento.
Ya quite la libreria y Adjunte los 3 archivos que me dices y funciona perfectamente.
tu tienes mas ejemplos, por ejemplo, leer una base de datos y generar un reporte normal, como de define el tamaña de papel, la documentacion sobre todos estos parametros donde los puedo conseguir.
Hola Rubén,
En general, para adaptar una función (es decir, código que ya existe), debemos cambiar la definicion de la printer y las fuentes. El resto lo dejamos como lo hacíamos con la TPrinter.
Puede que surja algo que no esté implementado, como te imaginarás esto lo fuí construyendo a medida que surgían las necesidades del equipo de trabajo.
Como en la misma documentación se recomienda, puedes crear/usar la clase THaruPdf para insertar tu código, probar correcciones, etc. sin tener que modificar la clase original. Eso se llama 'variaciones protegidas' y es una técnica muy práctica, porque por ejemplo podríamos escribir en ella un nuevo metodo o corregir alguno ya existente mientras esas incorporaciones se añaden a la versión "oficial".
Si lo que te refieres es a la clase TReport, hay un par de cuestiones que en su momento me impidieron usarla y desde ahí no he vuelto a intentarlo. Esas limitaciones estaban dadas porque la clase TReport en algún momento accede al dispositivo de impresión directamente, sin pasar por la clase TPrinter, por lo que no era posible simular con la THaru el comportamiento. Si se pudiese inyectar, pff... sería estupendo.
Otra cosa que sería interesante es avanzar con el visualizador de pdf que algún compañero publicó en el foro. Con eso ya nos quedaría una preview dpm, y con el pdf ya generado.
Comenta lo que te surja y seguro lo iremos resolviendo.
Gracias Carlos Mora.
Ya tambien logre que se genere en xHarbour
se debe colocar la libreria libharu.lib que esta en xHarbour\lib en Harbour es esta libhpdf.lib
y el el fuente hacer esta modificacion
METHOD GetImageFromFile( cImageFile )
IF HHasKey( ::hImageList, cImageFile ) //con harbour es HB_HHasKey como esta el fuente original
RETURN ::hImageList[ cImageFile ]
ENDIF
Te pregunto este archivo i2of5txt.ttf se usa para el manejo solamente de codigo de barras.
nunca he manejado codigo de barras
segun tu codigo
HaruAddFont( 'Arial Black', 'ariblk.ttf' )
HaruAddFont( 'i2of5txt', 'i2of5txt.ttf', .T. )
i2of5txt.ttf si esta en el codigo que publicaste , pero ariblk.ttf no esta , de donde lo toma el sistema como lo consigo o lo toma directamente del C:\Windows\Fonts.
Con resoecto al codigo de barras nunca he manejado esto necesitaria documentarme.
pero generas el codigo de barras con esta instruccion.
:CmSay( nOffset + 13.5, 8.9, i2of5Encode( i2Of5('30666666666009000466110123456789'+DtoS(Date()) ) ), oFont2of5 )
dicha barra que genera la puede leer cualquier lector, en este caso que informacion mostraria el lector, o mostaria esta informacion '30666666666009000466110123456789'+DtoS(Date()
perdona la pregunta pero en realidad desconosco este majeno.
Gracias por todo.