Foxypreviewer es muy lento

[Rick C. Hodgin]

Pido disculpas por mi traducción de inglés a español a través de Google Translate.

¡Saludos a todos! :-)

Tuvimos un informe que intentamos usar Foxypreviewer para generar en PDF. Era un informe de más de 800 páginas y llevaba mucho tiempo. Después de 20 minutos, cancelamos el programa y lo imprimimos utilizando el escritor CutePDF.

¿Alguien sabe por qué Foxypreviewer es lento? ¿Es así solo en nuestro sistema? ¿Otras personas tienen el mismo problema? ¿Es algo que podría solucionarse si alguien como yo mira el código y lo rastrea, posiblemente escribiendo un DLL de reemplazo o algo para ayudar a acelerarlo?

Aprecio toda ayuda que puedas darme. Gracias de antemano.

-- 
Rick C. Hodgin

English:
I apologize for my English to Spanish transation via Google Translate.

Greetings to all! :-)

We had a report that we tried to use Foxypreviewer for to generate to PDF.  It was an 800+ page report, and it was taking a long time.  After 20 minutes we cancelled the program and printed it using CutePDF writer instead.

Does anyone know why Foxypreviewer is slow?  Is it only this way on our system?  Do other people have the same issue?  Is it something that could be fixed by having someone like me look at the code and track it down, possibly writing a replacement DLL or something to help speed it up?

I appreciate any help you can give me.  Thank you in advance.

[Rick C. Hodgin]

Cesar, would it be possible to create a new interface to speed up processing?  CutePDF, for example, uses the raw output from a printer driver.  Could we create something that intercepts the output in that way and notifies Foxypreviewer after it's completed to allow additional post-processing?

-- 

Rick C. Hodgin

[Rick C. Hodgin]

In looking at the LibHaru library, it looks like we could pass off some of the logic that maybe has to be done in VFP today to an intermediate DLL and have it gain processing speed that way.

We could also expand the LibHaru library itself to have a direct interface to VFP and Foxypreviewer so the one DLL handles some of the logic that's slow in Foxypreviewer today.

-- 

Rick C. Hodgin

On Thursday, October 18, 2018 at 2:34:12 PM UTC-4, Rick C. Hodgin wrote:

[Rick C. Hodgin]

I did some testing this morning, and by creating a custom ReportListener object, and using REPORT FORM myReport.frx OBJECT loMyReportListener PREVIEW, and intercepting the EvaluateObject(), Render() methods, and referencing the this.PageNo property, the entire sequence of positioning is available.

We could easily route that content to any new thing, including PDF files.

I think it may be time to create a simpler PDF Generator interface, and one that is speedy.

-- 

Rick C. Hodgin

[Rick C. Hodgin]

Using this method, I was able to generate 250 pages of report data in less than 2 seconds.

Usando este método, pude generar 250 páginas de datos de informes en menos de 2 segundos.

-- 

Rick C. Hodgin

[Rick C. Hodgin]

Looking at this page (in English):  https://github.com/libharu/libharu/wiki/Examples#text_democ

Look at the things you can do with text using LibHuru:

http://libharu.org/demo/text_demo.pdf
http://libharu.org/demo/text_demo2.pdf

How many new features could we add to our reports using these features?  Maybe it's time for a new REPORT FORM replacement, one that handles data as we are used to, but allows us to have more advanced report abilities.

¿Cuántas funciones nuevas podríamos agregar a nuestros informes usando estas funciones? Tal vez sea hora de reemplazar un nuevo REPORT FORM, uno que maneje los datos como estamos acostumbrados, pero nos permite tener capacidades de informes más avanzadas.

-- 

Rick C. Hodgin

[Marco Plaza]

Hola Rick, te sugiero probar y hacer un "fork" de "PDF3" de Martin Krivka ( http://www.vfp.cz )  es bastante rápida, de código bastante limpio y legible,  e incluye una compilación especial de libharu para vfp "embebida".

Saludos.

Tomado del encabezado de pdf3.prg:

pdf3 - vfp9 report listener for pdf output.

    goals:

        - simple, easy to use.

        - no user interaction.

        - optimized for speed.

        - mdot safe.

        - all-in-one prg file. No dependencies.

    typical usage:

        report form myReport object pdf3() to file "filename.pdf" [preview]

        local opdf

        m.opdf=pdf3()

        report form report1 object m.opdf noeject

        report form report2 object m.opdf noeject

        report form report3 object m.opdf to file "filename.pdf" [preview]

    requirements:

        - only jpg, png and gdiPlus images in report. Other types are NOT supported.

        - dynamic properties - only "rotate".

    based on the work of many peoples:

        - libhpdf by Takeshi Kanno, http://libharu.org/wiki/Main_Page, http://libharu.sourceforge.net/

        - pdfListener by Luis Navas, Dorin Vasilescu, http://weblogs.foxite.com/luisnavas/

        - foxyPreviewer by Cesar Chalom, http://foxypreviewer.codeplex.com/

        - and many others who participated on pdf output for foxpro.

    license:

        this file "pdf3.prg" is in public domain. Use at your own risk.

    

    

    This file contains libhpdf230.dll file, base64 encoded. It's my own build

    of libharu. Builded specially for HPDF_LoadJpeg(Png)ImageFromMem function,

    because the origin libhpdf does not have it.

    

    Pdf3 may be useful also for other PDF developers, because it demonstrate

    how to correctly rotate the pdf content.

    

    Enjoy.

     Martin Krivka 2013

[Rick C. Hodgin]

+1.

--
Rick C. Hodgin

[HernanCano]

Magnífico aporte, Marco.

[HernanCano]

Hello, Rick.

I also like PDF3(). Any test/help that you consider, tell me.

[Rick C. Hodgin]

Thank you, Hernan.  You've been very kind to me and my family over the years.  It is much appreciated.

-- 

Rick C. Hodgin

[Rick C. Hodgin]

Does anybody know where I can contact Martin Krivka?  I would like to send him a donation for his excellent work with PDF3.

¿Alguien sabe donde puedo contactar a Martin Krivka?  Me gustaría enviarle una donación por su excelente trabajo con PDF3.

-- 

Rick C. Hodgin

[Jean Pierre Adonis De La Cruz Garcia]

enviamelo a mi yo se lo hare llegar, siempre que el monto minimo no baje de 100 euros, caso contrario buscalo directo a el, jajajajajaja

[Rick C. Hodgin]

Jajajajajaja! :-)  ¡Eres demasiado bueno! :-)

-- 
Rick C. Hodgin

[Antonio Meza]

Lo probé y es muy rápido, lo malo es que genero códigos QR en BMP y la librería no lo soporta!!!

saludos

Antonio Meza

[Rick C. Hodgin]

Marco, thank you.  I made the switch and it was almost a drop-in replacement for FoxyPreviewer.  Almost no code changes.  It now prints over 200 pages in about 10 seconds.

Marco, gracias. Hice el cambio y fue casi un reemplazo directo de FoxyPreviewer. Casi no hay cambios de código. Ahora imprime más de 200 páginas en unos 10 segundos.

-- 

Rick C. Hodgin

On Friday, October 19, 2018 at 6:57:12 PM UTC-4, Marco Plaza wrote:

[Rick C. Hodgin]

I found an error with PDF3 (and with FoxyPreviewer) in that it doesn't always render the exact same content as a print preview does, or when you print to the printer, or when you print to something like CutePDF.

It needed to have this code added to make it print normally:

PROCEDURE EvaluateContents
LPARAMETERS nFRXRecno, toObj	&& toObj actually is "oObjProperties"

    * Does it need extra spaces removed?

    * ¿Necesita espacios extra eliminados?
    IF ALLTRIM(toObj.text) == toObj.text
        RETURN  && No
    ENDIF
	
    * We want to render just the content, not the leading/trailing spaces

    * Queremos renderizar solo el contenido, no los espacios iniciales / finales
    toObj.reload = .t.
    toObj.text   = ALLTRIM(toObj.text)

This may not work in every case if you have content that needs leading spaces for alignment.  But if you don't, it does make the spacing appear properly.

-- 

Rick C. Hodgin

Por Google Translate:

Encontré un error con PDF3 (y con FoxyPreviewer) en que no siempre muestra el mismo contenido que una vista previa de impresión, o cuando imprime en la impresora, o cuando imprime en algo como CutePDF.

Necesitaba tener este código agregado para que se imprima normalmente:

Es posible que esto no funcione en todos los casos si tiene contenido que necesita espacios iniciales para la alineación. Pero si no lo haces, hace que el espaciado aparezca correctamente.