Unfortunately, there are two requirements here, which are sort of contradictory - at least, I haven't seen how to reconcile them:

1) Print on any printer.
2) Fast printing on text-only printing.

In Bata/Bolivia, I have designed some reports in text-mode, and some in graphics mode. The criterion was, how many pages will be printed per week, and with what printer. Heavy-duty printing (hundreds of pages per week) was in text-mode, on Epson printers, to save costs.

Unfortunately, this isn't practical for a commercial system, which many clients will use.

However, you may want to consider having two versions (graphical and text-only) of some reports that require printing in large quantities.

Regards,

Hilmar.

>Is there anyway that anyone knows of to prevent a dot matrix printer (Okidata models to be exact) from switching to NLQ print mode when printing reports creating using the visual foxpro report designer? The printer specific information is stripped from the report of course before compiling the app. What we have run into is that some of our customers still print to Okidata Microline 320 and Okidata ML 320 Turbo printers and we are converting most of our reports from dos reports (@...say and ??) to frxes. No matter what font I use in the report (courier new, courier, times new roman, arial, etc) the printer always switches from draft mode to nlq. This of course I'm assuming is due to font substitution being done by the printer. I do not want to create separate reports for each and every printer out there to store printer information and printer specific fonts in the frx....and some of our customers prefer the 'draft' mode to save ribbon and especially print time!
>
>Using dos printing, I would send escape sequences to the printers to tell it draft or high speed draft printing and the font and pitch, etc. However, we are trying to switch to all frx reports and no more dos reports and control codes, etc due to the many different types of printers out there now and so many gdi printers also that don't accept escape codes...
>
>Any ideas appreciated!