SSRS Report Font Rendering Issue - by srepphan

Status : 

  Not Reproducible<br /><br />
		The product team could not reproduce this item with the description and steps provided.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 482312 Comments
Status Closed Workarounds
Type Bug Repros 30
Opened 8/11/2009 8:53:05 AM
Access Restriction Public


I am having a problem with SQL Reporting Services and the way it renders fonts. This only happens in "Print Layout" mode or when actually printing. The spacing between the letters is set to 0 or below so that all of the letters appear bold and run together. I have tried many different fonts and have installed all updates and SQL_Server_2008_SP1_Cumulative_Update_3/10.00.2723.00. I still have the same issue. 
Sign in to post a comment.
Posted by JingTong on 3/1/2013 at 12:15 PM
Thank you for reporting this issue. 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 for Windows 7 or Windows Server 2008R2 OS.

Thank you,
Jing Tong
Reporting Services developer, Microsoft
Posted by Josh 2007 on 2/26/2013 at 6:36 PM
1. Do the Print view with a resolution of 1440x900. Stretched.
2. Re-render when connected with a resolution of 1024x768. Normal.


Posted by Greg Buchmann on 8/27/2012 at 9:44 AM
Slight correction. Rather than kerning, I guess the correct term is tracking. Anyway, it occurred on Win Serv 2008 R2 Enterprise 64-bit with SSRS 2008 R2 Enterprise 64-bit. Rebooting Windows cleared the issue. Would like to know root cause and the fix.
Posted by Greg Buchmann on 8/27/2012 at 8:56 AM
This issue is still occurring. Just ran into the issue with SSRS 2008 R2. Rebooting Windows on the Server cleared the font kerning issue. Is there any update on the root cause or the fix?
Posted by Steve72 on 5/17/2012 at 4:41 AM
We are using a report viewer in a WinForms application VS2010. If I print from my pc the font is fine. A lot of our work is on Terminal Server and the resulting print is narrow. If the RDC Display resolution is set to a 4/3 ratio e.g. 1600 x 1200 then the print font is fine, but the screen resolution for everything else looks bad. I currently have no workaround.
Posted by hgdsri on 1/17/2012 at 3:17 AM
Looks like it was a DPI issue. Got temparary solution:
Posted by hgdsri on 1/17/2012 at 1:33 AM
Hello- We are using sql server 2008 R2 with SP1. and ReportViewer 2010 dlls to view reports at client side.
We have generated these report rdls using Visual studio 2008 and works well except printing. Print priview works well. Actual printing differs from print preview. It adds 2 inch of addition left and top margin and prints with very large font. Any work around for this? This is really a serious issue. If we export that report to pdf and then if we print - it works perfect.
Other issue programmatically generated pdf using Render method too have this issue. Any suggestions will be appreciated...
Posted by ReportCreator on 9/1/2011 at 10:45 PM
I also have this very same issue but only one one (customer) server. I am not remoting to it, i am using a c# application with a report viewer, and the report viewer connects to the remote server but its not a remote desktop issue.

The server in question has no printers, and no print drivers installed, however i cannot currently install any to see if this fixes the issue.

This is pretty bad that so many people have this issue yet there isnt even a workaround :/
Posted by zeph82 on 2/17/2011 at 1:59 PM
I have similar issue where my SSRS report of 80 pages works fine until 72 pages and the last 8 pages have bigger font with no border lines. This happens only in report viewer but when i export it to PDF ,xls. It works fine. Customers are wanting this to work on report viewer too. Please help or suggest how to fix this. I am using SSRS 2005 and reproduced this issue on SQL 2008 report viewer and on SQL 2005 report viewer / server.
email: with resolution.
Posted by padmajyoti on 2/3/2011 at 10:08 PM
     i am also having same problem on SSRS report rendering.
The Issues is i am using code39(ID automation Barcode) fro Barcode generation.
and Rupee fornt for PRinting Indian Rupee Symbol.
when i am previewing it from my project it is showing fine and printing also fine.
but when i am developying it to server fornt is not rendering. it is showing keybord latter.
for ex. i am masking with barcode for 123456. when i am previewing it on my local system with project. it is fine.
but when i am developying it to server and rendering through my application or seeing on browser it is showing 123456 in barcode font and "`" for indian rupee font.
The Operation system is using for server Windows server 2008 R2 x64.
SQL server 2008 R2 x64
Sql server Reporting services 2008 R2 64

If any one can help will be Appreciated
Posted by Matt Dodds on 10/7/2010 at 5:01 AM
We just hit upon this with our ReportViewer operating in LocalReport mode from a web app on one of our servers.

The theory about console resolution vs TS resolution is accurate - in our case, someone had "taken over" the console session from a Remote Desktop Session using Terminal Services Manager. The user was operating their screen native at 1400 x 900 (ratio 1.6) as opposed to the standard console resolution of 1024 x 768 (ratio 1.333).

The renderer therefore erroneously applies some scaling and all your prints look too wide.

Ultimate solution: log on to the console, at the console and double-check your screen resolution. This seems to put everything back into place.
Posted by cassisi on 7/21/2010 at 9:46 AM
I've been having the corrupt text and invalid size problem in a local C# application ever since upgrading to the latest Report Viewer that is part of the VS2010 install.

Spelunking around the code with Reflector leads me to conclude:

1. For the Image/EMF target, PrintDpiX/Y completely overrides the documented DpiX/Y and whatever value is specified here will be used to measure and layout everything except for any images.

2. Images are dealt with by using whatever DPI is currently set for the given interative session - e.g. 96dpi or 120dpi

3. The internal code that generates the Metafile relies on retrieving the real screen size and width, something that older monitors didn't support and that is not supported during a remote desktop or terminal services session

(Some further discussion about this is here:

4. The EMF stream generated relies directly on whatever DPI is was set via PrintDpiX so knowing that is essential

For those who want to take a look, use Reflector to examine the CalculateMetafileRectangle internal routine and notice now the GetDeviceCaps(hdc, x) lines return a default of 320/240 when using remote desktop for e.g. But because the resolution is correct, the net result is non-square pixels depending on whether your precise resolution is of the ratio 320/240 (1:33) or not.

When this happens, you will clearly see corrupt overlapping and badly laid out text - but oddly any images (e.g. the MSChart control) and text within them is fine.

This may explain why on the server if you restart SSRS from within a console that has a resolution ratio of 1.33 like 1024x768 (thereby matching the 320/240 default size by ratio) the issue is resolved. However, I've only been using the local ReportViewer control so perhaps there's more to it on the server.

My issues with corrupt text, bad layout and incorrect sizing are now resolved:

I use a device info string that sets PrintDpiX/Y to DefaultPageSettings.PrinterResolution.X/Y to match the output device.

In the print callback, use the Metafile(Stream stream) constructor only - not the other ones. Then get the header (mfh) and apply a Graphics.ScaleTransform(mfh.DpiX / PrintDpiX, mfh.DpiY /PrintDpiY).

It is then possible to simply use Graphics.DrawImageUnscaled(mf, new Point(0,0)) and everything will come out as expected.

I've actually disabled the print layout and print buttons since they do not correctly do the above and so produce the corrupt output.

I also use Image/PDF and launch Adobe Acrobat to print in the case when someone is using Remote Desktop or when the monitor doesn't support returning the necessary information to Windows.

Note that these problems seem only to be here because Microsoft chose to generate EMF on the screen instead of directly to the printer context. It would be beneficial in a future version to pass in such a context to avoid this.

Posted by Stobbe on 6/11/2010 at 12:20 PM
I think this is what I am experiencing as well. I'm using the ReportExecution2005 web service to print SSRS2008 reports. The font on my report is Arial and it appears that letters are getting clumped together. I do not see this problem when I print the same report from ReportManger.
Posted by Janus Lin on 4/9/2010 at 7:30 AM
I also have the same issue as srepphan.

To reproduce, simply create several text boxes with...

I used several common fonts...
Arial, 10 pt (SSRS 2008 default)
Times New Roman, 12 pt (Office 2003 default)
Calibri, 11 pt (Office 2007 default)
Verdana, 11 pt
Tahoma, 11 pt

When printing from the SSRS report page, you can see that several letters are "clumping" together or spaced oddly. I have tried a variety of printers. If you export from the SSRS page to PDF or to Word and then print, everything prints as expected.
Posted by jesse_g2001 on 3/16/2010 at 1:36 PM
I have the exact same issue. When I try printing a deployed SSRS report out of CRM anything with a font of Copperplate Gothic Bold changes to Arial.
If the I print the report out of SSRS design everything prints correctly.
Posted by Microsoft on 1/11/2010 at 2:54 PM

Thanks for writing in about this. We have heard reports of this bug occuring at seemlingly random times from customers in the field, however we have never been able to reproduce this in-house and therefore have not been able to investigate it.

Microsoft customer support engineers are actively engaged with several affected customers and are trying to isolate a repro of this issue.

If you are hitting this, I strongly encourage you to contact Microsoft support and work with an engineer to gather the necessary information.

For this issue, I'm going to resolve it as Not Repro.

Thanks and best regards,
Chris B.
Posted by EinKullur on 11/18/2009 at 5:37 AM
For our client this bug appeared yesterday, no new deployment of reports and no service pack / patch / update or anything has been changed as far as i can see...... very spooky and BIG problem that i dont know any solution for.