What would be good way to export a report (FRX) as an image (eg PNG) 3

[Rajesh Karunakaran]

Dear friends,

What would be a good way to export a vfp report (output from FRX) as an image (eg PNG)?

For example, we can convert a report output to a PDF using FoxyPreviewer (there are other ways also of course).
Similary, I want to get the output from a FRX run onto an image file, preferably PNG file. How?
I know, there is an option to convert as PDF-as-Image but that still is a PDF I believe, isn't it?
But, I need a pure image file.

Any thoughts?

Rajesh



Rajesh

 

[Mike Lewis]

In fact FoxyPreviewer can export a repot to an image. From the Foxy documentation (page 53):

The exported images from FoxyPreviewer offer a perfect reproduction of your report as an image file. All Gdi+ compatible image types are allowed: BMP, GIF, PNG, TIFF, JPEG and EMF.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Rajesh Karunakaran]

Mike,

Let me check this.
I have versions v299z30 & v299z38.

Rajesh




Rajesh

 

[Gerrit Broekhuis]

Rajesh,

We use XFRX for FRX export to many formats, including PDF and PNG, but DOCX and XLSX too.

Regards, Gerrit

 

[Rajesh Karunakaran]

Mike,

Yes, it's working. Thank you for reminding me this.

Rajesh


Rajesh

 

[Mike Lewis]

Glad it worked, Rajesh. Thanks for reporting back.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

It's also a basic feature of a reportlistener to enable you to use the render method to render an image that corresponds to whatever report object is rendered.
Parameters of the render method are including a gdiplus image handle and the coordinates where the FRX element needs to be, and the FRX element.

Well, I don't say use this, I just mentioned it to point out this mechanism is used by FoxyPreviewer and it's a lot of tedious work that got into this. I'd not want to write routiens that would render both text or images or lines or whatever else report elements could be. But in theory you could usng just this reportlistner event and preparing one or more page sized GDI graphics objects, easy to do with GDIPlusX. I think FoxyPReviewr uses GDIPlusX library anyway.

The only aspect that means for you is you should expect there to be more than 1 image, if you have more than 1 page. At least I assume FoxyaPreviewer wouldn't create a PNG the size of two or more pages. There also is one well knownn image format that can contain multiple images: TIFF. I'd still prefer PNG as the best iomage format for compressing both photographic imageas and graphical (lines, font types) images and images containing both.

Since XFRX was developed before reportlisteners, I don't know if they adopted this in later versions, it's surely worth comparing the outputs of both, as one of them could be faster/better compressed/better looking overall with different techinques used.

I also wonder if an image file isn't even one of the object types supported by REPORT FROM with the TYPE <n>. That also depends on reportlistener capabilities, no legacy support for that clause. But I think it would be even easier to get pagewise output as it can be routed through the reportlistener OutputPage mthod, which can simply use a device handlle that can be a GDI+ image handle, which lets the repotrtengine create a whole page image in one step. As far as I see that's the machinsm used internatlly to create previews of the pages, too. But this can also be used as the final output mechanism without preview.

Anyway, go for FoxyPreviewer or XFRX or FoxFire and don't reinvent the wheel.

And think about the multiple pages scenario, too. I wonder what FoxyPreviewr does when you specify one PNG filename, lilkely it'll ad page numbers to the filename.

Chriss

 

[Chris Miller]

Just out of curiosity, this is how the OutptPage event can be used (derived from sample code inside the VFP help):

Local loImageReportlistener

loImageReportlistener = CreateObject("imagereportlistner")
Report Form Home()+"\TOOLS\FILESPEC\90FRX.FRX" object loImageReportlistener

Define Class imagereportlistner as ReportListener
    ListenerType = 2
    
    Procedure OutputPage()
        LPARAMETERS nPageNo, eDevice, nDeviceType, nLeft, nTop, nWidth, nHeight, nClipLeft, nClipTop, nClipWidth, nClipHeight
        
        IF nDeviceType == -1 && event from report
            THIS.OutputPage(nPageNo, JustStem(This.CommandClauses.File)+"page"+Transform(nPageno)+".png", 104) && self call with nDeviceType 104 for PNG (!)
            NoDefault && the event triggered call of this does nothing, the self call of outputpage does the actual PNG generation
         ENDIF
    EndProc
EndDefine

This will create one PNG per page of whatever report you run using the OBJECT loImageReportlistener clause using 104 as nDevicetype for PNG image (which is documented in the help as that). Instead you could also have all control about the actual gdi+ image rendered when using nDevicetype = 1 for a gdi+ grahpics handle, instead.

The actual help example code rather creates a TIFF file which is create when pageno is 1 and added to for all further pages. But whatever, it shows you don't need to dig as deep as rendering every
FRX element with the Render event and can still just redirect all output to image files.

Chriss

 

[Rajesh Karunakaran]

Chriss,

In fact, I had not thought about having multiple pages in the final report output!
Let me do a trail on that. Also, to see what FoxyPreviewer does with the filename I supply in that case.
Will report back here.

I will do a trial with the sample code you provided too.
Thank you.

Rajesh



Rajesh

 

[Chris Miller]

I don't know if your report is the same thing - the bill slip - as you want to display in an image control, then at least many slip printers make this a single page with varying length. And that can be a problem, too, as you never know whether the image size will hit a maximum height or will always extend to whatever height necessary.

With my code you don't influence the image size, it's automatic and my guess is it's the same size that VFP uses internally for report previews, it's not the resolution supported by printers which usually have a much higher dpi than a dsiplay, though that's not necessarily true for slip printers, which often have a rather low dpi density.

On the other hand, mif you define your report to fixed height pages instead of varying height, you can also do an image based preview with an image size that fits the display height and instead of scrolling allow for switching to the pages which result from this listener ot from foxypreviewer. I would say if a cu is made somewhere in the middle of a grou of items, that's unfortunate for a pagewise view and a scrollable slip is to be preferred, but it's also possible to design the images with an overlap, i.e. you can generate between pages by including the lower half of image m and the upper half of image n+1, so switching pages becomes scrolling half a display height.

You could also take this idea forward and allow emulated scrolling this way, in the simplest form, perhaps by having one oversized image of the whole slip of which you copy a display height part to display in an image control insterad of doing the clipping by a scrollable container or form.

Chriss