The Case of the Extra Page: Rendering Reporting Services as PDF

March 18, 2011

I had to troubleshoot a problem with a mysterious extra page appearing in a PDF this week. My first thought was that it was likely to caused by one of the most common problems that people encounter when developing reports that eventually get rendered as PDF is getting blank pages inserted into the PDF document. The cause of the blank pages is usually related to sizing. You can learn more at Understanding Pagination in Reporting Services in Books Online.

When designing a report, you have to be really careful with the layout of items in the body. As you move items around, the body will expand to accommodate the space you’re using and you might eventually tighten everything back up again, but the body doesn’t automatically collapse. One of my favorite things to do in Reporting Services 2005 – which I dubbed the “vacu-pack” method – was to just erase the size property of the Body and let it auto-calculate the new size, squeezing out all the extra space. Alas, that method no longer works beginning with Reporting Services 2008. Even when you make sure the body size is as small as possible (with no unnecessary extra space along the top, bottom, left, or right side of the body), it’s important to calculate the body size plus header plus footer plus the margins and ensure that the calculated height and width do not exceed the report’s height and width (shown as the page in the illustration above). This won’t matter if users always render reports online, but they’ll get extra pages in a PDF document if the report’s height and width are smaller than the calculate space.

Beginning the Investigation

In the situation that I was troubleshooting, I checked the properties:

Item Property Value
Body Height 6.25in
Width 10.5in
Page Header Height 1in
Page Footer Height 0.25in
Report Left Margin 0.1in
Right Margin 0.1in
Top Margin 0.05in
Bottom Margin 0.05in
Page Size – Height 8.5in
Page Size – Width 11in

So I calculated the total width using Body Width + Left Margin + Right Margin and came up with a value of 10.7 inches. And then I calculated the total height using Body Height + Page Header Height + Page Footer Height + Top Margin + Bottom Margin and got 7.6 inches. Well, page sizing couldn’t be the reason for the extra page in my report because 10.7 inches is smaller than the report’s width of 11 inches and 7.6 inches is smaller than the report’s height of 8.5 inches. I had to look elsewhere to find the culprit.

Conducting the Third Degree

My next thought was to focus on the rendering size of the items in the report. I’ve adapted my problem to use the Adventure Works database. At the top of the report are two charts, and then below each chart is a rectangle that contains a table.

In the real-life scenario, there were some graphics present as a background for the tables which fit within the rectangles that were about 3 inches high so the visual space of the rectangles matched the visual space of the charts – also about 3 inches high. But there was also a huge amount of white space at the bottom of the page, and as I mentioned at the beginning of this post, a second page which was blank except for the footer that appeared at the bottom. Placing a textbox beneath the rectangles to see if they would appear on the first page resulted the textbox’s appearance on the second page. For some reason, the rectangles wanted a buffer zone beneath them. What’s going on?

Taking the Suspect into Custody

My next step was to see what was really going on with the rectangle. The graphic appeared to be correctly sized, but the behavior in the report indicated the rectangle was growing. So I added a border to the rectangle to see what it was doing.

When I added borders, I could see that the size of each rectangle was growing to accommodate the table it contains. The rectangle on the right is slightly larger than the one on the left because the table on the right contains an extra row. The rectangle is trying to preserve the whitespace that appears in the layout, as shown below.

Closing the Case

Now that I knew what the problem was, what could I do about it? Because of the graphic in the rectangle (not shown), I couldn’t eliminate the use of the rectangles and just show the tables. But fortunately, there is a report property that comes to the rescue: ConsumeContainerWhitespace (accessible only in the Properties window). I set the value of this property to True. Problem solved. Now the rectangles remain fixed at the configured size and don’t grow vertically to preserve the whitespace. Case closed.


8 Responses to “The Case of the Extra Page: Rendering Reporting Services as PDF”

  1. This is one of the most common questions that I get to see in the MSDN forums, and most of the time, I end up repeating the same stuff while answering (and that too, without pictures). Next time, I would just post a link to this article :)..

  2. Thanks, Jason!

  3. Ha, I created that margins graphic for the MSDN site while I was a PM on the SSRS team several years ago :)

    Glad to see that it is still useful!

  4. Well, this graphic was created by me in PowerPoint for use in my slide deck for SSRS classes, as a variation on a theme from the one in BOL at But it’s nice to know who created the original version!

  5. Can’t find report property ConsumeContainerWhitespace
    in SSRS 2005 (VS 2005)- any idea?
    Not in the properties window either…

  6. This property didn’t exist until SQL Server 2008. You’ll have to use the “vacu-pack” method that I mention in the post when using SQL Server 2005.

  7. I have read this and done everything i could to make it fit but then it add additional blank pages

    i have changed that property to true.

    I will admit i have a lot on the page but have page break between tablix, can you add additional pages


  8. Hi Sue, This can be difficult to diagnose. Something is making the page break. Sometimes you have to remove items and add them back one at a time to determine which is the item causing the break.

Leave a Reply