HI Rich and thanks for your response.

We have determined that when printing to a parallel printer, there is a HUGE impact on the time it takes to get the document to the printer. Rendering and spooling the document is a little slower, but not significant. What is significant is the time that it takes get the spooled document through the parallel cable to the printer.

We performed a number of tests and narrowed it down to the parallel interface. Using a USB cable or printing to a network printer eliminated the slowdown, but we have found NO cure for the parallel printer cable.

From a development standpoint, it's fairly easy for us to conclude that we need to stay with REPORTBAHVIOR 80 for our text based reports. We develop accounting apps so the need for graphics in our reports is minimal. However, we do want to take advantage of the GDI+ preview screen which is far superior to the 80 one. There in lies the problem... what if they click the PRINT button. If they have a parallel cable, we're going to have some p*ssed off users...

So now we have to remove the PRINT button from the preview screen in order to prevent this from happening IF we want to use the new preview screen. Not good!

Clearly what's needed is a REPORTBEHAVIOR 85 which uses the 80 behavior for printing and the 90 behavior for previewing.

I'm quite surprised that there hasn't been more discussion regarding this. Doesn't anyone have their own printer anymore???

>>> The 90 version prints 10 times slower with a noticeable pause between each page. Total unusable.
>
>John,
>
>My studies of the new Report Engine and the performance vary greatly depending on several things. The first being whether or not you have ANY images on your report and second what the current printer resolution is at the time of printing. A high resolution setting at print time and rendering images can DRAMATICALLY increase the time to render and the time to print due to the fact that SET REPORTBEHAVIOR 90 or using the OBJECT clause causes the VFP Report Engine to render the images at the resolution of the printer using the GDI+ drawing commands.
>
>So, if your reports have images on them and you are rendering them at high resolutions you can look at a significant amount of data being sent to the spooler. It is not necessarily the speed of the port that is the slow down although it does play a big factor in how fast it can process data. But, the amount of data that is generated depending on the resolution can play a larger factor quickly as a single page with a few 6 megapixel images on the report page can render a 95MB EMF file. Previewing an entire report will render all pages to memory as EMF images, so imagine previewing or printing a few hundred pages with 6 megapixel images on a high resolution printer. There are also other factors going on with printer drivers that cause rendered output of even text to be rendered as graphics rather than text in PDF files thus resulting in a very large file.
>
>A customer contacted me recently about printing a 140 page report to a PDF document using the native VFP Report Writer and print to an Adobe PDF Writer printer driver using SET REPORTBEHAVIOR 90 to render bar charts by modifying the size of shapes using a ReportListener at runtime. The resulting PDF document was 64MB in size and took 145 seconds to print. The text of the PDF was not searchable though since the text in the report was rendered as graphics rather than text in the PDF document. Rendering the same report directly through the PDF engine in MERE resulted in a 347KB PDF file which rendered in approximately 3 seconds. In trying to figure out the difference in performance and size, I believe that the EMF+ records that are being placed into the EMF output when GDI+ commands such as the DrawString() command are called are not understood by older printer drivers. Thus, resulting in the text being rendered as an image rather than being coverted into printer command language text
>rendering commands which are much more efficient than pushing a bitmap representation of text to the printer. When a printer driver is processing the print spooler it sees each page as an EMF representation of the printed and then must read through each of the records in the EMF image and translate it into it's own printer command language to be sent to the printer.
>
>So, for some simple tests you may want to try changing the Printer Resolution between 150dpi and 1200dpi and see what effect that has on performance. Additionally, try rendering them to a PREVIEW rather than directly to the Printer to determine if its a rendering issue or a data throughput issue going to the printer.
>
>If you do not have a need to use REPORTBEHAVIOR 90, then I would stick with 80 and choose performance over resolution because even when printing via 80 behavior using images, the printer resolution is much higher than the screen and should still look fine.