Printing List Items

Why someone would need to “Print” from SharePoint is a little confusing. SharePoint is your new logical filing cabinet, fully virtualized with meta-tags. Just like you undoubtedly have dozens of colleagues begging you “not to print this email to help save the environment,” you can bet that some of your business processes still depend on or demand a printed sheet.

But printing from SharePoint, out-of-the-box, is very limited. You’re stuck with either browser printing or the inevitable “screen shot and crop” method of narrowing down content to one, clean page.

I google-found one suitable solution from Ishai Sagi to print out lists: http://www.sharepoint-tips.com/2007/01/how-to-add-print-list-option-to-list.html

After some more googling I found a decent solution from Vincent Rothwell: http://blog.thekid.me.uk/archive/2007/07/22/easily-print-sharepoint-lists-using-your-own-template.aspx

I went ahead and installed Rothwell's solution on a SharePoint team site that I knew people would want to get print-outs from. It was an out-of-the-box "Call Center" site template to track trouble tickets for our help desk operation. The solution contains javascript, images and XSLT files to manage the display of XML-based list data to the print engine.

It's an impressive solution, and I was able to extend the functionality with a few tricks.

First off, it will print an itemized list based on the fields displayed in your list view. This required me to create new list views just for printing. Some views had too many columns, others did not have enough. In our usage, we will be printing out individual items much more than a filtered list of items. The "item" print function gets its fields from the display view as well, so, for really extending the single item print process, I had to create a a list view showing all the fields available.

Rothwell's item print layout basically spits out an HTML table with ugly field names and field values that needed to be cleaned up. For instance, many field values were be returned with "nn;#" at the beginning. Values with this prefixed garbage needed to transformed with an XSLT, aka an XML Style-Sheet Transform. Here's an example, hacked from Rothwell's "common.xsl" file:

<xsl:template match="@*[name() = 'ows_Author' or name() = 'ows_Editor' ]">
<xsl:value-of select="substring-after(., ';#')" />
</xsl:template>

What it's saying is, "Hey, if you find these fields, and you property refer them to this template, spit out the value after the ',#' garbage..." It worked like a charm.

(By the way, the ows_Author is the "Created By" field and ows_Editor is the "Modified By" field)

I struggled for a bit trying to massage the field values by editing the "common.xsl" file, which is a shared file that handles the data templates for matching field names. I couldn't seem to definitively come up with a precise field list, both in terms of field names and fields that I could display. I installed Fiddler to check out the XML data presented in a list view. From Fiddler I was able to determine field names from the "z:row" XML data.

The "Call Center" service request data type contains a field called "Comments" that gets appended to each time you save an item. SharePoint displays this data as it should. Each comment has a time stamp and a user name and is presented as it should be over the WWW. The field type was "Multiple Line" with the "Append Changes to Existing Text" bit turned on.

I wanted all the comments on my item print sheet, but SharePoint was uncooperative. The XML data it spit out for that field returned only the last comment without a proper time stamp or user associated with the comment. Since the print out data is based on list view data, I changed one of my "view" aspx pages, which was just an XML markup web part to an XSLT data view web part.

I was able to get the list view data from the Comments field to show all appended changes, but I wasn't able to manipulate this data via my item print XSLT.

I might get there someday... Or I may just accept defeat.