The approach that you have suggested -- overriding GetPageHeight() -- is one of the simplest ways to do what you want. It is a little more complicated than you think, but it does work.

The other approach ("tweaking the HTMLListener code") doesn't actually make any sense. HTMLListener doesn't generate anything, and doesn't make any decisions about your HTML output. All it does is take the XML output of your report, which encapsulates everything that the report engine and base report listener ** as well as the FRX ** provide to the Xbase class, and apply XSLT to it. It is a thin subclass of XMLListener (or, to be exact, XMLDisplayListener), exploiting XMLListener's ability to do this and adding a default XSLT transform.

The way to do what you want is to change the XSLT transform. And there is no reason to change the class to do this, really. You can apply any XSLT transform you like, at runtime. This is all documented.

So, you can't "tell the HTMLListener not to generate things vertically". You just give it a different XSLT to support a different sort of output. And you can do this as many times, for as many different sorts of output out of one report, as you like.

The point of the default XSLT is just to get you as close to the original report (using all the information supplied to us from the output as the engine renders it) as we can get. Why doesn't it support a paged/unpaged mode? Simple: if there was supposed to be a default, it was supposed to be AS CLOSE TO THE ORIGINAL as possible, and also handle ALL REPORTS. The second item is critical. Many reports have actual *data* in their page headers and footers (especially when they use New Page On Group).

It would certainly be a nice enhancement to add a *second* default XSLT that would come into play if somebody turned a switch, but it would not be appropriate to all reports and it would also never be exactly perfect for all the reports for which it *was* appropriate.

Meanwhile... for your report, it's actually pretty trivial to provide a different XSLT for whatever type of output you prefer -- once you actually *know* what the report looks like and are writing the XSLT specifically for that report <s>. It doesn't have to look *anything* like the original output.

It's also relatively easy to provide a different, simple output that would handle *most* simple reports (but would fail pretty dramatically for overlaid objects, etc etc).

What is *impossible* is to provide a *generic* XSLT that will handle *all* reports and not use the information provided by the FRX and runtime rendering engine to decide how to lay them out.

I hope this gives you a bit of insight. I see a lot of misconceptions in this thread.

>L<