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.
