You will always have this problem on any Windows with scaling set to anything other than 100%.
From that perspective the FoxyPreviwer.App is a better reporting app than the original ReportPreview.App and ReportOutput.App and it indeed covers both functionalities, as it would of course be unhelpful to only change the preview and not the final output. To be clear, FoxyPreviewer could also replace the original VFP ReportPreview.App and ReportOutput.App files.
Xinjie pointed to the VFPX page that has the latest original VFP versions of them, and MarK pointed out where they go. Well, that's all part of the SP2 update of VFP9, too, and if you upgrade the reporting apps, you should upgrade your whole VFP9 IDE to the latest version SP2 and then Hotfix 3.
Anyway, if you provide an EXE and want it to support REPORTBEHVIOR 90, then you also have to provide all three apps (well, ReportBuilder.app only when your application actually allows to modify a report). And the FoxyPreviwer.App is a replacement for the ReportPreview.App and ReportOutput.App
What I wouldn't do, even when it turns out the dpi scaling problem can't be overcome otherwise is replace the VFP reporting apps with foxypreviewer already in the IDE environment. FoxyPreviewer makes it so easy as just DO FoxyPreviewer.app to change from the native VFP apps to FoxyaPreviewer, that it's worth - in my opinion - to keep the orignals in place for cases you still use them in an application in production. Of course, you still want to be able to test bugfixes with that apps in place.
What's also good to know is that without the apps, the VFP9r.dll still contains the 70 reportbehavior reportengine and is acting as a fallback to 90 behavior, if the apps are not available to the runtime, also see _reportoutput, _reportpreview and _reportbuilder system variables explained in the VFP help.
The thing about dpiawareness is not to fix all scaling problems, but to keep the OS from interfering with scaling and handling it yourself, setting an application to be dpiaware tells "I am aware of the need to scale up fonts and images myself". But then you still need to do exactly that yopurself. Since FoxyPreviewer is not just defining a new reportpreview window but a whole GDI+ based rendering of reports, it can do for reports what atlopes DPIAware Manager does for forms.
From what püeople told about their SetProcessDPIAware experiences it seems diffferent Winddows versions, maybe even different builds act differently. In my experience all text (fonts) are immediately crisper when you use SetProcessDPIAware or the EXE property setting shown by MarK or the manifest declaration as recommended as best practice. The different experiences may also come from the timinig of that API function call. At best Windows knows from the EXE manifest even before the process really is running. Also the documentation of the API function says it the process-default DPI awareness to system-DPI awareness, so it can differ what's the system setting for DPI awareness, you can configure some behavior there and what can be configured differs with Windows versions, I think.
The usual result of SetProcessDPIAware is that font scaling doesn't happen, for example, so your forms will become small on a higher resolution display. For that reason you should have forms that can adapt to higher reslutions anyway. If you do that you make any influences from Windows unnecessary and that's the core of stating your application is dpi aware. You're aware that on displays with higher dpi you need to take care for forms and especially all text on them doesn't get so tiny even young poeple would need magnifiers or reading aids to be able to use them.
The report problem originates in several scaling issues, I think, not just one. I'm not sure, but I think VFP has the hardcoded assumption that screens (so the preview phase of a report) always have 96dpi displays, so a 1080 display has an actual phsyical width of 11.25", which actually is close to that, really. A 14" (diagonal) 4:3 display has 11.44" width. And the typical 96dpi is from that era of 4:3 displays. If both dpi is higher and scaling factor is set high to comensate the smaller size of the same number of pixels, the rendering engine assuming 96dpi will therefore assume a much larger physical width and sclaing of font by windows does not counteract but even magnifies the problem, so that you get too large rendered fonts and only see half of the preview. That's why that happens, simplified. The printer driver will also weigh in later with a dpi of the printer, but that was always handled even before displays with higher resolutions and what's more important higher densities of pixels were a thing, because printers even had 300/600/1200 dpi in the 90s already and today even more.
Chriss
