C has posted recently with the title of Amusing, and I suppose I might have titled this post Bitterly Amusing.

Some problems not only don’t go away, but they need to be solved again, apparently, yea verily, in every technical generation.

When you generate output for a report, no matter where you’re doing it, you have format and content, just as you do in any publishing context.  This should come as no surprise to anybody reading. When you generate output that is supposed to be laid out in a fixed-page (read: printable) manner, you have to have some idea of the target page before you can apply format to content.  This, too, should not be a shock to read.

As it happens, both VFP and Reporting Services give you only one shot at declaring a page layout per report, and people constantly ask to surmount this limitation. They usually want to address different paper bins for different pages of the report or have different orientations for different pages. They sometimes want different page sizes as well.  Why can’t they do that out-of-the-box, and how can it be done?

In both environments, I think the source of this expectation (besides the very natural real-life requirements it represents) is the same: word processing applications. I’ve already written about this in the conclusion to an article I’ve just posted, so I’ll quote myself here. If you’re an RS person, just substitute “RDL” for “FRX” below:

Think of each FRX layout as a document section, similar to a Word document’s sections. Not coincidentally, Word allows you to associate a layout and print instructions with each section; Word’s “first page – other pages” facility is merely a special case within this feature.

Reports have only one printjob associated with them, even if it’s a theoretical one because you’re not printing. Reports have only one page layout each, and should be thought of as sections, not documents, if you need more sets of instructions.

In both environments, the resolution is the same, also: ask the report to render itself as EMFs, not to the printer. Then, if all you need is different orientation or paper bin, just send the appropriate instructions between the appropriate pages.

My Print Job to Call Your Own article explains how to do this in VFP, and it is considerably easier to do in .NET for you RS folks.  There is a sample of printing from a console application on http://gotreportviewer.com/ that gives you the code for rendering the EMFs, so start there.

In both environments, if you need different page sizes, use separate reports for each, so the processing engine has what it needs to define each distinct layout.  You can still bring the output EMFs together in a single print job, or display them in a single ordered view in a “preview application” — which only has to display EMFs.

If you’re going to a printer, you still issue the printing instructions on cue (or should that be enqueue?) as you blow through the full page set. If you’re going to screen, you probably need to adjust the aspect ratio of the image container appropriately for each “section”.

The article and my VFP PrintJobListener code go into some detail on the potential scaling issues for those of you doing this in VFP.  These issues are not addressed in the http://gotreportviewer.com/ sample, if I remember correctly, because neither it nor the related PrinterDelivery Sample for MS SQL Server handle page sizes very well at all.  It’s still exactly the same the same problem to solve, and you’ll solve it using some variation of the same weird math.

And once you’ve solved it, you’ll realize exactly the same bonus capabilities in both environments — such as now, how would you print two-up or four-up?  Gee, I wonder…