>I want to thank all of you for your replies. However, I am still stuck. I was hoping for a command or a parameter to tell the reports how many lines to print per page or something to tell it to fill the whole page or a dummy printer driver the can be configured to fit my specs or something else of the sort.
> I don't think that my company wants me to use third party software in its in-house application. This problem occurs in many reports; so, rewriting one wouldn't be sufficient. FileToStr() wouldn't include the Page Headers and Group Headers that I need. SET PRINTER FONT didn't change the output, either.
> Hilmar: What is the name of your download?
> Naomi: Any suggestions from how you wrote your program? Did it modify how the .FRX behaved or did you just recreate the whole report programmatically?
> Any other ideas on how to solve this?

Another approach you could consider would be to use Windows itself to create a binary copy of the print job that would normally be sent directly to the printer.

With any Windows printer, instead of printing to a USB or LPT port, you can specify FILE: instead. When you print the report, Windows then prompts you for a file name, and redirects the output to that file.

You can then print it later by copying the file directly to the printer.

REM .CMD/.BAT file:
REM Redirect a DOS LPT port to the (previously shared) printer:
NET USE LPT3: \\ServerComputer\SharedPrinterName

REM Binary copy ( /b switch ) the previously saved binary print job:
COPY SavedPrintJob.prn LPT3: /b

REM Clean up afterwards:
NET USE LPT3: /DEL
ERASE SavedPrintJob.prn

The above approach is a bit awkward but can probably be improved by judicious use of API calls.

Major downsides:

- won't work if the printer used for the final print job is different from the one used when the intermediate binary file is created

- unmanageable if you have more than a few printers; not suitable for a widely-distributed application