I hope I'm wrong, but someone is going to have to prove it to me because I don't see it any other way.

In a nutshell what I'm seeing is with 'set reportbehavior 90' if you print to a PostScript file and then distill it the 'text' will not be selectable in Adobe Acrobat 5 or 7. In fact, under Acrobat 7 when you do a Documents/Accessibility Quick Check it will tell you:

"This document appears to contain no text. It may be a scanned image."

I'm sorry, but that makes VFP 9 Report Behavior (RB90) completely useless to me and my customers. Whatever advanced reporting features it may have I can't use. My reports are data that will be consumed by users and used for other purposes like spreadsheets or other documents. Printing to paper is passe. Sure, Report Behavior 90 is great for paper or print preview, but that's not where things are at in this day in age. And having used WC where PDF is King RB90 is ok for reports that the user can only look at or print.


Hi Jeff,

What I believe is happening is that the DrawString() Function used to draw text in GDI+ is causing the Adobe Printer Drivers to see the text as graphics rather than text due to the way it is rendered into the EMF records which is where the output is printed from. GDI+ introduces a new set of EMF+ records for some of the new functions that older printer drivers don't properly interpret and end up seeing the output as graphics. I have been investigating this behavior for some time as it doesn't always seem to happen and others have posted this issue as well. So, there is some trigger that is getting set in a report that is causing items to be interpreted as a graphic image rather than a text string. But, so far I haven't nailed down what it might be that is sometimes triggering the graphics mode selection or for that matter how the printer driver is even able to intrepret the EMF+ record types on occassion, since the EMF format has not changed for many years and GDI+ introduces a set of new commands which alienates older EMF interpreters like printer drivers.

You can easily open the PostScript files before distilling and take a look at the raw data to see what was interpreted. I haven't done that yet myself as I have only test printed to the Adobe PDF Writer printer driver.

With the new ReportListener Class and Visual FoxPro 9's object-assisted report engine, my report engine can now quickly and accurately pass the rendered output from the VFP 9 Report Engine directly into the Mind's Eye Report Engine ActiveX control (without VFP rendering to EMFs first), where it stays as text when passed into the MERE ActiveX control. So, when the internal PDF rendering engine of the MERE ActiveX control generates a PDF document from the objects contained in the control, it writes out the Text as Text objects within the generated PDF document and it is selectable in Adobe Reader. It can also do this much faster than printing to a PDF Printer Driver, as MERE does not have to interpret the EMF stream going to the printer driver and then reorganize the data or convert it as it would for images to store in the PDF document. MERE simply writes out the data from its internal collection of report objects on each page as a PDF stream directly from memory and typically creates a PDF document between 10 and 20 times faster than printing to the adobe printer driver because of that. Additionally, MERE saves space on images by tracking each image as it generates a PDF document and will only insert one copy of the same image for the entire document and insert reference pointers to the same image as opposed to using a PDF printer driver.

You can always download the Mind's Eye Report Engine Trial Demo and see how fast it handles your reports under VFP 9 using the MERE_ReportListener class examples which are described in the Help File and are also installed into the PROGS folder. MERE can typically render a Report Preview quicker than VFP 9's Report Preview because it takes less time to store the data into MERE's memory storage than it does to write out to an EMF in memory. Also, displaying the Progress Bar in the VFP 9 REPORTBEHAVIOR 90 when rendering a Report Preview is much slower. An example report that I have that has 20,000 records takes around 8.4 seconds to completely render into the MERE ActiveX control using REPORT FORM cFileName OBJECT oMERE and takes around 60 seconds using REPORT FORM cFileName TO PRINTER PREVIEW with SET REPORTBEHAVIOR 90. If you turn off the Progess Bar display during the native VFP 9 report command using the NODIALOG clause, VFP 9 will render and preview the report in about 9.6 seconds. Now, if you set REPORTBEHAVIOR 80, the Report Preview using VFP 9 will render almost instantly. This is all very easy to test using the MindsEyeReportEngineTestForm.SCX Form that installs with the MERE Trial Demo and running the PAGE NUMBERING SAMPLE 20000 RECORDS.FRX report. It has page numbering on it and I just made a code change recently that allows MERE to bypass the 2nd pass when rendering reports that VFP uses two passes to calculate the _PAGETOTAL value on. So, MERE saves more time by not having to wait for 2 passes. The first tab of the Report Engine Test Form allows you to turn ON/OFF the NODIALOG option when you click on the RUN VFP ENGINE button and there is a drop down to change the REPORTBEHAVIOR from 90 to 80 for the native VFP Engine as well.

If VFP had the object-assisted report engine a few years ago, I could have spent several thousand hours on other things in life instead of trying to rewrite and mimic the VFP Report Writer from scratch. The MERE ActiveX control was originally written as a control to programmatically create reports placing objects anywhere anytime onto any size page and/or orientation at runtime, which I couldn't do with a standard VFP FRX Report. But, then I had the crazy idea of writing an interpreter for FRX reports and output from my interpreter into the MERE ActiveX control since there weren't any hooks into the VFP Report Engine then. But now with the ReportListener Class, I don't have to reverse engineer the Report Writer's "features". <g> If you look at the code in the RENDER Method of the MERE_ReportListener class, you will see that it simply calls the controls methods like AddText(), AddShape(), AddLine(), AddPicture(), AddBarCode(), etc. So, Kudos to the VFP Team for making life a lot easier!!

There are also other advantages to using MERE in VFP 9 in regards to printing because it makes it very easy to set the Paper Bin on each and every page of a report. It also properly renders page numbering with regard to _PAGENO of _PAGETOTAL with appended reports.