Telerik Reporting provides tailor-made report viewers for any major .NET platform and allows exporting to 15+ of the most common file formats - features that make it suitable for any business application.
Whether you’re adding features to your old-but-reliable WinForms application, or are developing a modern Angular project, Telerik Reporting has you covered! We provide the same high-quality content for any .NET platform, regardless of whether it is desktop- or web-oriented. An additional benefit is the large number of supported export formats that make our product a preferred solution for any business application.
In this post I will share more details about the rendering technologies we support in our report viewers. Since I already explained how easy it is to incorporate Telerik Reporting into your application, I will now dive into a bit more technical specifics, hoping that will help you understand how the reporting engine works to deliver the best data visualization for any scenario.
The workflow of processing and rendering a report is shown on the picture below:
As seen from this picture, the actual report rendering is at the end of the report life cycle, which means that we can change the rendering extension without modifying any of the prerequisites – the report definition, the data connections and the report processing will stay intact. This is especially useful when migrating an existing application to another platform, i.e. when your WPF application needs to go to the web, so all you would need to do is to add and configure an HTML5 Report Viewer and all the existing reports will be rendered in HTML format.
Every report viewer uses a specific rendering extension that has interactive and print-preview modes, which determine the rendering of interactive areas and the paging algorithm to be used.
This viewer is designed to be employed in .NET Windows Forms projects and uses standard Windows Forms controls. The viewer utilizes the Image rendering extension, which means that every report item is drawn onto a graphics canvas. The drawing itself is done using classes, provided by the GDI+ interface, which we believe has the best balance between drawing quality and speed. We use Metafile as a graphics provider to ensure correct scaling when the viewer zoom is changed. The interactive areas are determined via scanning the pixel color under the mouse cursor - an approach also used in game development.
WPF provides a rich XAML-based presentation system for building desktop applications with superb UI and view-model binding capabilities. Our WPF Report Viewer uses the XAML rendering extension, which generates native markup for each report item, created during the report processing. The produced XAML is loaded into the framework element that represents the report viewer area, rendering the report contents. This approach allows us to apply styling and create interactive elements using XAML-specific commands. The rendering speed depends on the number of elements that the report page contains – much like the HTML elements in a web page, rendered in a browser. The XAML report viewer also provides a customizable template, which allows fine-tuning for a perfect fit into any WPF application.
Although they use relatively mature technologies, we're constantly developing and improving our WinForms and WPF report viewers. For example, in our last release we added accessibility support for them, so they can be used in applications that aim to cover a wider user audience.
Even though it is not developed anymore, back in the day Microsoft Silverlight looked promising and delivered great graphic contents, using XAML-presentation like the WPF report viewer. The Silverlight report viewer lives on the client, while the report definitions and the rendering engine are located on the server. The communication between them is performed through a WCF service, which is also responsible for managing the report state and resources.
As its name suggests, this viewer is intended to be used in ASP.NET WebForms projects. The reports are processed and rendered server-side and the HTML content is delivered to the viewer through an HTTP handler. This viewer is not developed anymore, because it is superseded by the new HTML5 Report Viewer.
Reports are processed and rendered on the server where the Telerik Reporting engine and Telerik Reporting REST service run. Reports and their resources are handled and delivered to the viewer through the Reporting REST service. This viewer serves as a base for all the subsequently developed web viewers.
This viewer provides a server-side wrapper for the HTML5 Report Viewer. Developers that are used to ASP.NET MVC can easily configure and work with the Report Viewer via their preferred server-side programming language. With HTML5 ASP.NET MVC Report Viewer you can have the viewer configured in code. The MVC wrapper renders the widget and links to the required JS, CSS and HTML resources on the page. The MVC viewer works like the HTML5 Viewer in a client-server pair with the Reporting REST Service.
This viewer is also a wrapper around the HTML5 Report Viewer, but it is designed to be used by developers who are comfortable with ASP.NET WebForms technology. It is also aimed at users who would like to effortlessly replace the legacy ASP.NET WebForms Report Viewer and receive all the benefits that the HTML5 Report Viewer would add to their application. The viewer still could be easily modified and customized through the provided HTML5 templates and Kendo UI themes.
This is our latest addition in modern web report viewers. This viewer comes as a package, hosted on the npmjs.com public repository, ready to be added to your project with a single npm command. The report viewer is compatible both with Angular CLI and SystemJS projects. It is also based on the HTML5 Report Viewer and relies on the Telerik Reporting REST service to process and render the reports.
All the report viewers can be configured to render reports from Telerik Report Server. In this scenario the report processing and rendering is done on the machine where the server is hosted, and the rendered pages are streamed back to the client, where the viewer previews them to the user.
Besides showing a report in a viewer, it is often necessary to export a report to a certain format so it can be emailed or just displayed without opening a reporting application. Our list of rendering extensions covers the most used formats in business scenarios and adds a few more that might be needed in more specific configurations. The report export can be done through the viewer’s export menu and programmatically, using the ReportProcessor class.
We provide full support for Microsoft Office products like Word, Excel 2007, Excel 97 and PowerPoint, exporting to RTF, DOCX, XLSX, XLS, CSV, PPTX and XPS. Some of these formats are natively implemented and for others we rely on the OpenXML SDK, which defines the set of XML schemas for representing spreadsheets, charts, presentations and word processing documents, as noted in the ECMA-376 standard.
Image-based rendering extensions are useful when the report should be presented as a single image or series of images. The PDF rendering extension can also be assigned to this group, although it provides a couple of unique options like font embedding, password protection and editing the metadata of the exported PDF file. The Image rendering extension allows to select the output format – BMP, EMF, EMFPLUS, GIF, JPEF, PNG or TIFF (by default) and, when supported, to specify the compression scheme.
Web-based rendering extensions are useful when the report needs to be shown in a browser. We provide a self-contained rendering format, named MHTML or Web Archive, which is designed to be used when the report contents – markup, bitmaps and styles needs to be packed in a single file. The other formats - HTML5 and HTML5 Interactive should be used only programmatically, because this rendering extension is multi-stream and generates multiple files during the rendering process.
The rest of the rendering formats cover specific scenarios and are used internally by our report viewers, but they still can be executed programmatically, generating a valid XAML for use in a WPF or Silverlight application.
All rendering extensions can be configured through a special dictionary object, named Device Information Settings, which provides options for selecting or fine-tuning the selected rendering format. This object can contain information about the desired page range through the StartPage and EndPage keys, but can also turn on and off the TextRenderingHint for Image Rendering Extension, or set the Encoding which will be used when rendering in CSV format.
In this blog post I got a bit technical about the report processing and rendering extensions, but hopefully I was able to present the growing number of our report viewers and supported rendering extensions, which ensure that Telerik Reporting will find place in any application regardless the selected platform. If you want to learn more, start a free trial of Telerik Reporting or Telerik Report Server today.
By leveraging the broad array of themes, skins, styling and customization options, your application will awe even the best front-end designers. Check it out!
Check Out DevCraft
Try Reporting Now
And don't forget to take a look at our release webinars, where our technical experts provide a deep dive into all of our new features and functionalities.
Watch the Telerik Release Webinar
Watch the Kendo UI Release Webinar
Ivan Hristov has been a software developer in the Telerik Reporting division since 2013.
When not at work, he might be seen biking/skiing with his daughter, reading or discussing influential movies with friends. Feel free to reach out to him through LinkedIn.