Our continuous commitment to provide prompt fixes and excellent support for our products has resulted in a second Service Pack of Telerik Reporting. While smaller than the first one, it still contains important bug fixes and improvements. Here is a summary of what has been fixed:

• Report parameters are not displayed when Session State mode in SQLServer or StateServer.
• Sometimes font-size is not set correctly in HTML rendering.
• WinViewer.ToolbarVisible is not serialized correctly at design-time when the viewer is in a hidden container.
• Adding Dock or Anchor first and then setting KeepTogether does not warn of incompatibility. It simply crashes the designer later after a rebuild.
• Report.DataSource property is not reset when deleting the DataSet used as report's data source.
• PDF rendering extension sometimes disposes images which belong to the report definition instance.
• Importing an external style sheet that contains a Barcode or Checkbox throws an exception.
• Unit.ToString() and Unit.ToString(CultureInfo) does not omit the trailing zeros after the decimal separator.
• Processing.PictureBox item should determine the MimeType of the loaded image if possible.
• Nested anchored and docked items do not resize recursively at design time.
• Improve the user experience while using the "Select Type" dialog (used for defining style selectors).
• Multi-select parameter editor in WinViewer does not initially check the <Select All> item properly.

At the moment I am writing this the files are being uploaded to our servers and they should be available in the Client.Net accounts of all subscription holders any time now.

Over the past few days I worked on an image caching mechanism in the PDF Rendering Extension and I am happy to announce that the achieved output size reduction was more than significant.

The Problem

When a report contains the same binary image many times, the PDF Rendering Extension has no way of knowing that it is actually one and the same and renders it many times thus wasting disc space. For an illustration of this case imagine that you have your company's logo in the page header and your report is 200 pages long.

The Solution: Enter Cyclic Redundancy Check

I've implemented a central storage for all images that need to be rendered in PDF. It is a simple generic Dictionary. For a key I used a class that stores a reference to the original System.Drawing.Image and the source rectangle from that image that needs to be drawn into the PDF document. These two things uniquely identify a PDF image. Now, in order to use that class as a key for my dictionary, I overrode the GetHashCode and Equals methods. The hashcode for the object is calculated very easily:

1. Convert the image to a byte[] by using the handy System.Drawing.ImageConverter.
2. Calculate the CRC32 of this buffer.
3. Raise the calculated CRC32 to the power of the source rectangle's hashcode.

Now CRC32 might sound intimidating, but in fact it is a well known algorithm and is implemented on about 20-30 lines of code. Now, each time a new image arrives its hash is computed, the dictionary is searched to see whether we already have it in there, and if we have it we simply use the existing image. Of course .NET does all of the above for us, since we've done our job by overriding the Equals and GetHashCode methods of the key class.

The Results

Out of curiosity, I decided to export all of our sample reports to PDF and compare the results with and without caching. With image caching the output size fell by 45% which is sweet, but there is more. Often there is a tradeoff between speed and size. I expected the rendering speed to decrease since now I am doing checks in the image cache each time a new image arrives. But the speed increased by 4%. How can that be?

The explanation is simple. The cache checks are slowing the whole thing and there is no doubt about that. However, each time an image is streamed to PDF, some meta-data has to be read from it in order to determine color spaces, palletes, etc. The reading of this meta-data takes some amount of time. Now, since we have an image cache, meta-data extraction will happen only once for each image in the cache, unlike before when it occurred for every image, no matter whether it was redundant.

So in the end we have achieved a considerable size reduction topped with a slight speed increase. I have already checked-in these changes, so they should be available in the next release. Enjoy!

Hello People,

 

My name is Rossen Hristov and I am a developer at the Telerik Reporting team. This is my first post and in it I would like to share some good news with you -- Telerik Reporting Q2 2008 SP1 is now officially live. We have spent the last month or so making sure that most of the issues that you have reported have been addressed carefully. This Service Pack is by far the largest we have delivered in terms of issues fixed and I would like to thank you for the great feedback that you have provided during the past months.

The first thing that I would like to start with is the highly improved barcode rendering. My teammates and I have managed to make the barcode image quality much higher than before and reduce the memory footprint at the same time. On top of that the rendering speed has increased as well. I hope that those of you using our tool to print various barcodes will be pleasantly surprised. Any feedback on the barcode front will be highly appreciated.

Moving on, the next thing that underwent a major overhaul was the Visual Studio Report Designer. Some minor glitches in areas such as copy-pasting in Panels, global and external style-sheet application, and the In-Place Editor have been properly eliminated. Some aspects of code-behind serialization and the StyleBuilder have been improved as well.

There are improvements in the data binding and processing domain too. Many of you needed to use data fields in page sections which is now possible. To achieve greater flexibility the processing engine now allows modification of a processing TextBox's Value in various event handlers.

The WebViewer now automatically registers its HTTP Handler for IIS 7 which should be great news for those of you who like to use the latest technology. Also, adding the WebViewer to a page at design-time does not produce a parasite link tag anymore.

The different rendering engines were greatly improved to allow smooth and precise rendering. The HTML Rendering Engine now handles GroupKeepTogether correctly. Excel Export should not produce the notorious "Attempting to merge range..." message no more. The PDF Rendering Extension now displays transparent images without any problems and the RTF one can handle Padding.

There are so many more issues that were resolved, but a blog post is probably not the best place to mention them all, so I encourage all of you that use Telerik Reporting to check the full Release Notes for this Service Pack.

As for those of you that have not tried the product yet, I encourage you to download it and give it a spin. You will be pleasantly surprised by the functionality it offers.