Report Viewer Font getting stretched on WIndows Server Machine only

Question

I did a small app to make shipping bills, where a user enters the information they want and can either Preview (a form with a ReportViewer control is opening up) or Print direclty. The reportviewer uses a Local report embedded into the application.

Example Here : http://i.stack.imgur.com/z90z8.jpg

I have tried the app on a WinXP, Vista and Windows 7 machine and there is no problem, the report is previewed correctly.

But when installing it on the server directly (2003 R2, 64 bit) the Font are stretched (even Printing from the control). When printing directly (I created my own code to do it, the report is rendered in EMF and then prints it) I have the same problem.

But when saving in PDF or Word from the ReportViewer control the do appear correctly.

This is an annoyance because we remote desktop to the server to use our main MRP program, so using the program inside the server will be best, so we don't have so switch back to the desktop machine just for a single operation.

By the way this is the normal Arial Font, so it is not a missing font issue. Also the server does have a couple of Crystal (version 9 I think) and SQL server 2003 reporting runtime installed on them. This is using Visual Studio 2010.

Answer 1

This is a known problem and it took a long time for the Reporting Services and Dynamics NAV developers to investigate and dissect the root cause to a Windows Remote Desktop Protocol issue.

There are 2 solutions available:

1. Upgrade the VB2010 host machine to Windows 8 or Windows Server 2012.
2. Install the Windows Remote Desktop hotfix from http://support.microsoft.com/kb/2768741 for Windows 7 or Windows Server 2008R2 OS.

Answer 2

I ran into the same problem with a virtual machine hosted on a Win2008R2 box. The solution I found was posted by user Cassisi:

the key to fixing the server itself is to ensure the desktop resolution picked up by the SSRS service is 1024x768 (i.e. a 4:3 ratio) if the server is being remoting into via Desktop Services.

As a workaround I am going to try the solution described in his article on high-fidelity printing.