how to format xml/xls web report for specific paper size and orientation?"

[bcanavan]

When I export xml(and xls) from Access 2003 the result is a complete
report in a single page. I would like to get the entire report in a
single page (one trip to the server) for printing and
scrolling-preview, but with page breaks and page numbering appropriate
to the paper size.

I have a sense that this can be done in xsl, since xsl defines the
format for everything else in the report. My goal is to avoid the time
and expense of rebuilding these reports in VS or Crystal, or even using
a less expensive third-party product to generate, say, pdf's on the
fly. All I want is an asp or html document that's formatted for
printing like a normal printed report. Shouldn't Access and .NET be
enough? Why can't Access' ExportXML method handle this, or can it???

Any thoughts would be greatly appreciated.

Bob

[Ananda Sim]

Hmm, interesting thread you've started. I work with classic Access and
classic Access objects as that's the common deliverable to my clients so
was interested in your original posting and this one.

I took Access 2003 -> xml for a drive just now and made some mental notes.

bc******@bmghomes.com wrote:

When I export xml(and xls) from Access 2003 the result is a complete
report in a single page. I would like to get the entire report in a
single page (one trip to the server) for printing and
scrolling-preview, but with page breaks and page numbering appropriate
to the paper size.
Several issues here. I just outputted Northwind's Invoice report to XML
and saw megabyte files - 2Mb of .xml etc.. being output. This looks like
the box and dice from the Invoice table.

1. This is a lot to send out in one chunk to a web browser. Any
professional service would have sent it out as several pages. If it has
to be that size, Acrobat format is generally understood and acceptable.
A single webpage isn't

2. Classic webpages just "don't" break naturally in paper page sizes.
This is not something a webpage understands. Even screenfuls are not
understood by webpage technology because one often can only assume that
the browser is currently 800x600 or 1024x768 pixels per screen.

CSS2 - http://www.w3schools.com/css/css_ref_print.asp
implements the paper page concept - but then you have to make sure that
the recipient's web browser implements CSS2.
printing like a normal printed report. Shouldn't Access and .NET be
enough? Why can't Access' ExportXML method handle this, or can it???

Access as a desktop database manager, could be extended simply by
providing a whole raft of pre-programmed XSL formats, server side
"templates" with server side processing which allow paging by the
screenful, CSS2 layouts etc...

From what I just tested of Access 2003, it's early days - supplying
less than a handful of files (or a default template via ExportXML) in

%program files%\Microsoft Office\OFFICE\AccessWeb\

is not really a teaser rather than anything serious.

I guess the Access team has to decide where Access ends and other
reporting products like SQL Server Report Builder:

http://www.developer.com/db/article.php/3520116

begin. Or whether the two teams are in competition. Or whether they can
borrow each other's tools.

..NET isn't in the picture - it isn't even a tool - it's a programming
framework - you build tools with it.

HTH

[bcanavan]

Thanks, Ananda!

The more I read the more I suspect that XSL-FO can specify paper-size
and put page breaks in a single web page built from xml and xslt. (The
trick is finding documentation on FO, but I'm working on that too.)
Yes, you get all the report's "pages" in a single asp or html page, but
the pages break and number correctly for printing. Our reports will
typically not be so large as to make the page excessively large or slow
to download. In fact, they would be no larger than pages containing
search results at Google, even with the additional tags used for
layout. We no longer run reams of report output, and if we ever had to
they would be run in the office where our web servers and db servers
live -- no bandwidth issues.

SQL Server Reporting Services is my favorite option IF I can't do it
more simply. My goal is to avoid rebuilding a large number of reports
from scratch, and I feel like I'm almost there.

CSS is certainly an option, but I prefer to stick with XSL until my
theory is proven wrong. CSS would, again, involve too much work to
format so many reports.

I never considered screen resolution as an issue. It would only bear
on previewing in the browser, not on printing.

..NET is definitely in the picture but, as you say, the Access and .NET
teams probably need to spend more time together. You may not be aware
that the .net report class does indeed support paper size, and
overrides the page class to do exactly what I'm after. But, it
astounds me that every example I've seen using the Access ExportXML
method uses vbscript, and the method itself can only generate an asp
(or html) page -- not an aspx! In fact, you can easily make the report
dynamic with a little bit of code, but even that has to be done with
vbscript! I thought that by the time Access 2003 appeared we'd be
standardizing on vb, or at least exporting Access objects to
..net-compatible objects for web use, leaving vba out of the process.

I frankly don't care where Microsoft draws the line between Access and
other reporting products, but if Access is capable of exporting a
report to asp+xml+xsl, then it should do the whole job and support the
paper size/orientation as well.

Thanks for your reply. I'm going to continue my quest.

Bob

[Ananda Sim]

bc******@bmghomes.com wrote:

Thanks, Ananda!
No probs.

The more I read the more I suspect that XSL-FO can specify paper-size
and put page breaks in a single web page built from xml and xslt. (The
trick is finding documentation on FO, but I'm working on that too.)
XML topics are very well documented (sometimes in very formal language)
- XML is a w3c initiative and non proprietary. Here's my jump off
webpage on XSLT and XSL-FO

http://accesscoach.wikispaces.org/XSLT+Topics

XSL-FO is an intermediate formatting vocabulary - it is not an end in
itself.

XML data -> XSLT transformation instructions -> text based output

output can be

XHTML final document
XSL-FO intermediate document
etc...

XSL-FO -> XSL-FO processor -> final output

final output can be

PDF
RTF
etc...
Yes, you get all the report's "pages" in a single asp or html page, but
the pages break and number correctly for printing. Our reports will
What kinda HTML source is it outputting? I am not aware of any HTML code
that says "page break here".

http://www.htmlhelp.com/reference/html40/
CSS is certainly an option, but I prefer to stick with XSL until my
theory is proven wrong. CSS would, again, involve too much work to
format so many reports.
CSS is not a thing you do. CSS can be an external stylesheet that is
referenced by each HTML document output and defines styles for
everything (like Word's Heading 1, 2, 3, Normal Style)

I never considered screen resolution as an issue. It would only bear
on previewing in the browser, not on printing.
Try making a plain HTML document with a lot of text with no spaces in a
long line and fixed width tables. Then view it in your browser - it will
not view without scrolling. Now try printing it. It will be cut off.

.NET is definitely in the picture but, as you say, the Access and .NET
teams probably need to spend more time together. You may not be aware
It makes things clearer if we use relevant terms. .NET is a programming
library. Visual Studio is a development tool that has lots of facilities
and features. You use Visual Studio to create a program which relies on
the .NET library. I assume you're talking about the Visual Studio team
or the SQL Server team.
that the .net report class does indeed support paper size, and
overrides the page class to do exactly what I'm after. But, it
I'm not familiar with that. Are you talking of the Visual Studio
facility which has a report designer? If you are, that's a VS thing, not
a .NET thing.
astounds me that every example I've seen using the Access ExportXML
method uses vbscript, and the method itself can only generate an asp
(or html) page -- not an aspx! In fact, you can easily make the report
dynamic with a little bit of code, but even that has to be done with
vbscript! I thought that by the time Access 2003 appeared we'd be
standardizing on vb, or at least exporting Access objects to
.net-compatible objects for web use, leaving vba out of the process.

Not a lot of Office 11/2003 is .NET aware. There are considerable moves
in Office 12 apparently to make a good show, but Office 11/2003 .NET
exposure was through products like Visual Studio Tools for Office, a few
token XML output formats.

HTH

[bcanavan]

Thanks again, Ananda!

By "page break" I'm refering to xsl's recognition of where the page
break would occur for a particular paper size, and then formatting the
resulting page with page-breaking <br>'s and report page footers
accordingly, including page numbers for printing.

I know this can be done in xsl; I'm just trying to get a handle on the
syntax that makes it work. VS is a powerful tool (I'm trained in it,
and I've used it) but, again, I'm hoping to avoid having to rebuild
reports that Access can export as xml. The xsl format oject can do the
job, I just need to figure out how.

CSS is wonderful (I use lots of it) but it is, again, something that
doesn't just happen. Styles have to be created. Since the
automatically generated xsl already contains the styles I need, I'd
prefer to avoid the work of replacing it.

I'm not refering to VS in suggesting that the two teams work this out,
but Access. Since Access creates a ReportML with page setup properties
in it when exporting a report to xml , I would expect that the xsl it
generates would (at least optionally) account for things like paper
size. But it doesn't, and I see no reason why that couldn't have been
addressed in Access' xsl generator.

I appreciate your time and thoughts very much. Thanks again.

Bob

[Ananda Sim]

bc******@bmghomes.com wrote:

Thanks again, Ananda!
Fascinating discussion Bob.

By "page break" I'm refering to xsl's recognition of where the page
break would occur for a particular paper size, and then formatting the
resulting page with page-breaking <br>'s and report page footers
accordingly, including page numbers for printing. but Access. Since Access creates a ReportML with page setup properties
in it when exporting a report to xml , I would expect that the xsl it
generates would (at least optionally) account for things like paper
size. But it doesn't, and I see no reason why that couldn't have been
addressed in Access' xsl generator.

So you're taking the approach of counting lines? Rather like we would do
in Quick Basic outputting to non graphic 66 line perforated paper on an
Epson FX-80 printer? How do you handle current generation proportional
fonts with different font heights, graphic logo inserts, the odd
horizontal line and automatic wrap around in <table> tags?

Are you sending everything out in Courier 10?

Or, on reflection (my own, not .NET's <grin>) you are hoping to go

Access Report -> XSL-FO document -> XSL-FO renderer + XHTML / CSS
formatting engine -> formatted XHTML for screen and print layouts.

<Jaw drops open in amazement>

I know this can be done in xsl; I'm just trying to get a handle on the
syntax that makes it work. VS is a powerful tool (I'm trained in it,
http://www.w3schools.com/xsl/default.asp

has lots of tutorials and syntax demoes in XSLT and XSL-FO.

also

<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnacc2k2/html/odc_acc2xslt.asp>

and I've used it) but, again, I'm hoping to avoid having to rebuild
reports that Access can export as xml. The xsl format oject can do the
job, I just need to figure out how.

I think that's the practical key point. Access 2003 generates ReportML
data, not xsl-fo formatting page markup.

Ananda