Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Create a Printer Friendly Page in Your SharePoint Sites This tip describes a strategy and some techniques that you can leverage to create an appropriate “print this page” function. This short tip describes a strategy and some techniques that you can leverage to create an appropriate “print this page” function in your publishing pages. This is both a strategy and technique. The strategy describes some the approach you should take in design. The technique shows how JavaScript embedded in a SharePoint page layout (or master page) can generate a printer-friendly page suitable for printing on paper.
Of course, anyone can print a page. This article is describing an appropriateprint function. By appropriate we mean that the page won’t include the top banner, the “My Site” link, the left hand navigation or master page footer – any of the chrome on the page. Instead, we want a smart print function that prints out the real meat of the page and only the meat. Follow these steps to see this in action:
- 1. Access this page:
http://cdi-its.com/Pages/Quality_Management.aspx
- 2. Scroll to the bottom
- 3. Click “PRINT” to see the demonstration.
Technique
The technique leverages JavaScript. The JavaScript performs these tasks:
- 1. Obtain the current page’s <title>.
2. Open a new browser window.
3. Write the printable content to the window.
The following JavaScript shows how it’s done:
script type="text/javascript"> function Clickheretoprint()
{ var disp_setting = "toolbar=yes,location=no,directories=yes,menubar=yes,";
disp_setting += "scrollbars=yes,width=650, height=600, left=100,
top=25";
var pgTitle = document.title;
pgLogo = document.getElementById('GlobalTitleAreaImage').innerHTML;
pgLogo += '<h3>' + pgTitle.substr(pgTitle.indexOf('-') + 1) + '</h3><br>';
pgTitleFrame = document.getElementById
('onetidPageTitleAreaTable').innerHTML;
content_vlue = document.getElementById("PrintContent").innerHTML;
var docprint = window.open("", "", disp_setting);
docprint.document.open(); docprint.document.write
('<html><he' + 'ad>');
docprint.document.write('<link
rel="stylesheet" type="text/css" href="/_layouts/1033/styles/cdi_internet.css"/>
<link rel="stylesheet" type="text/css" href="/_layouts/1033/styles/core.css" />');
docprint.document.write('<title>' + pgTitle + '</title>');
docprint.document.write
('</he' + 'ad><bo' + 'dy onLoad="self.print()"><left>');
docprint.document.write(pgLogo); docprint.
document.write(pgTitleFrame); docprint.document.write(content_vlue);
docprint.
document.write('</left></body></html>'); docprint.document.close();
docprint.
focus(); } </script>
The script is easy enough to follow. Consider this line:
content_vlue = document.getElementById("PrintContent").innerHTML;
This line retrieves the actual printable content from a div named “PrintContent”. This shows a key design point: the printable content area has to be wrapped into at least one identifiable div tag. If you don’t have that, you need to add it. This is discussed in greater detail in the Strategy section below. Closing out the technique discussion, make a note of the following:
docprint.document.write('</he' + 'ad><bo' + 'dy onLoad="self.print()"><left>');
You should take away two points from that snippet:
- 1. You need to physically split up the <head> and <body> tags via the document.write() method. SharePoint designer looks for those physical tokens and when it finds them, emits some additional HTML. This HTML will break your JavaScript. We avoid SharePoint Designer’s “help” in this case by breaking up the head and body tags.
2. Our JavaScript is actually emiting JavaScript with the onLoad() event. All it does is issue a “self.print()” when the form opens, which launches the client’s default printer dialog.
Strategy
Now that you know the specific technique, the trick is to use it properly. You need to figure out a way to uniquely identify the printable content. There are two broad scenarios to consider:
- 1. Green field (no master page or page layouts have been created).
2. You already have a web site and you want to retroactively add the print function.
Green Field Approach
As with many SharePoint requirements, it’s far, far easier to meet them if you anticipate and plan for them in advance. The green field approach starts with the master page and/or page layouts. More than likely, you’ll focus on page layouts because printing is usually situational. You don’t want a printer friendly version of *every* page. The home page, for instance, often contains flashy graphics, image carousels, maybe some video – none of that is well suited to printing. However, your site visitors will probably want to print content from secondary and tertiary internal pages (such as product descriptions). You would normally modify the page layouts themselves rather than the master page to provide a print function appropriate to that page layout.
In a green field scenario, you haven’t actually created any page layouts, so now is the time to decide on a case by case basis, where will the printable content reside? Will there be a single monolithic HTML text field for the entire body of text? Will there be several, scattered across the page? Consider the site visitor’s expectation of printable content and plan accordingly. Once you’ve figured this out, wrap the printable content into one or more named DIVtags and add the print function to the page layout.
Retroactive
This may be a much harder nut to crack and there may not be an easy solution. The challenge here is that no one would have had printer friendly content in mind when they created the page in the first place. This presents a technical problem and a content problem.
The technical problem is fairly straight-forward. Review the page layouts upon which the site is built and look for opportunities to incorporate the print capability. Add the JavaScript as described above, put in a link and you’re done.
The content problem is more difficult and may require a significant amount of refactoring. Since authors didn’t have or plan for printing in advance, they need to ensure that the print function produces an appropriate result once it’s been rolled into the page layouts. They must then review the output on a page by page basis and correct any problems.
The retroactive scenario is difficult, like any refactoring effort, but it’s solvable.
Conclusion
Since man first saw an HTML page, he wanted to create a printable version of it. The approach outlined in this article leverages JavaScript that:
- * Opens a new browser window.
- * Locates and copies appropriate content to the window.
- * Configures the window to open the default client print dialog.
Like all things, this is more challenging to implement in a live web site, but SharePoint’s content management functionality via page layouts makes this easier than most refactoring efforts.
Happy printing!
