One of the things I see people getting confused about in Reporting Services is around page sizing. Not setting the correct properties can result in extra blank pages or improper paper orientation. Here are some general guidelines for setting page sizes.

The rules around page sizing depend on whether you are talking about physical pagination (used by the print control and the TIFF and PDF rendering extensions) or logical pagination (used by the HTML and GDI rendering extensions).

For rendering formats that render physical pages, set the PageHeight and PageWidth properties for the report to control the pagination. These can be set in the Report Properties dialog (available under the Report menu) along with LeftMargin, RightMargin, BottomMargin, and TopMargin.

One thing that is important to know is that setting the Body size at design time is not generally useful in controlling pagination. The body is simply the container for the collection of objects on the report. The design time size of the body represents the smallest amount of space that will be taken up by the report. However, if any objects grow as they are filled with data, the body will expand to contain them. Mostly, the body will grow taller (tables, lists, and textboxes are a few of the items that will cause vertical growth) but can also grow wider (matrices and autosized images can cause horizontal growth).

So, when does a physical page break occur? When the runtime size of the body (plus the page header and footer size, if they are defined) exceeds the specified page size (minus the margins). It's important to understand that controls on the page that don't look like they contain any information (a wide textbox) can cause a blank page to be added to the report if it exceeds the page boundaries. Page breaks can also be specified explicitly before or after instances of report items (rectangles, groups, data regions). There are also certain situations were we ignore explicit page breaks (e.g. inside subreports).

So what defines a portrait vs. landscape report? If the PageHeight is less than the PageWidth, then it is landscape, otherwise it is portrait. It is important to understand that Reporting Services has no notion of the rotation of the paper in the printer. It is up to the applications that consume the output (Acrobat reader, print control) to determine the correct printer settings to best render the specified page size.

Note that the DeviceInfo settings can be used at report rendering time to override the page sizes in the definition. This is how the client print control works when you change margins or page size. In SP2 and SQL 2005 Reporting Services, the default page sizes are extracted from the definition at publish time and written to the ReportServer database as custom properties on the report. While you can programmatically change these via the SetProperties method on the web service, they will be overwritten if the report is republished (unlike parameter and datasource information).

Logical pagination is a little bit different. In SQL 2000 Reporting Services, interactive rendering formats used the same PageHeight property to determine page breaks. Since there is no real page boundaries on web pages, it is only used as a guidelines to reduce the amount of data to put on a single page. SQL 2005 Reporting Services introduces the InteractiveHeight and InteractiveWidth properties to determine logical page breaks. Actually, InteractiveWidth is not used at all but may be in a future release. The nice thing about this is that if you don't want pagination in the web at all, you can set InteractiveHeight to 0 and the processing engine will produce your report as a single logical page.

The Excel rendering format does not explictly support pagination. The page size and margins are mapped into the Excel document for printing within Excel. For these reports, you will need to specifically include page breaks to break the report into multiple worksheets.