InfoPath Dev

I am working on a pretty complex SharePoint/InfoPath system for a client in the millwork supply business. The ability to print the form views is important to him. He wants nicely formatted pages, but his data often is displayed in very wide tables that can also run for many printed pages. Well-formatted printing (esp. page breaks across embedded tables) has been next to impossible due to InfoPath's reliance upon the IE printing engine (e.g., no support for page-break-inside).

So I've been thinking I should use Excel for printing. I figured I could use XML maps and templates to come up with a nifty solution. So I turned to my dog-eared copy of Jeff Webb's outstanding *Excel 2003 Programming* and was reminded that Excel does not support recursion more than 1-level deep. My template's main data source unfortunately contains recursion through 2-3 levels.

Does this mean that my only option -- if I want to use Excel -- is to use, say, VB.NET codebehind for my template, so that when the user switches to a Print view, the code iterates through the main data source nodes and writes them to an Excel template? In other words, traditional prorgrammatic worksheet creation without the use of XML maps? Does anyone have any other ideas for this printing conundrum? I hope InfoPath 12 has good built-in printing support.

Patrick Barnes

I was able to make contact with Jeff Webb, author of *Excel 2003: A Developer's Notebook* (which includes some great stuff on InfoPath). I summarize his comments here for the benefit of others who might later see this thread and have a similar challenge to mine.

Basically, he didn't think using code to populate a templated XML-mapped Excel spreadsheet just so that I could use Excel's printing features was a good way to go. It might be fine if I could use XML maps in a straightforward manner, but that only works for fairly simple scenarios.

He said I should seriously consider XSL-FO. I had considered this before, but when I found out InfoPath templates have no native support for XSL-FO (i.e., in the view XSL files) I decided against it, failing to consider an external transformation of the InfoPath form data.

Many people aren't that comfortable with writing XSL, but fortunately there are some really good tools on the market for creating the XSL-FO files. Altova.com offers StyleVision, though you have to buy the Enterprise Edition to get FO support, and it's pricey. Jeff also recommended products at ComponentOne.com, specifically Reports for .NET. This is much less expensive and also offers a WYSIWYG UI for creating XSL.

In summary, he wrote:

"You mentioned Altova -- their tools are great. If you're doing a lot of XML I recommend them highly. This would be my favored approach because the transform is the most flexible and I'm comfortable with XSL. If I really wanted to get fancy, I'd output the result as an Excel XML file not linked to the data. Then the user can decide what they want to print, reformat, etc.

"The advantage of the Component One tools is that they hide the transformation (they are XML-based, but their tools are click and drag). The learning curve is less steep, but you need to write some .NET code. You can also output Excel files from here.

"Those two choices are the best tools in the arena for your job, I guess I'd choose one based on what type of work I forsee for the future (how much XML/XSL do you want to learn)."

I hope this helps someone else out there.

Patrick

Check out the new XSL debugger in Visual Studio 2005. I hear it rocks!

Patrick Halstead [InfoPath MVP]
InfoPathDev

Thanks for the tip, Patrick. BTW, after experimenting with all of the possible printing options I settled on ExcelML. It wasn't too difficult to create an XML-to-Excel XSL file for the various InfoPath views.

I used .NET code for the transform and it works great! The user just clicks a button from an InfoPath "Print Manager" view and the data opens up in Excel, all nicely formatted and ready for printing.

I don't know much about InfoPath 12, but it seems to me that it shouldn't be too difficult to include a "Convert InfoPath View to ExcelML Transform Wizard" (and WordML, for that matter).

This is very cool. Can you send me some screenshots?

Patrick Halstead [InfoPath MVP]
InfoPathDev