Felices reyes!

[Carlos Mora]

https://drive.google.com/open?id=0B3uWe ... k9pZEdNR0k

El repositorio GIT refleja las correcciones

[karinha]

https://drive.google.com/open?id=0B3uWeESvC613ajdOak9pZEdNR0k

El repositorio GIT refleja las correcciones

Very good!! Ahora muestra el código de barras! Gracias, saludos.

[Carlos Mora]

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

[hmpaquito]

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

[Carlos Mora]

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

[hmpaquito]

Carlos,

Por partes, como diría el carnicero de York:

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.

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.

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.

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.

Si alguien quiere encarar el desafío, por supuesto que contará con mi apoyo, el 100% del código está disponible en el repositorio.

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í 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 ?


Saludos.

[Carlos Mora]

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.

Justamente el problema que tenía este señor era que él tenia una lista de nombres de fonts y sus ficheros que no coincidían segun diferentes versiones de Windows, y empeoraba al cambiar de idioma.

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.

La definición de los FONTs no está en la clase TPrinter, con lo que ya estamos hablando de otra cosa. Si en la clase TPrinter estuvieran incluídas las definiciones de FONTs, todo seria más sencillo, porque habría un lugar por donde 'atacar', pero la declaración de los fonts va de manera independiente.
La via más apropiada y elegante podría ser incluir en una subclase de TPrinter la declaración de las fuentes, y usar esa subclase en tu código. De esa manera tendrías algo bastante más aproximado a lo que buscas.

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

Esto es lo que yo no le veo solución. Define 'parecido' en terminos de font.

3. Sacar lista con aquellos que no coinciden para ir perfilando

Eso se puede hacer manualmente. De forma predeterminada, el módulo que gestiona fonts tiene una lista con los más usados: Arial, Verdana, Calibri, etc. Esa lista se puede ampliar sin problemas.

Se podria hacer una lista de archivos .ttf según version Windows e idioma de Windows.

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 ?

Siempre lo será. Microsoft juega con toda la baraja, nosotros con suerte menos de la mitad. En guor declaras las fuentes en el equipo que lo vas a usar, de una lista de fuentes instaladas que obtienes del propio ssoo. Eso lo puedes hacer sin problemas. Estamos hablando de una cosa 100% diferente: Alguien dice "Desdemona Black" y tu a partir de eso vas a buscar una definición que sea digerible en el idioma del pdf, adivinando el fichero ttf y demás. Y puede que en el equipo de testing Desdemona Black tenga significado, pero en el equipo del cliente eso no exista. Almomento de definir un FONT, dependemos mucho de la información del ambiente de ejecución, que no es el de desarrollo.

Por supuesto que cuentas con todo mi apoyo si te pones con ellos. Si es por cuestión de orden, yo sugiero añadir un metodo DefineFont en la TPrinter, o una subclase, para poder homogeneizar tu propio código, sino ya tendrías que tocar la declaracion de las fuentes, que se va mucho de contexto. Y todo esto garantizando que la librería sigue siendo "GUI agnostic" y se puede usar en consola.

[ruben Dario]

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

[Carlos Mora]

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

[hmpaquito]

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

[ruben Dario]

Gracias por su respuesta.
Carlos aqui coloco el mak. Con los cambios que dice el amigo hmpaquito funciona. Es no usar la libreria que proporcionas libhpdf.lib si no usar la de harbour, entonces lo mismo seria para png.lib.
estas librerias que proporcionas son mas modernas o son de otra version de harbour mas antigua.
He visto que tienes otros archivos DemoPdf.xpj DemoPdf.xdt DemoPdf.tds que herramientas usas para verlo, este es el que compila nunca he usado compilado asi.

Carlos estos prg THaruPDFBase.prg THaruPDF.prg HaruFonts.prg no se usan, o con estos construyes la libreria PdfPrinter.lib. Solamente funciona con Harbour no con xHarbour no lo he probado pero creo que toca construir la libreria PdfPrinter.lib para xHarbour.


Archivo MAk

Code: Select all  Expand view

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).rc
 

[Carlos Mora]

Estimado 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.

[ruben Dario]

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.

[Carlos Mora]

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.

[ruben Dario]

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.