Winforms Reports Shink when Scaling is on

[Luke]

We're using Telerik Winforms (2018.1.220.40) and Telerik Reporting (12.0.18.416). When a computer with Windows High DPI Scaling set to greater then 100% prints a report, the report is tiny and shrunken in the corner of the page.

Due to many of our users using Surface Tablets, this issue is a must fix. Please let us know how to resolve it. I can reproduce the issue with a sample project that with an incredibly simple repor, so it's nothing in our code.

[Silviya]

Hello Luke,

When using Windows Forms ReportViewer on a machine with DPI scale factor higher than 96 (100%), Windows will stretch the application bitmap to the expected physical size.
This makes the report viewer and the report content blurry. However, when you are trying to print the report, the Windows Forms viewer always bases the layout calculation on 96 DPI and it will print the report as it will be previewed in 96 DPI. This is because the application in which you are using the Windows Forms Report Viewer is not declared as DPI aware.

By default WinForms applications are declared as DPI Unaware. As such, the report viewer and the physical size of report cannot automatically handle DPI scaling and, as a result, will render blurry or be sized incorrectly in many common usage scenarios. So, when printing the report, the application doesn't respond (don't know about the machine's changed settings) to the changed DPI and scale it incorrectly.

The recommended approach is setting dpiAware element in your application to avoid further scaling, visual or interaction issues. For example:

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" >
  <asmv3:application>
    <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
      <dpiAware>True</dpiAware>
    </asmv3:windowsSettings>
  </asmv3:application>
</assembly>

You might also check our demos located in product installation path, i.e. C:\Program Files (x86)\Progress\Telerik Reporting <VERSION>\Examples\CSharp|VB\WinFormsDemo. The dpiAware.manifest file is placed at the root of the application.

Regards,
Silviya
Progress Telerik

[Luke]

The dpiAware element didn't help as posted. However, when I copied the manifest out of the WinFormsDemo you mentioned, that appears to work. The difference appears to be "<dpiAware>True/PM</dpiAware>" instead of "<dpiAware>True</dpiAware>"

Thanks for your help!

[Silviya]

Hello Luke,

As far as I can tell, true vs true/pm should make no difference whatsoever on a system with only one display. In case you have more than one monitor, setting true/pm means that the current process is per-monitor dpi aware.

For more information, check Application Manifests MSDN article and more concrete dpiAware section.

Regards,
Silviya
Progress Telerik

[Luke]

Unfortunately, while the solution provided does solve the printing problem, it has the side effect of making the entire application too small for our users. 

 

Why would the *display* DPI setting affect what's printed in any way? Can this behavior be disabled? We want the default windows behavior of "blowing up" our application by 200%, without it affecting printed reports.

[Mark]

Yes, this is the problem we are having.  We are making our Application DPIUNAWARE so they can scale their monitors w/out affecting the forms in our application.   The side effect of doing this, is that now, the report behaves just like the OP stated above.   I thought that I could just resetSetDipAware back to DPIAware right before we called our ReportViewer form, which contains the ReportViewer control in it, but that doesn't seem to work.  We are still looking for a solution for this, as some of our reports are design to work with pre-printed pages and now those don't work anymore.

[Todor]

Hi Mark,

When you use an embedded Reporting engine in the Windows Forms Viewer, all renderings happen in the viewer and the DPI awareness is the same for all export formats.

To overcome the problem, you may use a Reporting REST Service with the viewer, so that the rendering happens in a separate project - see How to Use Windows Forms Report Viewer With REST Service.

You may check the KB article How to Display/Print Report Correctly from Windows Forms Viewer without Declaring the Entire Application as DPI-aware for more suggestions.

[Silviya]

Hello Luke,

WinForms ReportViewer uses the Image Rendering that takes information about the DPI settings from the application and the machine. When DPI is higher than 96 (for example 200%) and the application is declared as DPI Unaware, the report viewer and the physical size of report do not automatically handle DPI scaling and, as a result, will render blurry or be sized incorrectly in many common usage scenarios. So, when printing the report, the application don’t respond (don't know about the machine's changed settings) to the changed DPI and scale it incorrectly.

For more information, please check High DPI desktop application development on Windows MSDN article.

As WinForms applications are not DPI aware by default, we strongly recommend to set dpiAware element in your application to avoid further scaling, visual or interaction issues.

And as of the scaling of the report viewer as 100%, you can easily build custom UI for the toolbar and work with the rendered report in the viewer. In this case, you can use the Windows Forms ReportViewer class.

Regards,
Silviya
Progress Telerik