What's the best approach to printing/reporting from WPF?

I have an upcoming project which will have to be able to print simple reports from its data. It'll be WPF-based, and I'm wondering which way to go.

I know that WPF introduces its own printing technology (based on XPS) which looks quite easy to use. However, part of me wonders whether it would just be easier to use the ReportViewer control and embed it in a Windows Forms host control, since that will give users the ability to export to a variety of formats as well as print.

Has anyone had any experience with printing/reporting from WPF? Which direction would you recommend?


We had this same issue, and ended up using RDLC/ReportViewer for now. There's no native WPF reporting tool (that I know of) and RDLC is pretty simple to use, and is free. The runtime overhead for it is small (around 2Mb) but you must remember to distribute it as it isn't part of the .NET Framework.

Limitations of RDL

I originally went with RDLC/ReportViewer for printing with WPF but found it very limiting. Some of the limitations I found were:

  • RDL could only create the most boring of reports
  • It was much more work to create a report using RDL than in straight WPF: The design tools are very primitive compared to Expression Blend and RDL deals only in tables
  • I didn't have the ability to use ControlTemplates, DataTemplates, Styles, etc
  • My report fields and columns could not effectively resize and rearrange based on data size
  • Graphics had to be imported as images - it could not be drawn or edited as vectors
  • Positioning of items required code-behind rather than data binding
  • Lack of transforms
  • Very primitive data binding

Printing directly from WPF is very easy

Because of these limitations I looked into creating reports using pure WPF and discovered it was really quite trivial. WPF allows you to implement your own DocumentPaginator subclass that can generate pages.

I developed a simple DocumentPaginator subclass that takes any Visual, analyzes the visual tree, and hides selected elements to create each page.

DocumentPaginator details

Here is what my DocumentPaginator subclass does during initialization (called when first PageCount is fetched, or during the first GetPage() call):

  1. Scans the visual tree and makes a map of all scrolled panels inside ItemsControls
  2. Starting with the outermost, makes items in the ItemsControls invisible last to first until the Visual fits on a single page without any need to scroll. If the outermost can't be reduced enough, reduces inner panels until it succeeds or has only one item at each level. Record the set of visible items as the first page.
  3. Hide the lowest-level items that have already been shown on the first page, then make subsequent items visible until they no longer fit on the page. Record all but the last-added item as the second page.
  4. Repeat the process for all pages, storing the results in a data structure.

My DocumentPaginator's GetPage method is as follows:

  1. Look up the given page number in the data structure generated during initialization
  2. Hide and show items in the visual tree as indicated in the data structure
  3. Set PageNumber and NumberOfPages attached properties so report can display page numbering
  4. Flush the Dispatcher (Dispatcher.BeginInvoke(DispatcherPriority.ApplicationIdle, new Action(() => {} ));) to get any background rendering tasks to complete
  5. Create a Rectangle the size of the page whose VisualBrush is the visual being printed
  6. Measure, Arrange, and UpdateLayout the rectangle, then return it

This turned out to be quite simple code, and allowed me to turn practically anything I could create with WPF into pages and print it.

Additional reporting support

Now that my paginator is working, I no longer have to worry very much about whether I am creating my WPF content for screen or paper. In fact, often UI that I build for data entry and editing also works very well for printing.

From there I added a simple toolbar and some code behind, resulting in a full-fledged reporting system built around WPF that was far more capable than RDL. My reporting code can export to files, print to the printer, cut/paste page images, and cut/paste data for Excel. I can also switch any of my UI to "print view" with a click of a checkbox to see what it will look like if printed. All this in just a few hundred lines of C# and XAML!

At this point I think the only feature RDL has that my reporting code doesn't have is the ability to generate a formatted Excel spreadsheet. I can see how this could be done but so far there has been no need - cutting and pasting the data alone has been enough.

From my experience my recommendation would be to write a paginator, then start using WPF itself to create your reports.

Look at http://wpfreports.codeplex.com/

Take a look at PdfReports. It's a code first reporting engine, which is built on top of the iTextSharp and EPPlus libraries. It's compatible with both .NET 3.5+ Web and Windows applications.

How about Scryber? It allows PDF report templates to be defined using xml and bound to data within your application at run time. http://scryber.codeplex.com/

To elaborate on Ray Burns answer, if you are looking for an implementation example, see: Custom Data Grid Document Paginator

Which is a great starting point.

I've reccently accomplished task of developing own reporting system, which basically consist on design enviroment and data Source manager. The first task was to develop WYSWIG-like design enviroment. I've done this using GDI+, without even bothering about printing, as it came out printing/generating print preview was easiest than i expected, In general it only takes to draw all things on screen to graphics object of printing event.

I think that in case of WPF it would be similar, so all you should worry about is to display you report on screen and printing would be only few lines of code.

Without getting into a whole political discussion about the future of WPF, the best option we found was to wrap the ReportViewer in a Windows Forms host control.


Need Your Help

Setting methods through prototype object or in constructor, difference?

javascript constructor prototype

Could you explain the difference between setting methods in the constructor and through prototype object? The following code shows these two ways of setting the methods - say_hello and say_bye both...

Interpolating data points in Excel

excel date interpolation

I'm sure this is the kind of problem other have solved many times before.