Crystal Reports .NET Web Forms - Ensure Correct Formatting For 120 DPI Screens

[ted_ueda]

I work for SAP Business Objects in Technical Customer Assurance.  My speciality is the Software Development Kits (SDKs) that we provide with our Business Intelligence products - BusinessObjects Enterprise, Web Intelligence, Desktop Intelligence, Crystal Reports and Crystal Xcelsius. 

In my blog, I discuss subjects that I personally find interesting - little known or not-well-documented corners of the SDK, new functionality or new SDKs, or interesting issues that I've come across in a SAP Incident or SAP Developer Network forums. 

You're more than welcome to suggest any topic (SAP Business Objects SDK related, of course...) that you'd like me to discuss - I have a dozen or so items on my blog to-do list, but I'm always on the hunt for anything interesting with our SDKs.   

Introduction

If you're a coder using the Crystal Reports .NET Web Forms to display reports, then this blog entry may be of interest to you.  I recommend looking at your code where you have CrystalReportViewer class instance instantiated, and see if you have the property:

    CrystalReportViewer.RenderingDPI

dynamically specified.  If not, then you likely have a bug - some of your clients won't see correct formatting of the report.

Let me illustrate - I have Crystal Reports 2008 .NET Web Forms app display a report.  On my development box, it looks like this:

A Crystal Report showing the titles of three Literary Classics, the text fields aligned just as I designed the report.  There doesn't appear to be any problems, right?

But what a few of your clients may see is the following:

Your clients will raise a flap, to see the fields overlap.  You'll be certain as I am, that they will not like "Green Eggs and Ham", overlap the adjacent text, which too overlaps the next, so "Horton Hears a Who!", is hard to read too.  What's a coder to do? Here's a suggestion for you.  If you check their screen setting, this is what I'm betting:  they've set the DPI, to 120 - rather high!  Windows default to 96, and therein lies the fix. Sorry - once I start Seussing, I can't stop.

The first screenshot was taken on a machine where the screen setting is 96dpi, while the second screenshot was taken on a machine set to 120dpi.  You can see that the larger dpi setting cause text font - all text fonts - to increase in size.  Since the CrystalReportViewer class by default assumes 96dpi, the report displayed on a machine with different dpi setting will not have correct formatting.

Correcting for Screen DPI Setting

With high-resolution, high-pixel-density LCD screens becoming ubiquitous - especially on laptops - more and more people are increasing the screen dpi setting to make text more legible.  You can no longer assume everyone viewing reports on your web app all have 96dpi.

So how can you correct the Crystal Report Web Forms display for screens set to 120dpi?  Fortunately, the CrystalReportViewer property RenderingDPI allows you to specify to what dpi the viewer should composit the HTML output. So if you invoke:

    CrystalReportViewer.RenderingDPI = 120

and view the report on the 120dpi machine, you'll see the correct formatting - exactly like the first screenshot.

Unfortunately, with the 120 setting, viewing the report on a 96dpi screen will show incorrect formatting - the fields and the text fonts will be uniformly reduced in size.

You need to ensure the RenderingDPI property value exactly matches the screen dpi. How to do this?

Dynamically Setting RenderingDPI

If you have BusinessObjects Enterprise or Crystal Reports Server, log onto InfoView and look at the User Preferences setting for Crystal Reports.  One of the preferences is "Select a rendering resolution (for Web):"  This is how InfoView does it - it leaves it up to the User to specify their dpi setting.  

This is certainly valid in an Enterprise-level application, where user information is persisted.  But it's still problematic - I have some machines set to 96dpi, while others set to 120dpi. It's a bit tedious to have to re-configure the setting whenever I move to a different machine.

There's no standard client-side JavaScript calls to retrieve the dpi setting, and the information isn't by default sent via HTTP Request header.

So how can you determine dynamically the screen dpi?

One way that I use - it's not original, you can see this "trick" or something similar being used out in the wild - is to create a HTML div tag defining an area 1 inch in height off the visible porton of the browser display, then use JavaScript to measure its height in pixels.   This gets you exactly the screen dpi.

Here's a sample HTML page:

determine_dpi.html
Displaying report...<div style="height: 1in;width: 1in"> </div>

which determines the dpi and redirects to Viewer.aspx with HTTP Get parameter "dpi" set to this value.  The Viewer.aspx instantiates the CrystalReportViewer class instance, and in the Page_Load method, retrieves the value and sets RenderingDPI:

Viewer.aspx.cs
using System; using System.Data; using System.Configuration; using System.Linq; using System.Web; using System.Web.Security; using System.Web.UI; using System.Web.UI.WebControls; using System.Web.UI.WebControls.WebParts; using System.Web.UI.HtmlControls; using System.Xml.Linq;  using CrystalDecisions.Shared; using CrystalDecisions.CrystalReports.Engine; using CrystalDecisions.Web;  public partial class _Default : System.Web.UI.Page  {     protected void Page_Load(object sender, EventArgs e)     {         int dpi = Convert.ToInt32(Request["dpi"]);          CrystalReportViewer1.RenderingDPI = dpi;      } }

so whatever setting is used in the client browser screen, the CrystalReportViewer will be formatting text correctly.

Conclusion

I'm certainly guilty of not practising what I preach here - I frequently neglect to set the proper RenderingDPI value, then end up getting bit later on. 

Part of the reason I wrote this blog entry is to remind me to not forget next time...

I hope you find this information useful too.