Thanks Lisa for your reply

But your reply found me mouthing the word "HOW" for almost everything. As usual the documentation from MS is sparse, does not explain HOW changes may be made and even the so called "Samples" for VFP9 are nothing but recompiled VFP 6,7 and & 8 Samples.

>Again, this is *sometimes* and *some browsers*. The HTML is still being tuned and this item might be changed by release. But if it isn't, it's a trivial change to make yourself.

HOW and where to make the change?

>A printable version would be a different XSLT of this XML,
Again HOW?

I will certainly have a look at the Graphical Output. Thanks for the pointer.

>You can also potentially use the default XSLT to provide printable output *if* you do two things:
>
> (a) override getPageHeight() and getPageWidth() to have a size slightly smaller than the default for any report.
>
> (b) limit the delivered browser content to a single page at a time. Do this using one of two mechanisms: use the RANGE clause on the original REPORT FORM command or send the XML out for the whole report, cache it on the server, and supply individual pages in response to a "printable page" button from the server.

How to override these?

Regards

Bernard

>Bernard (and Simon),
>
>[sorry it took me a while to see this message -- for anybody else with questions about this topic, I'm not on-line very frequently right now and may miss stuff]
>
>The reason you see the scrollbars has absolutely nothing to do with the fact that the content is a memofield.
>
>The default HTML presentation uses textboxes rather than straight spans for content that stretches in the report layout. It doesn't matter where the content comes from.
>
>There's a very simple reason for this: Linespacing in some browsers and rendering of some screen fonts is slightly different from the print version of the same fonts, used by the report rendering code to determine how much is going to fit on a page. As a result, without the ability to scroll (very slightly) some content at the bottom would be obscured by the next layout element down on the page.
>
>Again, this is *sometimes* and *some browsers*. The HTML is still being tuned and this item might be changed by release. But if it isn't, it's a trivial change to make yourself.
>
>I need to answer your larger question, about printing, before ending this message.
>
>But, before I do, one thing you should know: The default HTML uses the actual positioning (top, left, height, width values) from the report pages When it's positioning things. HTML doesn't have quite the same ability that FoxPro reports does to "stretch" and "float when object above stretches". You can position things relatively, but it's a bit different, and you'll run into problems with horizontal lines, etc.
>
>Now: you say you want your users to be able to print the default HTML out of the browser. That will almost never be appropriate. I believe the release notes are clear about this, and the docs will be as well.
>
>The aim of the default HTML is to match the original pages' layout as closely as possible, but given the way that (various) browsers actually format the pages, your pagination will not work quite as you want it to. You're now basically talking to a different page size than the report was originally rendered for, and with which the engine figured out how much was going to fit on a page.
>
>There are a number of possible solutions, but for printing purposes you will probably want to offer a "printable version" button. You have undoubtedly seen this kind of thing on web sites, and there is a good reason for it; this is not a problem unique to FoxPro or the default HTML <s>.
>
>A "printable version" of report content will have a number of differences from the default HTML. For one thing, it will allow the browser to "naturally" paginate rather than forcing items into a rigid vertical relationship based on the original placement of items on the printed page.
>
>Both versions have the same mechanism. The HTML you see in the default version is simply an XSLT translation of Visual FoxPro's Reporting XML. A printable version would be a different XSLT of this XML, and that XSLT (believe me <g>) should be a heckuva lot easier for you to write than the default/delivered transformation.
>
>As a completely different mechanism, you can supply a graphical format of any page in the report in response to a "printable page"request. Reference the OutputPage() method for some ideas. Such a page is an exact replica of the printed page, not an approximation. Of course, if your user has a different page size (or printable page size) than the printer for which you rendered the report on the server, it might still not fit properly on the user's end. (Some printer drivers allow you to scale to fit a page, some don't.)
>
>You can also potentially use the default XSLT to provide printable output *if* you do two things:
>
> (a) override getPageHeight() and getPageWidth() to have a size slightly smaller than the default for any report.
>
> (b) limit the delivered browser content to a single page at a time. Do this using one of two mechanisms: use the RANGE clause on the original REPORT FORM command or send the XML out for the whole report, cache it on the server, and supply individual pages in response to a "printable page" button from the server.
>
>HTH,
>
>>L<