>Right now I am just running the reports to preview.

It doesn't matter; the Preview still runs through the GDI, and accesses the printer driver for the target printer. If the printer driver is not well-behaved and does not put the FPU/MMX registers back in a known, usable state, the result can be exactly as noted; HP-supplied printer drivers (as opposed to the MS-provided drivers for the same printer from an OS distribution) are notorious for this behavior. Switching to one of the compatible MS-supplied drivers for the printer is likely to clear this up; if switching to a generic driver like the MS-supplied HP Laserjet Series II driver makes the problem go away, it's probably the driver issue. There are several solutions - avoid the HP driver and use one of the MS-supplied drivers that's compatible, bitch loudly at HP about their driver (they don't listen) or call the MSVCRT _fpreset() function after any call to the GDI that might invoke functions from the print driver.

DECLARE _fpreset IN MSVCRT

needs to occur once at the beginning of the program. After each VFP command that invokes the printer GDI function, like using the REPORT FORM command, the first command following it should read:

=_fpreset()