Skip to Content
Author's profile photo Trevor Dubinsky

Crystal Report printing inconsistancies in .NET

I have been hesitating writing a blog concerning the differences in printing from a .NET application and Crystal Reports designer for a bit. My hesitation in this was due to the chance that this will look negatively on our printing abilities, and whether I can write something short and clear enough about a topic that can be a pretty muddy and complicated.

I recently published a KBase article 154797 concerning this issue for a long and on-going case and thought I would take a stab at this. The kbase article sums this up nicely, it basically says “due to the fundamental differences between Win32 API and the .NET framework printing can be different”.

To understand this better, it is important to know that Crystal Reports are formatted using the system’s printer driver. This is true whether you are printing, viewing, or exporting. What this means different printers, OSs, driver versions can cause a change in the layout of the report.

Crystal Reports designer uses WIN32 API and windows Printer DEVMode structure when interacting with the printer. the DEVMode is the low level WIN API class to get all information from the printer and set the printer settings, and has been around since at least the Windows 95 days. Here is more information on the DEV mode structure if you really want it.

In VS .NET we use the System.Drawing.Printing classes and functions to set print information so we are framework compliant. The difficulty in this is that in the back end we have to convert from System.Drawing.Printing to the DEV mode structure for the CRPE32.dll to do its job. Unfortunately these two cannot always translate perfectly back and forth; this is where the “fundimental differences” lie.

We cannot change the print engine  and Crystal designer to use the .NET Printing especially since our reports need to run on non-Microsoft OSs. Nor can we now change .NET to use DEVMODE, so this is going to be a difference that will not go away, all we can do is minimize the issues that may occour. Here are a few things that you can do:

  • If you are primarily exporting and viewing use the “No Printer” option which simply causes the Crystal engine to emulate a printer driver.
  • Again if you are primarily exporting and viewing use the “Dissociate Formating Page Size and Printer Paper Size” which minimizes the page size on the report layout. It will cause scaling (to fit) when printing.
  • If printing on pre-formatted forms concider not printing directly to the forms but scanning the forms and adding it as a background image in the report, then aligning the fields to the background image. If the report is aligned differently fields and the image should realign uniformly.
  • Do continue to report printing issues you run into. Items that we can reproduce will be tracked and investigated. Some may come back as unable to be fixed because it is beyond our control. But others may be able to fixed.

For those that are thinking “There HAS TO BE something you can do to get .NET and Crystal to print exactly the same” let’s look at it from a different angle. The .NET framework only supports True-Type fonts however in the Crystal designer you can design a report to use fonts not supported in .NET. When viewing this in .NET  a font substitution will occour. Like the DEVMODE to System.Drawing.Printing there are differences in Win32 and .NET applications that just cannot be worked around.

Assigned Tags

      2 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      You write "If printing on pre-formatted forms concider not printing directly to the forms but scanning the forms and adding it as a background image in the report, then aligning the fields to the background image. If the report is aligned differently fields and the image should realign uniformly."

      The above suggestion will for example not work where customers must print on a pre-formatted giro form that later must be scanned by an external system. These reports must not be scaled. We have several other examples of pre-formatted reports and pre-printed paper with company logo etc.

      We have thousands of customer reports that are printed correctly with CR10 so we have now rolled back to CR 10 in our latest version and looking forward to a fix in the next CR 2010 for VS service pack.

      Jesper Bjerre

      Author's profile photo Trevor Dubinsky
      Trevor Dubinsky
      Blog Post Author
      Hi Jesper,

      Thank you for the feedback. The knowledge base article that I referenced says

      "The cause for this is because Crystal Reports prints to the printer using Win32 API and the printer's DEV mode structure where the .NET SDKs will print using the System.Drawing.Printing namespace."

      This was tracked and our developers have said that this behaviour is beyond our control as it goes into system and framework level.

      In other words don't wait for a fix because this is something we can't fix.

      I could suggest adding an enhancement request at our idea place to get this functionality if you want it. You can get to idea place here: http://www.sdn.sap.com/irj/scn/idea-place

      Kind Regards,

      Trevor